Re: [PATCH v2 3/4] ARM: dts: omap: omap4-epson-embt2ws: add unknown gpio outputs

[Roger Quadros <rogerq@kernel.org>]

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