Hans de Goede <hdegoede@xxxxxxxxxx> writes: > 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 That would be perfect. Specially with VBT info. > > Is there anything specific you would like to see in there? This is the info available for psr on my decoded vbt: BDB block 9 - PSR block: Panel 2 * Full link: no Require AUX to wakeup: no Lines to wait before link standby: 0 Idle frames to for PSR enable: 0 TP1 wakeup time: 5000 usec (0x32) TP2/TP3 wakeup time: 5000 usec (0x32) But now I realized that this bit that I'm talking about is actually on Block 2 and it is not currently being decoded: u16 psr_enabled:1; We need some work on igt tool apparently to decode this bit. So better to request users the undecoded version. > >>> 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. likely if SKL+ > >>> 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 ? It is about to land. So let's just wait a bit and ask for clean retest. Thanks a lot, Rodrigo. > >> 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 > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/intel-gfx _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
