| Message ID | 20220810060040.321697-1-saravanak@google.com |
|---|---|
| Headers | show |
| Series | fw_devlink improvements | expand |
Hi, * Saravana Kannan <saravanak@google.com> [220810 05:54]: > The driver core now: > - Has the parent device of a supplier pick up the consumers if the > supplier never has a device created for it. > - Ignores a supplier if the supplier has no parent device and will never > be probed by a driver > > And already prevents creating a device link with the consumer as a > supplier of a parent. > > So, we no longer need to find the "compatible" node of the supplier or > do any other checks in of_link_to_phandle(). We simply need to make sure > that the supplier is available in DT. This patch fixes booting for me, so it should be applied as a fix and tagged with: Fixes: 5a46079a9645 ("PM: domains: Delete usage of driver_deferred_probe_check_state()") If there are dependencies to the other patches in this series, it might make sense to revert commit 5a46079a9645 instead. Anyways, thanks for fixing the issue, for this patch: Reviewed-by: Tony Lindgren <tony@atomide.com> Tested-by: Tony Lindgren <tony@atomide.com> For the process, looks like the earlier series got merged despite the issues reported. And we had non-booting Linux next for at least some SoCs for weeks. And now we are about to have a non-booting -rc1 unless things get fixed fast. Annoying glitches, sigh.. Regards, Tony
On Fri, Aug 12, 2022 at 2:47 AM Tony Lindgren <tony@atomide.com> wrote: > > Hi, > > * Saravana Kannan <saravanak@google.com> [220810 05:54]: > > The driver core now: > > - Has the parent device of a supplier pick up the consumers if the > > supplier never has a device created for it. > > - Ignores a supplier if the supplier has no parent device and will never > > be probed by a driver > > > > And already prevents creating a device link with the consumer as a > > supplier of a parent. > > > > So, we no longer need to find the "compatible" node of the supplier or > > do any other checks in of_link_to_phandle(). We simply need to make sure > > that the supplier is available in DT. > > This patch fixes booting for me, so it should be applied as a fix and > tagged with: > > Fixes: 5a46079a9645 ("PM: domains: Delete usage of driver_deferred_probe_check_state()") > > If there are dependencies to the other patches in this series, it might > make sense to revert commit 5a46079a9645 instead. Yes, there are dependencies on the rest of the patches in this series. For linux-next, I think we should pick up this series once we get more Tested-bys. So if 5a46079a9645 is causing any regression in stable branches, we should pick up the revert series [1] instead of this series we are replying to. [1] - https://lore.kernel.org/all/20220727185012.3255200-1-saravanak@google.com/ > Anyways, thanks for fixing the issue, for this patch: > > Reviewed-by: Tony Lindgren <tony@atomide.com> > Tested-by: Tony Lindgren <tony@atomide.com> Thanks! > For the process, looks like the earlier series got merged despite the > issues reported. If I'm not mistaken, the issues were reported after the series got picked up. And the series got some tested-by s before it was picked up. And once it's in git history, we obviously can't drop it. > And we had non-booting Linux next for at least some SoCs > for weeks. And now we are about to have a non-booting -rc1 unless things > get fixed fast. Annoying glitches, sigh.. Sorry for breaking some boards -- so mean "creative" corner cases :) This rewrite is way more flexible (removes a lot of limitations in fw_devlink) and hopefully this handles all the corner cases. We'll see. -Saravana
+Naresh Kamboju On Tue, Aug 9, 2022 at 11:00 PM Saravana Kannan <saravanak@google.com> wrote: > > This patch series improves fw_devlink in the following ways: > > 1. It no longer cares about a fwnode having a "compatible" property. It > figures this our more dynamically. The only expectation is that > fwnode that are converted to devices actually get probed by a driver > for the dependencies to be enforced correctly. > > 2. Finer grained dependency tracking. fw_devlink will now create device > links from the consumer to the actual resource's device (if it has one, > Eg: gpio_device) instead of the parent supplier device. This improves > things like async suspend/resume ordering, potentially remove the need > for frameworks to create device links, more parallelized async probing, > and better sync_state() tracking. > > 3. Handle hardware/software quirks where a child firmware node gets > populated as a device before its parent firmware node AND actually > supplies a non-optional resource to the parent firmware node's > device. > > 4. Way more robust at cycle handling (see patch for the insane cases). > > 5. Stops depending on OF_POPULATED to figure out some corner cases. > > 6. Simplifies the work that needs to be done by the firmware specific > code. > > This took way too long to get done due to typo bugs I had in my rewrite or > corner cases I had to find and handle. But it's fairly well tested at this > point and I expect this to work properly. > > Abel & Doug, > > This should fix your cyclic dependency issues with your display. Can you > give it a shot please? > > Alexander, > > This should fix your issue where the power domain device not having a > compatible property. Can you give it a shot please? > > Tony, > > This should handle the odd case of the child being the supplier of the > parent. Can you please give this a shot? I want to make sure the cycle > detection code handles this properly and treats it like it's NOT a cycle. > > Geert, > > Can you test the renesas stuff I changed please? They should continue > working like before. Any other sanity test on other hardware would be > great too. > > Sudeep, > > I don't think there are any unfixed issues you had reported in my other > patches that this series might fix, but it'll be nice if you could give > this a sanity test. > > Guenter, > > I don't think this will fix the issue you reported in the amba patch, but > it's worth a shot because it improves a bunch of corner case handling. So > it might be better at handling whatever corner cases you might have in the > qemu platforms. Hi Naresh, Thanks for testing these patches in the other thread. Mind giving your tested-by here? I know you tested these patches in X15, but were there also other boards these patches were tested on as part of the run? Thanks, Saravana > > Thanks, > Saravana > > Cc: Abel Vesa <abel.vesa@linaro.org> > Cc: Alexander Stein <alexander.stein@ew.tq-group.com> > Cc: Tony Lindgren <tony@atomide.com> > Cc: Sudeep Holla <sudeep.holla@arm.com> > Cc: Geert Uytterhoeven <geert@linux-m68k.org> > Cc: John Stultz <jstultz@google.com> > Cc: Doug Anderson <dianders@chromium.org> > Cc: Guenter Roeck <linux@roeck-us.net> > > Saravana Kannan (9): > driver core: fw_devlink: Don't purge child fwnode's consumer links > driver core: fw_devlink: Improve check for fwnode with no > device/driver > soc: renesas: Move away from using OF_POPULATED for fw_devlink > gpiolib: Clear the gpio_device's fwnode initialized flag before adding > driver core: fw_devlink: Add DL_FLAG_CYCLE support to device links > driver core: fw_devlink: Allow marking a fwnode link as being part of > a cycle > driver core: fw_devlink: Consolidate device link flag computation > driver core: fw_devlink: Make cycle detection more robust > of: property: Simplify of_link_to_phandle() > > drivers/base/core.c | 437 +++++++++++++++++++++----------- > drivers/gpio/gpiolib.c | 6 + > drivers/of/property.c | 84 +----- > drivers/soc/renesas/rcar-sysc.c | 2 +- > include/linux/device.h | 1 + > include/linux/fwnode.h | 12 +- > 6 files changed, 323 insertions(+), 219 deletions(-) > > -- > 2.37.1.559.g78731f0fdb-goog >
* Saravana Kannan <saravanak@google.com> [220813 00:30]: > On Fri, Aug 12, 2022 at 2:47 AM Tony Lindgren <tony@atomide.com> wrote: > > > > Hi, > > > > * Saravana Kannan <saravanak@google.com> [220810 05:54]: > > > The driver core now: > > > - Has the parent device of a supplier pick up the consumers if the > > > supplier never has a device created for it. > > > - Ignores a supplier if the supplier has no parent device and will never > > > be probed by a driver > > > > > > And already prevents creating a device link with the consumer as a > > > supplier of a parent. > > > > > > So, we no longer need to find the "compatible" node of the supplier or > > > do any other checks in of_link_to_phandle(). We simply need to make sure > > > that the supplier is available in DT. > > > > This patch fixes booting for me, so it should be applied as a fix and > > tagged with: > > > > Fixes: 5a46079a9645 ("PM: domains: Delete usage of driver_deferred_probe_check_state()") > > > > If there are dependencies to the other patches in this series, it might > > make sense to revert commit 5a46079a9645 instead. > > Yes, there are dependencies on the rest of the patches in this series. > For linux-next, I think we should pick up this series once we get more > Tested-bys. > > So if 5a46079a9645 is causing any regression in stable branches, we > should pick up the revert series [1] instead of this series we are > replying to. Agreed we should apply the reverts in [1] for v6.0-rc series. At least several generations of the TI 32-bit ARM SoCs are failing to boot otherwise. Regards, Tony
On 22-08-09 23:00:29, Saravana Kannan wrote: > This patch series improves fw_devlink in the following ways: > > 1. It no longer cares about a fwnode having a "compatible" property. It > figures this our more dynamically. The only expectation is that > fwnode that are converted to devices actually get probed by a driver > for the dependencies to be enforced correctly. > > 2. Finer grained dependency tracking. fw_devlink will now create device > links from the consumer to the actual resource's device (if it has one, > Eg: gpio_device) instead of the parent supplier device. This improves > things like async suspend/resume ordering, potentially remove the need > for frameworks to create device links, more parallelized async probing, > and better sync_state() tracking. > > 3. Handle hardware/software quirks where a child firmware node gets > populated as a device before its parent firmware node AND actually > supplies a non-optional resource to the parent firmware node's > device. > > 4. Way more robust at cycle handling (see patch for the insane cases). > > 5. Stops depending on OF_POPULATED to figure out some corner cases. > > 6. Simplifies the work that needs to be done by the firmware specific > code. > > This took way too long to get done due to typo bugs I had in my rewrite or > corner cases I had to find and handle. But it's fairly well tested at this > point and I expect this to work properly. > > Abel & Doug, > > This should fix your cyclic dependency issues with your display. Can you > give it a shot please? Tested the specific case we discussed about here: https://lore.kernel.org/all/CAGETcx8F0wP+RA0KpjOJeZfc=DVG-MbM_=SkRHD4UhD2ReL7Kw@mail.gmail.com/raw Thanks for fixing this. Tested-by: Abel Vesa <abel.vesa@linaro.org> > > Alexander, > > This should fix your issue where the power domain device not having a > compatible property. Can you give it a shot please? > > Tony, > > This should handle the odd case of the child being the supplier of the > parent. Can you please give this a shot? I want to make sure the cycle > detection code handles this properly and treats it like it's NOT a cycle. > > Geert, > > Can you test the renesas stuff I changed please? They should continue > working like before. Any other sanity test on other hardware would be > great too. > > Sudeep, > > I don't think there are any unfixed issues you had reported in my other > patches that this series might fix, but it'll be nice if you could give > this a sanity test. > > Guenter, > > I don't think this will fix the issue you reported in the amba patch, but > it's worth a shot because it improves a bunch of corner case handling. So > it might be better at handling whatever corner cases you might have in the > qemu platforms. > > Thanks, > Saravana > > Cc: Abel Vesa <abel.vesa@linaro.org> > Cc: Alexander Stein <alexander.stein@ew.tq-group.com> > Cc: Tony Lindgren <tony@atomide.com> > Cc: Sudeep Holla <sudeep.holla@arm.com> > Cc: Geert Uytterhoeven <geert@linux-m68k.org> > Cc: John Stultz <jstultz@google.com> > Cc: Doug Anderson <dianders@chromium.org> > Cc: Guenter Roeck <linux@roeck-us.net> > > Saravana Kannan (9): > driver core: fw_devlink: Don't purge child fwnode's consumer links > driver core: fw_devlink: Improve check for fwnode with no > device/driver > soc: renesas: Move away from using OF_POPULATED for fw_devlink > gpiolib: Clear the gpio_device's fwnode initialized flag before adding > driver core: fw_devlink: Add DL_FLAG_CYCLE support to device links > driver core: fw_devlink: Allow marking a fwnode link as being part of > a cycle > driver core: fw_devlink: Consolidate device link flag computation > driver core: fw_devlink: Make cycle detection more robust > of: property: Simplify of_link_to_phandle() > > drivers/base/core.c | 437 +++++++++++++++++++++----------- > drivers/gpio/gpiolib.c | 6 + > drivers/of/property.c | 84 +----- > drivers/soc/renesas/rcar-sysc.c | 2 +- > include/linux/device.h | 1 + > include/linux/fwnode.h | 12 +- > 6 files changed, 323 insertions(+), 219 deletions(-) > > -- > 2.37.1.559.g78731f0fdb-goog >
On Tue, Aug 09, 2022 at 11:00:29PM -0700, Saravana Kannan wrote: > This patch series improves fw_devlink in the following ways: > > 1. It no longer cares about a fwnode having a "compatible" property. It > figures this our more dynamically. The only expectation is that > fwnode that are converted to devices actually get probed by a driver > for the dependencies to be enforced correctly. > > 2. Finer grained dependency tracking. fw_devlink will now create device > links from the consumer to the actual resource's device (if it has one, > Eg: gpio_device) instead of the parent supplier device. This improves > things like async suspend/resume ordering, potentially remove the need > for frameworks to create device links, more parallelized async probing, > and better sync_state() tracking. > > 3. Handle hardware/software quirks where a child firmware node gets > populated as a device before its parent firmware node AND actually > supplies a non-optional resource to the parent firmware node's > device. > > 4. Way more robust at cycle handling (see patch for the insane cases). > > 5. Stops depending on OF_POPULATED to figure out some corner cases. > > 6. Simplifies the work that needs to be done by the firmware specific > code. > > This took way too long to get done due to typo bugs I had in my rewrite or > corner cases I had to find and handle. But it's fairly well tested at this > point and I expect this to work properly. > > Abel & Doug, > > This should fix your cyclic dependency issues with your display. Can you > give it a shot please? > > Alexander, > > This should fix your issue where the power domain device not having a > compatible property. Can you give it a shot please? > > Tony, > > This should handle the odd case of the child being the supplier of the > parent. Can you please give this a shot? I want to make sure the cycle > detection code handles this properly and treats it like it's NOT a cycle. > > Geert, > > Can you test the renesas stuff I changed please? They should continue > working like before. Any other sanity test on other hardware would be > great too. > > Sudeep, > > I don't think there are any unfixed issues you had reported in my other > patches that this series might fix, but it'll be nice if you could give > this a sanity test. > Sure tested this on Juno on top of v6.0-rc1 and found no regressions. So, Tested-by: Sudeep Holla <sudeep.holla@arm.com> Just wanted to check if the logs are intentional or do you plan to make them debug. On Juno with hardly few such dependencies I get below extra logs during boot, it may add loads on other platforms. I am fine either way, just thought of checking. | amba 20040000.funnel: Fixed dependency cycle(s) with /etf@20010000/in-ports/port/endpoint | amba 20120000.replicator: Fixed dependency cycle(s) with /etr@20070000/in-ports/port/endpoint | amba 20120000.replicator: Fixed dependency cycle(s) with /tpiu@20030000/in-ports/port/endpoint | amba 220c0000.funnel: Fixed dependency cycle(s) with /etm@22040000/out-ports/port/endpoint | amba 220c0000.funnel: Fixed dependency cycle(s) with /funnel@20040000/in-ports/port@0/endpoint | amba 22140000.etm: Fixed dependency cycle(s) with /funnel@220c0000/in-ports/port@1/endpoint | amba 230c0000.funnel: Fixed dependency cycle(s) with /etm@23040000/out-ports/port/endpoint | amba 230c0000.funnel: Fixed dependency cycle(s) with /funnel@20040000/in-ports/port@1/endpoint | amba 23140000.etm: Fixed dependency cycle(s) with /funnel@230c0000/in-ports/port@1/endpoint | amba 23240000.etm: Fixed dependency cycle(s) with /funnel@230c0000/in-ports/port@2/endpoint | amba 23340000.etm: Fixed dependency cycle(s) with /funnel@230c0000/in-ports/port@3/endpoint | amba 20130000.funnel: Fixed dependency cycle(s) with /stm@20100000/out-ports/port/endpoint | amba 20140000.etf: Fixed dependency cycle(s) with /funnel@20130000/out-ports/port/endpoint | amba 20150000.funnel: Fixed dependency cycle(s) with /etf@20140000/out-ports/port/endpoint | amba 20150000.funnel: Fixed dependency cycle(s) with /etf@20010000/out-ports/port/endpoint | amba 20150000.funnel: Fixed dependency cycle(s) with /replicator@20120000/in-ports/port/endpoint | i2c 0-0070: Fixed dependency cycle(s) with /hdlcd@7ff60000/port/endpoint | i2c 0-0071: Fixed dependency cycle(s) with /hdlcd@7ff50000/port/endpoint
On Mon, Aug 15, 2022 at 4:01 AM Abel Vesa <abel.vesa@linaro.org> wrote: > > On 22-08-09 23:00:29, Saravana Kannan wrote: > > This patch series improves fw_devlink in the following ways: > > > > 1. It no longer cares about a fwnode having a "compatible" property. It > > figures this our more dynamically. The only expectation is that > > fwnode that are converted to devices actually get probed by a driver > > for the dependencies to be enforced correctly. > > > > 2. Finer grained dependency tracking. fw_devlink will now create device > > links from the consumer to the actual resource's device (if it has one, > > Eg: gpio_device) instead of the parent supplier device. This improves > > things like async suspend/resume ordering, potentially remove the need > > for frameworks to create device links, more parallelized async probing, > > and better sync_state() tracking. > > > > 3. Handle hardware/software quirks where a child firmware node gets > > populated as a device before its parent firmware node AND actually > > supplies a non-optional resource to the parent firmware node's > > device. > > > > 4. Way more robust at cycle handling (see patch for the insane cases). > > > > 5. Stops depending on OF_POPULATED to figure out some corner cases. > > > > 6. Simplifies the work that needs to be done by the firmware specific > > code. > > > > This took way too long to get done due to typo bugs I had in my rewrite or > > corner cases I had to find and handle. But it's fairly well tested at this > > point and I expect this to work properly. > > > > Abel & Doug, > > > > This should fix your cyclic dependency issues with your display. Can you > > give it a shot please? > > Tested the specific case we discussed about here: > https://lore.kernel.org/all/CAGETcx8F0wP+RA0KpjOJeZfc=DVG-MbM_=SkRHD4UhD2ReL7Kw@mail.gmail.com/raw > > Thanks for fixing this. > > Tested-by: Abel Vesa <abel.vesa@linaro.org> Thanks! -Saravana > > > > > Alexander, > > > > This should fix your issue where the power domain device not having a > > compatible property. Can you give it a shot please? > > > > Tony, > > > > This should handle the odd case of the child being the supplier of the > > parent. Can you please give this a shot? I want to make sure the cycle > > detection code handles this properly and treats it like it's NOT a cycle. > > > > Geert, > > > > Can you test the renesas stuff I changed please? They should continue > > working like before. Any other sanity test on other hardware would be > > great too. > > > > Sudeep, > > > > I don't think there are any unfixed issues you had reported in my other > > patches that this series might fix, but it'll be nice if you could give > > this a sanity test. > > > > Guenter, > > > > I don't think this will fix the issue you reported in the amba patch, but > > it's worth a shot because it improves a bunch of corner case handling. So > > it might be better at handling whatever corner cases you might have in the > > qemu platforms. > > > > Thanks, > > Saravana > > > > Cc: Abel Vesa <abel.vesa@linaro.org> > > Cc: Alexander Stein <alexander.stein@ew.tq-group.com> > > Cc: Tony Lindgren <tony@atomide.com> > > Cc: Sudeep Holla <sudeep.holla@arm.com> > > Cc: Geert Uytterhoeven <geert@linux-m68k.org> > > Cc: John Stultz <jstultz@google.com> > > Cc: Doug Anderson <dianders@chromium.org> > > Cc: Guenter Roeck <linux@roeck-us.net> > > > > Saravana Kannan (9): > > driver core: fw_devlink: Don't purge child fwnode's consumer links > > driver core: fw_devlink: Improve check for fwnode with no > > device/driver > > soc: renesas: Move away from using OF_POPULATED for fw_devlink > > gpiolib: Clear the gpio_device's fwnode initialized flag before adding > > driver core: fw_devlink: Add DL_FLAG_CYCLE support to device links > > driver core: fw_devlink: Allow marking a fwnode link as being part of > > a cycle > > driver core: fw_devlink: Consolidate device link flag computation > > driver core: fw_devlink: Make cycle detection more robust > > of: property: Simplify of_link_to_phandle() > > > > drivers/base/core.c | 437 +++++++++++++++++++++----------- > > drivers/gpio/gpiolib.c | 6 + > > drivers/of/property.c | 84 +----- > > drivers/soc/renesas/rcar-sysc.c | 2 +- > > include/linux/device.h | 1 + > > include/linux/fwnode.h | 12 +- > > 6 files changed, 323 insertions(+), 219 deletions(-) > > > > -- > > 2.37.1.559.g78731f0fdb-goog > >
On Mon, Aug 15, 2022 at 3:31 AM Tony Lindgren <tony@atomide.com> wrote: > > * Saravana Kannan <saravanak@google.com> [220813 00:30]: > > On Fri, Aug 12, 2022 at 2:47 AM Tony Lindgren <tony@atomide.com> wrote: > > > > > > Hi, > > > > > > * Saravana Kannan <saravanak@google.com> [220810 05:54]: > > > > The driver core now: > > > > - Has the parent device of a supplier pick up the consumers if the > > > > supplier never has a device created for it. > > > > - Ignores a supplier if the supplier has no parent device and will never > > > > be probed by a driver > > > > > > > > And already prevents creating a device link with the consumer as a > > > > supplier of a parent. > > > > > > > > So, we no longer need to find the "compatible" node of the supplier or > > > > do any other checks in of_link_to_phandle(). We simply need to make sure > > > > that the supplier is available in DT. > > > > > > This patch fixes booting for me, so it should be applied as a fix and > > > tagged with: > > > > > > Fixes: 5a46079a9645 ("PM: domains: Delete usage of driver_deferred_probe_check_state()") > > > > > > If there are dependencies to the other patches in this series, it might > > > make sense to revert commit 5a46079a9645 instead. > > > > Yes, there are dependencies on the rest of the patches in this series. > > For linux-next, I think we should pick up this series once we get more > > Tested-bys. > > > > So if 5a46079a9645 is causing any regression in stable branches, we > > should pick up the revert series [1] instead of this series we are > > replying to. > > Agreed we should apply the reverts in [1] for v6.0-rc series. At least > several generations of the TI 32-bit ARM SoCs are failing to boot > otherwise. Actually I wasn't clear in my earlier email. I meant to say "releases branches", as in 5.19.xxx and not "stable branches". So for 5.19.xxx we'd pick up these reverts. And for v6.0-rc if my other patch series [1] fixes the issue, I'd rather apply [1] than this series. Because this series is meant to be temporary (I'll be reverting this in the future). -Saravana [1] - https://lore.kernel.org/lkml/20220810060040.321697-1-saravanak@google.com/
Hello Saravana, Am Montag, 15. August 2022, 21:17:36 CEST schrieb Saravana Kannan: > 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. I was out of office so I didn't keep track of any dependencies, sorry. With these 2 changes above my power domain problem is fixed! Thanks Alexander
This patch series improves fw_devlink in the following ways: 1. It no longer cares about a fwnode having a "compatible" property. It figures this our more dynamically. The only expectation is that fwnode that are converted to devices actually get probed by a driver for the dependencies to be enforced correctly. 2. Finer grained dependency tracking. fw_devlink will now create device links from the consumer to the actual resource's device (if it has one, Eg: gpio_device) instead of the parent supplier device. This improves things like async suspend/resume ordering, potentially remove the need for frameworks to create device links, more parallelized async probing, and better sync_state() tracking. 3. Handle hardware/software quirks where a child firmware node gets populated as a device before its parent firmware node AND actually supplies a non-optional resource to the parent firmware node's device. 4. Way more robust at cycle handling (see patch for the insane cases). 5. Stops depending on OF_POPULATED to figure out some corner cases. 6. Simplifies the work that needs to be done by the firmware specific code. This took way too long to get done due to typo bugs I had in my rewrite or corner cases I had to find and handle. But it's fairly well tested at this point and I expect this to work properly. Abel & Doug, This should fix your cyclic dependency issues with your display. Can you give it a shot please? Alexander, This should fix your issue where the power domain device not having a compatible property. Can you give it a shot please? Tony, This should handle the odd case of the child being the supplier of the parent. Can you please give this a shot? I want to make sure the cycle detection code handles this properly and treats it like it's NOT a cycle. Geert, Can you test the renesas stuff I changed please? They should continue working like before. Any other sanity test on other hardware would be great too. Sudeep, I don't think there are any unfixed issues you had reported in my other patches that this series might fix, but it'll be nice if you could give this a sanity test. Guenter, I don't think this will fix the issue you reported in the amba patch, but it's worth a shot because it improves a bunch of corner case handling. So it might be better at handling whatever corner cases you might have in the qemu platforms. Thanks, Saravana Cc: Abel Vesa <abel.vesa@linaro.org> Cc: Alexander Stein <alexander.stein@ew.tq-group.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: John Stultz <jstultz@google.com> Cc: Doug Anderson <dianders@chromium.org> Cc: Guenter Roeck <linux@roeck-us.net> Saravana Kannan (9): driver core: fw_devlink: Don't purge child fwnode's consumer links driver core: fw_devlink: Improve check for fwnode with no device/driver soc: renesas: Move away from using OF_POPULATED for fw_devlink gpiolib: Clear the gpio_device's fwnode initialized flag before adding driver core: fw_devlink: Add DL_FLAG_CYCLE support to device links driver core: fw_devlink: Allow marking a fwnode link as being part of a cycle driver core: fw_devlink: Consolidate device link flag computation driver core: fw_devlink: Make cycle detection more robust of: property: Simplify of_link_to_phandle() drivers/base/core.c | 437 +++++++++++++++++++++----------- drivers/gpio/gpiolib.c | 6 + drivers/of/property.c | 84 +----- drivers/soc/renesas/rcar-sysc.c | 2 +- include/linux/device.h | 1 + include/linux/fwnode.h | 12 +- 6 files changed, 323 insertions(+), 219 deletions(-)