3.5-rc5: radeon acceleration regression on Transmeta system

- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120710/a7e5b04a/attachment.pgp>

[PATCH 15/15] drm/radeon: implement ring saving on reset v2

On Die, 2012-07-10 at 14:51 +0200, Christian K?nig wrote: > Try to save whatever is on the rings when > we encounter an lockup. > > v2: Fix spelling error. Free saved ring data if reset fails. > Add documentation for the new functions. > > Signed-off-by: Christian K?nig Just some more

Mesa shader compiling/optimizing process is too slow

Presumably there needs to be a api-level mechanism to wait for the background optimization to finish, so that piglit etc can validate the behavior of the optimized shader? -- Chris On Tue, Jul 10, 2012 at 5:17 AM, Eric Anholt wrote: > Tiziano Bacocco writes: > >> I've done benchmarks and

[PATCH 3/3] drm/exynos: implement kmap/kunmap/kmap_atomic/kunmap_atomic functions of dma_buf_ops

Implement kmap/kmap_atomic, kunmap/kunmap_atomic functions of dma_buf_ops. Signed-off-by: Cooper Yuan --- drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 17 +++-- 1 files changed, 11 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c

[PATCH 2/3] drm/exynos: add dmabuf mmap function

implement mmap function of dma_buf_ops. Signed-off-by: Cooper Yuan --- drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 38 1 files changed, 38 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c

[PATCH 1/3] drm/exynos: correct dma_buf exporter permission as ReadWrite

Set dma_buf exporter permission as ReadWrite, otherwise mmap will get errno 13: permission denied. Signed-off-by: Cooper Yuan --- drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c

[RFC] drm/radeon: restoring ring commands in case of a lockup

On 09.07.2012 18:10, Jerome Glisse wrote: > On Mon, Jul 9, 2012 at 11:59 AM, Michel D?nzer wrote: >> On Mon, 2012-07-09 at 12:41 +0200, Christian K?nig wrote: >>> Hi, >>> >>> The following patchset tries to save and restore the not yet processed >>> commands >>> from the rings in case of a

[PATCH 15/15] drm/radeon: implement ring saving on reset v2

Try to save whatever is on the rings when we encounter an lockup. v2: Fix spelling error. Free saved ring data if reset fails. Add documentation for the new functions. Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/radeon.h|4 ++

[PATCH 14/15] drm/radeon: record what is next valid wptr for each ring v2

Before emitting any indirect buffer, emit the offset of the next valid ring content if any. This allow code that want to resume ring to resume ring right after ib that caused GPU lockup. v2: use scratch registers instead of storing it into memory Signed-off-by: Jerome Glisse Signed-off-by:

[PATCH 13/15] drm/radeon: move radeon_ib_ring_tests out of chipset code

Making it easier to controlwhen it is executed. Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/evergreen.c |4 drivers/gpu/drm/radeon/ni.c|4 drivers/gpu/drm/radeon/r100.c |4 drivers/gpu/drm/radeon/r300.c |4

[PATCH 12/15] drm/radeon: remove vm_manager start/suspend

Just restore the page table instead. Addressing three problem with this change: 1. Calling vm_manager_suspend in the suspend path is problematic cause it wants to wait for the VM use to end, which in case of a lockup never happens. 2. In case of a locked up memory controller unbinding

[PATCH 11/15] drm/radeon: remove r600_blit_suspend

Just reinitialize the shader content on resume instead. Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/evergreen.c |1 - drivers/gpu/drm/radeon/evergreen_blit_kms.c | 40 +-- drivers/gpu/drm/radeon/ni.c |1 -

[PATCH 10/15] drm/radeon: remove ip_pool start/suspend

The IB pool is in gart memory, so it is completely superfluous to unpin / repin it on suspend / resume. Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/evergreen.c | 17 ++--- drivers/gpu/drm/radeon/ni.c | 16 ++-- drivers/gpu/drm/radeon/r100.c

[PATCH 09/15] drm/radeon: make cp init on cayman more robust

It's not critical, but the current code isn't 100% correct. Signed-off-by: Christian K?nig Reviewed-by: Jerome Glisse --- drivers/gpu/drm/radeon/ni.c | 133 ++- 1 file changed, 56 insertions(+), 77 deletions(-) diff --git a/drivers/gpu/drm/radeon/ni.c

[PATCH 06/15] drm/radeon: fix fence value access

It is possible that radeon_fence_process is called after writeback is disabled for suspend, leading to an invalid read of register 0x0. This fixes a problem for me where the fence value is temporary incremented by 0x1 on suspend/resume. Signed-off-by: Christian K?nig Reviewed-by: Jerome

