[PATCH v2 0/2][SRU]{OEM-B]SATA device is not going to DEVSLP

[AceLan Kao]

>From the log I got from DVT2 machine, the disk is in off state during
short/long idle.
These 2 commits are not crucial and the power consumption looks pretty
good on DVT2 machine.

We got some margin pass number on DVT1 machine, and PM feels safer to
have these commits in the kernel.
We can wait and see and do more tests on DVT2 machines to see if we
really need the patches.

2018-07-20 2:15 GMT+08:00 Anthony Wong <anthony.wong at canonical.com>:
> On Wed, Jul 18, 2018 at 09:26:30AM +0800, AceLan Kao wrote:
>> BugLink: https://bugs.launchpad.net/bugs/1781533
>>
>> [Impact]
>> Any of the platforms we’ve been seeing SATA problems not going to deepest
>> state leading to other devices not getting there during long idle or
>> s2idle. And it also prevents the system from entering deeper PC state
>> other than PC3.
>>
>> [Test]
>> Verified the power consumption on some new platforms, it doesn't do too
>> much difference to the numbers, but it improves.
>>
>> [Fix]
>> Suggested from Intel and Dell to contains the 2 commits
>> https://patchwork.kernel.org/patch/10502285/
>> https://patchwork.kernel.org/patch/10502287/
>>
>> [Regression Potential]
>> Low, the production machines with suspend-to-idle enabled should have the
>> DEVSLP function been validated.
>>
>> [Misc]
>> Those commits do not show up in any public git tree yet, so let's verify
>> them in oem kernel first, and then will submit to bionic kernel later.
>>
>> Srinivas Pandruvada (2):
>>   UBUNTU: SAUCE: ata: libahci: Correct setting of DEVSLP register
>>   UBUNTU: SAUCE: ata: libahci: Allow reconfigure of DEVSLP register
>>
>>  drivers/ata/libahci.c | 20 ++++++++++++--------
>>  1 file changed, 12 insertions(+), 8 deletions(-)
>
> I am not totally against these patches but given upstream has not
> acked the patches makes me feel uneasy to even accept them in
> linux-oem.
>
> On verification, do we have any machines that show the problem that SATA
> devices fail to enter DEVSLP?
>
> Thanks,
> Anthony