Re: [PATCH] drm/i915: Handle changing enable_psr parameter at runtime better

[Maarten Lankhorst <maarten.lankhorst@linux.intel.com>]

Op 08-03-18 om 18:43 schreef Pandiyan, Dhinakaran:
>
>
> On Thu, 2018-03-08 at 08:07 +0100, Maarten Lankhorst wrote:
>> Op 07-03-18 om 23:22 schreef Pandiyan, Dhinakaran:
>>> On Wed, 2018-03-07 at 17:39 +0100, Maarten Lankhorst wrote:
>>>> Similar to enable_fbc, enable_psr was ignored at runtime if it was
>>>> changed. The easiest fix is to pretend enable_psr is ignored at
>>>> configure time, and never activate it for !enable_psr, so both cases
>>>> are handled without modesets.
>>> What about cases where psr_flush() is not called and consequently the
>>> module parameter is not checked? With HW tracking, PSR is
>>> enabled/disabled during modeset and the hardware is expected to exit and
>>> activate PSR without driver intervention.
>> It looks like intel_frontbuffer_flush always calls intel_psr_flush,
>> so we at least get a PSR toggle after every atomic commit?
> I have a patch to remove flush() from legacy_cursor_update(). We end up
> with an inconsistent behavior when that patch gets merged,
> cursor moves -> trigger psr exit but don't read module parameter
> commits -> trigger psr exit but read module parameter
Legacy cursor updates are special, I don't mind them not changing PSR.
> Eventually, when we get to removing flush() from commits, then this
> patch won't really be useful. And tests disabling/enabling PSR at
> runtime will probably fail.
Could we transition to debugfs for changing it at runtime?

~Maarten
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx