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
