From: Douglas Anderson <dianders@chromium.org> To: Mark Brown <broonie@kernel.org> Cc: cychiang@chromium.org, Douglas Anderson <dianders@chromium.org>, Jaroslav Kysela <perex@perex.cz>, Liam Girdwood <lgirdwood@gmail.com>, Oder Chiou <oder_chiou@realtek.com>, Takashi Iwai <tiwai@suse.com>, alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org Subject: [PATCH] ASoC: rt5682: Prefer async probe Date: Fri, 28 Aug 2020 16:20:27 -0700 [thread overview] Message-ID: <20200828162005.1.I4f67f494c4f759b0e5c7f487e040dfdcf16e0876@changeid> (raw) 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
WARNING: multiple messages have this Message-ID (diff)
From: Douglas Anderson <dianders@chromium.org> To: Mark Brown <broonie@kernel.org> Cc: Oder Chiou <oder_chiou@realtek.com>, alsa-devel@alsa-project.org, Douglas Anderson <dianders@chromium.org>, linux-kernel@vger.kernel.org, Liam Girdwood <lgirdwood@gmail.com>, Takashi Iwai <tiwai@suse.com>, cychiang@chromium.org Subject: [PATCH] ASoC: rt5682: Prefer async probe Date: Fri, 28 Aug 2020 16:20:27 -0700 [thread overview] Message-ID: <20200828162005.1.I4f67f494c4f759b0e5c7f487e040dfdcf16e0876@changeid> (raw) 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
next reply other threads:[~2020-08-28 23:20 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-08-28 23:20 Douglas Anderson [this message] 2020-08-28 23:20 ` [PATCH] ASoC: rt5682: Prefer async probe Douglas Anderson 2020-08-30 11:04 ` Cheng-yi Chiang 2020-08-30 11:04 ` Cheng-yi Chiang 2020-08-30 16:22 ` Doug Anderson 2020-08-30 16:22 ` Doug Anderson 2020-09-01 14:50 ` Mark Brown 2020-09-01 14:50 ` Mark Brown
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200828162005.1.I4f67f494c4f759b0e5c7f487e040dfdcf16e0876@changeid \ --to=dianders@chromium.org \ --cc=alsa-devel@alsa-project.org \ --cc=broonie@kernel.org \ --cc=cychiang@chromium.org \ --cc=lgirdwood@gmail.com \ --cc=linux-kernel@vger.kernel.org \ --cc=oder_chiou@realtek.com \ --cc=perex@perex.cz \ --cc=tiwai@suse.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.