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

Rodrigo Vivi rodrigo.vivi at gmail.com
Wed Jan 29 14:54:00 CET 2014


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?

and what is missing on test? is it a busy ioctl in the end?

but anyway, doing this on set_domain we could fix the psr on
environments that doesn't follow this abi like KDE.

> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre



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



More information about the Intel-gfx mailing list