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. Kind regards Uffe