[PATCH 05/15] drm/radeon: fix ring commit padding

We don't need to pad anything if the number of dwords written to the ring already matches the requirements. Fixes some "writting more dword to ring than expected" warnings. Signed-off-by: Christian K?nig Reviewed-by: Jerome Glisse Reviewed-by: Michel D?nzer ---

[PATCH 04/15] drm/radeon: add an exclusive lock for GPU reset v2

From: Jerome Glisse GPU reset need to be exclusive, one happening at a time. For this add a rw semaphore so that any path that trigger GPU activities have to take the semaphore as a reader thus allowing concurency. The GPU reset path take the semaphore as a writer ensuring

[PATCH 03/15] drm/radeon: fix fence related segfault in CS

Don't return success if scheduling the IB fails, otherwise we end up with an oops in ttm_eu_fence_buffer_objects. Signed-off-by: Christian K?nig Reviewed-by: Jerome Glisse Reviewed-by: Michel D?nzer Cc: stable at vger.kernel.org --- drivers/gpu/drm/radeon/radeon_cs.c |2 +- 1 file

[PATCH 02/15] drm/radeon: add error handling to radeon_vm_unbind_locked

Waiting for a fence can fail for different reasons, the most common is a deadlock. Signed-off-by: Christian K?nig Reviewed-by: Michel D?nzer Reviewed-by: Jerome Glisse --- drivers/gpu/drm/radeon/radeon_gart.c | 17 ++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff

[PATCH 01/15] drm/radeon: add error handling to fence_wait_empty_locked

Instead of returning the error handle it directly and while at it fix the comments about the ring lock. Signed-off-by: Christian K?nig Reviewed-by: Michel D?nzer Reviewed-by: Jerome Glisse --- drivers/gpu/drm/radeon/radeon.h |2 +- drivers/gpu/drm/radeon/radeon_fence.c | 33

[RFC PATCH 8/8] nouveau: Prime execbuffer submission synchronization

From: Maarten Lankhorst Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/nouveau/nouveau_gem.c | 121 +++-- 1 file changed, 116 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c

[RFC PATCH 7/8] nouveau: nvc0 fence prime implementation

From: Maarten Lankhorst Create a read-only mapping for every imported bo, and create a prime bo in in system memory. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/nouveau/nvc0_fence.c | 104 +- 1 file changed, 89

[RFC PATCH 6/8] nouveau: nv84 fence prime implementation

From: Maarten Lankhorst Create a dma object for the prime semaphore and every imported sync bo. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/nouveau/nv84_fence.c | 121 -- 1 file changed, 115 insertions(+), 6

[RFC PATCH 5/8] nouveau: Add methods preparing for prime fencing

From: Maarten Lankhorst This can be used by nv84 and nvc0 to implement hardware fencing, earlier systems will require more thought but can fall back to software for now. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/nouveau/nouveau_bo.c |6 +-

[RFC PATCH 4/8] nouveau: add nouveau_bo_vma_add_access

From: Maarten Lankhorst This is needed to allow creation of read-only vm mappings in fence objects. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/nouveau/nouveau_bo.c |6 +++--- drivers/gpu/drm/nouveau/nouveau_drv.h |6 -- 2 files changed,

[RFC PATCH 3/8] nouveau: Extend prime code

From: Maarten Lankhorst The prime code no longer requires the bo to be backed by a gem object, and cpu access calls have been implemented. This will be needed for exporting fence bo's. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/nouveau/nouveau_drv.h

[RFC PATCH 2/8] prime wip: i915

From: Maarten Lankhorst Export the hardware status page so others can read seqno. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/i915_gem_dmabuf.c | 29 -- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 87

[RFC PATCH 1/8] dma-buf-mgr: Try 2

From: Maarten Lankhorst Core code based on ttm_bo and ttm_execbuf_util Signed-off-by: Maarten Lankhorst --- drivers/base/Makefile |2 +- drivers/base/dma-buf-mgr-eu.c | 263 + drivers/base/dma-buf-mgr.c

[RFC PATCH 0/8] Dmabuf synchronization

This patch implements my attempt at dmabuf synchronization. The core idea is that a lot of devices will have their own methods of synchronization, but more complicated devices allow some way of fencing, so why not export those as dma-buf? This patchset implements dmabufmgr, which is based on

[PATCH 14/15] drm/radeon: record what is next valid wptr for each ring v2

