Am Freitag, den 29.10.2010, 03:49 +0100 schrieb Peter Clifton:
> Hi guys,
>
> Just a heads-up here. I don't use many QT apps, so I don't know when
> this first started occurring, but with "late" drivers, (all known drm
> kernel fixes merged), I noticed the following corruptions. I'm not sure
> who
>>-Original Message-
>>From: intel-gfx-bounces+nanhai.zou=intel@lists.freedesktop.org
>>[mailto:intel-gfx-bounces+nanhai.zou=intel@lists.freedesktop.org] On
>>Behalf Of Zou, Nanhai
>>Sent: 2010年10月28日 9:02
>>To: Chris Wilson; intel-gfx@lists.freedesktop.org
>>Subject: Re: [Intel-gfx
uxa:enable BLT command on gen6,
BLT command will goto BLT ring buffer
on gen6.
Signed-off-by:Zou Nan hai
---
src/i830_reg.h |2 +
src/intel.h |4 +++
src/intel_batchbuffer.c | 37 +-
src/intel_batchbuffer.h | 10 +++
On 2010.10.28 10:50:04 +0100, Chris Wilson wrote:
>
> The POSTING_READs you added are no-ops since they are all followed by a
> read. The transconf should have the bpc in the register at this point or
> else we should have bugged much earlier. The break-exec-wait condition is
> still documented fo
On Thu, 28 Oct 2010 16:38:08 +0800, Zhenyu Wang wrote:
> We should enable FDI normal training on Sandybridge/CPT system
> as well. Also restore back some original register posting read
> that got removed. LVDS/VGA/HDMI seems back to life but DP still
> fails.
The POSTING_READs you added are no-op
On Thu, 28 Oct 2010 14:16:09 +0800, Zhenyu Wang wrote:
> + ret = i915_gem_object_enable_scanout(obj);
> + if (ret) {
> + kfree(intel_fb);
> + return ERR_PTR(ret);
> + }
We need to introduce a mutex_lock here. I wonder whether it is truly worth
it. Yes, user spa
We should enable FDI normal training on Sandybridge/CPT system
as well. Also restore back some original register posting read
that got removed. LVDS/VGA/HDMI seems back to life but DP still
fails.
Signed-off-by: Zhenyu Wang
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/
