Hi Jerome,
On Wed, Apr 25, 2012 at 9:03 PM, wrote:
> From: Jerome Glisse
>
> This add a command buffer dumping facilities, that will
> dump command buffer and all associated bo that most likely
> triggered a lockup.
[cut]
I spotted this:
> +void radeon_fence_blob_faulty_ib(struct radeon_devic
On Wed, Apr 25, 2012 at 11:20:36PM +0200, Marcin Slusarz wrote:
> Overall idea:
> Detect lockups by watching for timeouts (vm flush / fence), return -EIOs,
> handle them at ioctl level, reset the GPU and repeat last ioctl.
>
> GPU reset is done by doing suspend / resume cycle with few tweaks:
> -
Overall idea:
Detect lockups by watching for timeouts (vm flush / fence), return -EIOs,
handle them at ioctl level, reset the GPU and repeat last ioctl.
GPU reset is done by doing suspend / resume cycle with few tweaks:
- CPU-only bo eviction
- ignoring vm flush / fence timeouts
- shortening waits
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/nouveau/nv50_graph.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nv50_graph.c
b/drivers/gpu/drm/nouveau/nv50_graph.c
index 6899547..a61853f 100644
--- a/drivers/gpu/drm/nouveau/nv50_graph.c
We need this for lockup recovery.
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/nouveau/nouveau_bo.c |9 +++--
drivers/gpu/drm/nouveau/nouveau_drv.h |6 +++---
drivers/gpu/drm/nouveau/nouveau_vm.c | 20 ++--
drivers/gpu/drm/nouveau/nouveau_vm.h | 18 +++
Wait loop can be interrupted by signal, so if signals are raised
periodically (e.g. SIGALRM) this loop may never finish. Use
emission time as a base for fence timeout.
Signed-off-by: Marcin Slusarz
---
drivers/gpu/drm/nouveau/nouveau_fence.c |5 -
1 files changed, 4 insertions(+), 1 dele
Michael,
On Sun, 11 Mar 2012 22:23:22 +0100, Carsten Emde wrote:
On 03/11/2012 02:44 PM, Alan Cox wrote:
This patch allows to load an EDID data set via the firmware interface.
It contains data sets of frequently used screen resolutions (1024x768,
1280x1024, 1680x1050 and 1920x1080). The reques
On Tue, Apr 17, 2012 at 12:40 PM, Randy Dunlap wrote:
> On 04/16/2012 09:42 PM, Stephen Rothwell wrote:
>
>> Hi all,
>>
>> Changes since 20120416:
>
>
> When CONFIG_VGA_ARB is not enabled:
>
> drivers/built-in.o: In function `boot_vga_show':
> pci-sysfs.c:(.text+0x1060f): undefined reference to `v
On 04/25/2012 03:45 AM, Thierry Reding wrote:
> This function resolves an OF device node to an I2C adapter registered
> with the I2C core.
I think this is doing the same thing as a patch I posted recently:
http://www.spinics.net/lists/linux-i2c/msg07808.html
What's the advantage of one way over t
https://bugs.freedesktop.org/show_bug.cgi?id=49140
--- Comment #1 from Vadim 2012-04-25 16:06:28 PDT ---
Probably register limit. Shader uses 5 inputs + 8 outputs + 112 temps = 125
registers. I think it should work if you could make it less than 120.
--
Configure bugmail: https://bugs.freedeskt
Hi Dave,
2012/4/25, Dave Airlie :
> On Tue, Apr 24, 2012 at 6:17 AM, Inki Dae wrote:
>> this feature could be used to use memory region allocated by malloc() in
>> user
>> mode and mmaped memory region allocated by other memory allocators.
>> userptr
>> interface can identify memory type through
https://bugs.freedesktop.org/show_bug.cgi?id=41668
--- Comment #27 from dmotd 2012-04-25 19:44:29
PDT ---
apologies for the many months without reply - i have not been in a position to
contribute after making the initial bug report.
i recently performed a system update and am currently running
requently this isn't much of an issue.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120425/ae82b75a/attachment.pgp>
On Wed, Apr 25, 2012 at 5:53 PM, Luca Tettamanti wrote:
> Hi Jerome,
>
> On Wed, Apr 25, 2012 at 9:03 PM, ? wrote:
>> From: Jerome Glisse
>>
>> This add a command buffer dumping facilities, that will
>> dump command buffer and all associated bo that most likely
>> triggered a lockup.
> [cut]
>
>
On 25.04.2012 16:36, Jerome Glisse wrote:
> NAK i would rather have a full dump as i described. I can do a patch
> for that if you want.
>
I don't stick with those files neither, just wanted to restore the same
functionality as we had before.
Just finished a conference call with Alex and the rest
On Wed, Apr 25, 2012 at 10:37:26AM -0600, Bjorn Helgaas wrote:
> I assume this is related to 77b267c7549e3629ea55cf780aa3d474da7bc2d5
> ("vgaarb: Add support for setting the default video device") and that
> Matthew will take care of whatever needs to be done (if it's not fixed
> already).
Dave ha
On 25.04.2012 16:34, Jerome Glisse wrote:
> On Wed, Apr 25, 2012 at 9:40 AM, Alex Deucher
> wrote:
>> On Wed, Apr 25, 2012 at 9:19 AM, Michel D?nzer wrote:
>>> On Mit, 2012-04-25 at 14:46 +0200, Christian K?nig wrote:
Aligning offset can make it bigger than tmp->offset
leading to an ov
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #50 from Michel D?nzer 2012-04-25 09:16:19
PDT ---
Comment on attachment 60582
--> https://bugs.freedesktop.org/attachment.cgi?id=60582
possible fix
Review of attachment 60582:
-->
(https://bugs.freedesktop.org/page.cgi?id=splin
https://bugs.freedesktop.org/show_bug.cgi?id=49140
--- Comment #1 from Vadim 2012-04-25 16:06:28 PDT ---
Probably register limit. Shader uses 5 inputs + 8 outputs + 112 temps = 125
registers. I think it should work if you could make it less than 120.
--
Configure bugmail: https://bugs.freedeskt
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #49 from Alex Deucher 2012-04-25 08:59:57 PDT
---
Created attachment 60582
--> https://bugs.freedesktop.org/attachment.cgi?id=60582
possible fix
Does this patch help?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.
On 25.04.2012 15:19, Michel D?nzer wrote:
> On Mit, 2012-04-25 at 14:46 +0200, Christian K?nig wrote:
>> Aligning offset can make it bigger than tmp->offset
>> leading to an overrun bug in the following subtraction.
>>
>> Signed-off-by: Christian K?nig
> Please add
>
> Cc: stable at vger.kernel.org
On Wed, Apr 25, 2012 at 5:53 PM, Luca Tettamanti wrote:
> Hi Jerome,
>
> On Wed, Apr 25, 2012 at 9:03 PM, wrote:
>> From: Jerome Glisse
>>
>> This add a command buffer dumping facilities, that will
>> dump command buffer and all associated bo that most likely
>> triggered a lockup.
> [cut]
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #48 from Alexandre Demers
2012-04-25 08:21:12 PDT ---
(In reply to comment #47)
> (In reply to comment #46)
> > Does this kernel patch help?
> > http://lists.freedesktop.org/archives/dri-devel/2012-April/022037.html
>
> I was wonder
On Mit, 2012-04-25 at 14:46 +0200, Christian K?nig wrote:
> Aligning offset can make it bigger than tmp->offset
> leading to an overrun bug in the following subtraction.
>
> Signed-off-by: Christian K?nig
Please add
Cc: stable at vger.kernel.org
to the commit log (but don't send the patch to
Acked-by: Matthew Garrett
for the set.
--
Matthew Garrett | mjg59 at srcf.ucam.org
Hello all.
I wanted to follow-up on a very peculiar yet highly reproducible bug
involving suspend/resume, radeon, and a seemingly unrelated patch to
input serio.
The last comment in the thread was from Jerome Glisse saying it was a tough
bug to fix. Has anyone had any good ideas on how to fix it
From: Jerome Glisse
This add a command buffer dumping facilities, that will
dump command buffer and all associated bo that most likely
triggered a lockup.
Idea is that we go through unsignaled fence and we dump the
ib of the oldest unsignaled fence. Dumping is a 2 step process
on lockup detectio
From: Christian K?nig
Free them wenn the ib is freed, another
step to better debugging.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h |3 +++
drivers/gpu/drm/radeon/radeon_cs.c | 14 --
drivers/gpu/drm/radeon/radeon_ring.c |3 +++
3 files chang
From: Christian K?nig
That should aid in debugging multi ring lockups.
v2 rebase on top of debugfs removal
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h |1 +
drivers/gpu/drm/radeon/radeon_fence.c |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff
From: Christian K?nig
Since it is now identical to evergreen_gpu_is_lockup.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/ni.c | 19 ---
drivers/gpu/drm/radeon/radeon_asic.c | 12 ++--
drivers/gpu/drm/radeon/radeon_asic.h |1 -
3 files chang
From: Christian K?nig
Since it is now identical to r100_gpu_is_lockup.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/r300.c| 14 --
drivers/gpu/drm/radeon/radeon_asic.c | 16
drivers/gpu/drm/radeon/radeon_asic.h |1 -
3 files changed, 8
From: Christian K?nig
Nothing chipset or ring specific with it,
so also move it to radon_ring.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/evergreen.c | 10 +-
drivers/gpu/drm/radeon/ni.c | 11 +--
drivers/gpu/drm/radeon/r100.c| 10 +--
From: Christian K?nig
Fixing just another deadlock problem with gpu reset tests.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_ring.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ring.c
b/drivers/gpu/drm/radeon/rade
From: Christian K?nig
Don't hard code the 10 seconds timeout. Compute jobs
can run much longer.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h |1 +
drivers/gpu/drm/radeon/radeon_drv.c |4
drivers/gpu/drm/radeon/radeon_ring.c |2 +-
3 files changed, 6
From: Jerome Glisse
It isn't chipset specific, so it makes no sense
to have that inside r100.c.
v2: rebase on debugfs removal
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/evergreen.c |5 +--
drivers/gpu/drm/radeon/ni.c |5 +--
drivers/gpu/drm/radeon/r100.c
From: Christian K?nig
Not needed anymore.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h| 44 +---
drivers/gpu/drm/radeon/radeon_cs.c | 10 +++---
drivers/gpu/drm/radeon/radeon_device.c |2 +-
drivers/gpu/drm/radeon/radeon_gar
From: Christian K?nig
Instead of all this humpy pumpy with recursive
mutex (which also fixes only halve of the problem)
move the actual gpu reset out of the fence code,
return -EDEADLK and then reset the gpu in the
calling ioctl function.
v2: Split removal of radeon_mutex into separate patch.
From: Christian K?nig
Rings need to lock in order, otherwise
the ring subsystem can deadlock.
v2: fix error handling and number of locked doublewords.
v3: stop creating unneeded semaphores.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h |4 ++
drivers/gpu/drm
From: Christian K?nig
It isn't necessary any more and the suballocator
seems to perform even better.
v2: drop debugfs
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h | 22 +---
drivers/gpu/drm/radeon/radeon_device.c|1 -
drivers/gpu/drm/radeon/radeon_fen
From: Christian K?nig
As discussed with Michel that name better
describes the behavior of this function.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h|2 +-
drivers/gpu/drm/radeon/radeon_device.c |2 +-
drivers/gpu/drm/radeon/radeon_fence.c |4 ++--
3
From: Christian K?nig
We should signal the caller that we haven't waited at all.
v2: only change fence_wait_next not fence_wait_last.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_fence.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/
From: Christian K?nig
Directly use the suballocator to get small chunks
of memory. It's equally fast and doesn't crash when
we encounter a GPU reset.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/evergreen.c|1 -
drivers/gpu/drm/radeon/ni.c |1 -
drive
From: Christian K?nig
With that in place clients are automatically blocking
until their memory request can be handled.
v2: block only if the memory request can't be satisfied
in the first try, the first version actually lacked
a night of sleep.
v3: make blocking optional, update comment
From: Christian K?nig
Make the suballocator self containing to locking.
v2: split the bugfix into a seperate patch.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h|1 +
drivers/gpu/drm/radeon/radeon_sa.c | 17 +++--
2 files changed, 12 insertions(+), 6
From: Christian K?nig
Aligning offset can make it bigger than tmp->offset
leading to an overrun bug in the following subtraction.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_sa.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/rade
From: Christian K?nig
Previusly multiple rings could trigger multiple GPU
resets at the same time.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h |3 +-
drivers/gpu/drm/radeon/radeon_fence.c | 150 +
2 files changed, 77 insertions(
From: Christian K?nig
Removing all the different error messages and
having just one standard behaviour over all
chipset generations.
Signed-off-by: Christian K?nig
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen.c |7 ++-
drivers/gpu/drm/radeon/ni.c |7 ++
From: Christian K?nig
It makes no sense at all to have more than one flag.
Signed-off-by: Christian K?nig
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/radeon/r100.c |1 -
drivers/gpu/drm/radeon/r300.c |1 -
drivers/gpu/drm/radeon/radeon.h|1 -
drivers/gp
From: Christian K?nig
Different rings have different criteria to test
if they are stuck.
v2: rebased on current drm-next
Signed-off-by: Christian K?nig
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon.h |4 +-
drivers/gpu/drm/radeon/radeon_asic.c | 44
From: Jerome Glisse
Those file never were really helpfull in debuging.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/r100.c | 186 -
drivers/gpu/drm/radeon/r300.c | 50 -
drivers/gpu/drm/radeon/r420.c | 45
Patches also available at:
http://people.freedesktop.org/~glisse/debug/
So it's the Christian series minus all the debugfs related to
ring/ib/mc. The last patch add a new blob dumping facilities
that dump everythings (pm4, relocs table, bo content). It's
just a proof of concept to show what i mean
On 21.04.2012 16:14, Jerome Glisse wrote:
> 2012/4/21 Christian K?nig:
>> On 20.04.2012 01:47, Jerome Glisse wrote:
>>> 2012/4/19 Christian K?nig:
This includes mostly fixes for multi ring lockups and GPU resets, but it
should general improve the behavior of the kernel mode driver in case
On Mit, 2012-04-25 at 14:46 +0200, Christian K?nig wrote:
> As discussed with Michel that name better
> describes the behavior of this function.
>
> Signed-off-by: Christian K?nig
Reviewed-by: Michel D?nzer
--
Earthling Michel D?nzer | http://www.amd.com
Libre so
On Mit, 2012-04-25 at 14:46 +0200, Christian K?nig wrote:
> We should signal the caller that we haven't waited at all.
>
> v2: only change fence_wait_next not fence_wait_last.
>
> Signed-off-by: Christian K?nig
Reviewed-by: Michel D?nzer
--
Earthling Michel D?nzer |
Hi Jerome,
On Wed, Apr 25, 2012 at 9:03 PM, wrote:
> From: Jerome Glisse
>
> This add a command buffer dumping facilities, that will
> dump command buffer and all associated bo that most likely
> triggered a lockup.
[cut]
I spotted this:
> +void radeon_fence_blob_faulty_ib(struct radeon_devic
On 23.04.2012 09:40, Michel D?nzer wrote:
> On Sam, 2012-04-21 at 11:42 +0200, Christian K?nig wrote:
>> Regarding the debugging of lockups I had the following on my "in mind
>> todo" list:
>> 1. Rework the chip specific lockup detection code a bit more and
>> probably clean it up a bit.
>> 2. Make
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_ring.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ring.c
b/drivers/gpu/drm/radeon/radeon_ring.c
index 1c4348c..c563c25 100644
--- a/drivers/gpu/drm/r
Free them wenn the ib is freed, another
step to better debugging.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h |3 +++
drivers/gpu/drm/radeon/radeon_cs.c | 14 --
drivers/gpu/drm/radeon/radeon_ring.c |3 +++
3 files changed, 18 insertions(+), 2
That should aid in debugging multi ring lockups.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h |1 +
drivers/gpu/drm/radeon/radeon_fence.c |1 +
drivers/gpu/drm/radeon/radeon_ring.c | 43 -
3 files changed, 44 insertions(+), 1
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_fence.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
b/drivers/gpu/drm/radeon/radeon_fence.c
index 66e6ee0..09e13e3 100644
--- a/drivers/gpu/drm/radeon/radeon_fenc
Since it is now identical to evergreen_gpu_is_lockup.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/ni.c | 19 ---
drivers/gpu/drm/radeon/radeon_asic.c | 12 ++--
drivers/gpu/drm/radeon/radeon_asic.h |1 -
3 files changed, 6 insertions(+), 26
Since it is now identical to r100_gpu_is_lockup.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/r300.c| 14 --
drivers/gpu/drm/radeon/radeon_asic.c | 16
drivers/gpu/drm/radeon/radeon_asic.h |1 -
3 files changed, 8 insertions(+), 23 deleti
Nothing chipset or ring specific with it,
so also move it to radon_ring.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/evergreen.c | 10 +-
drivers/gpu/drm/radeon/ni.c | 11 +--
drivers/gpu/drm/radeon/r100.c| 10 +-
drivers/gpu/drm/rad
Fixing just another deadlock problem with gpu reset tests.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_ring.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ring.c
b/drivers/gpu/drm/radeon/radeon_ring.c
index 8add827.
Don't hard code the 10 seconds timeout. Compute jobs
can run much longer.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h |1 +
drivers/gpu/drm/radeon/radeon_drv.c |4
drivers/gpu/drm/radeon/radeon_ring.c |2 +-
3 files changed, 6 insertions(+), 1 deleti
It isn't chipset specific, so it makes no sense
to have that inside r100.c.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/evergreen.c |5 +--
drivers/gpu/drm/radeon/ni.c |5 +--
drivers/gpu/drm/radeon/r100.c| 57 +
drivers/
Not needed anymore.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h| 44 +---
drivers/gpu/drm/radeon/radeon_cs.c | 10 +++---
drivers/gpu/drm/radeon/radeon_device.c |2 +-
drivers/gpu/drm/radeon/radeon_gart.c | 16 ++-
Instead of all this humpy pumpy with recursive
mutex (which also fixes only halve of the problem)
move the actual gpu reset out of the fence code,
return -EDEADLK and then reset the gpu in the
calling ioctl function.
v2: Split removal of radeon_mutex into separate patch.
Return -EAGAIN if rese
Rings need to lock in order, otherwise
the ring subsystem can deadlock.
v2: fix error handling and number of locked doublewords.
v3: stop creating unneeded semaphores.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h |4 ++
drivers/gpu/drm/radeon/radeon_cs.c
It isn't necessary any more and the suballocator
seems to perform even better.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h | 22 +--
drivers/gpu/drm/radeon/radeon_device.c|1 -
drivers/gpu/drm/radeon/radeon_fence.c | 44 +-
drivers/gpu/drm/rad
As discussed with Michel that name better
describes the behavior of this function.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h|2 +-
drivers/gpu/drm/radeon/radeon_device.c |2 +-
drivers/gpu/drm/radeon/radeon_fence.c |4 ++--
3 files changed, 4 inserti
We should signal the caller that we haven't waited at all.
v2: only change fence_wait_next not fence_wait_last.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_fence.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_fence.
Directly use the suballocator to get small chunks
of memory. It's equally fast and doesn't crash when
we encounter a GPU reset.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/evergreen.c|1 -
drivers/gpu/drm/radeon/ni.c |1 -
drivers/gpu/drm/radeon/r600.c
With that in place clients are automatically blocking
until their memory request can be handled.
v2: block only if the memory request can't be satisfied
in the first try, the first version actually lacked
a night of sleep.
v3: make blocking optional, update comments and fix
another bu
Dumping the current allocations.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_object.h |5 +
drivers/gpu/drm/radeon/radeon_ring.c | 22 ++
drivers/gpu/drm/radeon/radeon_sa.c | 15 +++
3 files changed, 42 insertions(+), 0 delet
Make the suballocator self containing to locking.
v2: split the bugfix into a seperate patch.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h|1 +
drivers/gpu/drm/radeon/radeon_sa.c | 17 +++--
2 files changed, 12 insertions(+), 6 deletions(-)
diff --gi
Aligning offset can make it bigger than tmp->offset
leading to an overrun bug in the following subtraction.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_sa.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_sa.c
b/driver
Previusly multiple rings could trigger multiple GPU
resets at the same time.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h |3 +-
drivers/gpu/drm/radeon/radeon_fence.c | 146 +
2 files changed, 75 insertions(+), 74 deletions(-)
dif
Removing all the different error messages and
having just one standard behaviour over all
chipset generations.
Signed-off-by: Christian K?nig
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen.c |7 ++-
drivers/gpu/drm/radeon/ni.c |7 ++-
drivers/gpu/drm/r
Just register the debugfs files on init instead of
checking the chipset type multiple times.
Signed-off-by: Christian K?nig
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_ring.c | 31 +++
1 files changed, 19 insertions(+), 12 deletions(-)
diff --git a
It makes no sense at all to have more than one flag.
Signed-off-by: Christian K?nig
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/radeon/r100.c |1 -
drivers/gpu/drm/radeon/r300.c |1 -
drivers/gpu/drm/radeon/radeon.h|1 -
drivers/gpu/drm/radeon/radeon_devi
Different rings have different criteria to test
if they are stuck.
v2: rebased on current drm-next
Signed-off-by: Christian K?nig
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon.h |4 +-
drivers/gpu/drm/radeon/radeon_asic.c | 44 ++--
driver
Second round of patchset.
Thanks for all the comments and/or bug reports, allot of patches are now v2/v3
and should get another look. Every regression known so far should be fixed with
them now.
Additionally to the patches that where already included in the last set there
are 8 new ones which a
From: Alan Cox
Some boards such as the Intel D2700MUD allow you to have over 4GB of RAM.
The GTT on the PVR based devices is 32bit however. Hugh Dickins points out
that we should therefore be setting the mapping gfp mask.
This is not the whole fix for the problem. Some further shmem patches will
From: Alan Cox
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/cdv_device.c| 41 ++--
drivers/gpu/drm/gma500/psb_drv.h |5
drivers/gpu/drm/gma500/psb_intel_reg.h |5 +++-
3 files changed, 48 insertions(+), 3 deletions(-)
diff --git a/dri
From: Alan Cox
This provides the needed callback hooks to add hotplug display support to
the GMA36x0 devices.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/psb_drv.h |3 +++
drivers/gpu/drm/gma500/psb_irq.c | 30 +++---
2 files changed, 26 insertions(+), 7
From: Alan Cox
In particular clean up the errata handling and correct the crtc masks. We do
this a bit differently using our device abstraction for neatness.
This doesn't address the ACPI opregion and hotplug plumbing, nor the IRQ related
changes that will need. It touches on backlight init but
From: Alan Cox
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/cdv_intel_crt.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_crt.c
b/drivers/gpu/drm/gma500/cdv_intel_crt.c
index 1de27c7..1a82843 100644
--- a/drivers/gpu/drm/gma
From: Alan Cox
The problem in console mode is lack of linear memory. We can solve that by
dropping to 16bpp. The mode setting X server will allocate its own GEM
framebuffer in 32bpp and all will be well.
We could just do 16bpp anyway but that would be a regression on the lower
modes as many dist
From: Alan Cox
Introduce a panel presence check for Cedartrail. Non netbook devices don't
necessarily have a panel attached.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/cdv_intel_lvds.c | 57 +++
1 files changed, 57 insertions(+), 0 deletions(-)
diff --gi
From: Alan Cox
Pull in various i915 bits that we will need to begin tackling the LVDS detect
and ACPI events. We try and drift towards the i915 version of the code with
the long term goal that at least some of it can one day be unified.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/intel
From: Alan Cox
We don't want them uncached, combining will do nicely and fixes the performance
problem with the generic modesetting X server.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/gtt.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/gma5
From: Alan Cox
---
drivers/gpu/drm/gma500/cdv_intel_display.c | 331 +++-
drivers/gpu/drm/gma500/psb_intel_drv.h |3
drivers/gpu/drm/gma500/psb_intel_reg.h | 25 ++
3 files changed, 294 insertions(+), 65 deletions(-)
diff --git a/drivers/gpu/drm/gma500/
From: Alan Cox
We need to pull more stuff from the VBT in order to configure the clocking
correctly in all cases. Add the relevant bits from the other CDV driver work.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/intel_bios.c | 18
drivers/gpu/drm/gma500/intel_bios.h
From: Alan Cox
This was reported a long time ago (and I apologize to whoever it was that
reported it as I've lost the original report).
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/psb_drv.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/gma500/
This version drops the backlight patch while I figure how it breaks some
systems. It adds the now fixed hotplug monitor code.
---
Alan Cox (12):
gma500: Set the mapping mask
gma500: Add the base elements of CDV hotplug support
gma500: Add ops for hotplug support.
cdv: con
From: Alan Cox
We are not yet ready for this and it makes a mess on some devices.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/psb_drv.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
index c3
From: Alan Cox
Stop it poking at random registers on the i740 cards that may be out there
still.
As per Matthew's feedback remove the conditional checks and never enable the
opregion handling unless an appropriate driver has been loaded.
Signed-off-by: Alan Cox
---
drivers/acpi/video.c | 2
On Wed, Apr 25, 2012 at 11:20:36PM +0200, Marcin Slusarz wrote:
> Overall idea:
> Detect lockups by watching for timeouts (vm flush / fence), return -EIOs,
> handle them at ioctl level, reset the GPU and repeat last ioctl.
>
> GPU reset is done by doing suspend / resume cycle with few tweaks:
> -
From: Alan Cox
Signed-off-by: Alan Cox
---
drivers/acpi/video.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 9577b6f..66e8f73 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -1745,6 +1745,7 @@ sta
1 - 100 of 263 matches
Mail list logo
