[Intel-gfx] [PATCH 10/11] drm/i915: PSR Baytrail: Force exit by inactivating it.

[Daniel Vetter]

On Wed, Mar 12, 2014 at 6:11 PM, Rodrigo Vivi <rodrigo.vivi at gmail.com> wrote:
>> We have it, it's called dirtyfb. But we need to keep the current userspace
>> stuff mostly working first, hence all this trouble. We can fix the gtt
>> trouble with a delayed work (one vblank or so) which
>> a) does a psr_exit
>> b) shots down gtt mappings of the offending frontbuffer
>>
>> Then we can intercept the next write in gem_fault.
>>
>> Of course that will be horrible if we don't track correctly which buffers
>> are actually relevant for psr.
>> -Daniel
>
> I'm not sure I fully got your idea/plan here.
>
> Should I try a psr_exit with delayed back at dirtyfb? and create a new
> test case?
> Or this it self isn't enough?
>
> Btw, i'm using daily a hsw ult with psr enable and a kde environment
> using the same psr_exit strategy here for baytrail with psr enabled
> for more than 2 weeks without any issue so far.

Current userspace doesn't use dirtyfb, so we can't solely rely on
that. Iirc you currently have a psr_exit in set_domain. My idea above
was that we also need to have it in i915_gem_fault and further we need
to shot down ptes in psr_exit for the frontbuffer.

For an igt the following should trick this bug:
1) set_domain(GTT, GTT) on the frontbuffer
2) rendering something
-> check that the kernel has correctly done a psr_exit with the sink crc stuff

This is the testcase we already have. Now comes the interesting part
Chris pointed out:
3) have a long delay to make sure we are again in psr mode.
4) Write new stuff to the frontbuffer, _without_ doing a
set_domain(GTT, GTT). Userspace is allowed to do this.
-> check again sink crcs

Note that this issue doesn't exist with cpu memory mapped frontbuffer
rendering, since userspace is required to regularly call the sw_finish
ioctl, i.e. after both steps 2) and 4). But even for cpu mmaps
userspace is allowed to optimize the set_domain(CPU, CPU) call away
before step 3).

Of course if any other rendering happens in between step 2) and 3)
userspace must again do a set_domain call. So this case here is highly
contrived ;-)

I hope this explains this issue better.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch