The series looks really good, only one quibble below.
On Tue, 29 Mar 2011 16:59:53 -0700, Eric Anholt e...@anholt.net wrote:
+int i915_gem_object_set_cache_level(struct drm_i915_gem_object *obj,
+ enum i915_cache_level cache_level)
+ if (cache_level ==
Once a NAK has been asserted by the slave, we need to reset the GMBUS
controller in order to continue. This is done by asserting the Software
Clear Interrupt bit and then clearing it again to restore operations.
If we don't clear the NAK, then all future GMBUS xfers will fail,
including DDC
On Wed, 30 Mar 2011 09:48:25 -0700, Keith Packard kei...@keithp.com wrote:
On Wed, 30 Mar 2011 17:07:11 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
+clear_err:
+ I915_WRITE(GMBUS1 + reg_offset, GMBUS_SW_CLR_INT);
+ POSTING_READ(GMBUS1 + reg_offset);
+ I915_WRITE(GMBUS1 +
On Wed, 30 Mar 2011 08:09:47 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
The series looks really good, only one quibble below.
On Tue, 29 Mar 2011 16:59:53 -0700, Eric Anholt e...@anholt.net wrote:
+int i915_gem_object_set_cache_level(struct drm_i915_gem_object *obj,
+
On Wed, 30 Mar 2011 09:59:55 -0700, Eric Anholt e...@anholt.net wrote:
On Wed, 30 Mar 2011 08:09:47 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
The series looks really good, only one quibble below.
On Tue, 29 Mar 2011 16:59:53 -0700, Eric Anholt e...@anholt.net wrote:
+int
On Wed, 30 Mar 2011 17:59:51 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
I'm not even sure we need the first posting read. Maybe it should be a
wait_for(I915_READ(GMBUS1 + reg_offset) GMBUS_SW_CLR_INT, 100)
to be clearer that we are simply giving the hardware the chance to assert
I run all my displays, LCD or not, at 60 vertical refresh. Flicker is a
non-issue for these old eyes. Is there a way to force the kernel to use 60,
or find out what is being used? On the p275 Trinitron I'm using right now, I
doubt fc15's 2.6.38.2 is running 60, as the output is shifted so far
Signed-off-by: Eric Anholt e...@anholt.net
---
drivers/gpu/drm/i915/intel_display.c | 284 +++---
1 files changed, 24 insertions(+), 260 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7b2cd8a..d955646
Signed-off-by: Eric Anholt e...@anholt.net
---
drivers/gpu/drm/i915/intel_display.c | 16 ++--
1 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 610363c..7b2cd8a 100644
---
While g4x had DP, eDP came with Ironlake, so we don't need that code here.
Signed-off-by: Eric Anholt e...@anholt.net
---
drivers/gpu/drm/i915/intel_display.c | 57 ++---
1 files changed, 24 insertions(+), 33 deletions(-)
diff --git
This path, which shouldn't be *that* complicated, is now so littered
with per-chipset tweaks that it's hard to trace the order of what
happens. HAS_PCH_SPLIT() is the most radical change across chipsets,
so it seems like a natural split to simplify the code.
This first commit just copies the
We used to have these from the product of (pch, non-pch) * (pipe a,
pipe b). Now we can just use the nice per-pipe reg macros in the
split out crtc_mode_sets.
Signed-off-by: Eric Anholt e...@anholt.net
---
drivers/gpu/drm/i915/intel_display.c | 57 +-
1 files
They're used in one place, and not providing any descriptive value,
with their names just being approximately the conjunction of the
struct name and the struct field.
This diff was produced with gcc -E, copying the new struct definitions
out, moving a couple of the old comments into place in the
Ironlake is where the PCH split started.
Signed-off-by: Eric Anholt e...@anholt.net
---
drivers/gpu/drm/i915/intel_display.c | 361 ++
1 files changed, 150 insertions(+), 211 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
For debug testing.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 32b41b4..1268c6a
On Wed, Mar 30, 2011 at 02:08:56PM -0700, Jesse Barnes wrote:
For debug testing.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
I915_WRITE(GEN6_RC_CONTROL,
-GEN6_RC_CTL_RC6p_ENABLE |
-GEN6_RC_CTL_RC6_ENABLE |
+rc6_mask |
On Wed, 30 Mar 2011 18:16:11 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Wed, 30 Mar 2011 09:59:55 -0700, Eric Anholt e...@anholt.net wrote:
On Wed, 30 Mar 2011 08:09:47 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
The series looks really good, only one quibble below.
On Wed, 30 Mar 2011 13:01:04 -0700
Eric Anholt e...@anholt.net wrote:
Signed-off-by: Eric Anholt e...@anholt.net
---
drivers/gpu/drm/i915/intel_display.c | 284
+++---
1 files changed, 24 insertions(+), 260 deletions(-)
Was going to suggest you also drop the
On Wed, 30 Mar 2011 17:07:11 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
Once a NAK has been asserted by the slave, we need to reset the GMBUS
controller in order to continue. This is done by asserting the Software
Clear Interrupt bit and then clearing it again to restore operations.
On Wed, 30 Mar 2011 14:32:51 -0700
Ben Widawsky b...@bwidawsk.net wrote:
On Wed, Mar 30, 2011 at 02:08:56PM -0700, Jesse Barnes wrote:
For debug testing.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
I915_WRITE(GEN6_RC_CONTROL,
-
Eric Chris,
For those interested, here's some of my test results of the LLC caching
patch-set compared to a vanilla 2.6.38 and 2.6.39-rc1 on two SNBs. They
just show some nice gains across the board and I haven't hit any issues
with the patches.
Core i3 2100:
21 matches
Mail list logo