Re: [PATCH] mmc: sdhci-msm: Prefer asynchronous probe

[Doug Anderson]

Hi,

On Thu, Sep 3, 2020 at 7:44 AM Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote:
>
> On Thu, 3 Sep 2020 at 16:35, Doug Anderson <dianders@xxxxxxxxxxxx> wrote:
> >
> > Hi,
> >
> > On Thu, Sep 3, 2020 at 1:10 AM Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote:
> > >
> > > On Thu, 3 Sep 2020 at 01:43, Douglas Anderson <dianders@xxxxxxxxxxxx> 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.

OK, I probably spent way too much time on it, but here it is in all of
its glory:

https://lore.kernel.org/r/20200903232441.2694866-1-dianders@xxxxxxxxxxxx/

-Doug