Skip to contentSkip to conversation

i2c/designware: enable i2c controller to suspend/resume asynchronously

PATCH In review Fu, Zhonghui 4 participants 5 messages Jan 15, 2016 – Mar 8, 2016

Subsystems (3)

v2 of 3 In review Latest is v3 →

lore
Share & tools
lore
#0 lore raw

PATCH v2 1/1 i2c/designware: enable i2c controller to suspend/resume asynchronously

Now, PM core supports asynchronous suspend/resume mode for devices during system suspend/resume, and the power state transition of one device may be completed in separate kernel thread. PM core ensures all power state transition dependency between devices. This patch enables designware i2c controllers to suspend/resume asynchronously. This will take advantage of multicore and improve system suspend/resume speed. After enabling all i2c devices, i2c adapters and i2c controllers on ASUS T100TA tablet, the system suspend-to-idle time is reduced to about 510ms from 750ms, and the system resume time is reduced to about 790ms from 900ms.

---
Changes in v2:
- Move the device_enable_async_suspend() call into i2c_dw_proble()

 drivers/i2c/busses/i2c-designware-core.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
drivers/i2c/busses/i2c-designware-core.c +1 -0
index ba9732c..5d6ad27 100644
@@ -861,6 +861,7 @@ int i2c_dw_probe(struct dw_i2c_dev *dev)
 
 	init_completion(&dev->cmd_complete);
 	mutex_init(&dev->lock);
+	device_enable_async_suspend(dev->dev);
 
 	r = i2c_dw_init(dev);
 	if (r)

-- 1.7.1

#1 lore raw
Quoted 24 lines · Zhonghui

Now, PM core supports asynchronous suspend/resume mode for devices during system suspend/resume, and the power state transition of one device may be completed in separate kernel thread. PM core ensures all power state transition dependency between devices. This patch enables designware i2c controllers to suspend/resume asynchronously. This will take advantage of multicore and improve system suspend/resume speed. After enabling all i2c devices, i2c adapters and i2c controllers on ASUS T100TA tablet, the system suspend-to-idle time is reduced to about 510ms from 750ms, and the system resume time is reduced to about 790ms from 900ms.

---
Changes in v2:
- Move the device_enable_async_suspend() call into i2c_dw_proble()

  drivers/i2c/busses/i2c-designware-core.c |    1 +
  1 files changed, 1 insertions(+), 0 deletions(-)
drivers/i2c/busses/i2c-designware-core.c +0 -0
index ba9732c..5d6ad27 100644

drivers/i2c/busses/i2c-designware-core.c int i2c_dw_probe(struct dw_i2c_dev *dev) · line 865

Quoted 5 lines
drivers/i2c/busses/i2c-designware-core.c +1 -0
@@ -861,6 +861,7 @@ int i2c_dw_probe(struct dw_i2c_dev *dev)
 
  	init_completion(&dev->cmd_complete);
  	mutex_init(&dev->lock);
+	device_enable_async_suspend(dev->dev);
 

I'm aware Andy had concerns about about stability and you also mention in another thread:

"if enable all LPSS devices suspend/resume asynchronously, the system can't resume sometimes on ASUS T100TA(BayTrail-T SoC). But, I have verified that the system can resume normally every time if enable only i2c controller async mode and let other LPSS devices in sync mode on ASUS T100TA.".

What I'm thinking would this change move things forward and help to find out what potential underlying issues there are in LPSS code.

I'm fine with this I2C side change but can we assure we don't accidentally enable the same on other LPSS devices before finding the root cause for the crash?

Signature · 1 line
Jarkko
#2 lore raw
Quoted 48 lines · Jarkko Nikula
Quoted 30 lines · Zhonghui

Now, PM core supports asynchronous suspend/resume mode for devices during system suspend/resume, and the power state transition of one device may be completed in separate kernel thread. PM core ensures all power state transition dependency between devices. This patch enables designware i2c controllers to suspend/resume asynchronously.
This will take advantage of multicore and improve system suspend/resume
speed. After enabling all i2c devices, i2c adapters and i2c controllers
on ASUS T100TA tablet, the system suspend-to-idle time is reduced to
about 510ms from 750ms, and the system resume time is reduced to about
790ms from 900ms.

---
Changes in v2:
- Move the device_enable_async_suspend() call into i2c_dw_proble()

  drivers/i2c/busses/i2c-designware-core.c |    1 +

  1 files changed, 1 insertions(+), 0 deletions(-)
drivers/i2c/busses/i2c-designware-core.c +0 -0
index ba9732c..5d6ad27 100644

drivers/i2c/busses/i2c-designware-core.c int i2c_dw_probe(struct dw_i2c_dev *dev) · line 865

Quoted 5 lines
drivers/i2c/busses/i2c-designware-core.c +1 -0
@@ -861,6 +861,7 @@ int i2c_dw_probe(struct dw_i2c_dev *dev)
 
   	init_completion(&dev->cmd_complete);
   	mutex_init(&dev->lock);
+	device_enable_async_suspend(dev->dev);
 

I'm aware Andy had concerns about about stability and you also mention
in another thread:

"if enable all LPSS devices suspend/resume asynchronously, the system
can't resume sometimes on ASUS T100TA(BayTrail-T SoC). But, I have verified that the system can resume normally every time if enable only
i2c controller async mode and let other LPSS devices in sync mode on ASUS T100TA.".

Quoted 8 lines

What I'm thinking would this change move things forward and help to find
out what potential underlying issues there are in LPSS code.

I'm fine with this I2C side change but can we assure we don't accidentally enable the same on other LPSS devices before finding the
root cause for the crash?

Besides that we have to be really aware about DMA power related fix introduced in v4.5-rc1 in acpi_lpss.c [1]. So, I would like to see a wide testing especially on Intel Baytrail / Braswell platforms before enabling it.

[1] http://comments.gmane.org/gmane.linux.acpi.devel/80263

Signature · 2 lines
Andy Shevchenko <[email protected]>
Intel Finland Oy
#3 lore raw
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines

device may be completed in separate kernel thread. PM core ensures all power state transition dependency between devices. This patch

I'd like an Ack on that from a PM maintainer, because I think chips like PMICs are special and might not be covered by the generic case...

Quoted 4 lines

Besides that we have to be really aware about DMA power related fix introduced in v4.5-rc1 in acpi_lpss.c [1]. So, I would like to see a wide testing especially on Intel Baytrail / Braswell platforms before enabling it.

And this one, too.

#4 lore raw
Quoted 10 lines · Wolfram Sang
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

device may be completed in separate kernel thread. PM core ensures all power state transition dependency between devices. This patch

I'd like an Ack on that from a PM maintainer, because I think chips like PMICs are special and might not be covered by the generic case...

Quoted 4 lines

Besides that we have to be really aware about DMA power related fix introduced in v4.5-rc1 in acpi_lpss.c [1]. So, I would like to see a wide testing especially on Intel Baytrail / Braswell platforms before enabling it.

And this one, too.

Because of long leave, so sorry for very late reply.

I agree with you. Need more investigation and test for this patch before enabling it.

Thanks,
Zhonghui

Quoted 1 line