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:
CreateByteField
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
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 +++
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
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 nex
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
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
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
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/
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
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
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
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
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
drivers/gpu/drm/radeon/r300.
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
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 wel
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: Christi
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 storing
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 a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm
On Don, 2012-07-12 at 18:23 -0400, j.gli...@gmail.com wrote:
> 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 d
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
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:
CreateByteField
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
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 +++
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
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 nex
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,
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
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
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/
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
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
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
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
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
drivers/gpu/drm/radeon/r300.
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
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 wel
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: Christi
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 storing
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 a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm
42 matches
Mail list logo
