Re: Enabling i915 Panel Self Refresh by default on some devices ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux