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

[Daniel Vetter]

On Sat, Feb 01, 2014 at 11:34:02AM +0000, Chris Wilson wrote:
> 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.

Oops, sounds like we need to have another testcase which does this, both
for fbc and psr. It sounds like we'd need to nuke psr completely for this
case in set_domain (when gtt writes are enforced) and only re-enable it on
the next pageflip. If that's too shitty for some platforms we care about
we could have a timer in place to shoot down gtt mmappings and restore psr
after one second or something like this. Ofc that means we also need to
frob the page fault paths a bit then.

This is getting less pretty by the minute :(

While we discuss rendering models: Can you please double-check the fbc/psr
testcase and look for any insane sequence/cornercase (like the above one)
that we've missed thus far?

> 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.

Agreed on that, but imo we need to first get the legacy crap going without
regressions. Once we have that in solid shape we can extend things with
all kinds of fancy madness (I'm also thinking of explicit damage flushing
and things like this). But we've never had a solid baseline for fbc/psr
ever ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch