[Intel-gfx] [PATCH] drm/i915: workaround bad DSL readout v2

[Jesse Barnes]

On 09/10/2015 02:53 PM, Ville Syrjälä wrote:
> On Thu, Sep 10, 2015 at 02:38:53PM -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.
>> Avoid the problem by making sure we don't return scanline_offset from
>> the get_crtc_scanline function.  In moving the code there, I add to add
>> an additional delay since it could be called and have a legitimate 0
>> result for some time (depending on the pixel clock).
>>
>> v2: move hsw dsl read hack to get_crtc_scanline (Ville)
>>
>> References: https://bugs.freedesktop.org/show_bug.cgi?id=91579
>> Signed-off-by: Jesse Barnes <jbarnes at virtuousgeek.org>
>> ---
>>  drivers/gpu/drm/i915/i915_irq.c | 21 +++++++++++++++++++++
>>  1 file changed, 21 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
>> index 90bc6c2..97e5d52 100644
>> --- a/drivers/gpu/drm/i915/i915_irq.c
>> +++ b/drivers/gpu/drm/i915/i915_irq.c
>> @@ -697,6 +697,27 @@ static int __intel_get_crtc_scanline(struct intel_crtc *crtc)
>>  		position = __raw_i915_read32(dev_priv, PIPEDSL(pipe)) & DSL_LINEMASK_GEN3;
>>  
>>  	/*
>> +	 * On HSW, the DSL reg (0x70000) appears to return 0 if we
>> +	 * read it right around the start of vblank.  So try it again
>> +	 * so we don't accidentally end up spanning a vblank frame
>> +	 * increment, causing the pipe_update_end() code to squak at us.
>> +	 */
>> +	if (IS_HASWELL(dev) && !position) {
>> +		int i, temp;
>> +
>> +		for (i = 0; i < 100; i++) {
>> +			udelay(1);
>> +			temp = __raw_i915_read32(dev_priv, PIPEDSL(pipe)) &
>> +				DSL_LINEMASK_GEN3;
>> +			if (temp != position) {
>> +				position = temp;
>> +				goto out;
>> +			}
>> +		}
>> +	}
> 
> Hmm. Another idea. If it always happens at start of vbl, maybe have a
> look at the ISR. If scanline reads 0, but ISR says we're in vblank, just
> return vblank_start. That's assming ISR would in fact show that it's in
> vblank when this happens.

Sounds a bit racy, though I guess it wouldn't hurt.  I'm actually a
little dubious about this change anyway since it will mean longer delays
when we really are at the top of the field/frame.  You sure you don't
like the first one better?

Thanks,
Jesse