[PATCH] ASoC: rt5682: Prefer async probe

[PATCH] ASoC: rt5682: Prefer async probe

[Douglas Anderson]

The probe of rt5682 is pretty slow.  A quick measurement shows that it
takes ~650 ms on at least one board.  There's no reason to block all
other drivers waiting for this probe to finish.  Set the flag to allow
other drivers to probe while we're probing.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
NOTE: I haven't done any analysis of the driver to see _why_ it's so
slow, only that I have measured it to be slow.  Someone could
certainly take the time to profile / optimize it, but in any case it
still won't hurt to be async.

This is a very safe flag to turn on since:

1. It's not like our probe order was defined by anything anyway.  When
we probe is at the whim of when our i2c controller probes and that can
be any time.

2. If some other driver needs us then they have to handle the fact
that we might not have probed yet anyway.

3. There may be other drivers probing at the same time as us anyway
because _they_ used async probe.

While I won't say that it's impossible to tickle a bug by turning on
async probe, I would assert that in almost all cases the bug was
already there and needed to be fixed anyway.

 sound/soc/codecs/rt5682-i2c.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/codecs/rt5682-i2c.c b/sound/soc/codecs/rt5682-i2c.c
index 85aba311bdc8..6b4e0eb30c89 100644
--- a/sound/soc/codecs/rt5682-i2c.c
+++ b/sound/soc/codecs/rt5682-i2c.c
@@ -294,6 +294,7 @@ static struct i2c_driver rt5682_i2c_driver = {
 		.name = "rt5682",
 		.of_match_table = rt5682_of_match,
 		.acpi_match_table = rt5682_acpi_match,
+		.probe_type = PROBE_PREFER_ASYNCHRONOUS,
 	},
 	.probe = rt5682_i2c_probe,
 	.shutdown = rt5682_i2c_shutdown,
-- 
2.28.0.402.g5ffc5be6b7-goog

[PATCH] ASoC: rt5682: Prefer async probe

[Douglas Anderson]

The probe of rt5682 is pretty slow.  A quick measurement shows that it
takes ~650 ms on at least one board.  There's no reason to block all
other drivers waiting for this probe to finish.  Set the flag to allow
other drivers to probe while we're probing.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
NOTE: I haven't done any analysis of the driver to see _why_ it's so
slow, only that I have measured it to be slow.  Someone could
certainly take the time to profile / optimize it, but in any case it
still won't hurt to be async.

This is a very safe flag to turn on since:

1. It's not like our probe order was defined by anything anyway.  When
we probe is at the whim of when our i2c controller probes and that can
be any time.

2. If some other driver needs us then they have to handle the fact
that we might not have probed yet anyway.

3. There may be other drivers probing at the same time as us anyway
because _they_ used async probe.

While I won't say that it's impossible to tickle a bug by turning on
async probe, I would assert that in almost all cases the bug was
already there and needed to be fixed anyway.

 sound/soc/codecs/rt5682-i2c.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/codecs/rt5682-i2c.c b/sound/soc/codecs/rt5682-i2c.c
index 85aba311bdc8..6b4e0eb30c89 100644
--- a/sound/soc/codecs/rt5682-i2c.c
+++ b/sound/soc/codecs/rt5682-i2c.c
@@ -294,6 +294,7 @@ static struct i2c_driver rt5682_i2c_driver = {
 		.name = "rt5682",
 		.of_match_table = rt5682_of_match,
 		.acpi_match_table = rt5682_acpi_match,
+		.probe_type = PROBE_PREFER_ASYNCHRONOUS,
 	},
 	.probe = rt5682_i2c_probe,
 	.shutdown = rt5682_i2c_shutdown,
-- 
2.28.0.402.g5ffc5be6b7-goog

Re: [PATCH] ASoC: rt5682: Prefer async probe

[Cheng-yi Chiang]

On Sat, Aug 29, 2020 at 7:20 AM Douglas Anderson <dianders@chromium.org> wrote:
>
> The probe of rt5682 is pretty slow.  A quick measurement shows that it
> takes ~650 ms on at least one board.  There's no reason to block all
> other drivers waiting for this probe to finish.  Set the flag to allow
> other drivers to probe while we're probing.
>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
> NOTE: I haven't done any analysis of the driver to see _why_ it's so
> slow, only that I have measured it to be slow.  Someone could
> certainly take the time to profile / optimize it, but in any case it
> still won't hurt to be async.


