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. > > 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. 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. > > 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? There is one particular field on VBT that is the OEM telling it is safe to enable PSR with windows on that particular laptop. 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? Thanks, Rodrigo. > > Regards, > > Hans > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
