diff mbox series

mmc: sdhci-msm: Prefer asynchronous probe

Message ID 20200902164303.1.I5e598a25222b4534c0083b61dbfa4e0e76f66171@changeid
State New
Headers show
Series mmc: sdhci-msm: Prefer asynchronous probe | expand

Commit Message

Doug Anderson Sept. 2, 2020, 11:43 p.m. UTC
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.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
---

 drivers/mmc/host/sdhci-msm.c | 1 +
 1 file changed, 1 insertion(+)

Comments

Ulf Hansson Sept. 3, 2020, 8:10 a.m. UTC | #1
On Thu, 3 Sep 2020 at 01:43, Douglas Anderson <dianders@chromium.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.

>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>

Applied for next, thanks!

Kind regards
Uffe


> ---
>
>  drivers/mmc/host/sdhci-msm.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
> index d4c02884cca8..9dd0dbb65382 100644
> --- a/drivers/mmc/host/sdhci-msm.c
> +++ b/drivers/mmc/host/sdhci-msm.c
> @@ -2542,6 +2542,7 @@ static struct platform_driver sdhci_msm_driver = {
>                    .name = "sdhci_msm",
>                    .of_match_table = sdhci_msm_dt_match,
>                    .pm = &sdhci_msm_pm_ops,
> +                  .probe_type = PROBE_PREFER_ASYNCHRONOUS,
>         },
>  };
>
> --
> 2.28.0.402.g5ffc5be6b7-goog
>
Doug Anderson Sept. 3, 2020, 2:35 p.m. UTC | #2
Hi,

On Thu, Sep 3, 2020 at 1:10 AM Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> On Thu, 3 Sep 2020 at 01:43, Douglas Anderson <dianders@chromium.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.

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

-Doug
Ulf Hansson Sept. 3, 2020, 2:44 p.m. UTC | #3
On Thu, 3 Sep 2020 at 16:35, Doug Anderson <dianders@chromium.org> wrote:
>
> Hi,
>
> On Thu, Sep 3, 2020 at 1:10 AM Ulf Hansson <ulf.hansson@linaro.org> wrote:
> >
> > On Thu, 3 Sep 2020 at 01:43, Douglas Anderson <dianders@chromium.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
Doug Anderson Sept. 3, 2020, 11:28 p.m. UTC | #4
Hi,

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

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@chromium.org/

-Doug
diff mbox series

Patch

diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index d4c02884cca8..9dd0dbb65382 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -2542,6 +2542,7 @@  static struct platform_driver sdhci_msm_driver = {
 		   .name = "sdhci_msm",
 		   .of_match_table = sdhci_msm_dt_match,
 		   .pm = &sdhci_msm_pm_ops,
+		   .probe_type = PROBE_PREFER_ASYNCHRONOUS,
 	},
 };