Hi Doug, thank you for the fix.

There are multiple usleep in the probe of rt5682 driver.
The major one is a 300 ms sleep after the regulator turns on.
There are other sleeps for several tens of ms.
>
>
> This is a very safe flag to turn on since:
>
> 1. It's not like our probe order was defined by anything anyway.  When
> we probe is at the whim of when our i2c controller probes and that can
> be any time.
>
> 2. If some other driver needs us then they have to handle the fact
> that we might not have probed yet anyway.


Agree.
soc-core already handled this by returning -EPROBE_DEFER when a
component is not found.
So the machine driver can probe again.
Even in the current behavior, we already see machine driver probe
again when the codec driver is not ready,
so I think adding this async flag will not affect the machine driver.

>
>
> 3. There may be other drivers probing at the same time as us anyway
> because _they_ used async probe.
>
> While I won't say that it's impossible to tickle a bug by turning on
> async probe, I would assert that in almost all cases the bug was
> already there and needed to be fixed anyway.
>
>  sound/soc/codecs/rt5682-i2c.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/sound/soc/codecs/rt5682-i2c.c b/sound/soc/codecs/rt5682-i2c.c
> index 85aba311bdc8..6b4e0eb30c89 100644
> --- a/sound/soc/codecs/rt5682-i2c.c
> +++ b/sound/soc/codecs/rt5682-i2c.c
> @@ -294,6 +294,7 @@ static struct i2c_driver rt5682_i2c_driver = {
>                 .name = "rt5682",
>                 .of_match_table = rt5682_of_match,
>                 .acpi_match_table = rt5682_acpi_match,
> +               .probe_type = PROBE_PREFER_ASYNCHRONOUS,


One thing I am wondering is that there has not been any usage in codec
driver for this.
I think every codec driver can use this, and take the benefit of a
possible faster boot time ?

>
>         },
>         .probe = rt5682_i2c_probe,
>         .shutdown = rt5682_i2c_shutdown,
> --
> 2.28.0.402.g5ffc5be6b7-goog
>

Re: [PATCH] ASoC: rt5682: Prefer async probe

[Cheng-yi Chiang]

On Sat, Aug 29, 2020 at 7:20 AM Douglas Anderson <dianders@chromium.org> wrote:
>
> The probe of rt5682 is pretty slow.  A quick measurement shows that it
> takes ~650 ms on at least one board.  There's no reason to block all
> other drivers waiting for this probe to finish.  Set the flag to allow
> other drivers to probe while we're probing.
>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
> NOTE: I haven't done any analysis of the driver to see _why_ it's so
> slow, only that I have measured it to be slow.  Someone could
> certainly take the time to profile / optimize it, but in any case it
> still won't hurt to be async.


Hi Doug, thank you for the fix.

There are multiple usleep in the probe of rt5682 driver.
The major one is a 300 ms sleep after the regulator turns on.
There are other sleeps for several tens of ms.
>
>
> This is a very safe flag to turn on since:
>
> 1. It's not like our probe order was defined by anything anyway.  When
> we probe is at the whim of when our i2c controller probes and that can
> be any time.
>
> 2. If some other driver needs us then they have to handle the fact
> that we might not have probed yet anyway.


Agree.
soc-core already handled this by returning -EPROBE_DEFER when a
component is not found.
So the machine driver can probe again.
Even in the current behavior, we already see machine driver probe
again when the codec driver is not ready,
so I think adding this async flag will not affect the machine driver.

>
>
> 3. There may be other drivers probing at the same time as us anyway
> because _they_ used async probe.
>
> While I won't say that it's impossible to tickle a bug by turning on
> async probe, I would assert that in almost all cases the bug was
> already there and needed to be fixed anyway.
>
>  sound/soc/codecs/rt5682-i2c.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/sound/soc/codecs/rt5682-i2c.c b/sound/soc/codecs/rt5682-i2c.c
> index 85aba311bdc8..6b4e0eb30c89 100644
> --- a/sound/soc/codecs/rt5682-i2c.c
> +++ b/sound/soc/codecs/rt5682-i2c.c
> @@ -294,6 +294,7 @@ static struct i2c_driver rt5682_i2c_driver = {
>                 .name = "rt5682",
>                 .of_match_table = rt5682_of_match,
>                 .acpi_match_table = rt5682_acpi_match,
> +               .probe_type = PROBE_PREFER_ASYNCHRONOUS,


One thing I am wondering is that there has not been any usage in codec
driver for this.
I think every codec driver can use this, and take the benefit of a
possible faster boot time ?

>
>         },
>         .probe = rt5682_i2c_probe,
>         .shutdown = rt5682_i2c_shutdown,
> --
> 2.28.0.402.g5ffc5be6b7-goog
>

