Commit 52f5b683 authored by Douglas Anderson's avatar Douglas Anderson Committed by Jonathan Cameron

iio: sx9310: Prefer async probe

On one board I found that:
  probe of 5-0028 returned 1 after 259547 usecs

While some of this time is attributable to the pile of i2c transfers
that we do at probe time, the lion's share (over 200 ms) is sitting
waiting in the polling loop in sx9310_init_compensation() waiting for
the hardware to indicate that it's done.

There's no reason to block probe of all other devices on our probe.
Turn on async probe.
Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
Reviewed-by: default avatarStephen Boyd <swboyd@chromium.org>
Reviewed-by: default avatarDaniel Campello <campello@chromium.org>
Link: https://lore.kernel.org/r/20200901081920.v2.1.Id02b2f451b3eed71ddd580f4b8b44b3e33e84970@changeidSigned-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
parent aa06b6f4
...@@ -1056,6 +1056,13 @@ static struct i2c_driver sx9310_driver = { ...@@ -1056,6 +1056,13 @@ static struct i2c_driver sx9310_driver = {
.acpi_match_table = sx9310_acpi_match, .acpi_match_table = sx9310_acpi_match,
.of_match_table = sx9310_of_match, .of_match_table = sx9310_of_match,
.pm = &sx9310_pm_ops, .pm = &sx9310_pm_ops,
/*
* Lots of i2c transfers in probe + over 200 ms waiting in
* sx9310_init_compensation() mean a slow probe; prefer async
* so we don't delay boot if we're builtin to the kernel.
*/
.probe_type = PROBE_PREFER_ASYNCHRONOUS,
}, },
.probe_new = sx9310_probe, .probe_new = sx9310_probe,
.id_table = sx9310_id, .id_table = sx9310_id,
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment