On 01.05.2012 19:19, j.gli...@gmail.com wrote:
From: Christian König
Make the suballocator self containing to locking.
v2: split the bugfix into a seperate patch.
v3: Jerome Glisse use mutex, no reason to use spinlock that
are more heavyweight than mutex
NAK, radeon_sa_bo_free is called f
From: Michel Dänzer
Just a cosmetic fix to make dmesg a little less confusing.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/radeon/r100.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index cbac1cb..53ec
Hi Luca, Maarten,
On Monday 30 April 2012 01:01:30 pm Luca Tettamanti wrote:
> 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 0
On 02.05.2012 06:04, Jerome Glisse wrote:
On Wed, May 2, 2012 at 12:00 AM, wrote:
Ok so i reread stuff and the :
drm/radeon: add general purpose fence signaled callback
is a big NAK actually. It change the paradigm. Moving most of
the handling into the irq process which is something i am intima
From: Dave Airlie
This is the initial driver for emulated cirrus GPU found in qemu.
This driver only supports the emulated GPU and doesn't attempt
to bind to any real cirrus GPUs.
This driver is intended to be used with xf86-video-modesetting in userspace.
This follow the same design as ast and
On Wed, May 2, 2012 at 10:04 AM, Christian König
wrote:
> On 02.05.2012 06:04, Jerome Glisse wrote:
>>
>> On Wed, May 2, 2012 at 12:00 AM, wrote:
>>>
>>> Ok so i reread stuff and the :
>>> drm/radeon: add general purpose fence signaled callback
>>> is a big NAK actually. It change the paradigm. M
On 02.05.2012 12:32, Dave Airlie wrote:
On Wed, May 2, 2012 at 10:04 AM, Christian König
wrote:
On 02.05.2012 06:04, Jerome Glisse wrote:
On Wed, May 2, 2012 at 12:00 AM,wrote:
Ok so i reread stuff and the :
drm/radeon: add general purpose fence signaled callback
is a big NAK actually. I
On Wed, 2012-05-02 at 09:54 +0200, Jean Delvare wrote:
> Hi Luca, Maarten,
>
> On Monday 30 April 2012 01:01:30 pm Luca Tettamanti wrote:
> > 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, A
Hi Dave,
there still seems to be the need for some further discussion about the SA code,
so I again split that out of the patchset and tested the result a bit.
Most of the stuff still works fine without those offending changes, so to avoid
mailing around unrelated and already reviewed patches, I
It makes no sense at all to have more than one flag.
Signed-off-by: Christian König
Reviewed-by: Alex Deucher
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/r100.c |1 -
drivers/gpu/drm/radeon/r300.c |1 -
drivers/gpu/drm/radeon/radeon.h|1 -
driver
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
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h |4 +-
drivers/gpu/drm/radeon/radeon_asic.c | 44
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
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_ring.c | 31 +++
1 files changed, 19 insertions(+), 1
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
Reviewed-by: Jerome Glisse
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
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/evergreen.c |7 ++-
drivers/gpu/drm/radeon/ni.c |
Previusly multiple rings could trigger multiple GPU
resets at the same time.
Signed-off-by: Christian König
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h |3 +-
drivers/gpu/drm/radeon/radeon_fence.c | 146 +
2 files changed, 75 inserti
It's never used and so practically superfluous.
Signed-off-by: Christian König
Reviewed-by: Jerome Glisse
---
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/rade
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
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_fence.c |2 +-
1 files changed, 1 insertions(+), 1 deletio
As discussed with Michel that name better
describes the behavior of this function.
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_device.c |2 +-
drivers/gpu/drm/radeon
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
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h |4 ++
drivers/gpu
Don't hard code the 10 seconds timeout. Compute jobs
can run much longer.
Signed-off-by: Christian König
Reviewed-by: Jerome Glisse
---
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 change
It isn't chipset specific, so it makes no sense
to have that inside r100.c.
Signed-off-by: Christian König
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/evergreen.c |5 +--
drivers/gpu/drm/radeon/ni.c |5 +--
drivers/gpu/drm/radeon/r100.c| 57 +--
Fixing just another deadlock problem with gpu reset tests.
Signed-off-by: Christian König
Reviewed-by: Jerome Glisse
---
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/
Since it is now identical to r100_gpu_is_lockup.
Signed-off-by: Christian König
Reviewed-by: Jerome Glisse
---
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
Nothing chipset or ring specific with it,
so also move it to radon_ring.
Signed-off-by: Christian König
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/evergreen.c | 10 +-
drivers/gpu/drm/radeon/ni.c | 11 +--
drivers/gpu/drm/radeon/r100.c| 10 +--
Since it is now identical to evergreen_gpu_is_lockup.
Signed-off-by: Christian König
Reviewed-by: Jerome Glisse
---
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 c
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
2012/5/2 Michel Dänzer :
> From: Michel Dänzer
>
> Just a cosmetic fix to make dmesg a little less confusing.
>
> Signed-off-by: Michel Dänzer
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/r100.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gp
On Wed, May 2, 2012 at 7:25 AM, Christian König wrote:
> On 02.05.2012 12:32, Dave Airlie wrote:
>>
>> On Wed, May 2, 2012 at 10:04 AM, Christian König
>> wrote:
>>>
>>> On 02.05.2012 06:04, Jerome Glisse wrote:
On Wed, May 2, 2012 at 12:00 AM, wrote:
>
> Ok so i reread stuf
So here are sa improvement, ib pool cleanup and semaphore cleanup.
Those are Christian patches rebased on top of its last 17 patchset
and on top of sa allocator change.
The idea is that the sa_bo struct is not free until associated fence
is signaled. Meanwhile the ib structure or the semaphore/fen
From: Jerome Glisse
This patch is ground work for having the sa allocator as a standalone
self contained helper. Each sa_bo can be associated with a fence and
when allocating new one you can ask to block until there is room for
satisfying your request.
It also change the sa allocation logic. The
From: Christian König
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
v3: rebase on top of sa manager new patch
v4: rebase on top o
From: Jerome Glisse
Both ib and semaphore are always associated with a fence, rework the
sa allocator to store the fence in the sa_bo allowing sa allocator
to wait for a fence and retry allocation. This also simplify the ib
& semaphore code. Simpify semaphore code to use the sa allocator.
Signed
On Wed, May 2, 2012 at 9:11 AM, Christian König wrote:
> Hi Dave,
>
> there still seems to be the need for some further discussion about the SA
> code,
> so I again split that out of the patchset and tested the result a bit.
>
> Most of the stuff still works fine without those offending changes,
From: Alex Deucher
RV250 found on ppc embedded boards.
Cc: Hans Verkuil
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_combios.c | 66 +++
drivers/gpu/drm/radeon/radeon_mode.h|1 +
2 files changed, 67 insertions(+), 0 deletions(-)
diff --g
2012/5/2 Christian König :
> On 02.05.2012 06:04, Jerome Glisse wrote:
>>
>> On Wed, May 2, 2012 at 12:00 AM, wrote:
>>>
>>> Ok so i reread stuff and the :
>>> drm/radeon: add general purpose fence signaled callback
>>> is a big NAK actually. It change the paradigm. Moving most of
>>> the handling
https://bugs.freedesktop.org/show_bug.cgi?id=30383
Török Edwin changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On 5/2/12 6:27 AM, Dave Airlie wrote:
From: Dave Airlie
This is the initial driver for emulated cirrus GPU found in qemu.
This driver only supports the emulated GPU and doesn't attempt
to bind to any real cirrus GPUs.
In particular,
+/* only bind to the cirrus chip in qemu */
+static DEFINE
On 5/1/12 1:37 PM, Marc Gariepy wrote:
Match the correct information which is DMI_PRODUCT_NAME instead of
DMI_BOARD_NAME
See dmidecode information on launchpad for both thin client:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/911920
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/
This follows on from the last set and sorts out the lid regression
they caused on the Poulsbo devices. It then includes another pile
of clean up work and Medfield fixes from Kirill.
---
Alan Cox (1):
gma500: address the lid code
Kirill A. Shutemov (12):
gma500: mdfld_dsi_dpi_mode_set(
From: Alan Cox
We need this for Poulsbo
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/psb_drv.c |2 +-
drivers/gpu/drm/gma500/psb_drv.h |1 -
drivers/gpu/drm/gma500/psb_lid.c |2 +-
3 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_drv.
From: Kirill A. Shutemov
Signed-off-by: Kirill A. Shutemov
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/gtt.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/gma500/gtt.c b/drivers/gpu/drm/gma500/gtt.c
index 54e5c9e..7d6f737 100644
--- a/driver
From: Kirill A. Shutemov
Signed-off-by: Kirill A. Shutemov
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/gtt.c | 11 +++
drivers/gpu/drm/gma500/psb_drv.h |2 +-
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/gma500/gtt.c b/drivers/gpu/drm
From: Kirill A. Shutemov
Signed-off-by: Kirill A. Shutemov
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/psb_drv.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_drv.h b/drivers/gpu/drm/gma500/psb_drv.h
index 9dc4476..e59511d 100644
From: Kirill A. Shutemov
Signed-off-by: Kirill A. Shutemov
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/framebuffer.c |3 +--
drivers/gpu/drm/gma500/psb_drv.h |2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/gma500/framebuffer.c
b/driver
From: Kirill A. Shutemov
Signed-off-by: Kirill A. Shutemov
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/framebuffer.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/gma500/framebuffer.c
b/drivers/gpu/drm/gma500/framebuffer.c
index 30400b6..f47
From: Kirill A. Shutemov
Signed-off-by: Kirill A. Shutemov
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/psb_irq.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_irq.c b/drivers/gpu/drm/gma500/psb_irq.c
index 4ffb2a0..8652cdf 100644
-
From: Kirill A. Shutemov
This was mostly already fixed but this one change is needed to match Kirill's
original submission
Signed-off-by: Kirill A. Shutemov
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/opregion.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a
From: Kirill A. Shutemov
Signed-off-by: Kirill A. Shutemov
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/oaktrail_hdmi_i2c.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/gma500/oaktrail_hdmi_i2c.c
b/drivers/gpu/drm/gma500/oaktrail_hdmi_i2c.c
From: Kirill A. Shutemov
Signed-off-by: Kirill A. Shutemov
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/cdv_intel_lvds.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
index 44a
From: Kirill A. Shutemov
cc1: warning: include/drm: No such file or directory [enabled by default]
It's reproducible if you build with O=/some/obj/dir and W=1.
Signed-off-by: Kirill A. Shutemov
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/Makefile |2 +-
1 files changed, 1 inserti
From: Kirill A. Shutemov
Signed-off-by: Kirill A. Shutemov
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma500/mid_bios.c| 295 +++---
drivers/gpu/drm/gma500/oaktrail.h| 25 +--
drivers/gpu/drm/gma500/oaktrail_device.c |8 -
drivers/gpu/drm/gma500
From: Kirill A. Shutemov
The proper stride value set in mdfld__intel_pipe_set_base().
TODO: move tc35876x support to separate driver and get rid of all
if (mdfld_get_panel_type(dev, pipe) == TC35876X) { ... }
Signed-off-by: Kirill A. Shutemov
Signed-off-by: Alan Cox
---
drivers/gpu/drm/gma5
Fix the documented opcodes in dri2proto.txt to be consistent with the
actual opcode values in dri2proto.h and in xcb/proto:src/dri2.xml. (It
looks like the opcodes were incorrect due to copy-paste errors).
CC: Kristian Høgsberg
---
dri2proto.txt | 18 +-
1 file changed, 9 inser
From: Dave Airlie
We should initialise this to 0 really to avoid getting false positives.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nouveau_acpi.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c
b/drivers/gpu/drm/no
On Wed, May 02, 2012 at 01:44:15PM -0400, Adam Jackson wrote:
> On 5/1/12 1:37 PM, Marc Gariepy wrote:
> >Match the correct information which is DMI_PRODUCT_NAME instead of
> >DMI_BOARD_NAME
> >See dmidecode information on launchpad for both thin client:
> >
> >https://bugs.launchpad.net/ubuntu/+s
On Wed, May 2, 2012 at 3:03 PM, Chad Versace
wrote:
> Fix the documented opcodes in dri2proto.txt to be consistent with the
> actual opcode values in dri2proto.h and in xcb/proto:src/dri2.xml. (It
> looks like the opcodes were incorrect due to copy-paste errors).
Looks correct to me.
Kristian
>
So this patchset convert the fence to use 64bits sequence and simplify
the fence code (dropping fence lock). I am still convinced that the
best solution is to have the various helper code deals with fence
cleanup/processing. The last patch show an example of what can be
done to improve sa allocator
From: Jerome Glisse
This convert fence to use uint64_t sequence number intention is
to use the fact that uin64_t is big enough that we don't need to
care about wrap around.
Tested with and without writeback using 0xF000 as initial
fence sequence and thus allowing to test the wrap around from
From: Jerome Glisse
This add the number of adjacent scratch reg you want to allocate
or free to the scratch alloc/free function.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/r100.c | 12 ++--
drivers/gpu/drm/radeon/r420.c |4 ++--
drivers/gpu/drm/rade
From: Jerome Glisse
Using 64bits fence sequence we can directly compare sequence
number to know if a fence is signaled or not. Thus the fence
list became useless, so does the fence lock that mainly
protected the fence list.
Things like ring.ready are no longer behind a lock, this should
be ok as
From: Jerome Glisse
With fence rework it's now easier to agressivly free idle bo
when there is no hole to satisfy current allocation request.
The hit of some cs ioctl to have to go through the sa bo list
and free them is minimal, it happens once in while and avoid
some fence waiting.
Signed-off-
From: Jerome Glisse
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_cs.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 82f2e7b0..b3800cb 100644
--- a/drivers/gpu/drm/rade
On Wed, May 2, 2012 at 4:24 PM, wrote:
> From: Jerome Glisse
>
> Signed-off-by: Jerome Glisse
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/radeon_cs.c | 5 +
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
> b/driver
On 5/2/12 3:24 PM, Dave Airlie wrote:
From: Dave Airlie
We should initialise this to 0 really to avoid getting false positives.
Signed-off-by: Dave Airlie
Reviewed-by: Adam Jackson
- ajax
___
dri-devel mailing list
dri-devel@lists.freedesktop.or
On 5/2/12 4:20 PM, j.gli...@gmail.com wrote:
+ /* there is small chance that we overwritte a bigger last_emited
+* value, but in normal usage this
+*/
Seems unfinished. Also "overwrite".
- ajax
___
dri-devel mailing list
dri-de
https://bugs.freedesktop.org/show_bug.cgi?id=49140
--- Comment #5 from Marko 2012-05-02 22:42:10 PDT ---
> vec3 p3 = vec3(p.x, p.y, p.z);
> float t = dot(v, p3);
> float t2 = gm1*t/v2 - g*p.w;
> r = vec4( v*t2 + p3, g * (p.w - t));
>
Vadim, this is really great and much appreci
Ok so i reread stuff and the :
drm/radeon: add general purpose fence signaled callback
is a big NAK actually. It change the paradigm. Moving most of
the handling into the irq process which is something i am intimatly
convinced we should avoid.
Here is the patchset up to ib pool cleanup. I have yet
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
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h |4 +-
drivers/gpu/drm/radeon/radeon_asi
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
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/r100.c |1 -
drivers/gpu/drm/radeon/r300.c |1 -
drivers/gpu/drm/radeon/radeon.h
From: Christian K?nig
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
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_ring.c | 31 +++
1 files chan
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
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/evergreen.c |7 ++-
drivers/gpu/drm/ra
From: Christian K?nig
Previusly multiple rings could trigger multiple GPU
resets at the same time.
Signed-off-by: Christian K?nig
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h |3 +-
drivers/gpu/drm/radeon/radeon_fence.c | 150 +
2 f
From: Christian K?nig
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
Revi
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
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h|1 +
drivers/gpu/drm/radeon/radeon_sa.c | 17 +++--
2 files
From: Christian K?nig
Dumping the current allocations.
Signed-off-by: Christian K?nig
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_object.h |5 +
drivers/gpu/drm/radeon/radeon_ring.c | 22 ++
drivers/gpu/drm/radeon/radeon_sa.c | 14 +++
From: Jerome Glisse
The sa allocator is suppose to be a ring allocator, ie allocation
happen first at the end and if there is no more room we start at
the begining again. This patch make the code match this design.
sa_manager keep track of the start & end hole, it first try to
allocate in the end
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
Reviewed-by: Michel D?nzer
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_fence.c |2 +-
1 files changed, 1
From: Christian K?nig
As discussed with Michel that name better
describes the behavior of this function.
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_device.c |2 +-
From: Christian K?nig
It's never used and so practically superfluous.
Signed-off-by: Christian K?nig
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h |1 -
drivers/gpu/drm/radeon/radeon_fence.c |7 ---
2 files changed, 0 insertions(+), 8 deletions(-)
diff --gi
From: Jerome Glisse
This allow to associate a fence with sa bo and retry and
wait if sa bo alloc can block.
v2: bug fixes
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h | 10 ++-
drivers/gpu/drm/radeon/radeon_cs.c|4 +-
drivers/gpu/drm/radeon/radeon_g
On Wed, May 2, 2012 at 12:00 AM, wrote:
> Ok so i reread stuff and the :
> drm/radeon: add general purpose fence signaled callback
> is a big NAK actually. It change the paradigm. Moving most of
> the handling into the irq process which is something i am intimatly
> convinced we should avoid.
>
>
On 01.05.2012 19:19, j.glisse at gmail.com wrote:
> From: Christian K?nig
>
> Make the suballocator self containing to locking.
>
> v2: split the bugfix into a seperate patch.
> v3: Jerome Glisse use mutex, no reason to use spinlock that
> are more heavyweight than mutex
NAK, radeon_sa_bo_free
From: Michel D?nzer
Just a cosmetic fix to make dmesg a little less confusing.
Signed-off-by: Michel D?nzer
---
drivers/gpu/drm/radeon/r100.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index cbac1cb..53ec
Hi Luca, Maarten,
On Monday 30 April 2012 01:01:30 pm Luca Tettamanti wrote:
> 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 0
On 02.05.2012 06:04, Jerome Glisse wrote:
> On Wed, May 2, 2012 at 12:00 AM, wrote:
>> Ok so i reread stuff and the :
>> drm/radeon: add general purpose fence signaled callback
>> is a big NAK actually. It change the paradigm. Moving most of
>> the handling into the irq process which is something
From: Dave Airlie
This is the initial driver for emulated cirrus GPU found in qemu.
This driver only supports the emulated GPU and doesn't attempt
to bind to any real cirrus GPUs.
This driver is intended to be used with xf86-video-modesetting in userspace.
This follow the same design as ast and
On Wed, May 2, 2012 at 10:04 AM, Christian K?nig
wrote:
> On 02.05.2012 06:04, Jerome Glisse wrote:
>>
>> On Wed, May 2, 2012 at 12:00 AM, ?wrote:
>>>
>>> Ok so i reread stuff and the :
>>> drm/radeon: add general purpose fence signaled callback
>>> is a big NAK actually. It change the paradigm. M
On 02.05.2012 12:32, Dave Airlie wrote:
> On Wed, May 2, 2012 at 10:04 AM, Christian K?nig
> wrote:
>> On 02.05.2012 06:04, Jerome Glisse wrote:
>>> On Wed, May 2, 2012 at 12:00 AM,wrote:
Ok so i reread stuff and the :
drm/radeon: add general purpose fence signaled callback
is
On Wed, 2012-05-02 at 09:54 +0200, Jean Delvare wrote:
> Hi Luca, Maarten,
>
> On Monday 30 April 2012 01:01:30 pm Luca Tettamanti wrote:
> > On Mon, Apr 30, 2012 at 11:07 AM, Maarten Maathuis > gmail.com> wrote:
> > > On Mon, Apr 30, 2012 at 12:37 AM, Dmitry Torokhov
> > >
> > > wrote:
> > >> O
Hi Dave,
there still seems to be the need for some further discussion about the SA code,
so I again split that out of the patchset and tested the result a bit.
Most of the stuff still works fine without those offending changes, so to avoid
mailing around unrelated and already reviewed patches, I
It makes no sense at all to have more than one flag.
Signed-off-by: Christian K?nig
Reviewed-by: Alex Deucher
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/r100.c |1 -
drivers/gpu/drm/radeon/r300.c |1 -
drivers/gpu/drm/radeon/radeon.h|1 -
driver
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
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h |4 +-
drivers/gpu/drm/radeon/radeon_asic.c | 44
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
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_ring.c | 31 +++
1 files changed, 19 insertions(+), 1
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
Reviewed-by: Jerome Glisse
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
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/evergreen.c |7 ++-
drivers/gpu/drm/radeon/ni.c |
Previusly multiple rings could trigger multiple GPU
resets at the same time.
Signed-off-by: Christian K?nig
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h |3 +-
drivers/gpu/drm/radeon/radeon_fence.c | 146 +
2 files changed, 75 inserti
It's never used and so practically superfluous.
Signed-off-by: Christian K?nig
Reviewed-by: Jerome Glisse
---
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/rade
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
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_fence.c |2 +-
1 files changed, 1 insertions(+), 1 deletio
As discussed with Michel that name better
describes the behavior of this function.
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_device.c |2 +-
drivers/gpu/drm/radeon
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
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h |4 ++
drivers/gpu
1 - 100 of 146 matches
Mail list logo