On Tue, Jul 10, 2012 at 8:51 AM, Christian K?nig wrote: > Before emitting any indirect buffer, emit the offset of the next > valid ring content if any. This allow code that want to resume > ring to resume ring right after ib that caused GPU lockup. > > v2: use scratch registers instead of storing

[PATCH 1/2] drm: Add colouring to the range allocator

In order to support snoopable memory on non-LLC architectures (so that we can bind vgem objects into the i915 GATT for example), we have to avoid the prefetcher on the GPU from crossing memory domains and so prevent allocation of a snoopable PTE immediately following an uncached PTE. To do that,

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #65 from Alexandre Demers 2012-07-10 00:23:46 PDT --- Created attachment 64053 --> https://bugs.freedesktop.org/attachment.cgi?id=64053 xsession with drm-next .xsession with drm-next branch -- Configure bugmail:

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #64 from Alexandre Demers 2012-07-10 00:22:55 PDT --- Created attachment 64052 --> https://bugs.freedesktop.org/attachment.cgi?id=64052 dmesg drm-next dmesg with latest drm-next branch -- Configure bugmail:

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #63 from Alexandre Demers 2012-07-10 00:21:56 PDT --- Now running latest drm-next just in case. Always the same error, but with a little something new: with regular kernel, once the GPU crashed, it stays this way. With the drm-next

[PATCH] drm/exynos: Add exynos drm specific fb_mmap function

This patch adds a exynos drm specific implementation of fb_mmap which supports mapping a non-contiguous buffer to user space. This new function does not assume that the frame buffer is contiguous and calls dma_mmap_writecombine for mapping the buffer to user space. dma_mmap_writecombine will be

Re: [REGRESSION] nouveau: Memory corruption using nva3 engine for 0xaf

On Mon, Jul 09, 2012 at 03:13:25PM +0200, Henrik Rydberg wrote: On Thu, Jul 05, 2012 at 10:34:10AM +0200, Henrik Rydberg wrote: On Thu, Jul 05, 2012 at 08:54:46AM +0200, Henrik Rydberg wrote: Thanks for tracking down the source of this corruption. I don't have any such hardware, so

[PATCH 1/2] drm: Add colouring to the range allocator

In order to support snoopable memory on non-LLC architectures (so that we can bind vgem objects into the i915 GATT for example), we have to avoid the prefetcher on the GPU from crossing memory domains and so prevent allocation of a snoopable PTE immediately following an uncached PTE. To do that,

[RFC PATCH 0/8] Dmabuf synchronization

This patch implements my attempt at dmabuf synchronization. The core idea is that a lot of devices will have their own methods of synchronization, but more complicated devices allow some way of fencing, so why not export those as dma-buf? This patchset implements dmabufmgr, which is based on

[RFC PATCH 1/8] dma-buf-mgr: Try 2

From: Maarten Lankhorst maarten.lankho...@canonical.com Core code based on ttm_bo and ttm_execbuf_util Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- drivers/base/Makefile |2 +- drivers/base/dma-buf-mgr-eu.c | 263 +

[RFC PATCH 2/8] prime wip: i915

From: Maarten Lankhorst maarten.lankho...@canonical.com Export the hardware status page so others can read seqno. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- drivers/gpu/drm/i915/i915_gem_dmabuf.c | 29 -- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 87

[RFC PATCH 3/8] nouveau: Extend prime code

From: Maarten Lankhorst maarten.lankho...@canonical.com The prime code no longer requires the bo to be backed by a gem object, and cpu access calls have been implemented. This will be needed for exporting fence bo's. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com ---

[RFC PATCH 4/8] nouveau: add nouveau_bo_vma_add_access

From: Maarten Lankhorst maarten.lankho...@canonical.com This is needed to allow creation of read-only vm mappings in fence objects. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- drivers/gpu/drm/nouveau/nouveau_bo.c |6 +++--- drivers/gpu/drm/nouveau/nouveau_drv.h |

[RFC PATCH 5/8] nouveau: Add methods preparing for prime fencing

From: Maarten Lankhorst maarten.lankho...@canonical.com This can be used by nv84 and nvc0 to implement hardware fencing, earlier systems will require more thought but can fall back to software for now. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com ---

[RFC PATCH 6/8] nouveau: nv84 fence prime implementation

From: Maarten Lankhorst maarten.lankho...@canonical.com Create a dma object for the prime semaphore and every imported sync bo. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- drivers/gpu/drm/nouveau/nv84_fence.c | 121 -- 1 file changed,

