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@xxxxxxxxx>: > > > 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel