On Wed, Jan 31, 2024 at 04:56:27PM +0800, Jian-Hong Pan wrote:
> Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx> 於 2024年1月30日 週二 下午6:13寫道：
> >
> > Hi,
> >
> > On Tue, Jan 30, 2024 at 05:59:33PM +0800, Jian-Hong Pan wrote:
> > > Some systems, like ASUS B1400CEAE equipped with the SATA controller
> > > [8086:a0d3] can use LPM policy to save power, especially for s2idle.
> > >
> > > However, the same controller may be failed on other platforms. So,
> > > commit (ata: ahci: Revert "ata: ahci: Add Tiger Lake UP{3,4} AHCI
> > > controller") drops LPM policy for [8086:a0d3]. But, this blocks going
> > > to deeper CPU Package C-state when s2idle with enabled Intel VMD.
> >
> > Tiger Lake really should support this with no issues (as are the
> > generations after it). I suggest trying to figure out what was the root
> > cause of the original problem that triggered the revert, if possible at
> > all, perhaps it is is something not related to LPM and that would allow
> > us to enable this unconditionally on all Tiger Lake.
> >
> > I'm pretty sure the platform where this was reported suffers the same
> > s2idle issue you are seeing without this patch.
>
> Simply applying LPM policy to [8086:a0d3] sounds like a good idea!
>
> I installed an SATA storage into ASUS B1400CEAE and tested with
> enabled & disabled VMD again. Both the NVMe and SATA storage work with
> applying LPM policy to [8086:a0d3], which means that it does not hit
> the issue mentioned in the commit (ata: ahci: Revert "ata: ahci: Add
> Tiger Lake UP{3,4} AHCI controller").
We would like to enable LPM for Tiger Lake again, but last time we tried
to do so, we got a bunch of reports:
https://bugzilla.kernel.org/show_bug.cgi?id=217114
https://bbs.archlinux.org/viewtopic.php?id=283906
Where people complained that their SATA drive dissappeared as a result.
The bug reports were reported on the following hardware:
ASUS Vivobook 15 X513EAN
Lenovo L3-15ITL6 IdeaPad
Acer A515-56-32DK
Acer A514
HP Pavilion 14-dv0589na
Usually, when a single vendor manages to mess something up in their
platform firmware, and we deal with that by adding a quirk for that
specific vendor.
But here it is four different vendors... This kind of suggests that
there could be a some more fundamental LPM related issue at play here.
Yes, we are fully aware that on some other platforms, not having
LPM enabled stops those platforms from entering the lowest CPU power
states. So right now we are doomed if we do enable LPM, doomed if we
don't.
However, having some systems drawing more power than needed is better
than some other systems not detecting their SATA drives at all.
Unfortunately, we don't have any of these laptops that has a Tiger Lake
AHCI controller (with a disappearing drive), so until someone who does
debugs this, I think we are stuck at status quo.
Kind regards,
Niklas
