On Fri, Nov 05, 2010 at 01:02:33PM -0700, Carl Worth wrote:
This is an intermediate snapshot of ongoing driver development. The
primary purpose of this snapshot is to capture some recent
improvements, (particularly in Sandybridge support), for further
testing.
As always, we look forward to
Add two tracepoints at I915_WRITE/READ for tracing down all the
register write and read.
Signed-off-by: Yuanhan Liu yuanhan@linux.intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 61 -
drivers/gpu/drm/i915/i915_trace.h | 23 ++
2 files
Filter out the read/write of GPIO registers.
Signed-off-by: Yuanhan Liu yuanhan@linux.intel.com
---
drivers/gpu/drm/i915/i915_drv.h |5 +
drivers/gpu/drm/i915/intel_i2c.c | 25 +
2 files changed, 18 insertions(+), 12 deletions(-)
diff --git
On Mon, 08 Nov 2010 00:19:11 -0800, Eric Anholt e...@anholt.net wrote:
I'd rather not unless we find that it does really fix someone.
Moved to -next instead.
Thanks!
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing
I just send two patches out, without trace on load patch for
now(explained at below).
On Mon, 2010-11-08 at 00:03 +0800, Chris Wilson wrote:
Oh my, this turns out to be quite hacky indeed...
if (i915_trace_on_load) {
const struct ftrace_event_call enable_list[] = {
#define EVENT(name)
Hi Chris,
The following patch that you recently committed breaks my ASUS Eee PC
1015PEM by causing the display to be offset by about 1 inch (a few
centimeters) when the mode is (re)set during boot. I previously posted
both photographs and video of the problem in another PROBLEM thread.
Here is
On Mon, 2010-11-08 at 11:26 +, James Courtier-Dutton wrote:
On 8 November 2010 10:27, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Mon, 08 Nov 2010 05:18:32 -0500, Jon Masters jonat...@jonmasters.org
wrote:
Hi Chris,
The following patch that you recently committed breaks my ASUS
On Mon, 2010-11-08 at 11:33 +, James Courtier-Dutton wrote:
On 8 November 2010 10:54, Jon Masters jonat...@jonmasters.org wrote:
Here is the EDID output after booting:
[...@monticello ~]$ hexdump /sys/class/drm/card0-LVDS-1/edid
000 ff00 00ff 6422 03e9 8544 0001
On Mon, 08 Nov 2010 06:29:09 -0500, Jon Masters jonat...@jonmasters.org wrote:
On Mon, 2010-11-08 at 06:22 -0500, Jon Masters wrote:
As I mentioned on IRC, I'm familiar with how I2C works electrically, and
therefore EDID implementation as a concept, but I am not really a
graphics hacker so
Sent: Wednesday, November 03, 2010 2:06 PM
Looks like an ordinary userspace bo leak. Now you want to start
instrumenting textures and making sure they are all accounted for.
Equally
the bug may be in mesa leaking references.
As a followup on this issue,
Texture tracking looks good so far
On Sat, 06 Nov 2010 09:23:06 +, Peter Clifton pc...@cam.ac.uk wrote:
Fixes corruption with glBufferSubData on my machine,
Can someone review and push?
Looks good. Thanks!
pgpj9dGzySOaO.pgp
Description: PGP signature
___
Intel-gfx mailing list
On Mon, 2010-11-08 at 12:13 +, Chris Wilson wrote:
On Mon, 08 Nov 2010 06:29:09 -0500, Jon Masters jonat...@jonmasters.org
wrote:
On Mon, 2010-11-08 at 06:22 -0500, Jon Masters wrote:
As I mentioned on IRC, I'm familiar with how I2C works electrically, and
therefore EDID
---BeginMessage---
On Mon, 2010-11-08 at 23:24 +, Chris Wilson wrote:
Commit 219adae1 cached the EDID found during LVDS init, but in the
process prevented the init routine from discovering the preferred
fixed-mode for the panel. This was causing us to guess the correct mode,
which
13 matches
Mail list logo
