The issue is that with inline clflushing the clflushing isn't properly
swizzled. Fix this by
- always clflushing entire 128 byte chunks and
- unconditionally flush before writes when swizzling a given page.
We could be clever and check whether we pwrite a partial 128 byte
chunk instead of a
According to the PRM (Vol3P2), the PCH FDI receiver ISR read for bit lock
should be retried at least once. This patch retries the read 5 times
with a small delay in between reads. I've had reports of display corruption
on resume with FDI train 1 fail!, so I'm hoping that adding this retry
will
On Fri, 2 Mar 2012 12:53:39 -0500
Sean Paul seanp...@chromium.org wrote:
According to the PRM (Vol3P2), the PCH FDI receiver ISR read for bit lock
should be retried at least once. This patch retries the read 5 times
with a small delay in between reads. I've had reports of display corruption
With the recent set of gmbus fixes, this seems to work on my i855gm.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_i2c.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_i2c.c
On Fri, Mar 02, 2012 at 10:03:58AM -0800, Jesse Barnes wrote:
On Fri, 2 Mar 2012 12:53:39 -0500
Sean Paul seanp...@chromium.org wrote:
According to the PRM (Vol3P2), the PCH FDI receiver ISR read for bit lock
should be retried at least once. This patch retries the read 5 times
with a
This is commit acc83eb5a1e0ae7dbbf89ca2a1a943ade224bb84
Latest mesa relies on correctly detected swizzling for certain operations,
hence this patch needs to be applied to all kernels prior to v3.2.
Otherwise certain OpenGL features will not quite work correctly on
Sandybridge/Ivybdridge machines.
On Fri, Mar 02, 2012 at 09:33:53PM +0100, Daniel Vetter wrote:
This is commit acc83eb5a1e0ae7dbbf89ca2a1a943ade224bb84
Oops, the upstream. got cut away, i.e. this a stable submission for
pre-3.2 kernels.
-Daniel
Latest mesa relies on correctly detected swizzling for certain operations,
hence
i'm currently testing this workaround:
https://bugzilla.redhat.com/show_bug.cgi?id=788433#c2
is it possible that this bug is caused outside of the gfx driver?
my newest theory is, that my hard disc forgot to flush its write cache before
power off... :-)
-arne