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

[Rodrigo Vivi]

>> > In the case of a moving cursor that means indefinitely.
>> That's true... So I think we really need a work queue delaying the enable.
>> Or do you have any better idea?
>
> Yeah, sounds like we need a delayed work-queue to re-enable psr, also for
> gtt mmap writes. See Chris' latest crazy example of what the X server is
> currently allowed to do.

http://cgit.freedesktop.org/~vivijim/drm-intel/commit/?h=psr-baytrail-wq&id=f356c599db47dca4966dfb173282b111ce3055f5

But I'm not sure if I should do all with delayed schedule or still
calling this psr_update on mark_idle and just schedule work on cursor.
what do you think?


Please notice that besides the wq it also has mutex psr added on this:

http://cgit.freedesktop.org/~vivijim/drm-intel/commit/?h=psr-baytrail-wq&id=b18fb62af0d591cec593a75f7cf896b46e0cc91e

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

To be honest this passed on my mind and I did a local test with sleep
after set_domain, but test worked so I didn't mind with that... but
seems that it was only a conincidence or I put the sleep on a wrong
place...
Anyway I will include more test cases...
Anyway, do you think that above delayed work with 5 seconds would sove
this case? or do you still want I do something to avoid it getting
back between set_doamin and next page_flip?
But in this case isn't there a risk to get it disabled forever? like
in the old cursor without the delayed work?

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

I agree with Daniel, mainly for the big pressure on getting PSR
Baytrail in asap.
I'm considering yet that full PSR rework to get it tied to pipe
config... But will do this later.
First I'd like to have one working with minimal userspace interaction needed.