Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1323215 > unrolled thread

Re: [PATCH v2] i2c/designware: enable i2c controller to suspend/resume asynchronously

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v2] i2c/designware: enable i2c controller to  suspend/resume asynchronously Jarkko Nikula <jarkko.nikula@linux.intel.com> - 2016-02-01 16:10 +0100
    Re: [PATCH v2] i2c/designware: enable i2c controller to  suspend/resume asynchronously Andy Shevchenko <andriy.shevchenko@linux.intel.com> - 2016-02-01 16:20 +0100
      Re: [PATCH v2] i2c/designware: enable i2c controller to  suspend/resume asynchronously Wolfram Sang <wsa@the-dreams.de> - 2016-02-01 17:00 +0100

#1323215 — Re: [PATCH v2] i2c/designware: enable i2c controller to suspend/resume asynchronously

On 01/15/2016 08:38 AM, Fu, Zhonghui wrote:
> 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.
>
> Signed-off-by: Zhonghui Fu <zhonghui.fu@linux.intel.com>
> ---
> 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(-)
>
> diff --git a/drivers/i2c/busses/i2c-designware-core.c b/drivers/i2c/busses/i2c-designware-core.c
> index ba9732c..5d6ad27 100644
> --- a/drivers/i2c/busses/i2c-designware-core.c
> +++ b/drivers/i2c/busses/i2c-designware-core.c
> @@ -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?

-- 
Jarkko

[toc] | [next] | [standalone]

#1323225

On Mon, 2016-02-01 at 17:04 +0200, Jarkko Nikula wrote:
> On 01/15/2016 08:38 AM, Fu, Zhonghui wrote:
> > 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.
> > 
> > Signed-off-by: Zhonghui Fu <zhonghui.fu@linux.intel.com>
> > ---
> > 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(-)
> > 
> > diff --git a/drivers/i2c/busses/i2c-designware-core.c
> > b/drivers/i2c/busses/i2c-designware-core.c
> > index ba9732c..5d6ad27 100644
> > --- a/drivers/i2c/busses/i2c-designware-core.c
> > +++ b/drivers/i2c/busses/i2c-designware-core.c
> > @@ -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?

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

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

[toc] | [prev] | [next] | [standalone]

#1323271

[Multipart message — attachments visible in raw view] — view raw

> > > 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...

> 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.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web