A couple of fixes for bugs that have finally been caught by QA that came
in through -next (a subtle change in the timing/sequence of pipe/plane
enabling upset PNV, and a broken implementation is_pot()). And a bug
fix for 2.6.38 tiling on gen2/3 (when going from GPU fenced to CPU
fenced).
Later gen can proceed immediately with the modesetting as it is
automatically double-buffered.
References: https://bugs.freedesktop.org/show_bug.cgi?id=34601
Cc: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_display.c |
A broken implementation of is_pot() prevented the detection of when a
singular pipe was enabled.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35402
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_display.c |2 +-
1 files changed, 1 insertions(+),
From: Herton Ronaldo Krzesinski herton.krzesin...@canonical.com
When i915_gem_retire_requests_ring calls i915_gem_request_remove_from_client,
the client_list for that request may already be removed in i915_gem_release.
So we may call twice list_del(request-client_list), resulting in an
oops like
... as wait_for_vblank (and friends) will do a flush of the MMIO writes
anyway.
References: https://bugs.freedesktop.org/show_bug.cgi?id=34601
Cc: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_display.c |8
... even though it was disabled. A mistake in the handling of fence reuse
caused us to skip the vital delay of waiting for the object to finish
rendering before changing the register.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34584
Cc: Andy Whitcroft a...@canonical.com
Cc: Daniel
If the pipe or plane is already enabled, then we do not need to enable
it again and can skip the delay.
References: https://bugs.freedesktop.org/show_bug.cgi?id=34601
Cc: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
As we may release the last reference, we need to store the device in a
local variable in order to unlock afterwards.
[ 60.140768] BUG: unable to handle kernel paging request at 6b6b6b9f
[ 60.140973] IP: [c1536d11] __mutex_unlock_slowpath+0x5a/0x111
[ 60.141014] *pdpt = 24a54001 *pde
On Tue, 15 Mar 2011 12:07:23 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Fix up the debug file to report the right frequencies. On SNB, we program
the PCU with a frequency ratio, which is multiplied by 100MHz on the CPU
side. But GFX only runs at half that, so report it as such to
On Fri, 18 Mar 2011 08:02:03 +, Chris Wilson ch...@chris-wilson.co.uk
wrote:
... as wait_for_vblank (and friends) will do a flush of the MMIO writes
anyway.
This one seems reasonable.
Reviewed-by: Keith Packard kei...@keithp.com
--
keith.pack...@intel.com
pgppxraae0dbT.pgp
On Fri, 18 Mar 2011 08:02:04 +, Chris Wilson ch...@chris-wilson.co.uk
wrote:
If the pipe or plane is already enabled, then we do not need to enable
it again and can skip the delay.
This should mention that you're also skipping the operation on disable.
Otherwise,
Reviewed-by: Keith
This comment is misleading -- the patch replaces a call to
intel_wait_for_vblank with a call to intel_flush_display_plane.
From my reading of the docs, enable requires two actions:
1) DSPACNTR with enable going from 0-1
2) wait for vblank
At disable, three actions are required:
1) DSPACNTR
On Fri, 18 Mar 2011 08:02:08 +, Chris Wilson ch...@chris-wilson.co.uk
wrote:
As we may release the last reference, we need to store the device in a
local variable in order to unlock afterwards.
Reviewed-by: Keith Packard kei...@keithp.com
--
keith.pack...@intel.com
pgpHcqpgV3keH.pgp
On Fri, 18 Mar 2011 08:02:09 +, Chris Wilson ch...@chris-wilson.co.uk
wrote:
A broken implementation of is_pot() prevented the detection of when a
singular pipe was enabled.
- return mask (mask -mask) == 0;
+ return mask (mask -mask) == mask;
I think the form
mask
On Fri, 18 Mar 2011 08:02:03 +
Chris Wilson ch...@chris-wilson.co.uk wrote:
... as wait_for_vblank (and friends) will do a flush of the MMIO writes
anyway.
References: https://bugs.freedesktop.org/show_bug.cgi?id=34601
Cc: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Chris
On Fri, 18 Mar 2011 08:02:04 +
Chris Wilson ch...@chris-wilson.co.uk wrote:
If the pipe or plane is already enabled, then we do not need to enable
it again and can skip the delay.
References: https://bugs.freedesktop.org/show_bug.cgi?id=34601
Cc: Jesse Barnes jbar...@virtuousgeek.org
On Fri, 18 Mar 2011 08:02:05 +
Chris Wilson ch...@chris-wilson.co.uk wrote:
References: https://bugs.freedesktop.org/show_bug.cgi?id=34601
Cc: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_display.c | 24
On Fri, 18 Mar 2011 08:02:06 +
Chris Wilson ch...@chris-wilson.co.uk wrote:
Later gen can proceed immediately with the modesetting as it is
automatically double-buffered.
References: https://bugs.freedesktop.org/show_bug.cgi?id=34601
Cc: Jesse Barnes jbar...@virtuousgeek.org
On Fri, 18 Mar 2011 12:14:33 +
Chris Wilson ch...@chris-wilson.co.uk wrote:
On Tue, 15 Mar 2011 12:07:23 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Fix up the debug file to report the right frequencies. On SNB, we program
the PCU with a frequency ratio, which is multiplied by
On Fri, 18 Mar 2011 09:25:22 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
On Fri, 18 Mar 2011 08:02:04 +
Chris Wilson ch...@chris-wilson.co.uk wrote:
If the pipe or plane is already enabled, then we do not need to enable
it again and can skip the delay.
References:
On Fri, 18 Mar 2011 17:37:06 +
Chris Wilson ch...@chris-wilson.co.uk wrote:
On Fri, 18 Mar 2011 09:25:22 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
On Fri, 18 Mar 2011 08:02:04 +
Chris Wilson ch...@chris-wilson.co.uk wrote:
If the pipe or plane is already enabled,
On Fri, 18 Mar 2011 09:26:04 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
On Fri, 18 Mar 2011 08:02:05 +
Chris Wilson ch...@chris-wilson.co.uk wrote:
References: https://bugs.freedesktop.org/show_bug.cgi?id=34601
Cc: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Chris
Use CPU package registers to monitor CPU and GPU power consumption. Add
a trace point for package power as well, to simplify data collection.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_debugfs.c | 50 +++--
On Fri, 18 Mar 2011 08:22:16 -0700, Keith Packard kei...@keithp.com wrote:
On Fri, 18 Mar 2011 08:02:09 +, Chris Wilson ch...@chris-wilson.co.uk
wrote:
A broken implementation of is_pot() prevented the detection of when a
singular pipe was enabled.
- return mask (mask -mask)
On Fri, 18 Mar 2011 10:56:15 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Add trace points for when the GPU goes from idle to busy and vice-versa.
Also trace when we start to idle the GPU and when it finally does idle
(this could take awhile if the ring is full of commands).
On Thu, 17 Mar 2011 19:29:03 -0700, Ben Widawsky b...@bwidawsk.net wrote:
From: Ben Widawsky bwida...@gmail.com
Have the assembler support creating a byte array for binary blob-like
inclusion. In my case, to write some exception handler which is not
jit'd.
I don't have push access, so if
Apologies for cluttering the list, but I'm wondering if anyone else (on
the same or different Ironlake hardware) is affected by these two bugs:
[Ironlake LVDS Vaio-Y] Ineffectual backlight brightness controls
https://bugs.freedesktop.org/show_bug.cgi?id=34417
[Ironlake LVDS Vaio-Y] blank
On Wed, Mar 16, 2011 at 17:59:20 -0600, John Harrigan wrote:
I have a Lenovo X201 laptop with an i7-620M processor. After I resume
from a Suspend to RAM the graphics are very slow. Suspend to Disk does
not cause the same problem and doing a Suspend to Disk after a Suspend
to RAM fixes the
On Fri, 18 Mar 2011 11:12:07 -0700, Eric Anholt e...@anholt.net wrote:
At the risk of bikeshed, is_power_of_2() in log2.h is prettier. (note:
treats 0 as not power of two).
I like the colour of your bikeshed, sold!.
Thanks, I missed that earlier when looking for an implementation of
is_pot().
Spurred on by the tiling corruption caused by disabling the pipelined
fencing, I think I finally fixed the GPU hangs plaguing the
implementation. (It's a matter of timing and making sure that is
sufficient serialisation between the CPU and GPU writes to the fence
registers, but not too much...)
With the last bug preventing fence pipelining fixed (or at least the
last known bug), re-enable pipelining to avoid stalling on fence
acquisition between batches.
Cc: Andy Whitcroft a...@canonical.com
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_gem.c |3
This fixes a bookkeeping error causing an OOPS whilst waiting for an
object to finish using a fence. Now we can simply wait for the fence to
be written independent of the objects currently inhabiting it (past,
present and future).
Cc: Andy Whitcroft a...@canonical.com
Signed-off-by: Chris Wilson
Cc: Andy Whitcroft a...@canonical.com
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_gem.c | 29 +
1 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
Whenever we finish reading an object through a fence, for safety we
clear any GPU read domain and so invalidate any TLBs associated with
the fenced region upon its next use.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_gem.c|2 ++
There might be some further patches. I believe we may need to reinitialize rc6
after a GPU reset, but I don't know for certain yet.
Also it was recommended by Chris that we use i915_enable_rc6 for coarser
control over gen6 as well. That function was a little daunting, and so I'll
submit that as
In the failure cases during rc6 initialization, both the power context
and render context may get !refcount without holding struct_mutex.
However, on rc6 disabling, the lock is held by the caller.
Added a simple parameter to control whether or not to acquire the lock.
Signed-off-by: Ben
There is a race condition between setting PWRCTXA and executing
MI_SET_CONTEXT. PWRCTXA must not be set until a valid context has been
written (or else the GPU could possible go into rc6, and return to an
invalid context).
Reported-and-Tested-by: Gu Rui chaos.pro...@gmail.com
Bugzilla:
Currently this is only useful for the rc6 stuff. But this would also be
useful when I finally get around to the logical context + ppgtt stuff.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_debugfs.c | 25 +
1 files changed, 25
The previous patches should fix enough of the known issues to try
re-enabling rc6 for general consumption
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_drv.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c
39 matches
Mail list logo