[RFC PATCH 7/8] nouveau: nvc0 fence prime implementation

From: Maarten Lankhorst maarten.lankho...@canonical.com Create a read-only mapping for every imported bo, and create a prime bo in in system memory. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- drivers/gpu/drm/nouveau/nvc0_fence.c | 104

[RFC PATCH 8/8] nouveau: Prime execbuffer submission synchronization

From: Maarten Lankhorst maarten.lankho...@canonical.com Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- drivers/gpu/drm/nouveau/nouveau_gem.c | 121 +++-- 1 file changed, 116 insertions(+), 5 deletions(-) diff --git

[PATCH 02/15] drm/radeon: add error handling to radeon_vm_unbind_locked

Waiting for a fence can fail for different reasons, the most common is a deadlock. Signed-off-by: Christian König deathsim...@vodafone.de Reviewed-by: Michel Dänzer michel.daen...@amd.com Reviewed-by: Jerome Glisse jgli...@redhat.com --- drivers/gpu/drm/radeon/radeon_gart.c | 17

[PATCH 03/15] drm/radeon: fix fence related segfault in CS

Don't return success if scheduling the IB fails, otherwise we end up with an oops in ttm_eu_fence_buffer_objects. Signed-off-by: Christian König deathsim...@vodafone.de Reviewed-by: Jerome Glisse jgli...@redhat.com Reviewed-by: Michel Dänzer michel.daen...@amd.com Cc: sta...@vger.kernel.org ---

[PATCH 01/15] drm/radeon: add error handling to fence_wait_empty_locked

Instead of returning the error handle it directly and while at it fix the comments about the ring lock. Signed-off-by: Christian König deathsim...@vodafone.de Reviewed-by: Michel Dänzer michel.daen...@amd.com Reviewed-by: Jerome Glisse jgli...@redhat.com --- drivers/gpu/drm/radeon/radeon.h

[PATCH 04/15] drm/radeon: add an exclusive lock for GPU reset v2

From: Jerome Glisse jgli...@redhat.com GPU reset need to be exclusive, one happening at a time. For this add a rw semaphore so that any path that trigger GPU activities have to take the semaphore as a reader thus allowing concurency. The GPU reset path take the semaphore as a writer ensuring

[PATCH 05/15] drm/radeon: fix ring commit padding

We don't need to pad anything if the number of dwords written to the ring already matches the requirements. Fixes some writting more dword to ring than expected warnings. Signed-off-by: Christian König deathsim...@vodafone.de Reviewed-by: Jerome Glisse jgli...@redhat.com Reviewed-by: Michel

[PATCH 06/15] drm/radeon: fix fence value access

It is possible that radeon_fence_process is called after writeback is disabled for suspend, leading to an invalid read of register 0x0. This fixes a problem for me where the fence value is temporary incremented by 0x1 on suspend/resume. Signed-off-by: Christian König

[PATCH 07/15] drm/radeon: fix fence init after resume

Start with last signaled fence number instead of last emitted one. Signed-off-by: Christian König deathsim...@vodafone.de Reviewed-by: Jerome Glisse jgli...@redhat.com --- drivers/gpu/drm/radeon/radeon_fence.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 08/15] drm/radeon: remove FIXME comment from chipset suspend

For a normal suspend/resume we allready wait for the rings to be empty, and for a suspend/reasume in case of a lockup we REALLY don't want to wait for anything. Signed-off-by: Christian König deathsim...@vodafone.de Reviewed-by: Jerome Glisse jgli...@redhat.com ---

[PATCH 09/15] drm/radeon: make cp init on cayman more robust

It's not critical, but the current code isn't 100% correct. Signed-off-by: Christian König deathsim...@vodafone.de Reviewed-by: Jerome Glisse jgli...@redhat.com --- drivers/gpu/drm/radeon/ni.c | 133 ++- 1 file changed, 56 insertions(+), 77 deletions(-)

[PATCH 10/15] drm/radeon: remove ip_pool start/suspend

The IB pool is in gart memory, so it is completely superfluous to unpin / repin it on suspend / resume. Signed-off-by: Christian König deathsim...@vodafone.de --- drivers/gpu/drm/radeon/evergreen.c | 17 ++--- drivers/gpu/drm/radeon/ni.c | 16 ++--

[PATCH 12/15] drm/radeon: remove vm_manager start/suspend

Just restore the page table instead. Addressing three problem with this change: 1. Calling vm_manager_suspend in the suspend path is problematic cause it wants to wait for the VM use to end, which in case of a lockup never happens. 2. In case of a locked up memory controller unbinding

