[PATCH] drm/radeon: fix bo creation retry path

From: Jerome Glisse Retry label was at wrong place in function leading to memory leak. Cc: Signed-off-by: Jerome Glisse --- drivers/gpu/drm/radeon/radeon_object.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

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

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. v3: Some more spelling fixes v4: It doesn't make sense to save anything if all fences are signaled Signed-off-by:

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

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 v3: skip over the surface sync for ni and si as

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

Making it easier to control when it is executed. Signed-off-by: Christian K?nig Reviewed-by: Michel D?nzer --- drivers/gpu/drm/radeon/evergreen.c |4 drivers/gpu/drm/radeon/ni.c|4 drivers/gpu/drm/radeon/r100.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 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 Reviewed-by: Jerome Glisse --- drivers/gpu/drm/radeon/evergreen.c |1 -

[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 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

[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

Ring saving patches round 3

I hope that this is the last round necessary, beside including all the comments from Michel and Jerome there is a small change to patch 15 to not save anything if the all fences on a ring are already signaled. The branch is also available as: git://people.freedesktop.org/~deathsimple/linux

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

On Tue, Jul 10, 2012 at 11:15:23AM +0100, Chris Wilson wrote: > 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

AMD GPU: Toshiba, brightness and ATIF

Hello, I'm trying to figure out how to control the brightness of the screen of my laptop, a Toshiba L885-10W. The ACPI DSDT table contains the standard control methods, the setter (_BCM), however, only sets a value in the record returned by ATIF method and send out a notification:

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

On Thu, Jul 12, 2012 at 12:12 PM, 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

[PATCH] dma-fence: dma-buf synchronization

Op 12-07-12 00:29, Rob Clark schreef: > From: Rob Clark > > A dma-fence can be attached to a buffer which is being filled or consumed > by hw, to allow userspace to pass the buffer without waiting to another > device. For example, userspace can call page_flip ioctl to display the > next frame of

AMD GPU: Toshiba, brightness and ATIF

Hello, I'm trying to figure out how to control the brightness of the screen of my laptop, a Toshiba L885-10W. The ACPI DSDT table contains the standard control methods, the setter (_BCM), however, only sets a value in the record returned by ATIF method and send out a notification:

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

On Tue, Jul 10, 2012 at 11:15:23AM +0100, Chris Wilson wrote: 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

[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 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

Ring saving patches round 3

I hope that this is the last round necessary, beside including all the comments from Michel and Jerome there is a small change to patch 15 to not save anything if the all fences on a ring are already signaled. The branch is also available as: git://people.freedesktop.org/~deathsimple/linux

[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 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 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 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 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 control when it is executed. Signed-off-by: Christian König deathsim...@vodafone.de Reviewed-by: Michel Dänzer michel.daen...@amd.com --- drivers/gpu/drm/radeon/evergreen.c |4 drivers/gpu/drm/radeon/ni.c|4 drivers/gpu/drm/radeon/r100.c

[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 14/15] drm/radeon: record what is next valid wptr for each ring v3

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 v3: skip over the surface sync for ni and si as

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

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. v3: Some more spelling fixes v4: It doesn't make sense to save anything if all fences are signaled Signed-off-by:

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

On Thu, Jul 12, 2012 at 12:12 PM, 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

[PATCH] drm/radeon: fix bo creation retry path

From: Jerome Glisse jgli...@redhat.com Retry label was at wrong place in function leading to memory leak. Cc: sta...@vger.kernel.org Signed-off-by: Jerome Glisse jgli...@redhat.com --- drivers/gpu/drm/radeon/radeon_object.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git