[Intel-gfx] [PATCH] drm/i915: Add Baytrail PSR Support.

Chris Wilson chris at chris-wilson.co.uk
Sat Feb 1 12:34:02 CET 2014


On Wed, Jan 29, 2014 at 08:21:41PM +0100, Daniel Vetter wrote:
> On Wed, Jan 29, 2014 at 12:55:35PM -0200, Rodrigo Vivi wrote:
> > This patch adds PSR Support to Baytrail.
> > 
> > Baytrail cannot easily detect screen updates and force PSR exit.
> > So we inactivate it on {busy_ioctl, sw_finish and mark_busy}
> > and update to enable it back on next display mark_idle.
> > 
> > v2: Also inactivate PSR on cursor update.
> > v3: Inactivate PSR on mark_busy, dset_domain and sw_finish_ioctl, and
> >     early on page flip besides avoid initializing inactive/active flag
> >     more than once.
> > v4: Fix identation issues.
> > v5: Rebase and add Baytrail per pipe support although leaving PIPE_B
> >     support disabled by for now since it isn't working properly yet.
> > v6: Removing forgotten comment and useless clkgating definition.
> > v7: Remove inactivate from set_domain. Chris warned this was semanticaly
> >     wrong.
> 
> Like I've said I agree that it's not pretty, but I also think it's the
> only thing we can do atm. For fbc we have the hardware-based fence
> tracking, but it sounds like that's busted for psr on byt.

No, it also does not match current userspace.

X will :
1. take a GTT mapping of the frontbufer
2. call set-to-domain write=GTT
3. write into mmap
4. go to sleep for a second or more
5. goto 3.

Once it has a write=GTT mmapping and it has not been used for anything
else, it will not inform the kernel that it needs to change domain
again, because as far as it is aware the memory is still in the correct
domain and perfectly coherent.

Besides which I keep asking for a PSR property so X can switch to an
alternative rendering strategy that should be more power efficient and
PSR friendly.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre



More information about the Intel-gfx mailing list