On Wed, 14 Nov 2012 12:55:54 +0800, "Xiang, Haihao"
wrote:
> From: "Xiang, Haihao"
>
> Xiang, Haihao (2):
> tests: storedw on VEBOX
> Update gem_ring_sync_loop to support VEBOX ring (the 4th ring) on
> Haswell
Should be using the GET_PARAM to determine support for the various
rings.
-C
The bspec was recently updated to remove the ability to update the
semaphore using the MI_SEMAPHORE_BOX command, the ability to wait upon
the semaphore value remained. Instead the advice is to update the
register using the MI_LOAD_REGISTER_IMM command. In cursory testing,
semaphores continue to fun
Hi all,
Our QA noticed a regression in one of our i915/GEM testcases in 3.7:
https://bugs.freedesktop.org/show_bug.cgi?id=56859
Direct link to dmesg of the machine:
https://bugs.freedesktop.org/attachment.cgi?id=70052 Note that the
machine is 32bit, which seems to be important since Chris Wilson
On Wed, Nov 14, 2012 at 6:09 PM, Daniel Vetter wrote:
> Hi all,
>
> Our QA noticed a regression in one of our i915/GEM testcases in 3.7:
>
> https://bugs.freedesktop.org/show_bug.cgi?id=56859
>
> Direct link to dmesg of the machine:
> https://bugs.freedesktop.org/attachment.cgi?id=70052 Note that
Hi all,
Pretty much still the same approach, but with a few changes compared to last
time around:
- split out the throttle fix
- fixed a bug in the wait_error EXIT_COND
- drop a unecessary barrier and update the comments&commit message to explain
why that's safe
Chris Wilson expressed some conc
Tha one is really big, since it contains tons of comments explaining
how things work. Which is nice ;-)
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h | 212
1 file changed, 107 insertions(+), 105 deletions(-)
diff --git a/drivers/gpu/d
This has been sprinkled all over the place in dev_priv. I think
it'd be good to also move all the code into a separate file like
i915_gem_error.c, but that's for another patch.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 10 +++---
drivers/gpu/drm/i915/i915_dma.c
And to make Ben Widawsky happier, use the gpu_error instead of
the entire device as the argument in some functions.
Drop the outdated comment on ->wedged for now, a follow-up patch will
change the semantics and add a proper comment again.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i9
While auditing the code I've noticed one place (the throttle ioctl)
which does not yet wait for the reset handler to complete and doesn't
properly decode the wedge state into -EAGAIN/-EIO. Fix this up by
calling the right helpers. This might explain the oddball "my
compositor just died in a success
We have two important transitions of the wedged state in the current
code:
- 0 -> 1: This means a hang has been detected, and signals to everyone
that they please get of any locks, so that the reset work item can
do its job.
- 1 -> 0: The reset handler has completed.
Now the last transition
With the previous patch the state transition handling of the reset
code itself is now (hopefully) race free and solid. But that still
leaves out everyone else - with the various lock-free wait paths
we have there's the possibility that the reset happens between the
point where we read the seqno we
On Thu, 30 Aug 2012 11:29:11 +0200
"Indan Zupancic" wrote:
> On Tue, August 28, 2012 16:55, Daniel Vetter wrote:
> > On Tue, Aug 28, 2012 at 04:39:34PM +0200, Indan Zupancic wrote:
> >> Some backlight problems on GEN4 can be solved by not fiddling with the
> >> backlight. The current code sets th
Jani Nikula noticed that the parentheses are wrong and we & the bit
with the register address instead of the read-back value. He sent a
patch to correct that.
On second look, we write the same register in the previous line, and
the w/a seems to be to set FDI_RX_PHASE_SYNC_POINTER_OVR to enable the
On Wed, 14 Nov 2012 09:15:14 +
Chris Wilson wrote:
> The bspec was recently updated to remove the ability to update the
> semaphore using the MI_SEMAPHORE_BOX command, the ability to wait upon
> the semaphore value remained. Instead the advice is to update the
> register using the MI_LOAD_REG
Due to a discrepancy between the sleep time and the amount of time we
spend waiting inside the wait_event_timeout, it is possible that we end
up computing that negative time remains in the wait_ioctl. This is
obviously a bogus result to return to userspace, and triggers a WARN, so
we need to fix up
SNB graphics devices have a bug that prevent them from accessing certain
memory ranges, namely anything below 1M and in the pages listed in the
table. So reserve those at boot if set detect a SNB gfx device on the
CPU to avoid GPU hangs.
Stephane Marchesin had a similar patch to the page allocato
On Wed, 14 Nov 2012 20:43:31 +
Jesse Barnes wrote:
> SNB graphics devices have a bug that prevent them from accessing certain
> memory ranges, namely anything below 1M and in the pages listed in the
> table. So reserve those at boot if set detect a SNB gfx device on the
> CPU to avoid GPU ha
On Wed, 14 Nov 2012 21:19:05 +
Alan Cox wrote:
> On Wed, 14 Nov 2012 20:43:31 +
> Jesse Barnes wrote:
>
> > SNB graphics devices have a bug that prevent them from accessing certain
> > memory ranges, namely anything below 1M and in the pages listed in the
> > table. So reserve those at
On Wed, 14 Nov 2012 20:43:31 +
Jesse Barnes wrote:
> SNB graphics devices have a bug that prevent them from accessing certain
> memory ranges, namely anything below 1M and in the pages listed in the
> table. So reserve those at boot if set detect a SNB gfx device on the
> CPU to avoid GPU ha
On Wed, 14 Nov 2012 13:55:34 -0800
Jesse Barnes wrote:
> On Wed, 14 Nov 2012 21:19:05 +
> Alan Cox wrote:
>
> > On Wed, 14 Nov 2012 20:43:31 +
> > Jesse Barnes wrote:
> >
> > > SNB graphics devices have a bug that prevent them from accessing certain
> > > memory ranges, namely anythin
20 matches
Mail list logo
