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

[Heiko Schocher]

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).

bye,
Heiko
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: hs at denx.de