Set them to the state seen in a running system, initialized
by vendor u-boot or kernel. Add line names where they are defined in the
vendor kernel.
gpio15 resets something in the display, otherwise meaning of the
gpios is not known.
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
---
.../boot/dts/ti/omap/omap4-epson-embt2ws.dts | 92 +++++++++++++++++++
1 file changed, 92 insertions(+)
diff --git a/arch/arm/boot/dts/ti/omap/omap4-epson-embt2ws.dts b/arch/arm/boot/dts/ti/omap/omap4-epson-embt2ws.dts
index 7684868a2eed..983a21d95db3 100644
--- a/arch/arm/boot/dts/ti/omap/omap4-epson-embt2ws.dts
+++ b/arch/arm/boot/dts/ti/omap/omap4-epson-embt2ws.dts
@@ -115,6 +115,73 @@ wl12xx_vmmc: wl12xx-vmmc {
};
};
+&gpio1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&gpio1_hog_pins &gpio1wk_hog_pins>;
+
+ lb-reset-hog {
+ gpio-hog;
+ gpios = <9 GPIO_ACTIVE_HIGH>;
+ output-low;
+ line-name = "lb_reset";
+ };
+
+ power-en-hog {
+ gpio-hog;
+ gpios = <10 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "power_en";
+ };
+
+ /*
+ * Name taken from vendor kernel but no evidence of actual usage found
+ * nor what it really controls.
+ */
+ panel-power-en-hog {
+ gpio-hog;
+ gpios = <14 GPIO_ACTIVE_HIGH>;
+ output-low;
+ line-name = "panel_power_en";
+ };
+
+ /*
+ * These two are exported to sysfs in vendor kernel, usage unknown,
+ * backlight state seems unrelated to these.
+ */
+ blc-r-hog {
+ gpio-hog;
+ gpios = <17 GPIO_ACTIVE_HIGH>;
+ output-low;
+ line-name = "blc_r";
+ };
+
+ blc-l-hog {
+ gpio-hog;
+ gpios = <16 GPIO_ACTIVE_HIGH>;
+ output-low;
+ line-name = "blc_l";
+ };
+
+ high-hog {
+ gpio-hog;
+ gpios = <15 GPIO_ACTIVE_HIGH /* maybe dsi to dpi chip reset? */
+ 21 GPIO_ACTIVE_HIGH
+ 26 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "unknown-high";
+ };
+
+ low-hog {
+ gpio-hog;
+ gpios = <18 GPIO_ACTIVE_HIGH
+ 19 GPIO_ACTIVE_HIGH
+ 20 GPIO_ACTIVE_HIGH
+ 22 GPIO_ACTIVE_HIGH>;
+ output-low;
+ line-name = "unknown-low";
+ };
+};
+
&i2c1 {
pinctrl-names = "default";
pinctrl-0 = <&i2c1_pins>;
@@ -406,6 +473,22 @@ OMAP4_IOPAD(0x56, PIN_INPUT_PULLUP | MUX_MODE3) /* gpio35 */
>;
};
+ gpio1_hog_pins: pinmux-gpio1-hog-pins {
+ pinctrl-single,pins = <
+ OMAP4_IOPAD(0x1b4, PIN_OUTPUT | MUX_MODE3) /* gpio14 */
+ OMAP4_IOPAD(0x1b8, PIN_OUTPUT | MUX_MODE3) /* gpio16 */
+ OMAP4_IOPAD(0x1ba, PIN_OUTPUT | MUX_MODE3) /* gpio17 */
+
+ OMAP4_IOPAD(0x1b6, PIN_OUTPUT | MUX_MODE3) /* gpio15 */
+ OMAP4_IOPAD(0x1bc, PIN_OUTPUT | MUX_MODE3) /* gpio18 */
+ OMAP4_IOPAD(0x1be, PIN_OUTPUT | MUX_MODE3) /* gpio19 */
+ OMAP4_IOPAD(0x1c0, PIN_OUTPUT | MUX_MODE3) /* gpio20 */
+ OMAP4_IOPAD(0x1c2, PIN_OUTPUT | MUX_MODE3) /* gpio21 */
+ OMAP4_IOPAD(0x1c4, PIN_OUTPUT | MUX_MODE3) /* gpio22 */
+ OMAP4_IOPAD(0x1cc, PIN_OUTPUT | MUX_MODE3) /* gpio26 */
+ >;
+ };
+
i2c1_pins: pinmux-i2c1-pins {
pinctrl-single,pins = <
OMAP4_IOPAD(0x122, PIN_INPUT_PULLUP | MUX_MODE0) /* i2c1_scl */
@@ -527,6 +610,15 @@ OMAP4_IOPAD(0x1c8, PIN_OUTPUT | MUX_MODE3) /* gpio_24 / WLAN_EN */
};
};
+&omap4_pmx_wkup {
+ gpio1wk_hog_pins: pinmux-gpio1wk-hog-pins {
+ pinctrl-single,pins = <
+ OMAP4_IOPAD(0x68, PIN_INPUT_PULLDOWN | MUX_MODE3) /* gpio9 */
+ OMAP4_IOPAD(0x6a, PIN_INPUT | MUX_MODE3) /* gpio10 */
+ >;
+ };
+};
+
&uart2 {
pinctrl-names = "default";
pinctrl-0 = <&uart2_pins &bt_pins>;
--
2.39.5On 10/10/2024 15:29, Andreas Kemnade wrote: > Set them to the state seen in a running system, initialized > by vendor u-boot or kernel. Add line names where they are defined in the > vendor kernel. > gpio15 resets something in the display, otherwise meaning of the > gpios is not known. > > Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Reviewed-by: Roger Quadros <rogerq@kernel.org>
On 10/10/2024 15:29, Andreas Kemnade wrote:
> Set them to the state seen in a running system, initialized
> by vendor u-boot or kernel. Add line names where they are defined in the
> vendor kernel.
> gpio15 resets something in the display, otherwise meaning of the
> gpios is not known.
>
> Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
> ---
> .../boot/dts/ti/omap/omap4-epson-embt2ws.dts | 92 +++++++++++++++++++
> 1 file changed, 92 insertions(+)
>
> diff --git a/arch/arm/boot/dts/ti/omap/omap4-epson-embt2ws.dts b/arch/arm/boot/dts/ti/omap/omap4-epson-embt2ws.dts
> index 7684868a2eed..983a21d95db3 100644
> --- a/arch/arm/boot/dts/ti/omap/omap4-epson-embt2ws.dts
> +++ b/arch/arm/boot/dts/ti/omap/omap4-epson-embt2ws.dts
> @@ -115,6 +115,73 @@ wl12xx_vmmc: wl12xx-vmmc {
> };
> };
>
> +&gpio1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&gpio1_hog_pins &gpio1wk_hog_pins>;
> +
> + lb-reset-hog {
> + gpio-hog;
> + gpios = <9 GPIO_ACTIVE_HIGH>;
> + output-low;
> + line-name = "lb_reset";
> + };
> +
> + power-en-hog {
> + gpio-hog;
> + gpios = <10 GPIO_ACTIVE_HIGH>;
> + output-high;
> + line-name = "power_en";
> + };
As GPIO 9 and 10 come form the Wake-up domain, my guess is
they are used as wake-up input source. Reset button / Power off/wake button?
From pinmux they seem to be Input. So why do we need to force them to a
certain output state?
Can you please confirm if everything works as usual without this hog?
We could still give the GPIO a name without the hog right?
maybe user-space is interested in the state.
> +
> + /*
> + * Name taken from vendor kernel but no evidence of actual usage found
> + * nor what it really controls.
> + */
> + panel-power-en-hog {
> + gpio-hog;
> + gpios = <14 GPIO_ACTIVE_HIGH>;
> + output-low;
> + line-name = "panel_power_en";
> + };
> +
> + /*
> + * These two are exported to sysfs in vendor kernel, usage unknown,
> + * backlight state seems unrelated to these.
> + */
> + blc-r-hog {
> + gpio-hog;
> + gpios = <17 GPIO_ACTIVE_HIGH>;
> + output-low;
> + line-name = "blc_r";
> + };
> +
> + blc-l-hog {
> + gpio-hog;
> + gpios = <16 GPIO_ACTIVE_HIGH>;
> + output-low;
> + line-name = "blc_l";
> + };
> +
> + high-hog {
> + gpio-hog;
> + gpios = <15 GPIO_ACTIVE_HIGH /* maybe dsi to dpi chip reset? */
> + 21 GPIO_ACTIVE_HIGH
> + 26 GPIO_ACTIVE_HIGH>;
> + output-high;
> + line-name = "unknown-high";
> + };
> +
> + low-hog {
> + gpio-hog;
> + gpios = <18 GPIO_ACTIVE_HIGH
> + 19 GPIO_ACTIVE_HIGH
> + 20 GPIO_ACTIVE_HIGH
> + 22 GPIO_ACTIVE_HIGH>;
> + output-low;
> + line-name = "unknown-low";
> + };
> +};
> +
> &i2c1 {
> pinctrl-names = "default";
> pinctrl-0 = <&i2c1_pins>;
> @@ -406,6 +473,22 @@ OMAP4_IOPAD(0x56, PIN_INPUT_PULLUP | MUX_MODE3) /* gpio35 */
> >;
> };
>
> + gpio1_hog_pins: pinmux-gpio1-hog-pins {
> + pinctrl-single,pins = <
> + OMAP4_IOPAD(0x1b4, PIN_OUTPUT | MUX_MODE3) /* gpio14 */
> + OMAP4_IOPAD(0x1b8, PIN_OUTPUT | MUX_MODE3) /* gpio16 */
> + OMAP4_IOPAD(0x1ba, PIN_OUTPUT | MUX_MODE3) /* gpio17 */
> +
> + OMAP4_IOPAD(0x1b6, PIN_OUTPUT | MUX_MODE3) /* gpio15 */
> + OMAP4_IOPAD(0x1bc, PIN_OUTPUT | MUX_MODE3) /* gpio18 */
> + OMAP4_IOPAD(0x1be, PIN_OUTPUT | MUX_MODE3) /* gpio19 */
> + OMAP4_IOPAD(0x1c0, PIN_OUTPUT | MUX_MODE3) /* gpio20 */
> + OMAP4_IOPAD(0x1c2, PIN_OUTPUT | MUX_MODE3) /* gpio21 */
> + OMAP4_IOPAD(0x1c4, PIN_OUTPUT | MUX_MODE3) /* gpio22 */
> + OMAP4_IOPAD(0x1cc, PIN_OUTPUT | MUX_MODE3) /* gpio26 */
> + >;
> + };
> +
> i2c1_pins: pinmux-i2c1-pins {
> pinctrl-single,pins = <
> OMAP4_IOPAD(0x122, PIN_INPUT_PULLUP | MUX_MODE0) /* i2c1_scl */
> @@ -527,6 +610,15 @@ OMAP4_IOPAD(0x1c8, PIN_OUTPUT | MUX_MODE3) /* gpio_24 / WLAN_EN */
> };
> };
>
> +&omap4_pmx_wkup {
> + gpio1wk_hog_pins: pinmux-gpio1wk-hog-pins {
> + pinctrl-single,pins = <
> + OMAP4_IOPAD(0x68, PIN_INPUT_PULLDOWN | MUX_MODE3) /* gpio9 */
> + OMAP4_IOPAD(0x6a, PIN_INPUT | MUX_MODE3) /* gpio10 */
> + >;
> + };
> +};
> +
> &uart2 {
> pinctrl-names = "default";
> pinctrl-0 = <&uart2_pins &bt_pins>;
--
cheers,
-roger
Am Thu, 10 Oct 2024 23:15:51 +0300
schrieb Roger Quadros <rogerq@kernel.org>:
> On 10/10/2024 15:29, Andreas Kemnade wrote:
> > Set them to the state seen in a running system, initialized
> > by vendor u-boot or kernel. Add line names where they are defined
> > in the vendor kernel.
> > gpio15 resets something in the display, otherwise meaning of the
> > gpios is not known.
> >
> > Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
> > ---
> > .../boot/dts/ti/omap/omap4-epson-embt2ws.dts | 92
> > +++++++++++++++++++ 1 file changed, 92 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/ti/omap/omap4-epson-embt2ws.dts
> > b/arch/arm/boot/dts/ti/omap/omap4-epson-embt2ws.dts index
> > 7684868a2eed..983a21d95db3 100644 ---
> > a/arch/arm/boot/dts/ti/omap/omap4-epson-embt2ws.dts +++
> > b/arch/arm/boot/dts/ti/omap/omap4-epson-embt2ws.dts @@ -115,6
> > +115,73 @@ wl12xx_vmmc: wl12xx-vmmc { };
> > };
> >
> > +&gpio1 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&gpio1_hog_pins &gpio1wk_hog_pins>;
> > +
> > + lb-reset-hog {
> > + gpio-hog;
> > + gpios = <9 GPIO_ACTIVE_HIGH>;
> > + output-low;
> > + line-name = "lb_reset";
> > + };
> > +
> > + power-en-hog {
> > + gpio-hog;
> > + gpios = <10 GPIO_ACTIVE_HIGH>;
> > + output-high;
> > + line-name = "power_en";
> > + };
>
> As GPIO 9 and 10 come form the Wake-up domain, my guess is
> they are used as wake-up input source. Reset button / Power off/wake
> button? From pinmux they seem to be Input. So why do we need to force
> them to a certain output state?
Interesting reasoning and good to bring up those thoughts.
Vendor v3.0 kernel:
shell@android:/sys/kernel/debug # cat gpio
GPIOs 0-31, gpio:
[...]
gpio-9 (gpio_lb_reset ) out lo
gpio-10 (gpio_power_en ) out hi
So they are configured as output.
There is one power button. It can be handled via the TWL6032 (driver
not upstreamed yet). There is also one reset button resetting the SoC.
I do not see a reason why to deviate from vendor kernel.
> Can you please confirm if everything works as usual without this hog?
>
Well, if everything is working well, I would agree to optimize
these things. But not now. There are races in the boot process
and I would like to rule out that any random or strange behavior has
anything to do with some gpio setting.
Regards,
Andreas
On 11/10/2024 12:12, Andreas Kemnade wrote:
> Am Thu, 10 Oct 2024 23:15:51 +0300
> schrieb Roger Quadros <rogerq@kernel.org>:
>
>> On 10/10/2024 15:29, Andreas Kemnade wrote:
>>> Set them to the state seen in a running system, initialized
>>> by vendor u-boot or kernel. Add line names where they are defined
>>> in the vendor kernel.
>>> gpio15 resets something in the display, otherwise meaning of the
>>> gpios is not known.
>>>
>>> Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
>>> ---
>>> .../boot/dts/ti/omap/omap4-epson-embt2ws.dts | 92
>>> +++++++++++++++++++ 1 file changed, 92 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/ti/omap/omap4-epson-embt2ws.dts
>>> b/arch/arm/boot/dts/ti/omap/omap4-epson-embt2ws.dts index
>>> 7684868a2eed..983a21d95db3 100644 ---
>>> a/arch/arm/boot/dts/ti/omap/omap4-epson-embt2ws.dts +++
>>> b/arch/arm/boot/dts/ti/omap/omap4-epson-embt2ws.dts @@ -115,6
>>> +115,73 @@ wl12xx_vmmc: wl12xx-vmmc { };
>>> };
>>>
>>> +&gpio1 {
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&gpio1_hog_pins &gpio1wk_hog_pins>;
>>> +
>>> + lb-reset-hog {
>>> + gpio-hog;
>>> + gpios = <9 GPIO_ACTIVE_HIGH>;
>>> + output-low;
>>> + line-name = "lb_reset";
>>> + };
>>> +
>>> + power-en-hog {
>>> + gpio-hog;
>>> + gpios = <10 GPIO_ACTIVE_HIGH>;
>>> + output-high;
>>> + line-name = "power_en";
>>> + };
>>
>> As GPIO 9 and 10 come form the Wake-up domain, my guess is
>> they are used as wake-up input source. Reset button / Power off/wake
>> button? From pinmux they seem to be Input. So why do we need to force
>> them to a certain output state?
>
> Interesting reasoning and good to bring up those thoughts.
>
> Vendor v3.0 kernel:
> shell@android:/sys/kernel/debug # cat gpio
> GPIOs 0-31, gpio:
> [...]
> gpio-9 (gpio_lb_reset ) out lo
> gpio-10 (gpio_power_en ) out hi
>
> So they are configured as output.
> There is one power button. It can be handled via the TWL6032 (driver
> not upstreamed yet). There is also one reset button resetting the SoC.
>
> I do not see a reason why to deviate from vendor kernel.
OK.
>
>> Can you please confirm if everything works as usual without this hog?
>>
> Well, if everything is working well, I would agree to optimize
> these things. But not now. There are races in the boot process
> and I would like to rule out that any random or strange behavior has
> anything to do with some gpio setting.
>
> Regards,
> Andreas
--
cheers,
-roger
© 2016 - 2024 Red Hat, Inc.