Message-ID: <CAPDyKFq31bucJhP9hp1HSqh-qM2uNGHgDoyQpmbJf00nEf_T4Q@mail.gmail.com>
Date:   Thu, 3 Sep 2020 16:44:01 +0200
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     Doug Anderson <dianders@...omium.org>
Cc:     Veerabhadrarao Badiganti <vbadigan@...eaurora.org>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>
Subject: Re: [PATCH] mmc: sdhci-msm: Prefer asynchronous probe

On Thu, 3 Sep 2020 at 16:35, Doug Anderson <dianders@...omium.org> wrote:
>
> Hi,
>
> On Thu, Sep 3, 2020 at 1:10 AM Ulf Hansson <ulf.hansson@...aro.org> wrote:
> >
> > On Thu, 3 Sep 2020 at 01:43, Douglas Anderson <dianders@...omium.org> wrote:
> > >
> > > Turning on initcall debug on one system showed this:
> > >   initcall sdhci_msm_driver_init+0x0/0x28 returned 0 after 34782 usecs
> > >
> > > The lion's share of this time (~33 ms) was in mmc_power_up().  This
> > > shouldn't be terribly surprising since there are a few calls to delay
> > > based on "power_delay_ms" and the default delay there is 10 ms.
> > >
> > > Because we haven't specified that we'd prefer asynchronous probe for
> > > this driver then we'll wait for this driver to finish before we start
> > > probes for more drivers.  While 33 ms doesn't sound like tons, every
> > > little bit counts.
> > >
> > > There should be little problem with turning on asynchronous probe for
> > > this driver.  It's already possible that previous drivers may have
> > > turned on asynchronous probe so we might already have other things
> > > (that probed before us) probing at the same time we are anyway.  This
> > > driver isn't really providing resources (clocks, regulators, etc) that
> > > other drivers need to probe and even if it was they should be handling
> > > -EPROBE_DEFER.
> > >
> > > Let's turn this on and get a bit of boot speed back.
> >
> > Thanks for a very well written commit message!
> >
> > Indeed, I am sure many mmc host drivers could benefit from a similar
> > change. At least regular platform drivers and amba drivers are pretty
> > sure to work, but who knows.
>
> Yeah, and many non-mmc drivers can benefit too, which is why I've been
> sending several of these patches recently as I optimize boot perf on
> the device that's sitting in front of me.  ;-)  I think the idea was
> that eventually we'd want the kernel to just turn on async by default
> everywhere, but at the time the flag was introduced there were too
> many subtle bugs everywhere.  It feels like one way to get to the
> point where we'd be confident that this is OK to turn on everywhere is
> to just start turning it on in lots of places.  Once enough places
> have it on then perhaps that will give folks confidence that it's OK
> to turn on by default across the board.

Yeah, I guess this is the only way forward at this point.

>
> If you'd like, I can post patches to update some other set of MMC host
> drivers, either as one giant patch (hard to backport, but not as
> spammy) or as a large pile of patches.  I've never played with
> coccinelle so I'd probably fall back to doing this by hand.  I could
> probably only test on a small handful (I think I have easy access to
> dw-mmc-rockchip and sdhci-of-arasan besides the msm one I already
> posted), so another option is that I could also just post for those
> devices...  ...or we can just hope others will notice and start
> posting similar patches themselves after testing.  Let me know what
> you'd prefer.  ;-)

Honestly, I don't know. You go ahead with the option you prefer - then
I will have a look. :-)

Don't worry if we break some, as it should be rather easy to fix - as
long as we keep an eye on it.

Kind regards
Uffe

Powered by blists - more mailing lists