[Intel-gfx] [PATCH] drm/i915: Dump the contents of the GTT

[Sedat Dilek]

On Fri, Aug 16, 2013 at 10:34 AM, Sedat Dilek <sedat.dilek at gmail.com> wrote:
> On Fri, Aug 16, 2013 at 9:39 AM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
>> On Fri, Aug 16, 2013 at 09:24:01AM +0200, Sedat Dilek wrote:
>>> On Thu, Aug 15, 2013 at 12:13 PM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
>>> > I've just pushed a (cairo-based!) tool to intel-gpu-tools,
>>> > intel_framebuffer_dump, that should also confirm everything we've found
>>> > so far - i.e. that we read and write consistently through the GTT into
>>> > stolen memory. Which just leaves the step between memory and the
>>> > display.
>>>
>>> Thanks.
>>> This still forces me to upgrade to a higher cairo version, not sure
>>> which to which more depends this will lead.
>>>
>>> So, the root-cause for my issue is not intel-gfx related?
>>> BIOS? Quirk needed?
>>> Other areas?
>>
>> No, I am pretty sure it is our evil hardware tormenting us. Daniel made
>> one suggestion to remove the rmw from DISPBASE i.e. revert
>>
>> commit 446f254566ea8911c9e19c7bc8a162fc0e53cf31
>> Author: Armin Reese <armin.c.reese at intel.com>
>> Date:   Fri Mar 30 16:20:16 2012 -0700
>>
>>     drm/i915: Mask reserved bits in display/sprite address registers
>>
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
>> index e2690ec..56ac7df 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -3370,8 +3370,7 @@
>>  #define DISP_BASEADDR_MASK     (0xfffff000)
>>  #define I915_LO_DISPBASE(val)  (val & ~DISP_BASEADDR_MASK)
>>  #define I915_HI_DISPBASE(val)  (val & DISP_BASEADDR_MASK)
>> -#define I915_MODIFY_DISPBASE(reg, gfx_addr) \
>> -               (I915_WRITE((reg), (gfx_addr) | I915_LO_DISPBASE(I915_READ(reg))))
>> +#define I915_MODIFY_DISPBASE(reg, gfx_addr) I915_WRITE((reg), (gfx_addr))
>>
>>  /* VBIOS flags */
>>  #define SWF00                  (dev_priv->info->display_mmio_offset + 0x71410)
>>
>>
>> which avoids invoking suspiciously racy behaviour.
>
> Only that line or the complete commit?
> The complete commit cannot be cleanly reverted.
>

I have tested...

1. Linux v3.11-rc as base
2. d-i-n (up to commit 89296cd1af88b0c8cec6a4806db6db236729decc, on top of 1)
3. with the attached patch (on top of 2)

NO, this did not help here.

- Sedat -
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-drm-i915-Partly-revert-446f254566ea8911c9e19c7bc8a16.patch
Type: application/octet-stream
Size: 1267 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20130816/cc451ef1/attachment.obj>