Re: [PATCH] i2c: designware: Do nothing in system suspend/resume when RT suspended

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

+Cc: Hans.

On Wed, 2017-06-21 at 16:40 +0200, Ulf Hansson wrote:
> On 20 June 2017 at 18:08, Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Tue, 2017-06-20 at 15:07 +0200, Ulf Hansson wrote:
> > > On 16 June 2017 at 15:49, Ulf Hansson <ulf.hansson@linaro.org>
> > > wrote:
> > > > Jarkko, Andy,
> > > > 
> > > > I just wanted to mention that I haven't forgot about this, I am
> > > > doing
> > > > the final changes for the ACPI PM domain at this very moment,
> > > > however
> > > > I need a couple of more days more before I can post something.
> > > > 

> > I have gone through the series briefly.
> > My concern is a quite nasty bug we have workaround for in
> > acpi_lpss.c,
> > i.e. auto power gating of DesignWare DMA on Intel Braswell
> > (CherryTrail)
> > platforms when it's enumerated via ACPI.
> 
> First, as long as there is no driver calling the new API
> acpi_dev_disable_direct_comlete(), the ACPI PM domain should behave
> exactly the same as before these changes.
> 
> However, regarding your concern, can you please be a bit more precise
> on how you deal with the problems. I would appreciate if you could
> give me real pointers to the code for the workaround, the above is too
> hand wavy for me to understand.

In acpi_lpss.c there are big comments about this issue.

Hans, Cc'ed, is working on that in relation to PWM power problems.

> 
> So where things really starts to change is in the final i2c patch in
> the series, which converts the i2c designware platform driver to use
> the runtime PM centric approach, and to do that, it calls the
> acpi_dev_disable_direct_complete().

Does it mean we will loose a possibility to use DMA for I2C (not much I
care about and would be unlikely a user for this, just wondering)?

> > 
> > Below is the sequence to test if it works and survives removal and
> > system sleep (lpss-power.sh is the script which shows a power state
> > of
> > selected devices along with PMC Atom status registers and runtime
> > PM):
> > 
> >    0 lpss-power.sh
> >    1 mount -t debugfs none /sys/kernel/debug
> >    2 lpss-power.sh
> >    3 modprobe i2c-designware-platform
> >    4 lpss-power.sh
> >    5 modprobe sdhci-acpi
> >    6 lpss-power.sh
> >    7 lsmod
> >    8 modprobe dw-dmac
> >    9 lpss-power.sh
> >   10 modprobe -r dw-dmac
> >   11 lpss-power.sh
> >   12 modprobe dw-dmac
> >   13 lpss-power.sh
> >   14 rtcwake -m mem -s3
> >   15 lpss-power.sh
> >   16 modprobe -r dw-dmac
> >   17 lpss-power.sh
> >   18 modprobe dw-dmac
> >   19 lpss-power.sh
> >   20 stty -F /dev/ttyS2 921600
> >   21 dmesg > /dev/ttyS2
> >   22 cat /proc/interrupts
> >   23 cat < /dev/ttyS1
> >   24 lpss-power.sh
> >   25 cat < /dev/ttyS1 &
> >   26 lpss-power.sh
> >   27 rtcwake -m mem -s3
> >   28 lpss-power.sh
> >   29 fg
> >   30 lpss-power.sh
> > 
> > Be aware that DMA is not enabled for I2C!
> 
> So if DMA isn't enabled for I2C, what is there to worry about?

Since LPSS are all in the same ACPI PM, and I would really carefully
change behaviour for any of LPSS component driver without wide testing.

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