Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200710230224.2265647-1-dianders@chromium.org>
In-Reply-To: <20200710230224.2265647-1-dianders@chromium.org>
From:   Rob Herring <robh+dt@kernel.org>
Date:   Mon, 13 Jul 2020 08:11:07 -0600
Message-ID: <CAL_JsqKC5WtHb-coMCxMTDJ7CJcjVXcAxDT4J9N-Xyr=0uuURA@mail.gmail.com>
Subject: Re: [PATCH 0/9] drm/msm: Avoid possible infinite probe deferral and
 speed booting
To:     Douglas Anderson <dianders@chromium.org>
Cc:     Rob Clark <robdclark@gmail.com>, 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>,
        devicetree@vger.kernel.org, Daniel Vetter <daniel@ffwll.ch>,
        David Airlie <airlied@linux.ie>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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?

>   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.

> Once I do this I notice that my boot gets marginally faster (you
> don't need to probe the sub devices over and over) and also if I

Can you quantify that?

Have you run with devlinks enabled. You need a command line option to
enable. That too should reduce deferred probes.

> have a problem it doesn't loop forever (on my system it still
> gets upset about some stuck clocks in that case, but at least I
> can boot up).

Deferred probe only runs when a device is added, so it's not like it
is continually running.

Rob