From: Rob Clark <robdclark@gmail.com>
To: Rob Herring <robh+dt@kernel.org>
Cc: Doug Anderson <dianders@chromium.org>,
Sean Paul <sean@poorly.run>, Andy Gross <agross@kernel.org>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
linux-arm-msm <linux-arm-msm@vger.kernel.org>,
freedreno <freedreno@lists.freedesktop.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>, Daniel Vetter <daniel@ffwll.ch>,
David Airlie <airlied@linux.ie>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/9] drm/msm: Avoid possible infinite probe deferral and speed booting
Date: Mon, 13 Jul 2020 14:32:59 -0700 [thread overview]
Message-ID: <CAF6AEGufuFW3ba3u3A+mY+Gw0ouH2x9xY-9A+OtVff+iXdix9A@mail.gmail.com> (raw)
In-Reply-To: <CAL_JsqLJM5nwNSdugMBLDVtjP97dikCm_AiHjnDs1jqBOFoaaQ@mail.gmail.com>
On Mon, Jul 13, 2020 at 1:25 PM Rob Herring <robh+dt@kernel.org> wrote:
>
> On Mon, Jul 13, 2020 at 9:08 AM Doug Anderson <dianders@chromium.org> wrote:
> >
> > Hi,
> >
> > On Mon, Jul 13, 2020 at 7:11 AM Rob Herring <robh+dt@kernel.org> wrote:
> > >
> > > On Fri, Jul 10, 2020 at 5:02 PM Douglas Anderson <dianders@chromium.org> wrote:
> > > >
> > > > I found that if I ever had a little mistake in my kernel config,
> > > > or device tree, or graphics driver that my system would sit in a loop
> > > > at bootup trying again and again and again. An example log was:
> > >
> > > Why do we care about optimizing the error case?
> >
> > It actually results in a _fully_ infinite loop. That is: if anything
> > small causes a component of DRM to fail to probe then the whole system
> > doesn't boot because it just loops trying to probe over and over
> > again. The messages I put in the commit message are printed over and
> > over and over again.
>
> Sounds like a bug as that's not what should happen.
>
> If you defer during boot (initcalls), then you'll be on the deferred
> list until late_initcall and everything is retried. After
> late_initcall, only devices getting added should trigger probing. But
> maybe the adding and then removing a device is causing a re-trigger.
>
> > > > msm ae00000.mdss: bound ae01000.mdp (ops 0xffffffe596e951f8)
> > > > msm_dsi ae94000.dsi: ae94000.dsi supply gdsc not found, using dummy regulator
> > > > msm_dsi_manager_register: failed to register mipi dsi host for DSI 0
> > > > [drm:ti_sn_bridge_probe] *ERROR* could not find any panel node
> > > > ...
> > > >
> > > > I finally tracked it down where this was happening:
> > > > - msm_pdev_probe() is called.
> > > > - msm_pdev_probe() registers drivers. Registering drivers kicks
> > > > off processing of probe deferrals.
> > > > - component_master_add_with_match() could return -EPROBE_DEFER.
> > > > making msm_pdev_probe() return -EPROBE_DEFER.
> > > > - When msm_pdev_probe() returned the processing of probe deferrals
> > > > happens.
> > > > - Loop back to the start.
> > > >
> > > > It looks like we can fix this by marking "mdss" as a "simple-bus".
> > > > I have no idea if people consider this the right thing to do or a
> > > > hack. Hopefully it's the right thing to do. :-)
> > >
> > > It's a simple test. Do the child devices have any dependency on the
> > > parent to probe and/or function? If so, not a simple-bus.
> >
> > Great! You can see in the earlier patch in the series that the very
> > first thing that happens when the parent device probes is that it
> > calls devm_of_platform_populate(). That means no dependencies, right?
>
> It should. But then I reviewed the MDSS binding today and it looks
> like the MDSS is the interrupt parent for at least some child devices?
>
yes, that is correct
BR,
-R
next prev parent reply other threads:[~2020-07-13 21:32 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-10 23:02 [PATCH 0/9] drm/msm: Avoid possible infinite probe deferral and speed booting Douglas Anderson
2020-07-10 23:02 ` [PATCH 1/9] drm/msm: Use the devm variant of of_platform_populate() Douglas Anderson
2020-07-10 23:02 ` [PATCH 2/9] dt-bindings: msm/dpu: Add simple-bus to dpu bindings Douglas Anderson
2020-07-10 23:02 ` [PATCH 3/9] dt-bindings: msm/mdp5: " Douglas Anderson
2020-07-10 23:02 ` [PATCH 4/9] drm/msm: Avoid manually populating our children if "simple-bus" is there Douglas Anderson
2020-07-10 23:02 ` [PATCH 5/9] arm64: dts: qcom: sc7180: Add "simple-bus" to our mdss node Douglas Anderson
2020-07-10 23:02 ` [PATCH 6/9] arm64: dts: qcom: sdm845: " Douglas Anderson
2020-07-10 23:02 ` [PATCH 7/9] arm64: dts: qcom: msm8916: " Douglas Anderson
2020-07-10 23:02 ` [PATCH 8/9] arm64: dts: qcom: msm8996: " Douglas Anderson
2020-07-10 23:02 ` [PATCH 9/9] ARM: dts: qcom: msm8974: " Douglas Anderson
2020-07-13 14:11 ` [PATCH 0/9] drm/msm: Avoid possible infinite probe deferral and speed booting Rob Herring
2020-07-13 14:58 ` [Freedreno] " Jeffrey Hugo
2020-07-13 15:08 ` Doug Anderson
2020-07-13 20:25 ` Rob Herring
2020-07-13 21:32 ` Rob Clark [this message]
2020-07-13 23:50 ` Doug Anderson
2020-07-14 16:32 ` [Freedreno] " Jeffrey Hugo
2020-07-14 22:13 ` Rob Herring
2020-07-14 22:52 ` Bjorn Andersson
2020-07-15 17:30 ` Rob Herring
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=CAF6AEGufuFW3ba3u3A+mY+Gw0ouH2x9xY-9A+OtVff+iXdix9A@mail.gmail.com \
--to=robdclark@gmail.com \
--cc=agross@kernel.org \
--cc=airlied@linux.ie \
--cc=bjorn.andersson@linaro.org \
--cc=daniel@ffwll.ch \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=sean@poorly.run \
/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).