(The only change in v2 is to add Jarkko's ack / tested-by)
PM Core allows buses and drivers to specify if they'd like their devices
to suspend/resume synchronously or asynchronously. When resuming:
1) SYNCHRONOUS DEVICES:
- All synchronous devices (system wide!) are resumed in a single thread,
serially i.e. one after the other. So their resume latencies add up,
and also, this results in unnecessary and unnatural waiting order.
In my current system (total resume time ~895ms) and this is the trend
on almost all chromebooks in the past 3-4 years (we carry patch3 in
our tree already, without which it would be even more worse):
https://rajatxjain.github.io/public_shared/resume_before_patches.html
As you can see I2C devices do not even begin to resume until 450ms,
waiting unnaturally for another device i915 to finish resuming:
I2C touchscreen device (resume latency = 374 ms) - asynchronous
-> (waiting on) I2C adapter resume (synchronous)
-> (waiting on) Designware resume (synchronous)
-> (waiting on) intel_backlight resume (synchronous)
-> (waiting on) its PARENT i915 resume (asynchronous resume
time = 376ms)
As you can see the two biggest resume routines are both run serially
after one another (even though they don't have any real dependency)
thus increasing the system critical resume path. If we can run them
concurrently, we can cut down the system resume time considerably.
2) ASYNCHRONOUS DEVICES:
- On the other hand, all asynchronous devices's resume routines are
scheduled so they can run in parallel with other asynchronous
routines. PM core still ensures for both async/sync devices that:
- All parent child relations are honored.
- Any device dependencies are honored. Device dependencies between
any 2 unrelated devices can be specified using device_link_add().
- Async resume devices are sychnronized at the end of each
suspend/resume phase, before moving onto next.
With these patches in place, the I2C devices can resume in parallel
with i915:
https://rajatxjain.github.io/public_shared/resume_after_patch.html
As far as I understand, the only reason we might not want a device to be
marked for asynchronous resume is if we suspect it cannot handle
concurrent resume with other devices, which does not look to be the
case.
This patchset marks the designware, the I2c adapters, and the i2c
clients for asynchronous suspend/resume. In case it helps to gain any
confidence, the patch 3 (for i2c clients) has been included and shipping
on all our chromebooks for the past 3+ years, and has not shown any
issues. The designware and i2c adapters should be easier.
Derek Basehore (1):
i2c: enable async suspend/resume on i2c client devices
Rajat Jain (2):
i2c: designware: Enable async suspend / resume of designware devices
i2c: enable async suspend/resume for i2c adapters
drivers/i2c/busses/i2c-designware-platdrv.c | 2 ++
drivers/i2c/i2c-core-base.c | 2 ++
2 files changed, 4 insertions(+)
--
2.33.0.1079.g6e70778dc9-goog
Enable async suspend/resume of i2c adapters. It enormously helps with
reducing the resume time of systems (as much as 20%-40%) where I2C devices
can take significant time (100s of ms) to resume.
Signed-off-by: Rajat Jain <[email protected]>
Tested-by: Jarkko Nikula <[email protected]>
---
v2: Add Jarkko's tested by
drivers/i2c/i2c-core-base.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 54964fbe3f03..8d4f2be54e17 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -1576,6 +1576,7 @@ static int i2c_register_adapter(struct i2c_adapter *adap)
if (res)
goto out_reg;
+ device_enable_async_suspend(&adap->dev);
pm_runtime_no_callbacks(&adap->dev);
pm_suspend_ignore_children(&adap->dev, true);
pm_runtime_enable(&adap->dev);
--
2.33.0.1079.g6e70778dc9-goog
From: Derek Basehore <[email protected]>
This enables the async suspend for i2c client devices. This reduces
the suspend/resume time considerably on platforms where i2c devices
can take a lot of time (hundreds of ms) to resume.
Signed-off-by: Derek Basehore <[email protected]>
Signed-off-by: Rajat Jain <[email protected]>
Tested-by: Jarkko Nikula <[email protected]>
---
v2: Add Jarkko's tested by
drivers/i2c/i2c-core-base.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 8d4f2be54e17..70d32efb68ef 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -1047,6 +1047,7 @@ i2c_new_client_device(struct i2c_adapter *adap, struct i2c_board_info const *inf
client->dev.of_node = of_node_get(info->of_node);
client->dev.fwnode = info->fwnode;
+ device_enable_async_suspend(&client->dev);
i2c_dev_set_name(adap, client, info);
if (info->swnode) {
--
2.33.0.1079.g6e70778dc9-goog
Mark the designware devices for asynchronous suspend. With this, the
resume for designware devices does not get stuck behind other unrelated
devices (e.g. intel_backlight that takes hundreds of ms to resume,
waiting for its parent devices).
Signed-off-by: Rajat Jain <[email protected]>
Acked-by: Jarkko Nikula <[email protected]>
Tested-by: Jarkko Nikula <[email protected]>
---
v2: Add Jarkko's ack / tested by
drivers/i2c/busses/i2c-designware-platdrv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
index 21113665ddea..2bd81abc86f6 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -293,6 +293,8 @@ static int dw_i2c_plat_probe(struct platform_device *pdev)
DPM_FLAG_MAY_SKIP_RESUME);
}
+ device_enable_async_suspend(&pdev->dev);
+
/* The code below assumes runtime PM to be disabled. */
WARN_ON(pm_runtime_enabled(&pdev->dev));
--
2.33.0.1079.g6e70778dc9-goog
Hi,
> As far as I understand, the only reason we might not want a device to be
> marked for asynchronous resume is if we suspect it cannot handle
> concurrent resume with other devices, which does not look to be the
> case.
Since parent-child relationships are handled, I'd say let us try this.
If there are siblings which depend on each other, I think they should be
marked with "device_link_add" anyhow. I am afraid we will encounter some
regressions with such siblings. However, I don't think there will be a
lot and the time savings for all Linux systems may be worth the
(hopefully) little hazzle.
> This patchset marks the designware, the I2c adapters, and the i2c
> clients for asynchronous suspend/resume. In case it helps to gain any
> confidence, the patch 3 (for i2c clients) has been included and shipping
> on all our chromebooks for the past 3+ years, and has not shown any
> issues. The designware and i2c adapters should be easier.
This in deed helps to gain confidence. I agree that the clients are
probably the most tricky ones. If that works on all Chromebooks for 3
years now, I am positive we can test this series in linux-next now.
Thanks for this work,
Wolfram
On Mon, Oct 25, 2021 at 02:35:29PM -0700, Rajat Jain wrote:
> Mark the designware devices for asynchronous suspend. With this, the
> resume for designware devices does not get stuck behind other unrelated
> devices (e.g. intel_backlight that takes hundreds of ms to resume,
> waiting for its parent devices).
>
> Signed-off-by: Rajat Jain <[email protected]>
> Acked-by: Jarkko Nikula <[email protected]>
> Tested-by: Jarkko Nikula <[email protected]>
Applied to for-next, thanks!
On Mon, Oct 25, 2021 at 02:35:31PM -0700, Rajat Jain wrote:
> From: Derek Basehore <[email protected]>
>
> This enables the async suspend for i2c client devices. This reduces
> the suspend/resume time considerably on platforms where i2c devices
> can take a lot of time (hundreds of ms) to resume.
>
> Signed-off-by: Derek Basehore <[email protected]>
> Signed-off-by: Rajat Jain <[email protected]>
> Tested-by: Jarkko Nikula <[email protected]>
Applied to for-next, thanks!
On Mon, Oct 25, 2021 at 02:35:30PM -0700, Rajat Jain wrote:
> Enable async suspend/resume of i2c adapters. It enormously helps with
> reducing the resume time of systems (as much as 20%-40%) where I2C devices
> can take significant time (100s of ms) to resume.
>
> Signed-off-by: Rajat Jain <[email protected]>
> Tested-by: Jarkko Nikula <[email protected]>
Applied to for-next, thanks!