On Fri, Aug 16, 2013 at 10:34 AM, Sedat Dilek <sedat.dilek@xxxxxxxxx> wrote: > On Fri, Aug 16, 2013 at 9:39 AM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx> >> 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 -
Attachment:
0001-drm-i915-Partly-revert-446f254566ea8911c9e19c7bc8a16.patch
Description: Binary data
_______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
