[Letux-kernel] [PATCH pre-upstream RFC] ARM: dts: omap3-gta04: add pulldown/up settings for twl4030 gpio

H. Nikolaus Schaller hns at goldelico.com
Mon Sep 24 11:49:20 CEST 2018

Hi Andreas,

> Am 23.09.2018 um 21:42 schrieb Andreas Kemnade <andreas at kemnade.info>:
> Pullup and down settings were missing, so add them to avoid
> floating pins.
> Signed-off-by: Andreas Kemnade <andreas at kemnade.info>
> ---
> arch/arm/boot/dts/omap3-gta04.dtsi | 11 +++++++++++
> 1 file changed, 11 insertions(+)
> diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi b/arch/arm/boot/dts/omap3-gta04.dtsi
> index 09e45e7ad4bc..3adeb56dee37 100644
> --- a/arch/arm/boot/dts/omap3-gta04.dtsi
> +++ b/arch/arm/boot/dts/omap3-gta04.dtsi
> @@ -657,6 +657,17 @@
> 	status = "disabled";
> };
> +&twl_gpio {
> +	/* pullups: BIT(2) */
> +	ti,pullups = <0x000004>;

Maybe, is there a BIT() macro in DTS?
We certainly can use ( | ) to combine several bits.

If we could, it could read like

	ti,pullups = < (BIT(2)) >;

> +	/*
> +	 * pulldowns:
> +	 * BIT(0),  BIT(6), BIT(7), BIT(8), BIT(13)
> +	 * BIT(15), BIT(16), BIT(17)
> +	 */
> +	ti,pulldowns = <0x03a1c1>;

	ti,pulldowns = < (BIT(0) | BIT(6) | BIT(7) | BIT(8) | BIT(13)
			 | BIT(15) | BIT(16) | BIT(17)) >;

> +};
> +
> &twl_keypad {
> 	status = "disabled";
> };
> -- 
> 2.11.0

Since there isn't any BIT() macro in include/dt-bindings we can
define our own just before &twl_gpio (until DT maintainers complain):

#define BIT(nr)			(1 << (nr))

Regarding the bit numbers, I have checked with Table 2-1 and schematics:

P12	gpio0/cd1
N12	gpio1/cd2
L4	gpio2
P13	gpio15
M4	gpio6/pwm0
N14	gpio7/vibra/pwm1
D8	gpio8/uart1.rxd
L14	stp/gpio9
L13	dir/gpio10
M13	nxt/gpio11
J13	data3/uart4.ctso/gpio12
G14	data4/gpio14
G13	data5/gpio3
F14	data6/gpio4
F13	data7/gpio5
G11	gpio13/ledsync
C3	gpio16/bt.pcm.vdr/dig.mic.clk0
C5	gpio17/bt.pcm.vdx/dig.mic.clk1

Table 2.2 describes the signals and it appears that they are explicitly
allowed to be floating if unused, because they have internal pull-downs
active after reset.

A big problem with these tables is that they seem to have typos
and mix gpio6/16 and gpio7/17.

Anyways it seems to be useful to explicitly setup pullup/down.

Next, there is this note in the register description:
"By default, pulldowns are enabled to avoid leakage when the GPIOs are not connected externally. Therefore, because GPIO3 is muxed with the DATA5 pin of USB ULPI and this functionality is the default, the default for this GPIO is not pullup- and pulldown-enabled."

So this is different from OMAP3 - the pullup/down is not at the BGA pad
but part of the gpio. So if a pin is NOT in gpio mode the PU/PD is a don't care...

Looking into schematics:
gpio3 - 5 and 9 - 12, 14 are used by the ULPI-PHY and they are not in gpio mode.
gpio0 and 1 are connected to the jtag chain
gpio2 is our jack detect (on gta04a5 only, unconnected on a3/a4 boards)
gpio6 is an (optional) modem reset state detector
gpio7 and 15 are spare and not connected
gpio8 is not connected
gpio13 is not connected
gpio16, 17 are used for bluetooth PCM

So only gpio0-2, 6-8, 13, 15 are basically relevant (or do we switch any other pin to GPIO mode?).
I think that initializing the sound system will switch the gpio16/17 to bluetooth PCM mode
and gpio PD/PU becomes irrelevant.

So I'd say:

gpio0,1		PD
gpio2		PU
gpio3-5		don't care
gpio6		PD (unless we want to detect RESET_OUT = modem state)
gpio7		PD
gpio8		PD
gpio9-12,14	don't care
gpio13		PD
gpio15		PD
gpio16-17	PD

Now let's compare with default register values (GPIOPUPDCTRx)...

Here we have the next deviation between data sheets...
gpio0-3 are said to have neither PU nor PD enabled after reset of the chip...

Therefore it is a good idea to set them explicitly...

Now for the bits I'd say:

ti,pullup = < (BIT(2)) >;
ti,pulldown = < (BIT(0) | BIT(1) | BIT(6) | BIT(7) | BIT(8) | BIT(13) | BIT(15) | BIT(16) | BIT(17)) >;

Fortunately, this is almost (except BIT(1)) the same as you propose :)
I.e. looks good.


> _______________________________________________
> http://projects.goldelico.com/p/gta04-kernel/
> Letux-kernel mailing list
> Letux-kernel at openphoenux.org
> http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel

More information about the Letux-kernel mailing list