On Sun, 19 Aug 2012 21:12:17 +0200
Daniel Vetter wrote:
> Hi all,
>
> Changes since last time around:
> - The prep patches are all merged now.
> - I've left out the actual DP fixes/cleanups, I think we should merge
> those in a separte step.
> - A few bugfixes (thanks to Paulo, Jani and Chris).
>From 952c95621b5fd95a629c36017c36ac9e6c40e839 Mon Sep 17 00:00:00 2001
From: Anhua Xu
Date: Tue, 21 Aug 2012 11:00:57 +0800
Subject: [PATCH] drm/i915: fix reassignment of variable "intel_dp->DP"
This little regression was introduced by:
commit 417e822deee1d2bcd8a8a60660c40a0903713f2b
Author: Kei
On Tue, 21 Aug 2012 00:49:17 +
"Liu, Ying2" wrote:
> We are running mesademo on Ivybridge platform. Glxdemo/glxpixmap
> doesn't work.
>
> If somebody could help us out, that would be great.
Please do not send HTML e-mail to the mailing list.
>
>
>
> The followings are the command dump from
hi,every body
du81692468___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
We are running mesademo on Ivybridge platform. Glxdemo/glxpixmap doesn't work.
If somebody could help us out, that would be great.
The followings are the command dump from ring buffer when glxdemo and glxpixmap
are runing:
Address GPU commands Meaning
0x0 7
ERR_INT on HSW will display unclaimed MMIO accesses. This can be either
the result of a driver bug writing to an invalid addresses, or the
result of RC6.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.c | 4
drivers/gpu/drm/i915/i915_reg.h | 1 +
2 files changed, 5 insertions
ERR_INT can generate interrupts. However since most of the conditions seem
quite fatal the patch opts to simply report it in error state instead of
adding more complexity to the interrupt handler for little gain (the
bits are sticky anyway).
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i
On Sat, Aug 11, 2012 at 03:41:26PM +0100, Chris Wilson wrote:
> Signed-off-by: Chris Wilson
Since most of the overlay-supporting hw uses physical mem for the overlay
I think this isn't much worth it: The additional frobbery in
attach/detach_phys object is likely more work than we'll anything we'l
On Sat, Aug 11, 2012 at 03:41:21PM +0100, Chris Wilson wrote:
> Signed-off-by: Chris Wilson
What about putting kmap/unmap abstractions into obj->ops (like the dma_buf
interface already has)? Since the pwrite/pread code is already rather
branch heave I hope we don't see the overhead of the indirec
On Sat, Aug 11, 2012 at 03:41:17PM +0100, Chris Wilson wrote:
> As we may wish to wrap regions preallocated by the BIOS, we need to do
> that before carving out contiguous chunks of stolen space for FBC.
>
> Signed-off-by: Chris Wilson
Some comments inline below.
-Daniel
> ---
> drivers/gpu/dr
On Sat, Aug 11, 2012 at 03:41:15PM +0100, Chris Wilson wrote:
> A few of the earlier registers where enlarged and so the Base Data of
> Stolem Memory Register (BDSM) was pushed to 0xb0.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_gem_stolen.c |9 -
> 1 file chan
On Sat, Aug 11, 2012 at 03:41:07PM +0100, Chris Wilson wrote:
> In order to specialise functions depending upon the type of object, we
> can attach vfuncs to each object via their obj->driver_private pointer,
> bringing it back to life!
>
> For instance, this will be used in future patches to only
On Wed, Aug 15, 2012 at 10:41:45AM +0200, Daniel Vetter wrote:
> James Bottomley reported [1] a massive power regression, due to the
> enabling of semaphores by default in 3.5. A workaround for him is to
> again disable semaphores. And indeed, his system has a very hard time
> to entre rc6 with sem
Signed-off-by: Adam Jackson
---
src/intel_module.c | 14 ++
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/src/intel_module.c b/src/intel_module.c
index edea48d..be9688a 100644
--- a/src/intel_module.c
+++ b/src/intel_module.c
@@ -392,11 +392,17 @@ static Bool has_k
... let's see how whether this catches anything earlier and I can
track down a few bugs.
v2: Add more checks and also add DRM_DEBUG_KMS output so that it's
clear which connector/encoder/crtc is being checked atm. Which proved
rather useful for debugging ...
v3: Add a WARN in the common encoder dp
On Sun, 19 Aug 2012, Daniel Vetter wrote:
> I'll also plan to put tags for the entire series in the merge commit, so if
> you
> have tested this on a few machines, read through and agree with the new
> designs,
> please reply with your tested-by/acked-by/reviewed-by tags.
>
> Flames, comments an
On Mon, 20 Aug 2012 11:37:30 +0200, Daniel Vetter wrote:
> Ok, I've picked up things up to this patch, with the few changes applied
> as discussed (plus ditching an unused var that I've forgotten to kill when
> purging the put_pages from gem_reset). I'll look at the others later
> today.
I think
On Mon, Aug 20, 2012 at 10:36:09AM +0100, Chris Wilson wrote:
> On Mon, 20 Aug 2012 11:00:39 +0200, Daniel Vetter
> wrote:
> > int
> > -i915_gem_object_get_pages_gtt(struct drm_i915_gem_object *obj,
> > - gfp_t gfpmask)
> > +i915_gem_object_get_pages_gtt(struct drm_i915_g
On Sat, Aug 11, 2012 at 03:41:03PM +0100, Chris Wilson wrote:
> Given the persistence of an offset for the lifetime of an object, itis
> easy to contemplate how the mmap space becomes badly fragmented to the
> point that further allocations fail with ENOSPC. Our only recourse at
> this point is to
On Mon, 20 Aug 2012 11:00:39 +0200, Daniel Vetter
wrote:
> int
> -i915_gem_object_get_pages_gtt(struct drm_i915_gem_object *obj,
> - gfp_t gfpmask)
> +i915_gem_object_get_pages_gtt(struct drm_i915_gem_object *obj)
> {
> + struct drm_i915_private *dev_priv = obj->ba
... let's see how whether this catches anything earlier and I can
track down a few bugs.
v2: Add more checks and also add DRM_DEBUG_KMS output so that it's
clear which connector/encoder/crtc is being checked atm. Which proved
rather useful for debugging ...
v3: Add a WARN in the common encoder dp
A pair of universally true checks that just need to be put in the right
place depending on where in the patch sequence you go. Note that
i915_gem_object_put_pages_gtt() already gains the
BUG_ON(obj->gtt_space), but on reflection that needed to migrate to
put_pages().
---
drivers/gpu/drm/i915/i915
On Mon, 20 Aug 2012 11:04:52 +0200, Daniel Vetter wrote:
> On Sat, Aug 11, 2012 at 03:41:01PM +0100, Chris Wilson wrote:
> > Signed-off-by: Chris Wilson
> > if (obj->pin_mappable) {
> > - mappable_size += obj->gtt_space->size;
> > + mappable_size +=
On Sat, Aug 11, 2012 at 03:41:01PM +0100, Chris Wilson wrote:
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 19 ++-
> 1 file changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i9
When dealing with a working set larger than the GATT, or even the
mappable aperture when touching through the GTT, we end up with evicting
objects only to rebind them at a new offset again later. Moving an
object into and out of the GTT requires clflushing the pages, thus
causing a double-clflush p
Prep work to make Chris Wilson's unbound tracking patch a bit easier
to read. Alas, I'd have preferred that moving the page allocation
retry loop from bind to get_pages would have been a separate patch,
too. But that looks like real work ;-)
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/
26 matches
Mail list logo
