On Mon, Apr 30, 2012 at 12:37 AM, Dmitry Torokhov
wrote:
> On Sat, Apr 28, 2012 at 11:33:50AM -0400, Nick Bowler wrote:
>> On 2012-04-28 02:19 -0400, Alex Deucher wrote:
>> > On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler
>> > wrote:
>> > > Hi Ben,
>> > >
>> > > On 2012-04-27 15:20 +1000, Ben Skeg
https://bugs.freedesktop.org/show_bug.cgi?id=48880
Florian Mickler changed:
What|Removed |Added
CC||flor...@mickler.org
--- Comment #27 fr
https://bugs.freedesktop.org/show_bug.cgi?id=42490
Florian Mickler changed:
What|Removed |Added
CC||flor...@mickler.org
--- Comment #27 fr
2011-12-19 19:31 keltezéssel, Adam Jackson írta:
On Mon, 2011-12-19 at 18:56 +0100, Boszormenyi Zoltan wrote:
Thanks. As I am logged in as my user, there's no such button.
How can I set it as the system default? It was a long time ago
when GNOME allowed a root login.
Ideally, gnome would imple
On Mon, Apr 30, 2012 at 11:07 AM, Maarten Maathuis wrote:
> On Mon, Apr 30, 2012 at 12:37 AM, Dmitry Torokhov
> wrote:
>> On Sat, Apr 28, 2012 at 11:33:50AM -0400, Nick Bowler wrote:
>>> On 2012-04-28 02:19 -0400, Alex Deucher wrote:
>>> > On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler
>>> > wrot
https://bugs.freedesktop.org/show_bug.cgi?id=49281
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=43829
Alex Deucher changed:
What|Removed |Added
CC||vimregist...@gmail.com
--- Comment #7 fro
https://bugs.freedesktop.org/show_bug.cgi?id=48880
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
This is one more patchset bringing minor improvements to the current
HDMI implementation. I think after this step I'll start working on
moving Evergreen HDMI code to the separated file. Some cleanups and
making ACR re-usable were needed before that.
Patches depend on the earlier 5-patches-set I se
---
drivers/gpu/drm/radeon/r600_hdmi.c | 26 --
1 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c
b/drivers/gpu/drm/radeon/r600_hdmi.c
index c6de0022..69839df 100644
--- a/drivers/gpu/drm/radeon/r600_hdmi.c
+++ b/drivers/
---
drivers/gpu/drm/radeon/r600_hdmi.c | 42 +++
1 files changed, 27 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c
b/drivers/gpu/drm/radeon/r600_hdmi.c
index 69839df..7d24753 100644
--- a/drivers/gpu/drm/radeon/r600_hdmi.c
+++ b/
---
drivers/gpu/drm/radeon/r600_hdmi.c | 61
drivers/gpu/drm/radeon/radeon.h| 14
2 files changed, 41 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c
b/drivers/gpu/drm/radeon/r600_hdmi.c
index 7d24753..0319619 1
On Fri, 20 Apr 2012, Dave Airlie wrote:
On Thu, Apr 12, 2012 at 7:19 PM, Ilija Hadzic
wrote:
Make dev_mapping per-minor instead of per device. This is
a preparatory patch for introducing render nodes. This
will allow per-node instead of per-device mapping range,
once we introduce render node
Hi Dave,
if nobody has a last moment concern please include the following patches in
drm-next.
Except for some minor fixes they have already been on the list for quite some
time,
but I intentional left out the debugfs related patches cause we haven't
finished the
discussion about them yet.
If
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
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
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
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
Aligning offset can make it bigger than tmp->offset
leading to an overrun bug in the following subtraction.
v2: Against initial suspicions this can't happen in mainline,
so no need to push it into stable.
Signed-off-by: Christian König
Reviewed-by: Michel Dänzer
---
drivers/gpu/drm/radeon/
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
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
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
To prevent deadlocks under extreme conditions.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h|1 +
drivers/gpu/drm/radeon/radeon_gart.c |2 +-
drivers/gpu/drm/radeon/radeon_object.h |3 ++-
drivers/gpu/drm/radeon/radeon_ring.c |2 +-
drivers/gpu/dr
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
Instead of hacking the calculation multiple times.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_gart.c |6 ++
drivers/gpu/drm/radeon/radeon_object.h | 11 +++
drivers/gpu/drm/radeon/radeon_ring.c |6 ++
3 files changed, 15 insertions(+), 8 deleti
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
---
drivers/gpu/drm/radeon/radeon_fence.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/
As discussed with Michel that name better
describes the behavior of this function.
Signed-off-by: Christian König
Reviewed-by: Michel Dänzer
---
drivers/gpu/drm/radeon/radeon.h|2 +-
drivers/gpu/drm/radeon/radeon_device.c |2 +-
drivers/gpu/drm/radeon/radeon_fence.c |4 ++--
Should be used to free resource that are protected by a fence.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h |8 -
drivers/gpu/drm/radeon/radeon_fence.c | 50 +---
2 files changed, 52 insertions(+), 6 deletions(-)
diff --git a/dri
It's never used and so practically superfluous.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h |1 -
drivers/gpu/drm/radeon/radeon_fence.c |7 ---
2 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/dr
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.
v2: ignore ERESTARTSYS in error reporting,
split fence changes into seperate patch,
use try_free SA callback to avoid lockups
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h | 1
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
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 ++-
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
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 504fb8f.
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/
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
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
On Mon, Apr 30, 2012 at 10:50 AM, Christian König
wrote:
> Hi Dave,
>
> if nobody has a last moment concern please include the following patches in
> drm-next.
>
> Except for some minor fixes they have already been on the list for quite some
> time,
> but I intentional left out the debugfs relat
On Mon, Apr 30, 2012 at 11:12 AM, Jerome Glisse wrote:
> On Mon, Apr 30, 2012 at 10:50 AM, Christian König
> wrote:
>> Hi Dave,
>>
>> if nobody has a last moment concern please include the following patches in
>> drm-next.
>>
>> Except for some minor fixes they have already been on the list for
On Fri, 20 Apr 2012, Dave Airlie wrote:
On Thu, Apr 12, 2012 at 7:19 PM, Ilija Hadzic
wrote:
The following set of patches is the reword of the series
sent two weeks ago [2] that will revive the drm-render-nodes [1]
branch. Details of the original series are described in [2].
Thanks for loo
On 30.04.2012 17:12, Jerome Glisse wrote:
On Mon, Apr 30, 2012 at 11:12 AM, Jerome Glisse wrote:
On Mon, Apr 30, 2012 at 10:50 AM, Christian König
wrote:
Hi Dave,
if nobody has a last moment concern please include the following patches in
drm-next.
Except for some minor fixes they have al
On Mon, Apr 30, 2012 at 10:50 AM, Christian König
wrote:
> 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.
On Mon, Apr 30, 2012 at 10:50 AM, Christian König
wrote:
> Make the suballocator self containing to locking.
>
> v2: split the bugfix into a seperate patch.
>
> Signed-off-by: Christian König
I would say NAK but i don't have better solution yet to the issue.
Idea is that cs mutex protect the SA,
On Mon, Apr 30, 2012 at 11:37 AM, Christian König
wrote:
> On 30.04.2012 17:12, Jerome Glisse wrote:
>>
>> On Mon, Apr 30, 2012 at 11:12 AM, Jerome Glisse
>> wrote:
>>>
>>> On Mon, Apr 30, 2012 at 10:50 AM, Christian König
>>> wrote:
Hi Dave,
if nobody has a last moment conc
On Mon, Apr 30, 2012 at 3:48 PM, Ilija Hadzic
wrote:
>
>
> On Fri, 20 Apr 2012, Dave Airlie wrote:
>
>> On Thu, Apr 12, 2012 at 7:19 PM, Ilija Hadzic
>> wrote:
>>>
>>> Make dev_mapping per-minor instead of per device. This is
>>> a preparatory patch for introducing render nodes. This
>>> will all
On Mon, 30 Apr 2012, Dave Airlie wrote:
When we move a buffer from VRAM->RAM we have to invalidate all
userspace mappings for it.
There could be userspace mappings on any of the device nodes, so we
need to get them all.
Ah OK, I get it ... and the reason you don't have to do this when you
>
> Do you have pointers to that discussion (assuming it was on sime mailing
> list)? The least I can do, while I am at it, is try to understand it and
> see if I can incorporate some ideas from there in the rework of the patch.
Nope it was an offhand discussion on irc while we were talking about
On Mon, Apr 30, 2012 at 6:53 PM, Dave Airlie wrote:
>>
>> Do you have pointers to that discussion (assuming it was on sime mailing
>> list)? The least I can do, while I am at it, is try to understand it and
>> see if I can incorporate some ideas from there in the rework of the patch.
>
> Nope it w
https://bugs.freedesktop.org/show_bug.cgi?id=49309
Bug #: 49309
Summary: R600_STREAMOUT is broken
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
On Fri, Apr 20, 2012 at 6:20 AM, Dave Airlie wrote:
> On Thu, Apr 12, 2012 at 7:19 PM, Ilija Hadzic
> wrote:
>> The following set of patches is the reword of the series
>> sent two weeks ago [2] that will revive the drm-render-nodes [1]
>> branch. Details of the original series are described in [
https://bugs.freedesktop.org/show_bug.cgi?id=49309
--- Comment #1 from Marek Olšák 2012-04-30 12:12:08 PDT ---
So what's the issue? The GL version? There's a new requirement for GL3: 4x
multisampling.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are rec
https://bugs.freedesktop.org/show_bug.cgi?id=49309
--- Comment #2 from Alexandre Demers 2012-04-30
15:41:04 PDT ---
(In reply to comment #1)
> So what's the issue? The GL version? There's a new requirement for GL3: 4x
> multisampling.
If Matteo is interested, it's Mesa's commit
8e90913e9f99ff32
https://bugs.freedesktop.org/show_bug.cgi?id=49309
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=49309
--- Comment #3 from Matteo Rapone 2012-04-30 16:19:01 UTC
---
So is it a missing functionality? Thank you. Sorry if I've wasted your time.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving thi
https://bugs.freedesktop.org/show_bug.cgi?id=49309
--- Comment #4 from Alex Deucher 2012-04-30 16:34:16 PDT ---
GL3 requires MSAA which is not yet supported. GL3 was mistakenly enabled
without it initially. Dave has a branch with initial support which will be
merged when ready:
http://cgit.free
https://bugs.freedesktop.org/show_bug.cgi?id=49321
Bug #: 49321
Summary: Khronos WebGL conformance test and shadertoy failure
Classification: Unclassified
Product: Mesa
Version: unspecified
Platform: Other
OS/Version: All
https://bugs.freedesktop.org/show_bug.cgi?id=49322
Bug #: 49322
Summary: No picture on display connected via Displayport
adaptor to HD 7870
Classification: Unclassified
Product: DRI
Version: XOrg CVS
Platform: x86-64 (
On Sun, Apr 29, 2012 at 11:53:16AM +0200, David Herrmann wrote:
> We use errno and EINVAL so include errno.h.
>
> This patch introduced this bug:
> http://cgit.freedesktop.org/mesa/mesa/commit/src/gallium/state_trackers/egl/fbdev/native_fbdev.c?id=b60120608f6ddf4098bc324363197c979ee04cb7
>
> Sign
On Sun, 2012-04-29 at 20:12 +0200, Alexander Stein wrote:
> NVIDIA Corporation C77 [GeForce 8300] (rev a2) has chipset 0xaa which
> supports HDMI Audio.
This was fixed in nouveau git already a few days ago:
http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=2c421e3ad2672e1253abca6387ccbb10cf
On Mon, Apr 30, 2012 at 12:37 AM, Dmitry Torokhov
wrote:
> On Sat, Apr 28, 2012 at 11:33:50AM -0400, Nick Bowler wrote:
>> On 2012-04-28 02:19 -0400, Alex Deucher wrote:
>> > On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler
>> > wrote:
>> > > Hi Ben,
>> > >
>> > > On 2012-04-27 15:20 +1000, Ben Skeg
https://bugs.freedesktop.org/show_bug.cgi?id=48880
Florian Mickler changed:
What|Removed |Added
CC||florian at mickler.org
--- Comment #27
https://bugs.freedesktop.org/show_bug.cgi?id=42490
Florian Mickler changed:
What|Removed |Added
CC||florian at mickler.org
--- Comment #27
2011-12-19 19:31 keltez?ssel, Adam Jackson ?rta:
> On Mon, 2011-12-19 at 18:56 +0100, Boszormenyi Zoltan wrote:
>
>> Thanks. As I am logged in as my user, there's no such button.
>> How can I set it as the system default? It was a long time ago
>> when GNOME allowed a root login.
> Ideally, gnome w
On Mon, Apr 30, 2012 at 11:07 AM, Maarten Maathuis
wrote:
> On Mon, Apr 30, 2012 at 12:37 AM, Dmitry Torokhov
> wrote:
>> On Sat, Apr 28, 2012 at 11:33:50AM -0400, Nick Bowler wrote:
>>> On 2012-04-28 02:19 -0400, Alex Deucher wrote:
>>> > On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler >> > ellipt
https://bugs.freedesktop.org/show_bug.cgi?id=49281
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=43829
Alex Deucher changed:
What|Removed |Added
CC||vimregisters at gmail.com
--- Comment #7
https://bugs.freedesktop.org/show_bug.cgi?id=48880
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
This is one more patchset bringing minor improvements to the current
HDMI implementation. I think after this step I'll start working on
moving Evergreen HDMI code to the separated file. Some cleanups and
making ACR re-usable were needed before that.
Patches depend on the earlier 5-patches-set I se
---
drivers/gpu/drm/radeon/r600_hdmi.c | 26 --
1 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c
b/drivers/gpu/drm/radeon/r600_hdmi.c
index c6de0022..69839df 100644
--- a/drivers/gpu/drm/radeon/r600_hdmi.c
+++ b/drivers/
---
drivers/gpu/drm/radeon/r600_hdmi.c | 42 +++
1 files changed, 27 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c
b/drivers/gpu/drm/radeon/r600_hdmi.c
index 69839df..7d24753 100644
--- a/drivers/gpu/drm/radeon/r600_hdmi.c
+++ b/
---
drivers/gpu/drm/radeon/r600_hdmi.c | 61
drivers/gpu/drm/radeon/radeon.h| 14
2 files changed, 41 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c
b/drivers/gpu/drm/radeon/r600_hdmi.c
index 7d24753..0319619 1
On Fri, 20 Apr 2012, Dave Airlie wrote:
> On Thu, Apr 12, 2012 at 7:19 PM, Ilija Hadzic
> wrote:
>> Make dev_mapping per-minor instead of per device. This is
>> a preparatory patch for introducing render nodes. This
>> will allow per-node instead of per-device mapping range,
>> once we introduc
Hi Dave,
if nobody has a last moment concern please include the following patches in
drm-next.
Except for some minor fixes they have already been on the list for quite some
time,
but I intentional left out the debugfs related patches cause we haven't
finished the
discussion about them yet.
If
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
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
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
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
Aligning offset can make it bigger than tmp->offset
leading to an overrun bug in the following subtraction.
v2: Against initial suspicions this can't happen in mainline,
so no need to push it into stable.
Signed-off-by: Christian K?nig
Reviewed-by: Michel D?nzer
---
drivers/gpu/drm/radeon/
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
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
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
To prevent deadlocks under extreme conditions.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h|1 +
drivers/gpu/drm/radeon/radeon_gart.c |2 +-
drivers/gpu/drm/radeon/radeon_object.h |3 ++-
drivers/gpu/drm/radeon/radeon_ring.c |2 +-
drivers/gpu/dr
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
Instead of hacking the calculation multiple times.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_gart.c |6 ++
drivers/gpu/drm/radeon/radeon_object.h | 11 +++
drivers/gpu/drm/radeon/radeon_ring.c |6 ++
3 files changed, 15 insertions(+), 8 deleti
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
---
drivers/gpu/drm/radeon/radeon_fence.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/
As discussed with Michel that name better
describes the behavior of this function.
Signed-off-by: Christian K?nig
Reviewed-by: Michel D?nzer
---
drivers/gpu/drm/radeon/radeon.h|2 +-
drivers/gpu/drm/radeon/radeon_device.c |2 +-
drivers/gpu/drm/radeon/radeon_fence.c |4 ++--
Should be used to free resource that are protected by a fence.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h |8 -
drivers/gpu/drm/radeon/radeon_fence.c | 50 +---
2 files changed, 52 insertions(+), 6 deletions(-)
diff --git a/dri
It's never used and so practically superfluous.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h |1 -
drivers/gpu/drm/radeon/radeon_fence.c |7 ---
2 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/dr
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.
v2: ignore ERESTARTSYS in error reporting,
split fence changes into seperate patch,
use try_free SA callback to avoid lockups
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h | 1
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
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 ++-
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
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 504fb8f.
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/
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
1 - 100 of 121 matches
Mail list logo