Re: [PATCH] ASoC: rt5682: Prefer async probe

[Doug Anderson]

Hi,

On Sun, Aug 30, 2020 at 4:05 AM Cheng-yi Chiang <cychiang@chromium.org> wrote:
>
> > @@ -294,6 +294,7 @@ static struct i2c_driver rt5682_i2c_driver = {
> >                 .name = "rt5682",
> >                 .of_match_table = rt5682_of_match,
> >                 .acpi_match_table = rt5682_acpi_match,
> > +               .probe_type = PROBE_PREFER_ASYNCHRONOUS,
>
>
> One thing I am wondering is that there has not been any usage in codec
> driver for this.
> I think every codec driver can use this, and take the benefit of a
> possible faster boot time ?

One possibility is that they are all enabled as modules instead of
builtin to the kernel so nobody ever thought to do it.  Modules are
always probed asynchronously, so this flag is basically a no-op there
(and, in fact, for anything that can be built as a module we have even
more certainty that async probe is safe).

In the case of the Chrome OS 5.4 tree it's possible this driver should
be moved to a module.  However, even if we do that my patch is still
fine and would be helpful if anyone has a reason to build this driver
in.  Similar patches could likely be made to other codecs and would
similarly speed up boots in cases where codecs were builtin.

-Doug

Re: [PATCH] ASoC: rt5682: Prefer async probe

[Doug Anderson]

Hi,

On Sun, Aug 30, 2020 at 4:05 AM Cheng-yi Chiang <cychiang@chromium.org> wrote:
>
> > @@ -294,6 +294,7 @@ static struct i2c_driver rt5682_i2c_driver = {
> >                 .name = "rt5682",
> >                 .of_match_table = rt5682_of_match,
> >                 .acpi_match_table = rt5682_acpi_match,
> > +               .probe_type = PROBE_PREFER_ASYNCHRONOUS,
>
>
> One thing I am wondering is that there has not been any usage in codec
> driver for this.
> I think every codec driver can use this, and take the benefit of a
> possible faster boot time ?

One possibility is that they are all enabled as modules instead of
builtin to the kernel so nobody ever thought to do it.  Modules are
always probed asynchronously, so this flag is basically a no-op there
(and, in fact, for anything that can be built as a module we have even
more certainty that async probe is safe).

In the case of the Chrome OS 5.4 tree it's possible this driver should
be moved to a module.  However, even if we do that my patch is still
fine and would be helpful if anyone has a reason to build this driver
in.  Similar patches could likely be made to other codecs and would
similarly speed up boots in cases where codecs were builtin.

-Doug

Re: [PATCH] ASoC: rt5682: Prefer async probe

[Mark Brown]

On Fri, 28 Aug 2020 16:20:27 -0700, Douglas Anderson wrote:
> The probe of rt5682 is pretty slow.  A quick measurement shows that it
> takes ~650 ms on at least one board.  There's no reason to block all
> other drivers waiting for this probe to finish.  Set the flag to allow
> other drivers to probe while we're probing.

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Thanks!

[1/1] ASoC: rt5682: Prefer async probe
      commit: 160c174ff6972bb56bf48ac3335297889839e1f1

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

Re: [PATCH] ASoC: rt5682: Prefer async probe

[Mark Brown]

On Fri, 28 Aug 2020 16:20:27 -0700, Douglas Anderson wrote:
> The probe of rt5682 is pretty slow.  A quick measurement shows that it
> takes ~650 ms on at least one board.  There's no reason to block all
> other drivers waiting for this probe to finish.  Set the flag to allow
> other drivers to probe while we're probing.

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Thanks!

[1/1] ASoC: rt5682: Prefer async probe
      commit: 160c174ff6972bb56bf48ac3335297889839e1f1

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark