On 27/04/18 10:16, Hans de Goede wrote:
Hi,
On 27-04-18 11:07, Alan Jenkins wrote:
On 27/04/18 09:36, Hans de Goede wrote:
Hi,
On 27-04-18 10:33, Alan Jenkins wrote:
In v4.16 I read the new Kconfig, it looks the default for laptops
has changed to preserve the LPM value set by firmware. And that
this default is carried into Fedora 27 now.
$ grep MOBILE /boot/config-4.16.3-200.fc27.x86_64
CONFIG_SATA_MOBILE_LPM_POLICY=0
+ help
+ Select the Default SATA Link Power Management (LPM) policy
to use
+ for mobile / laptop variants of chipsets / "South Bridges".
+
+ The value set has the following meanings:
+ 0 => Keep firmware settings
But the code doesn't seem to match. In `enum ata_lpm_policy`, 0 is
ATA_LPM_UNKNOWN (and there is no FIRMWARE value at all). I cannot
write "firmware" as an LPM value. And booting this Fedora kernel,
reading the LPM value still shows "max_performance".
Can the Kconfig help text be clarified?
The Kconfig help-text is correct, a setting of 0 / ATA_LPM_UNKNOWN
causes the libata code
to not make any changes to LPM settings, so it preserves whatever
the firmware set.
But the sysfs interface has never known about this and always
reported the ATA_LPM_UNKNOWN
setting (which has been the default for basically ever) as
"max_performance".
So the Kconfig help-text is correct (to the best of my knowledge)
but indeed when
compared to the sysfs value it is a bit confusing.
Regards,
Hans
Hi
Odd, that's not what I understood from Matthew Garret's 2015 posts,
and I assume you wouldn't count some post-2015 change as "forever".
> In fact, right now we even remove any existing SATA power
management configuration that the firmware has initialised.
- https://mjg59.dreamwidth.org/34868.html
His patches had to add code to save the firmware settings, as well as
adding a new "firmware_default" policy (oops, not "firmware").
- https://lkml.org/lkml/2015/4/18/76
The code changing the LPM settings is guarded by this check:
if (link->lpm_policy != ap->target_lpm_policy)
Where link->lpm_policy always gets initialized to ATA_LPM_UNKNOWN
and ap->target_lpm_policy gets set to the Kconfig default (*) or
the value written to sysfs.
So when the policy is set to ATA_LPM_UNKNOWN we are not making
any changes,
Ah, right. That's very much what it looks like.
I checked the replies on those links and didn't see anything concrete to
disprove it i.e. reports of "firmware_defaults" saving power.
A bit confusing yes, particularly if we managed to confuse Matthew and
got him to publish something not strictly correct :).
but it could be that we are doing a reset somewhere
which override the firmware values and replace them with the
por (power-on-reset) default values.
So maybe we should change the Kconfig help for 0 from
"Keep firmware settings" to "Default"?
Regards,
Hans
*) The Kconfig default only applies to chipsets which are marked as
"mobile", so this should only be used on laptops and some HTPC-ish
boxes which use a mobile chipset.
I'm only guessing, but it sounds like an error could cause a reset, and
discard the firmware LPM setting.
That might be a reason not to advertise LPM_UNKNOWN in the same terms as
the proposed "firmware_defaults". I.e. probably it does the same thing
in practice, but we didn't consciously decide to provide that guarantee...
Then I don't have an idea how to clarify it in Kconfig.
As you say, the real confusion comes from the sysfs file. In principle
it might be "fixed" by removing LPM_UNKNOWN as an option for
`ap->target_lpm_policy` in favour of "firmware_defaults"...
or minimally: not lying, showing it as a value "unknown" in sysfs, which
cannot be set at runtime. That might be nicer for testers.
Thanks again! For explaining this so patiently. And for working on
this in general. I'm 90% sure my laptop firmware doesn't set LPM. It
definitely seems a big win in powertop.[*]
[*] (I had to stop enabling the full `powertop --autotune` in my
personal boot scripts, because _something_ in it was causing an
occasional lockup on resume from suspend. Dell Lattitude E5450).
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
