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 <h...@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@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).
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: h...@denx.de
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
