On Mon, Jan 13, 2020 at 11:34:54AM +0100, Patrick Delaunay wrote:
Hi,
it is the V3 of "dm: add support of new binding in gpio and pincontrol" http://patchwork.ozlabs.org/project/uboot/list/?series=145044
I rebase on v2020.01 and made some minor update after Simon Glass review. And I also split the previous patch was part of v2 08/14 to help review http://patchwork.ozlabs.org/patch/1200865/ "gpio: add ops for configuration with dir flags"
I create this patchset to prepare alignment of stm32mp157c-ev1 device-tree with the linux kernel v5.4.
One node for touch screen support use the IRQ line configuration using the new kernel binding introduced by the linux kernel commit ede033e1e863c from v5.1 ('dt-bindings: gpio: document the new pull-up/pull-down flags') https://github.com/torvalds/linux/commit/ede033e1e863c
gt9147: goodix_ts@5d { compatible = "goodix,gt9147"; reg = <0x5d>; status = "okay"; irq-gpios = <&stmfx_pinctrl 14 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)>; irq-flags = <IRQ_TYPE_EDGE_RISING>; };
In Linux Kernel, the GPIO configuration (pull down/up) are now managed by GPIO lib but they are not yet supported by U-boot in uclass GPIO or pincontrol (when used by gpio-hog).
This serie adds the support of theses new defines (with ops get_config/set_config) added in kernel GPIO binding and adds the test in sandbox.
NB: In a second phase, the removed set_open_drain/get_open_drain API could be replaced by the new ops get_config/set_config.
I also align the gpio binding file with the version from the latest kernel v5.3 (I don't think I remove any U-Boot specific part with this patch) I move the added information on gpio hog code in a new file doc/README.gpio.
To have functional test, I convert pinctrl-generic to livetree otherwise the pins are not correctly configured in sandbox, when CONFIG_OF_LIVE is activated.
For the test on gpio I add information for pin configuration in output of the command "pinmux status" with a simple pincontrol driver associated to GPIO driver.
NB: after rebase on master branch, the sandbox test "ut dm power_domain" is failing; it was not the case for v2019.10.
------------------------------------------------------ Captured stdout call ------------------------------------------------------- => ut dm power_domain Test: dm_test_power_domain: power-domain.c ../test/dm/test-main.c:72, dm_test_destroy(): 0 == uclass_destroy(uc): Expected 0x0 (0), got 0xffffffea (-22) ../test/dm/test-main.c:107, dm_do_test(): 0 == dm_test_destroy(uts): Expected 0x0 (0), got 0x1 (1) ../test/dm/test-main.c:169, dm_test_main(): 0 == dm_do_test(uts, test, 1): Expected 0x0 (0), got 0x1 (1) =>
I think it is linked to commit 52edfed65de9 ("dm: core: device: switch off power domain after device removal")
After some investigation :
1/ pincontrol is remove in uclass_destroy(0)
2/ power domain is removed in uclass_destroy(0)
3/ device_chld_unbind() dev_power_domain_off -> probe power domain (again) --> pinctrl_select_state() in device_probe() ---> pincontrol is probed (again)
4/ at the end of dev_power_domain_off() function the power domain is unbind in dev_power_domain_off device_remove(pd.dev, DM_REMOVE_NORMAL);
So power domain driver is correctly removed but it is not the case for the pincontrol driver and that cause the issue.
The problem occurs after my serie only because I introduce a second pincontrol driver for sandbox, so the dynamic changes but my serie is not the root cause of the issue.
Workaround to allow test execution: "dm: core: device: don't probe pinctrl for power domain"
Simon, any idea on how to fix the test failure above? I don't think excluding the test is the right path forward. Thanks!