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! -- Tom
signature.asc
Description: PGP signature