[PATCH 11/15] drm/radeon: remove r600_blit_suspend

Just reinitialize the shader content on resume instead. Signed-off-by: Christian König deathsim...@vodafone.de --- drivers/gpu/drm/radeon/evergreen.c |1 - drivers/gpu/drm/radeon/evergreen_blit_kms.c | 40 +-- drivers/gpu/drm/radeon/ni.c |

[PATCH 13/15] drm/radeon: move radeon_ib_ring_tests out of chipset code

Making it easier to controlwhen it is executed. Signed-off-by: Christian König deathsim...@vodafone.de --- drivers/gpu/drm/radeon/evergreen.c |4 drivers/gpu/drm/radeon/ni.c|4 drivers/gpu/drm/radeon/r100.c |4 drivers/gpu/drm/radeon/r300.c

[PATCH 14/15] drm/radeon: record what is next valid wptr for each ring v2

Before emitting any indirect buffer, emit the offset of the next valid ring content if any. This allow code that want to resume ring to resume ring right after ib that caused GPU lockup. v2: use scratch registers instead of storing it into memory Signed-off-by: Jerome Glisse jgli...@redhat.com

[PATCH 15/15] drm/radeon: implement ring saving on reset v2

Try to save whatever is on the rings when we encounter an lockup. v2: Fix spelling error. Free saved ring data if reset fails. Add documentation for the new functions. Signed-off-by: Christian König deathsim...@vodafone.de --- drivers/gpu/drm/radeon/radeon.h|4 ++

Re: [RFC] drm/radeon: restoring ring commands in case of a lockup

On 09.07.2012 18:10, Jerome Glisse wrote: On Mon, Jul 9, 2012 at 11:59 AM, Michel Dänzer mic...@daenzer.net wrote: On Mon, 2012-07-09 at 12:41 +0200, Christian König wrote: Hi, The following patchset tries to save and restore the not yet processed commands from the rings in case of a lockup

[PATCH 1/3] drm/exynos: correct dma_buf exporter permission as ReadWrite

Set dma_buf exporter permission as ReadWrite, otherwise mmap will get errno 13: permission denied. Signed-off-by: Cooper Yuan coopery...@gmail.com --- drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git

[PATCH 2/3] drm/exynos: add dmabuf mmap function

implement mmap function of dma_buf_ops. Signed-off-by: Cooper Yuan coopery...@gmail.com --- drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 38 1 files changed, 38 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c

[PATCH 3/3] drm/exynos: implement kmap/kunmap/kmap_atomic/kunmap_atomic functions of dma_buf_ops

Implement kmap/kmap_atomic, kunmap/kunmap_atomic functions of dma_buf_ops. Signed-off-by: Cooper Yuan coopery...@gmail.com --- drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 17 +++-- 1 files changed, 11 insertions(+), 6 deletions(-) diff --git

Re: [PATCH 15/15] drm/radeon: implement ring saving on reset v2

On Die, 2012-07-10 at 14:51 +0200, Christian König wrote: Try to save whatever is on the rings when we encounter an lockup. v2: Fix spelling error. Free saved ring data if reset fails. Add documentation for the new functions. Signed-off-by: Christian König deathsim...@vodafone.de

Re: [PATCH 14/15] drm/radeon: record what is next valid wptr for each ring v2

On Tue, Jul 10, 2012 at 8:51 AM, Christian König deathsim...@vodafone.de wrote: Before emitting any indirect buffer, emit the offset of the next valid ring content if any. This allow code that want to resume ring to resume ring right after ib that caused GPU lockup. v2: use scratch registers

Re: 3.5-rc5: radeon acceleration regression on Transmeta system

On Mon, 09 Jul 2012 14:30:40 +0300, Meelis Roos said: It's actually more complicated than that. Old kernel images started misbehaving from around 2.6.35-rc5 and any kernel older than that was OK. When I recompiled the older kernels with squeeze gcc (migh have been lenny gcc before, or

Re: general protection fault on ttm_init()

On Sat, Jul 07, 2012 at 11:31:42PM +0800, Fengguang Wu wrote: On Sat, Jul 07, 2012 at 10:08:47AM +0800, Fengguang Wu wrote: On Fri, Jul 06, 2012 at 06:09:20PM +0100, Dave Airlie wrote: On Fri, Jul 6, 2012 at 5:49 PM, Dave Airlie airl...@gmail.com wrote: On Fri, Jul 6, 2012 at 3:48 PM,