[Intel-gfx] [PATCH] drm/i915: drrs_invalidate at flip schedule

[Ramalingam C]

Sorry for late response. I was away for longer.

Daniel,

As we have the intel_frontbuffer_flush, I have created the 
intel_frontbuffer_invalidate.
This can be called from flip preparation notification to handle the 
frontbuffer invalidation.
I will share the patches now.

On Monday 18 May 2015 01:50 PM, Daniel Vetter wrote:
> On Fri, May 15, 2015 at 02:08:22AM +0530, Ramalingam C wrote:
>> After scheduling a flip for obj, we are supposed to invalidate the
>> drrs.
>>
>> Action:
>>      Adding a call to intel_edp_drrs_invalidate at
>>      intel_frontbuffer_flip_prepare.
>>
>> Signed-off-by: Ramalingam C <ramalingam.c at intel.com>
>> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
>> ---
>>   drivers/gpu/drm/i915/intel_frontbuffer.c |    1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_frontbuffer.c b/drivers/gpu/drm/i915/intel_frontbuffer.c
>> index 57095f5..44387ed 100644
>> --- a/drivers/gpu/drm/i915/intel_frontbuffer.c
>> +++ b/drivers/gpu/drm/i915/intel_frontbuffer.c
>> @@ -244,6 +244,7 @@ void intel_frontbuffer_flip_prepare(struct drm_device *dev,
>>   	dev_priv->fb_tracking.busy_bits &= ~frontbuffer_bits;
>>   	mutex_unlock(&dev_priv->fb_tracking.lock);
>>   
>> +	intel_edp_drrs_invalidate(dev, frontbuffer_bits);
> Nope. The problem here is that drrs wants business, but the frontbuffer
> tracking only gives you coherency signals (flush/invalidate). But for
> business both flush and invalidate indicate that there's something going
> on on the screen. Which means you _must_ uplock the display in both
> drrs_flush and drrs_invalidate.
>
> By applaying the upclocking only to the flip codepath you're only papering
> over this bug in one specific case, but not for all the other paths where
> frontbuffer rendering is possible.
> -Daniel
>
>>   	intel_psr_single_frame_update(dev);
>>   }
>>   
>> -- 
>> 1.7.9.5
>>

-- 
Thanks,
--Ram