From: Alexander Stein <alexander.stein@ew.tq-group.com>
To: Saravana Kannan <saravanak@google.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Linus Walleij <linus.walleij@linaro.org>,
Bartosz Golaszewski <brgl@bgdev.pl>,
Rob Herring <robh+dt@kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
Geert Uytterhoeven <geert+renesas@glider.be>,
Magnus Damm <magnus.damm@gmail.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Daniel Scally <djrscally@gmail.com>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
Len Brown <lenb@kernel.org>, Abel Vesa <abel.vesa@linaro.org>,
Tony Lindgren <tony@atomide.com>,
Sudeep Holla <sudeep.holla@arm.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
John Stultz <jstultz@google.com>,
Doug Anderson <dianders@chromium.org>,
Guenter Roeck <linux@roeck-us.net>,
kernel-team@android.com, linux-kernel@vger.kernel.org,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, linux-acpi@vger.kernel.org
Subject: Re: [PATCH v1 0/9] fw_devlink improvements
Date: Tue, 16 Aug 2022 09:17:43 +0200 [thread overview]
Message-ID: <8296964.NyiUUSuA9g@steina-w> (raw)
In-Reply-To: <CAGETcx-JUV1nj8wBJrTPfyvM7=Mre5j_vkVmZojeiumUGG6QZQ@mail.gmail.com>
Hello Saravana,
Am Montag, 15. August 2022, 22:56:07 CEST schrieb Saravana Kannan:
> On Mon, Aug 15, 2022 at 12:17 PM Saravana Kannan <saravanak@google.com>
wrote:
> > On Mon, Aug 15, 2022 at 5:39 AM Alexander Stein
> >
> > <alexander.stein@ew.tq-group.com> wrote:
> > > Hello Saravana,
> > >
> > > Am Mittwoch, 10. August 2022, 08:00:29 CEST schrieb Saravana Kannan:
> > > > Alexander,
> > > >
> > > > This should fix your issue where the power domain device not having a
> > > > compatible property. Can you give it a shot please?
> > >
> > > thanks for the update. Unfortunately this does not work:
> > > > [ 0.774838] PM: Added domain provider from /soc@0/bus@30000000/
> > >
> > > gpc@303a0000/pgc/power-domain@0
> > >
> > > > [ 0.775100] imx-pgc imx-pgc-domain.1: __genpd_dev_pm_attach()
> > > > failed to
> > >
> > > find PM domain: -2
> > >
> > > > [ 0.775324] PM: Added domain provider from /soc@0/bus@30000000/
> > >
> > > gpc@303a0000/pgc/power-domain@2
> > >
> > > > [ 0.775601] PM: Added domain provider from /soc@0/bus@30000000/
> > >
> > > gpc@303a0000/pgc/power-domain@3
> > >
> > > > [ 0.775842] PM: Added domain provider from /soc@0/bus@30000000/
> > >
> > > gpc@303a0000/pgc/power-domain@4
> > >
> > > > [ 0.776642] PM: Added domain provider from /soc@0/bus@30000000/
> > >
> > > gpc@303a0000/pgc/power-domain@7
> > >
> > > > [ 0.776897] PM: Added domain provider from /soc@0/bus@30000000/
> > >
> > > gpc@303a0000/pgc/power-domain@8
> > >
> > > > [ 0.777158] PM: Added domain provider from /soc@0/bus@30000000/
> > >
> > > gpc@303a0000/pgc/power-domain@9
> > >
> > > > [ 0.777405] PM: Added domain provider from /soc@0/bus@30000000/
> > >
> > > gpc@303a0000/pgc/power-domain@a
> > >
> > > > [ 0.779342] genpd genpd:0:38320000.blk-ctrl:
> > > > __genpd_dev_pm_attach()
> > >
> > > failed to find PM domain: -2
> > >
> > > > [ 0.779422] imx8m-blk-ctrl 38320000.blk-ctrl: error -ENODEV: failed
> > > > to
> > >
> > > attach power domain "bus"
> > >
> > > > [ 0.848785] etnaviv-gpu 38000000.gpu: __genpd_dev_pm_attach()
> > > > failed to
> > >
> > > find PM domain: -2
> > >
> > > > [ 1.114220] pfuze100-regulator 0-0008: Full layer: 2, Metal layer:
> > > > 1
> > > > [ 1.122267] pfuze100-regulator 0-0008: FAB: 0, FIN: 0
> > > > [ 1.132970] pfuze100-regulator 0-0008: pfuze100 found.
> > > > [ 1.157011] imx-gpcv2 303a0000.gpc: Failed to create device link
> > > > with
> > >
> > > 0-0008
> > >
> > > > [ 1.164094] imx-gpcv2 303a0000.gpc: Failed to create device link
> > > > with
> > >
> > > 0-0008
> > >
> > > The required power-supply for the power domains is still not yet
> > > available.
> > > Does this series require some other patches as well?
> >
> > Ah sorry, yeah, this needs additional patches. The one I gave in the
> > other thread when I debugged this and I also noticed another issue.
> > Here's the combined diff of what's needed. Can you add this on top of
> > the series and test it?
> >
> > diff --git a/drivers/irqchip/irq-imx-gpcv2.c
> > b/drivers/irqchip/irq-imx-gpcv2.c index b9c22f764b4d..8a0e82067924 100644
> > --- a/drivers/irqchip/irq-imx-gpcv2.c
> > +++ b/drivers/irqchip/irq-imx-gpcv2.c
> > @@ -283,6 +283,7 @@ static int __init imx_gpcv2_irqchip_init(struct
> > device_node *node,
> >
> > * later the GPC power domain driver will not be skipped.
> > */
> >
> > of_node_clear_flag(node, OF_POPULATED);
> >
> > + fwnode_dev_initialized(domain->fwnode, false);
> >
> > return 0;
> >
> > }
> >
> > diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
> > index 6383a4edc360..181fbfe5bd4d 100644
> > --- a/drivers/soc/imx/gpcv2.c
> > +++ b/drivers/soc/imx/gpcv2.c
> > @@ -1513,6 +1513,7 @@ static int imx_gpcv2_probe(struct platform_device
> > *pdev)>
> > pd_pdev->dev.parent = dev;
> > pd_pdev->dev.of_node = np;
> >
> > + pd_pdev->dev.fwnode = of_fwnode_handle(np);
> >
> > ret = platform_device_add(pd_pdev);
> > if (ret) {
> >
> > With this patch, I'd really expect the power domain dependency to be
> > handled correctly.
> >
> > > Whats worse, starting with commit 9/9 [of: property: Simplify
> > > of_link_to_phandle()], other drivers fail to probe waiting for pinctrl
> > > to be available.
> >
> > Heh, Patch 9/9 and all its other dependencies in this series was to
> > fix your use case. Ironic that it's causing you more issues.
> >
> > > > $ cat /sys/kernel/debug/devices_deferred
> > > > gpio-leds platform: wait for supplier gpioledgrp
> > > > extcon-usbotg0 platform: wait for supplier usb0congrp
> > > > gpio-keys platform: wait for supplier gpiobuttongrp
> > > > regulator-otg-vbus platform: wait for supplier reggotgvbusgrp
> > > > regulator-vdd-arm platform: wait for supplier dvfsgrp
> > >
> > > Apparently for some reason they are not probed again, once the pinctrl
> > > driver probed.
> >
> > I'm hoping that this is just some issue due to the missing patch
> > above, but doesn't sound like it if you say that the pinctrl ended up
> > probing eventually.
> >
> > So when device_links_driver_bound() calls
> > __fw_devlink_pickup_dangling_consumers(), it should have picked up the
> > consumers of node like gpiobuttongrp and moved it to the pinctrl
> > device. And right after that we call __fw_devlink_link_to_consumers()
> > that would have created the device links. And then right after that,
> > we go through all the consumers and add them to the deferred probe
> > list. After that deferred probe should have run... either because it's
> > enabled at late_initcall() or because a new device probed
> > successfully.
> >
> > Can you check which one of my expectations isn't true in your case?
>
> Actually I have a hypothesis on what might be happening. It could be a
> case of the consumer device getting added after the supplier has been
> initialized.
>
> If the patch above doesn't fix everything, can you add this diff on
> top of the patch above and see if that fixes everything? If it fixes
> the pinctrl issue, can you check my hypothesis be checking in what
> order the devices get added and get probed?
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index 2f012e826986..866755d8ad95 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -2068,7 +2068,11 @@ static int fw_devlink_create_devlink(struct device
> *con, device_links_write_unlock();
> }
>
> - sup_dev = get_dev_from_fwnode(sup_handle);
> + if (sup_handle->flags & FWNODE_FLAG_NOT_DEVICE)
> + sup_dev = fwnode_get_next_parent_dev(sup_handle);
> + else
> + sup_dev = get_dev_from_fwnode(sup_handle);
> +
> if (sup_dev) {
> /*
> * If it's one of those drivers that don't actually bind to
>
And with this change my pinctrl probing is fixed as well!
Thanks
Alexander
next prev parent reply other threads:[~2022-08-16 9:04 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-10 6:00 [PATCH v1 0/9] fw_devlink improvements Saravana Kannan
2022-08-10 6:00 ` [PATCH v1 1/9] driver core: fw_devlink: Don't purge child fwnode's consumer links Saravana Kannan
2022-08-10 6:00 ` [PATCH v1 2/9] driver core: fw_devlink: Improve check for fwnode with no device/driver Saravana Kannan
2022-08-10 6:00 ` [PATCH v1 3/9] soc: renesas: Move away from using OF_POPULATED for fw_devlink Saravana Kannan
2022-08-10 6:00 ` [PATCH v1 4/9] gpiolib: Clear the gpio_device's fwnode initialized flag before adding Saravana Kannan
2022-08-15 9:57 ` Bartosz Golaszewski
2022-08-10 6:00 ` [PATCH v1 5/9] driver core: fw_devlink: Add DL_FLAG_CYCLE support to device links Saravana Kannan
2022-08-10 6:00 ` [PATCH v1 6/9] driver core: fw_devlink: Allow marking a fwnode link as being part of a cycle Saravana Kannan
2022-08-10 6:00 ` [PATCH v1 7/9] driver core: fw_devlink: Consolidate device link flag computation Saravana Kannan
2022-08-10 6:00 ` [PATCH v1 8/9] driver core: fw_devlink: Make cycle detection more robust Saravana Kannan
2022-08-10 6:00 ` [PATCH v1 9/9] of: property: Simplify of_link_to_phandle() Saravana Kannan
2022-08-12 9:47 ` Tony Lindgren
2022-08-13 0:37 ` Saravana Kannan
2022-08-15 10:31 ` Tony Lindgren
2022-08-15 21:00 ` Saravana Kannan
2022-08-12 9:49 ` [PATCH v1 0/9] fw_devlink improvements Tony Lindgren
2022-08-13 0:51 ` Saravana Kannan
2022-08-15 10:33 ` Tony Lindgren
2022-08-15 18:23 ` Saravana Kannan
2022-08-18 7:05 ` Tony Lindgren
2022-08-18 15:00 ` Greg Kroah-Hartman
2022-08-14 5:59 ` Saravana Kannan
2022-08-15 10:17 ` Naresh Kamboju
2022-08-15 11:01 ` Abel Vesa
2022-08-15 18:23 ` Saravana Kannan
2022-08-15 12:39 ` Alexander Stein
2022-08-15 19:17 ` Saravana Kannan
2022-08-15 20:56 ` Saravana Kannan
2022-08-16 7:17 ` Alexander Stein [this message]
2022-08-16 18:51 ` Saravana Kannan
2022-08-16 7:17 ` Alexander Stein
2022-08-15 13:52 ` Sudeep Holla
2022-08-17 13:01 ` Geert Uytterhoeven
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8296964.NyiUUSuA9g@steina-w \
--to=alexander.stein@ew.tq-group.com \
--cc=abel.vesa@linaro.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=brgl@bgdev.pl \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=djrscally@gmail.com \
--cc=frowand.list@gmail.com \
--cc=geert+renesas@glider.be \
--cc=geert@linux-m68k.org \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=jstultz@google.com \
--cc=kernel-team@android.com \
--cc=lenb@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=magnus.damm@gmail.com \
--cc=rafael@kernel.org \
--cc=robh+dt@kernel.org \
--cc=sakari.ailus@linux.intel.com \
--cc=saravanak@google.com \
--cc=sudeep.holla@arm.com \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).