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@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.dt...
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...
and added for u-boot now gpio hog definitons:
&i2c3 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_i2c3>; status = "okay";
expander: tca6416@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@21a8000 gpio 7 [ + ] pca953x | | | |-- tca6416@20
=> gpio status [...] Bank gpio@20_: gpio@20_6: input: 0 [x] env_reset.gpio-hog gpio@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