[U-Boot] [PATCH v2] gpio: add gpio-hog support

[Michal Simek]

On 27. 05. 19 14:48, Heiko Schocher wrote:
> Hello Michal,
> 
> Am 27.05.2019 um 14:31 schrieb Michal Simek:
>> Hi,
>>
>> On 27. 05. 19 14:06, Heiko Schocher wrote:
>>> Hello Michal,
>>>
>>> Am 27.05.2019 um 13:34 schrieb Michal Simek:
>>>> On 27. 05. 19 12:49, Heiko Schocher wrote:
>>>>> add gpio-hog support. GPIO hogging is a mechanism
>>>>> providing automatic GPIO request and configuration
>>>>> as part of the gpio-controller's driver probe function.
>>>>>
>>>>> for more infos see:
>>>>> doc/device-tree-bindings/gpio/gpio.txt
>>>>>
>>>>> Signed-off-by: Heiko Schocher <hs at denx.de>
>>>>>
>>>>> ---
>>>>> not yet started clean travis build, see result:
>>>>> https://travis-ci.org/hsdenx/u-boot-test/builds/537732421
>>>>>
>>>>> Changes in v2:
>>>>> - move gpio_hog() call from post_probe() to post_bind()
>>>>>     call. Check if current gpio device has gpio-hog
>>>>>     definitions, if so, probe it.
>>>>
>>>> I am using i2c to gpio chip and with v2 this chip is not listed via dm
>>>> completely. It means something is wrong for sure.
>>>
>>> What do you mean with "this chip is not listed via dm completely" ?
>>
>> first of all I am using zcu102
>> http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/dts/zynqmp-zcu102-revA.dts;h=6e22871713139517ad5f7f1d2e659690233bd946;hb=HEAD#l129
>>
>>
>> There are 2 i2c-gpio chips  @20 and @21. @20 has hogs and it is not
>> listed via dm tree when v2 is applied (v1 is without any issue).
>> @21 is seen there.
> 
> Hmm... look like the same setup as mine ...
> 
>>>> It looks like that parent is not probed that's why it is failing.
>>>
>>> I use this on the aristainetos board, work currently on rework for DM/DT
>>> usage in U-Boot, dts not yet in u-boot but in linux, see:
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/imx6qdl-aristainetos2.dtsi#n286
>>>
>>>
>>>
>>> and added for u-boot now gpio hog definitons:
>>>
>>> &i2c3 {
>>>          pinctrl-names = "default";
>>>          pinctrl-0 = <&pinctrl_i2c3>;
>>>          status = "okay";
>>>
>>>          expander: tca6416 at 20 {
>>>                  compatible = "ti,tca6416";
>>>                  reg = <0x20>;
>>>                  #gpio-cells = <2>;
>>>                  gpio-controller;
>>>
>>>                  env_reset {
>>>                          gpio-hog;
>>>                          input;
>>>                          gpios = <6 GPIO_ACTIVE_LOW>;
>>>                  };
>>>                  boot_rescue {
>>>                          gpio-hog;
>>>                          input;
>>>                          gpios = <7 GPIO_ACTIVE_LOW>;
>>
>> nit: there could be also line-name setup.
> 
> Ok, I add support for it.
> 
>>>                  };
>>>          };
>>> };
>>
>> The setup looks the same as I have here.
> 
> Yes.
> 
>>>
>>> works fine for me ...
>>>
>>> => dm tree
>>>   Class     Index  Probed  Driver                Name
>>> -----------------------------------------------------------
>>>   root         0  [ + ]   root_driver           root_driver
>>> [...]
>>>   i2c          2  [ + ]   i2c_mxc               |   |   |-- i2c at 21a8000
>>>   gpio         7  [ + ]   pca953x               |   |   |   |--
>>> tca6416 at 20
>>>
>>> => gpio status
>>> [...]
>>> Bank gpio at 20_:
>>> gpio at 20_6: input: 0 [x] env_reset.gpio-hog
>>> gpio at 20_7: input: 1 [x] boot_rescue.gpio-hog
>>> =>
>>>
>>> Hmm.. how can I reproduce your problem?
>>
>> Take a look but IIRC you should have zcu102 around too.
> 
> Indeed we have one:
> 
> $ remote_power -l | grep zcu102
> katmai3         off        r360         off           zcu102            off
> 
> I have to look, how I can test without breaking the board... Is there
> something like a bootmode switch, so I can restore the board if I broke
> it? (Sorry if dummy question, never worked on the board).

yes - there are easy way how to restore the board. Not sure if you use
jtag, qspi or sd boot mode.

Thanks,
Michal