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

Rodrigo Vivi rodrigo.vivi at gmail.com
Wed Jan 29 15:23:15 CET 2014


ok, got it.

So, the correct here is to remove inactivate from set_domain and add
gem_bo_busy call on MMAP_GTT testcase?

On Wed, Jan 29, 2014 at 12:02 PM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> On Wed, Jan 29, 2014 at 11:54:00AM -0200, Rodrigo Vivi wrote:
>> On Wed, Jan 29, 2014 at 11:27 AM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
>> > On Wed, Jan 29, 2014 at 11:24:44AM -0200, Rodrigo Vivi wrote:
>> >> On Wed, Jan 29, 2014 at 11:12 AM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
>> >> > On Wed, Jan 29, 2014 at 10:47:54AM -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, set_domain, 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.
>> >> >
>> >> > Not set-domain. This is semantically a flush and so should be after the
>> >> > damage is done.
>> >>
>> >> Yep, I semantically I agree, but if we let to inactivate psr after
>> >> damage is done we will miss screen updates.
>> >> This was the safest way to get psr enabled and fully working and
>> >> passing crc tests.
>> >> If you have another place to suggest i'd be glad in do some tests
>> >> here, but for now this is the more stable place I know about.
>> >
>> > It's the test that are at fault here for not following the established
>> > ABI imo.
>>
>> this makes sense.
>>
>> do we have this established ABI documented somewhere?
>
> Only what was established as required to make things work a few years
> ago...
>
>> and what is missing on test? is it a busy ioctl in the end?
>
> busy or even a sw_finish. I see it already did the sw_finish. We have in
> the past talked about formalizing the gap in the documentation with a
> new call...
>
>> but anyway, doing this on set_domain we could fix the psr on
>> environments that doesn't follow this abi like KDE.
>
> As we have discussed in the past, that is an issue in the ddx that
> short-circuits the required flush if there was only GTT damage.
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br



More information about the Intel-gfx mailing list