[PATCH v3 00/21] dm: add support of new binding in gpio and pincontrol

[Simon Glass]

Hi Tom and Patrick,

On Fri, 27 Mar 2020 at 13:44, Simon Glass <sjg at chromium.org> wrote:
>
> Hi Tom,
>
> On Fri, 27 Mar 2020 at 13:21, Tom Rini <trini at konsulko.com> wrote:
> >
> > 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 at 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!
>
> Not really. I will see if I can figure it out when I get back to things.
>

I found a solution and send out two patches.

Regards,
Simon