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 wrote:
> > > > On Fri, Jul 6, 2012 at 3:48 PM, Fengguang
hing.
-- 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>
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 spel
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 compar
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 diff
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
b/drivers/gpu/
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
b/drivers/gpu/drm/exynos/exynos_drm_dm
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
b/dri
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 lockup
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 ++
drivers/gpu/drm/radeon/radeon_device.c
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: Chris
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
drive
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 th
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 -
drivers/gpu/drm/r
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
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 b
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
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/evergreen.c |1 -
drivers/gpu/drm/radeon/ni.c
Start with last signaled fence number instead
of last emitted one.
Signed-off-by: Christian K?nig
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_fence.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
b/drivers/gpu/drm/
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
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
---
drivers/gpu/drm/radeon/radeon_r
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 that
no concurrent res
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 changed,
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 --gi
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 +++
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
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 11c9c
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 insertions(+), 15 deletions(-)
diff --gi
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 deletions(-)
diff --git a/drivers/gpu/drm/n
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 +-
drivers/gpu/drm/nouveau/nouveau_c
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, 7 insertions(+), 5 deletions(-)
d
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 |6 +-
drivers/gpu/drm/nouve
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
drivers/gpu/drm/i915/intel_ringb
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| 149 +++
dr
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 ttm's
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
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, we
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
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 spel
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: https://bugs.fre
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: https://bugs.freedesk
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 b
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
b/drivers/gpu/
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
b/drivers/gpu/drm/exynos/exynos_drm_dm
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
b/dri
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 lockup and with that should
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 ++
drivers/gpu/drm/radeon/radeon_device.c
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: Chris
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
drive
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 -
drivers/gpu/drm/r
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 th
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
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 b
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
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/evergreen.c |1 -
drivers/gpu/drm/radeon/ni.c
Start with last signaled fence number instead
of last emitted one.
Signed-off-by: Christian König
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_fence.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
b/drivers/gpu/drm/
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
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
---
drivers/gpu/drm/radeon/radeon_r
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 that
no concurrent res
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 +++
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: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_cs.c |2 +-
1 file changed, 1
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 --gi
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
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 11c9c
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 insertions(+), 15 deletions(-)
diff --gi
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 deletions(-)
diff --git a/drivers/gpu/drm/n
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 +-
drivers/gpu/drm/nouveau/nouveau_c
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, 7 insertions(+), 5 deletions(-)
d
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 |6 +-
drivers/gpu/drm/nouve
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
drivers/gpu/drm/i915/intel_ringb
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| 149 +++
dr
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 ttm's
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, we
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 hardwa
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 abl
71 matches
Mail list logo
