[Intel-gfx] [PATCH 1/2] drm/i915: workaround bad DSL readout in start of pipe update

[Jesse Barnes]

On 09/10/2015 09:11 AM, Ville Syrjälä wrote:
> On Thu, Sep 10, 2015 at 08:34:22AM -0700, Jesse Barnes wrote:
>> On HSW at least (still testing other platforms, but should be harmless
>> elsewhere), the DSL reg reads back as 0 when read around vblank start
>> time.  This ends up confusing the atomic start/end checking code, since
>> it causes the update to appear as if it crossed a frame count boundary.
>> Workaround that by avoiding updates in the first couple of scanlines.
>> In testing, even a delay of a single microsecond is enough to give us a
>> good DSL value again, so the millisecond we'll wait when we hit this
>> case occasionally ought to be plenty.
>>
>> References: https://bugs.freedesktop.org/show_bug.cgi?id=91579
>> Signed-off-by: Jesse Barnes <jbarnes at virtuousgeek.org>
>> ---
>>  drivers/gpu/drm/i915/intel_sprite.c | 10 +++++++++-
>>  1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c
>> index ca7e264..0c2c62f 100644
>> --- a/drivers/gpu/drm/i915/intel_sprite.c
>> +++ b/drivers/gpu/drm/i915/intel_sprite.c
>> @@ -113,8 +113,16 @@ void intel_pipe_update_start(struct intel_crtc *crtc)
>>  		 */
>>  		prepare_to_wait(wq, &wait, TASK_UNINTERRUPTIBLE);
>>  
>> +		/*
>> +		 * On HSW, the DSL reg (0x70000) appears to return 0 if we
>> +		 * read it right around the start of vblank.  So skip past it
>> +		 * so we don't accidentally end up spanning a vblank frame
>> +		 * increment, causing the update_end() code to squak at us.
>> +		 * (We use 2 in the comparison to account for the
>> +		 * scanline_offset used to correct the DSL readout.)
>> +		 */
>>  		scanline = intel_get_crtc_scanline(crtc);
>> -		if (scanline < min || scanline > max)
>> +		if (scanline > 2 && (scanline < min || scanline > max))
>>  			break;
> 
> And it means we'll miss a frame whenever the scanline is 0-2 even on a
> non-broken. So I don't kike it.

We only stall 1ms in the timeout later, so we shouldn't miss a frame, we'll just queue the update in the middle of it instead, right?

> 
> Dunno maybe something more targeted like:
> 
> read dsl
> if (IS_HASWELL && scanline == crtc->scanline_offset) {
> 	udelay(1);
> 	read dsl again
> }
> in __intel_get_crtc_scanline()?
> 
> The udelay() is a bit unfortunate, but we'll need accurate scanline
> informnation for the vblank timestamps too.

Yeah, hiding it in the get_crtc_scanline() might be better; it would be good to know if this affects other platforms as well though.  More testing is needed for that.

Jesse