Messages in this thread Patch in this message | | | Date | Tue, 16 Aug 2022 15:30:26 +0200 | Subject | Re: [PATCH v1 0/3] Bring back driver_deferred_probe_check_state() for now | From | "Luca Weiss" <> |
| |
Hi Saravana,
On Tue Aug 16, 2022 at 1:36 AM CEST, Saravana Kannan wrote: > On Mon, Aug 15, 2022 at 9:57 AM Luca Weiss <luca.weiss@fairphone.com> wrote: > > > > On Mon Aug 15, 2022 at 1:01 PM CEST, Tony Lindgren wrote: > > > * Saravana Kannan <saravanak@google.com> [700101 02:00]: > > > > More fixes/changes are needed before driver_deferred_probe_check_state() > > > > can be deleted. So, bring it back for now. > > > > > > > > Greg, > > > > > > > > Can we get this into 5.19? If not, it might not be worth picking up this > > > > series. I could just do the other/more fixes in time for 5.20. > > > > > > Yes please pick this as fixes for v6.0-rc series, it fixes booting for > > > me. I've replied with fixes tags for the two patches that were causing > > > regressions for me. > > > > > > > Hi, > > > > for me Patch 1+3 fix display probe on Qualcomm SM6350 (although display > > for this SoC isn't upstream yet, there are lots of other SoCs with very > > similar setup). > > > > Probe for DPU silently fails, with CONFIG_DEBUG_DRIVER=y we get this: > > > > msm-mdss ae00000.mdss: __genpd_dev_pm_attach() failed to find PM domain: -2 > > > > While I'm not familiar with the specifics of fw_devlink, the dtsi has > > power-domains = <&dispcc MDSS_GDSC> for this node but it doesn't pick > > that up for some reason. > > > > We can also see that a bit later dispcc finally probes. > > Luca, > > Can you test with this series instead and see if it fixes this issue? > https://lore.kernel.org/lkml/20220810060040.321697-1-saravanak@google.com/ >
Unfortunately it doesn't seem to work with the 9 patches, and the attached diff also doesn't seem to make a difference. I do see this in dmesg which I haven't seen in the past:
[ 0.056554] platform 1d87000.phy: Fixed dependency cycle(s) with /soc@0/ufs@1d84000 [ 0.060070] platform ae00000.mdss: Fixed dependency cycle(s) with /soc@0/clock-controller@af00000 [ 0.060150] platform ae00000.mdss: Failed to create device link with ae00000.mdss [ 0.060188] platform ae00000.mdss: Failed to create device link with ae00000.mdss [ 0.061135] platform c440000.spmi: Failed to create device link with c440000.spmi [ 0.061157] platform c440000.spmi: Failed to create device link with c440000.spmi [ 0.061180] platform c440000.spmi: Failed to create device link with c440000.spmi [ 0.061198] platform c440000.spmi: Failed to create device link with c440000.spmi [ 0.061215] platform c440000.spmi: Failed to create device link with c440000.spmi [ 0.061231] platform c440000.spmi: Failed to create device link with c440000.spmi [ 0.061252] platform c440000.spmi: Failed to create device link with c440000.spmi
Also I'm going to be on holiday from today for about 2 weeks so I won't be able to test anything in that time.
And in case it's interesting, here's the full dmesg to initramfs: https://pastebin.com/raw/Fc8W4MVi
Regards Luca
> You might also need to add this delta on top of the series if the > series itself isn't sufficient. > 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 > > -Saravana
| |