[PATCH 0/8] Enable eDP PSR functionality at HSW - v3

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

 



Yeah, I completely agree with you. This is the reason of that
separated 2 lines patch 8/8.

On Mon, Mar 4, 2013 at 8:27 PM, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Thu, Feb 28, 2013 at 08:02:18PM +0200, Ville Syrj?l? wrote:
>> On Thu, Feb 28, 2013 at 02:52:32PM -0300, Paulo Zanoni wrote:
>> > Hi
>> >
>> > 2013/2/25 Rodrigo Vivi <rodrigo.vivi at gmail.com>:
>> > > PSR is an eDP feature that allows power saving even with static image at eDP screen.
>> > >
>> > > v3: Accepted many suggestions that I received at v2 review, fixing, cleaning and improving the code.
>> > >
>> > > v2: Main differences in this v2:
>> > > - Created vbt struct to get i915 dev_priv more organized and to avoid adding more stuff into it.
>> > > - migrated hsw macros to use transcoder instead of pipes than I could address eDP
>> > > - remove patch that was only adding edp psr registers and added them on demand
>> > >
>> > > v1:
>> > > Shobit Kumar has implemented this patch series some time ago, but had no eDP panel with PSR capability to test them.
>> > >
>> > > I could test and verify that this series fully identify PSR capability and enables it at HSW.
>> > > I also verified that it saves from 0.5-1W but only when in blank screen. It seems it is not really entering in sleeping mode with static image at eDP screen yet.
>> >
>> > What do you mean with "blank screen"? It seems we disable PSR before
>> > blanking the screen, so the 0.5-1W saving could be from the backlight.
>> > Did you try masking more bits on the SRD_DEBUG register to see if it
>> > enters PSR more easily? The first test I'd try would be to set 1 to
>> > all those mask regs and see what happens (maybe we'll enter PSR and
>> > never ever leave it again?).
>>
>> One thing I'm wondering if we can even enable PSR w/o implementing the
>> FBC tracking bits. I mean what happens if someone renders to the front
>> buffer while PSR is active?
>
> This is actually my main concern with PSR enabling - our current FBC code
> is broken, and historically the hw is not one iota better :( Worst case we
> need to manually detect frontbuffer rendering and disable PSR ...
>
> Imo this needs to be resolved before we can enable PSR by default
> anywhere.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx



--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br


[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux