The previous patches should fix enough of the known issues to try
re-enabling rc6 for general consumption
Signed-off-by: Ben Widawsky
---
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 b/drivers/gpu/drm/i9
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
---
drivers/gpu/drm/i915/i915_debugfs.c | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
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
Bugzilla: https://bugzilla.kernel.org/show_
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 Widawsky
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 a
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
---
drivers/gpu/drm/i915/i915_gem.c|2 ++
drivers/gpu/drm/i915/i915_gem_execbu
Cc: Andy Whitcroft
Signed-off-by: Chris Wilson
---
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
index 5201f82..2dbf8f7 100644
--- a/drivers/
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
Signed-off-by: Chris Wilson
---
drivers/gpu/d
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
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c |3 ---
1 files changed, 0 insertions(+), 3 d
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...)
On Fri, 18 Mar 2011 11:12:07 -0700, Eric Anholt 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().
-Chris
--
C
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
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 screen
On Thu, 17 Mar 2011 19:29:03 -0700, Ben Widawsky wrote:
> From: Ben Widawsky
>
> 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 anyone thinks this is useful,
On Fri, 18 Mar 2011 18:12:25 +
Chris Wilson wrote:
> On Fri, 18 Mar 2011 10:56:15 -0700, Jesse Barnes
> 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
On Fri, 18 Mar 2011 10:56:15 -0700, Jesse Barnes
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).
>
> Signed-off-by: Jesse Barnes
On Fri, 18 Mar 2011 08:22:16 -0700, Keith Packard wrote:
> On Fri, 18 Mar 2011 08:02:09 +, Chris Wilson
> wrote:
>
> > A broken implementation of is_pot() prevented the detection of when a
> > singular pipe was enabled.
>
> > - return mask && (mask & -mask) == 0;
> > + return mask && (
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).
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.h |4 +++
drivers/gp
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
---
drivers/gpu/drm/i915/i915_debugfs.c | 50 +++--
drivers/gpu/drm/i915/i915_drv.h |
On Fri, 18 Mar 2011 08:22:16 -0700, Keith Packard wrote:
> On Fri, 18 Mar 2011 08:02:09 +, Chris Wilson
> wrote:
>
> > A broken implementation of is_pot() prevented the detection of when a
> > singular pipe was enabled.
>
> > - return mask && (mask & -mask) == 0;
> > + return mask && (
On Fri, 18 Mar 2011 09:26:04 -0700, Jesse Barnes
wrote:
> On Fri, 18 Mar 2011 08:02:05 +
> Chris Wilson wrote:
>
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=34601
> > Cc: Jesse Barnes
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 24
On Fri, 18 Mar 2011 17:37:06 +
Chris Wilson wrote:
> On Fri, 18 Mar 2011 09:25:22 -0700, Jesse Barnes
> wrote:
> > On Fri, 18 Mar 2011 08:02:04 +
> > Chris Wilson wrote:
> >
> > > If the pipe or plane is already enabled, then we do not need to enable
> > > it again and can skip the de
On Fri, 18 Mar 2011 09:25:22 -0700, Jesse Barnes
wrote:
> On Fri, 18 Mar 2011 08:02:04 +
> Chris Wilson 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=
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 avoid
confusion.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_debugfs.c
On Fri, 18 Mar 2011 12:14:33 +
Chris Wilson wrote:
> On Tue, 15 Mar 2011 12:07:23 -0700, Jesse Barnes
> 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
On Fri, 18 Mar 2011 08:02:06 +
Chris Wilson 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
> Signed-off-by: Chris Wilson
> ---
This is another o
On Fri, 18 Mar 2011 08:02:05 +
Chris Wilson wrote:
> References: https://bugs.freedesktop.org/show_bug.cgi?id=34601
> Cc: Jesse Barnes
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_display.c | 24
> 1 files changed, 12 insertions(+), 12 deletio
On Fri, 18 Mar 2011 08:02:04 +
Chris Wilson 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
> Signed-off-by: Chris Wilson
> ---
Does thi
On Fri, 18 Mar 2011 08:02:03 +
Chris Wilson 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
> Signed-off-by: Chris Wilson
> ---
Looks good.
Reviewed-by: Jesse
On Fri, 18 Mar 2011 08:02:09 +, Chris Wilson
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 && (mask & (mas
On Fri, 18 Mar 2011 08:02:08 +, Chris Wilson
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
--
keith.pack...@intel.com
pgpHcqpgV3keH.pgp
Description: PGP signature
__
On Fri, 18 Mar 2011 08:02:06 +, Chris Wilson
wrote:
> Later gen can proceed immediately with the modesetting as it is
> automatically double-buffered.
This comment is misleading -- the change is in intel_disable_plane, not
intel_enable_pipe.
--
keith.pack...@intel.com
pgpikAVhZf1TV.pgp
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:04 +, Chris Wilson
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 Packard
--
keith.pack...@
On Fri, 18 Mar 2011 08:02:03 +, Chris Wilson
wrote:
> ... as wait_for_vblank (and friends) will do a flush of the MMIO writes
> anyway.
This one seems reasonable.
Reviewed-by: Keith Packard
--
keith.pack...@intel.com
pgppxraae0dbT.pgp
Description: PGP signature
___
On Tue, 15 Mar 2011 12:07:23 -0700, Jesse Barnes
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 avoid
> confusion.
Jess
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: [] __mutex_unlock_slowpath+0x5a/0x111
[ 60.141014] *pdpt = 24a54001 *pde = 00
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
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c | 24
1 files c
... 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
Cc: Daniel Vetter
[Note for 2.6.
... 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
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c |8
1 files changed, 0 insertions(+), 8 deletions(-)
From: Herton Ronaldo Krzesinski
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 this report:
[126167.230394]
References: https://bugs.freedesktop.org/show_bug.cgi?id=34601
Cc: Jesse Barnes
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c | 24
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/g
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
---
drivers/gpu/drm/i915/intel_display.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --g
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
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c |4 +++-
1 files changed, 3 insertions(+), 1 de
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).
Comments?
45 matches
Mail list logo
