Re: [PATCH v2 3/4] ARM: dts: omap: omap4-epson-embt2ws: add unknown gpio outputs
From: Roger Quadros
Date: Fri Oct 11 2024 - 06:38:08 EST
On 11/10/2024 12:12, Andreas Kemnade wrote:
> Am Thu, 10 Oct 2024 23:15:51 +0300
> schrieb Roger Quadros <rogerq@xxxxxxxxxx>:
>
>> 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@xxxxxxxxxxxx>
>>> ---
>>> .../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