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@xxxxxxxx> 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@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 > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Rodrigo Vivi Blog: http://blog.vivi.eng.br _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel