Hi,
On 06-02-18 00:14, Rodrigo Vivi wrote:
Hi Hans,
On Fri, Feb 02, 2018 at 09:55:32AM +0000, Hans de Goede wrote:
Hi,
On 01-02-18 13:31, Hans de Goede wrote:
Hi All,
As you may have heard I've recently been working on improving
Linux laptop battery life, specifically the OOTB experience
without tweaking any options such as e.g. powertop --auto-tune
would do, see:
https://fedoraproject.org/wiki/Changes/ImprovedLaptopBatteryLife
First of all thank you very much for triggering that. It's been
so helpful.
Also sorry for not having replied sooner here.
So far this is going quite nicely, it looks like Fedora 28
will have SATA ALPM (big win), autosuspend of USB Bluetooth HCIs
and snd_intel_hda powersaving all enabled OOTB.
Looking for more savings I've run some quick tests with
i915.enable_psr=1, this seems to be another nice win (for an idle
system) of aprox. 0.5W.
So as with the other 3 items I just mentioned I'm now looking into
somehow enabling this be default, at least one some models.
Currently I'm thinking doing a whitelist or blacklist (*) for this,
but first I think we need some more data about on how much models
this just works and where it is causing issues, as such I've done
a blog post to gather this data:
https://hansdegoede.livejournal.com/18653.html
So I will revisit this eventually, once people have had some time
to respond to this blog-post.
In the mean time I wonder if anyone can explain why this options
is currently disabled by default. E.g. are there any known specific
models laptops / panels which are causing issues, are the bugzillas
for this? Etc. ?
Also does anyone know if any problems are mainly panel or laptop
model specific ? I would expect this to mostly be panel specific
and not depend on the model laptop (given then certain models
ship with different panels over their production lifetime).
Regards,
Hans
p.s.
If anyone on this list can make 10 minutes to run the tests
described in my blogpost and gather the data mentioned there, then
that would be great.
*) I know that maintaining such a white/blacklist in the kernel
is going to be a pain, so my current thinking on this is to make
this runtime configurable through a sysfs attribute and then
use a udev rule + udev hwdb entries for this.
So a quick update on this. The response has been quite overwhelming,
with well over 50 test-reports received sofar. The results are all
over the place, some people see no changes, some people report the
aprox. 0.5W saving my own test show and many people also report
display problems, sometimes combined with a significant increase in
power-consumption.
Do you have that public somewhere? I couldn't see the comments on your blog
or on wiki.
Not yet, I asked people to email me their results and the response has
been quite overwhelming and I've been busy with other stuff, I do plan
to eventually build a table with all the info like the SATA one here:
https://fedoraproject.org/wiki/Changes/ImprovedLaptopBatteryLife#How_To_Test
Is there anything specific you would like to see in there?
I need to take a closer look at all the results, but right now I
believe that the best way forward with this is (unfortunately) a
whitelist matching on a combination of panel-id (from edid) and
dmi data, so that we can at least enable this on popular models
(any model with atleast one user willing to contribute).
First I'd like to check what platform people used on the test.
Right, this is why I asked for "cat /proc/cpuinfo | grep "model name""
output so that we will know which iGPU generation people are
using. I've also asked for vendor + model name of the laptop.
Also on SKL+ platforms I expect bad issues since https://patchwork.freedesktop.org/series/37598/
is not merged yet. Anyone using DC state plus this will probably
have a bad experience.
Ah, that may explain quite a few of the failure reports I've
received.
So intel-gfx-team folks any input from your side, any feedback
on the plan to use a udev rule + udev hwdb entries to build a
whitelist for this?
It would be interesting to collect the /sys/kernel/debug/dri/0/i915_vbt
Is it possible to get back to these people asking this?
Yes I can ask everyone who has done testing to send me their vbt. I've
this email alias with all people who have responded in Bcc, so I can e.g.
also ask skylake+ users to re-test once:
https://patchwork.freedesktop.org/series/37598/
Has landed, or maybe re-test now with a kenrel-cmdline option to
work around the issue ?
There is one particular field on VBT that is the OEM > telling it is safe to enable PSR with windows on that particular laptop.
Sounds like useful info to put in the table of test-results
I plan to create. Can you provide a tool (perl script, whatever) to
extract this from a vbt dump?
So far we are ignoring this, but I believe we should start respecting
that. Maybe with that we could avoid the white list.
I want to avoid at maximum any kind of white list because it would be hard
to maintain and hard to expand.
And at this point we have known issues and this possibility of
the vbt list. So let's investigate before adopting this strategy.
What do you think?
Using the VBT field sounds like an excellent solution and when I get
around to extracting the info from all the mails I've received from
testers, then we can see if there is a good correlation between
people reporting issues and this bit being 0.
Note ideally their would also be a good correlation between the bit
being 1 and people reporting success, but if this bit allows us to
enable PSR on some models and avoid regressions that would be a good
start.
Regards,
Hans
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
