On Wed, Jul 10, 2013 at 10:07 AM, Torsten Kaiser
wrote:
> Commit 63e28a7a5ffce59b645ca9cbcc01e1e8be56bd75, "uvesafb: Clean up
> MTRR code" contains the following change:
>
> @@ -1930,6 +1891,9 @@ static int uvesafb_setup(char *options)
> }
> }
>
> +if (mtrr != 3 && mtrr != 1)
> +
On Thu, Jul 11, 2013 at 01:45:30AM +0200, David Herrmann wrote:
> Instead of delaying inode initialization until first ->open(), we can use
> an anonymous inode. This avoids modifying FS internal inode fields and
> provides us a private address_space right during initialization.
>
> Delayed TTM de
On Thu, Jul 11, 2013 at 3:36 AM, Andy Lutomirski wrote:
> On Wed, Jul 10, 2013 at 10:07 AM, Torsten Kaiser
> wrote:
>> Commit 63e28a7a5ffce59b645ca9cbcc01e1e8be56bd75, "uvesafb: Clean up
>> MTRR code" contains the following change:
>>
>> @@ -1930,6 +1891,9 @@ static int uvesafb_setup(char *option
Hi Daniel,
On Wednesday 10 July 2013 20:17:44 Daniel Vetter wrote:
> It has way too much potential for driver writers to do stupid things
> like delayed hw setup because the load sequence is somehow racy (e.g.
> the imx driver in staging). So don't call it for modesetting drivers,
> which reduces
Hi Daniel,
Thanks for the patch.
On Wednesday 10 July 2013 16:48:45 Daniel Vetter wrote:
> I've checked both implementations (radeon/nouveau) and they both grab
> the page array from ttm simply by dereferencing it and then wrapping
> it up with drm_prime_pages_to_sg in the callback and map it wit
https://bugs.freedesktop.org/show_bug.cgi?id=66805
--- Comment #1 from Michel Dänzer ---
Can you provide the output from running with the environment variable
RADEON_DUMP_SHADERS=1 ? Beware that it might be large if the game compiles many
shaders before the failure.
--
You are receiving this ma
https://bugs.freedesktop.org/show_bug.cgi?id=66425
Christian König changed:
What|Removed |Added
Attachment #81770|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=66425
--- Comment #21 from Austin Lund ---
(In reply to comment #20)
> Created attachment 82325 [details] [review]
> Possible fix.
>
> I was able to reproduce the problem, and this patch (only a slightly
> modified version of the old one) seems to fix
https://bugs.freedesktop.org/show_bug.cgi?id=66805
--- Comment #2 from Laurent carlier ---
Created attachment 82327
--> https://bugs.freedesktop.org/attachment.cgi?id=82327&action=edit
shader dump from portal with RADEON_DUMP_SHADERS=1
--
You are receiving this mail because:
You are the assig
drm_gem_object_init() and drm_gem_private_object_init() do exactly the
same (except for shmem alloc) so make the first use the latter to reduce
code duplication.
Also drop the return code from drm_gem_private_object_init(). It seems
unlikely that we will extend it any time soon so no reason to kee
These don't make any sense, really..
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_pci.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 80c0b2b..a7b46ff 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pc
https://bugs.freedesktop.org/show_bug.cgi?id=66731
--- Comment #2 from Stefano Teso ---
Thanks for the quick response.
I just wanted to note that the glitch is still there with llvm 3.4 trunk.
--
You are receiving this mail because:
You are the assignee for the bug.
___
On Thu, Jul 11, 2013 at 9:54 AM, Laurent Pinchart
wrote:
> Hi Daniel,
>
> On Wednesday 10 July 2013 20:17:44 Daniel Vetter wrote:
>> It has way too much potential for driver writers to do stupid things
>> like delayed hw setup because the load sequence is somehow racy (e.g.
>> the imx driver in st
On Thu, Jul 11, 2013 at 11:56:32AM +0200, David Herrmann wrote:
> drm_gem_object_init() and drm_gem_private_object_init() do exactly the
> same (except for shmem alloc) so make the first use the latter to reduce
> code duplication.
>
> Also drop the return code from drm_gem_private_object_init().
On Thu, Jul 11, 2013 at 11:56:32AM +0200, David Herrmann wrote:
> drm_gem_object_init() and drm_gem_private_object_init() do exactly the
> same (except for shmem alloc) so make the first use the latter to reduce
> code duplication.
>
> Also drop the return code from drm_gem_private_object_init().
Hi
On Sun, Jul 7, 2013 at 7:17 PM, David Herrmann wrote:
> Use the new vma manager instead of the old hashtable. Also convert all
> drivers to use the new convenience helpers. This drops all the
> (map_list.hash.key << PAGE_SHIFT) non-sense.
>
> Locking and access-management is exactly the same a
On Thu, Jul 11, 2013 at 11:56 AM, David Herrmann wrote:
> drm_gem_object_init() and drm_gem_private_object_init() do exactly the
> same (except for shmem alloc) so make the first use the latter to reduce
> code duplication.
>
> Also drop the return code from drm_gem_private_object_init(). It seems
Hi
On Thu, Jul 11, 2013 at 1:12 PM, Martin Peres wrote:
> On 07/07/2013 19:17, David Herrmann wrote:
>>
>> Hi
>>
>> This is v2 of the unified VMA offset manager series. The first draft is
>> available at LWN [1]. This series replaces the VMA offset managers in GEM
>> and
>> TTM with a unified imp
https://bugs.freedesktop.org/show_bug.cgi?id=66450
--- Comment #7 from Christian König ---
Created attachment 82331
--> https://bugs.freedesktop.org/attachment.cgi?id=82331&action=edit
Possible fix v2
Update patch, should work better this time.
But please note that shader based decoding is fa
On Thu, Jul 11, 2013 at 5:56 AM, David Herrmann wrote:
> drm_gem_object_init() and drm_gem_private_object_init() do exactly the
> same (except for shmem alloc) so make the first use the latter to reduce
> code duplication.
>
> Also drop the return code from drm_gem_private_object_init(). It seems
Cc lists this time around ...
-Daniel
On Thu, Jul 11, 2013 at 2:06 PM, Daniel Vetter wrote:
> Hi Dave,
>
> One feature latecomer, I've forgotten to merge the patch to reeanble the
> Haswell power well feature now that the audio interaction is fixed up.
> Since that was the only unfixed issue with
On Thu, Jul 11, 2013 at 3:41 AM, Paul Menzel
wrote:
> Dear Linux folks,
>
>
> using a Linux 3.10 with the drm-next-3.11 tree from Alex Deuscher merged
> and built with `make deb-pkg`, it failed the last boot.
>
> [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1).
>
> The stra
https://bugs.freedesktop.org/show_bug.cgi?id=66425
--- Comment #22 from Christian König ---
(In reply to comment #21)
> I got this compile warning:
>
> /home/lund/src/linux/drivers/gpu/drm/radeon/radeon_uvd.c: In function
> ‘radeon_uvd_fini’:
> /home/lund/src/linux/drivers/gpu/drm/radeon/radeon
On Thu, Jul 11, 2013 at 2:24 AM, Daniel Vetter wrote:
> On Wed, Jul 10, 2013 at 09:00:33PM -0400, Jerome Glisse wrote:
>> On Wed, Jul 10, 2013 at 8:27 PM, Jean-Sébastien Pédron
>> wrote:
>> > Hello,
>> >
>> > I'm trying to understand how TTM buffer object mapping works on Linux, to
>> > make this
On Wed, Jul 10, 2013 at 8:11 AM, Daniel Vetter wrote:
> Hi all,
>
> I've figured that it's again time for a bit of (late) drm spring cleanup. This
> series here consists of a pile of "rip old stuff out" patches interleaved with
> "disable old cruft for kms drivers and hide it better".
>
> Comments
https://bugs.freedesktop.org/show_bug.cgi?id=44772
Harald Judt changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://bugs.freedesktop.org/show_bug.cgi?id=66425
--- Comment #23 from Harald Judt ---
Thanks, I confirm that the patch fixes the problem!
I've tested this at least 5 times with both the vanilla and the tuxonice
hibernation, and both now work pretty stable with 3.10. (As a side note: The
BFQ IO
https://bugs.freedesktop.org/show_bug.cgi?id=44772
Harald Judt changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
From: Alex Deucher
They still seem to cause instability on some r6xx parts.
As a follow up, we can switch to using CP DMA for bo
moves on r6xx as a lighter weight alternative to using
the 3D engine.
A version of this patch should also go to stable kernels.
Tested-by: J.N.
Signed-off-by: Alex D
From: Alex Deucher
Lighter weight than using the 3D engine.
v2: fix ring count
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r600.c| 81 ++
drivers/gpu/drm/radeon/r600d.h |1 +
drivers/gpu/drm/radeon/radeon_asic.h |3 +
3 files
From: Alex Deucher
Lighter weight than using the 3D engine.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_asic.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
b/drivers/gpu/drm/radeon/radeon_asic.c
index ea5c
I've picked up the patch for my fixes queue. Thanks!
Alex
On Wed, Jul 10, 2013 at 6:26 AM, Maarten Lankhorst
wrote:
> Op 10-07-13 12:03, Markus Trippelsdorf schreef:
>> On 2013.07.10 at 11:56 +0200, Maarten Lankhorst wrote:
>>> Op 10-07-13 11:46, Markus Trippelsdorf schreef:
On 2013.07.10
From: Jerome Glisse
Avoid creating temporary platform device that will lead to issue
when several radeon gpu are in same computer. Instead directly use
the radeon device for requesting firmware.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/cik.c| 25 +++--
On Thu, Jul 11, 2013 at 3:59 PM, Ilija Hadzic
wrote:
>
> Alex,
>
> Can you please share some details about the nature or symptom of the
> "instability". One problem that I have been seeing on my end is that when I
> use the DMA ring intensively (by intensively I mean, calling the copy
> function e
Alex,
Can you please share some details about the nature or symptom of the
"instability". One problem that I have been seeing on my end is that when
I use the DMA ring intensively (by intensively I mean, calling the copy
function every frame), combined with some 3D rendering that causes a lot
https://bugs.freedesktop.org/show_bug.cgi?id=66450
--- Comment #8 from Eugene Shalygin ---
With this patch playback works. Thank you!
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.
https://bugs.freedesktop.org/show_bug.cgi?id=61470
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||webmas...@jamescobban.net
--- Comment #25
https://bugs.freedesktop.org/show_bug.cgi?id=43829
--- Comment #26 from Alex Deucher ---
Created attachment 82347
--> https://bugs.freedesktop.org/attachment.cgi?id=82347&action=edit
possible fix
Does the attached patch help?
--
You are receiving this mail because:
You are the assignee for t
From: Alex Deucher
Helpful for debugging GPUVM errors as we can see what
hw block and page generated the fault in the log.
v2: simplify fault decoding
Signed-off-by: Alex Deucher
Reviewed-by: Christian König
---
drivers/gpu/drm/radeon/evergreen.c | 10 ++-
drivers/gpu/drm/radeon/ni.c
From: Alex Deucher
Helpful for debugging GPUVM errors as we can see what
hw block and page generated the fault in the log.
v2: simplify fault decoding
Signed-off-by: Alex Deucher
Reviewed-by: Christian König
---
drivers/gpu/drm/radeon/si.c | 272 +-
From: Alex Deucher
Helpful for debugging GPUVM errors as we can see what
hw block and page generated the fault in the log.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/cik.c | 32 ++--
drivers/gpu/drm/radeon/cikd.h | 16
2 files chang
Hi,
Thank you Jérôme and Daniel for your input, that's really helpful!
I have another question: in ttm_bo_mmap(), a reference to the buffer
object is acquired at the beginning of the function. Another reference
is acquired in ttm_bo_vm_open() (released in ttm_bo_vm_close()).
But where is the
On Thu, Jul 11, 2013 at 5:43 PM, Jean-Sébastien Pédron
wrote:
> Hi,
>
> Thank you Jérôme and Daniel for your input, that's really helpful!
>
> I have another question: in ttm_bo_mmap(), a reference to the buffer object
> is acquired at the beginning of the function. Another reference is acquired
>
Hi
On Thu, Jul 11, 2013 at 11:43 PM, Jean-Sébastien Pédron
wrote:
> Hi,
>
> Thank you Jérôme and Daniel for your input, that's really helpful!
>
> I have another question: in ttm_bo_mmap(), a reference to the buffer object
> is acquired at the beginning of the function. Another reference is acqui
Le 11/07/2013 23:51, David Herrmann a écrit :
->vm_open() isn't called for the first mmap(), afaik (only called
during fork()s or similar). So the reference in ttm_bo_mmap() is a
replacement for the reference you take in the ->vm_open() callback.
So the reference is acquired either in ttm_bo_mm
https://bugs.freedesktop.org/show_bug.cgi?id=66836
Priority: medium
Bug ID: 66836
Assignee: dri-devel@lists.freedesktop.org
Summary: [r600g] WoW is crashing with HD6450
Severity: normal
Classification: Unclassified
OS: Linux
https://bugs.freedesktop.org/show_bug.cgi?id=66836
--- Comment #1 from Chris Rankin ---
Created attachment 82348
--> https://bugs.freedesktop.org/attachment.cgi?id=82348&action=edit
Crash dump analysis
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=66836
--- Comment #2 from Chris Rankin ---
Created attachment 82349
--> https://bugs.freedesktop.org/attachment.cgi?id=82349&action=edit
dmesg output
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=66837
Priority: medium
Bug ID: 66837
Assignee: dri-devel@lists.freedesktop.org
Summary: [regression] X hangs since commit
098316211ce65db79d00c5975fa30873426450a6
Severity: critica
https://bugs.freedesktop.org/show_bug.cgi?id=64695
--- Comment #6 from Alexandre Demers ---
Quickly tested with today's git and it still does the same "Oops". However, KDE
doesn't have any problem to load. I'll give more info soon, I just don't have
much time right now.
--
You are receiving thi
On 07/07/2013 19:17, David Herrmann wrote:
Hi
This is v2 of the unified VMA offset manager series. The first draft is
available at LWN [1]. This series replaces the VMA offset managers in GEM and
TTM with a unified implementation.
The first 4 patches contain the new VMA offset manager and are t
On 11/07/2013 13:21, David Herrmann wrote:
Hi
On Thu, Jul 11, 2013 at 1:12 PM, Martin Peres wrote:
On 07/07/2013 19:17, David Herrmann wrote:
Hi
This is v2 of the unified VMA offset manager series. The first draft is
available at LWN [1]. This series replaces the VMA offset managers in GEM
a
Since the original merge of nouveau to upstream kernel, we were assuming that
nv90 (and later) cards have 32 lines.
Based on mmio traces of the binary driver, as well as PBUS error messages
during read/write of the e070/e074 registers, we can conclude that nv92 has
only 16 lines whereas nv94 (and
This patch adds a buffer synchronization framework based on DMA BUF[1]
and and based on ww-mutexes[2] for lock mechanism.
The purpose of this framework is to provide not only buffer access control
to CPU and DMA but also easy-to-use interfaces for device drivers and
user application. This framewor
Hi all,
This patch set introduces a buffer synchronization framework based
on DMA BUF[1] and based on ww-mutexes[2] for lock mechanism.
The purpose of this framework is to provide not only buffer access
control to CPU and CPU, and CPU and DMA, and DMA and DMA but also
easy-to-use interfaces for d
This patch adds lock callback to dma buf file operations,
and this callback will be called by fcntl system call.
With this patch, fcntl system call can be used for buffer
synchronization between CPU and CPU, and CPU and DMA in user mode.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
We care about the upper 32 bits here so we have to use 1ULL instead of 1
to avoid a shift wrapping bug.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/ctxnvc0.c
b/drivers/gpu/drm/nouveau/core/engine/graph/ctxnvc0.c
index 64dca26..fe67415 100644
--- a/drivers
Am 11.07.2013 21:35, schrieb alexdeuc...@gmail.com:
From: Alex Deucher
They still seem to cause instability on some r6xx parts.
As a follow up, we can switch to using CP DMA for bo
moves on r6xx as a lighter weight alternative to using
the 3D engine.
A version of this patch should also go to s
Am 11.07.2013 21:59, schrieb Ilija Hadzic:
Alex,
Can you please share some details about the nature or symptom of the
"instability". One problem that I have been seeing on my end is that
when I use the DMA ring intensively (by intensively I mean, calling
the copy function every frame), combi
Am 11.07.2013 21:53, schrieb j.gli...@gmail.com:
From: Jerome Glisse
Avoid creating temporary platform device that will lead to issue
when several radeon gpu are in same computer. Instead directly use
the radeon device for requesting firmware.
Signed-off-by: Jerome Glisse
Thanks, also had t
Hi
This implements anon_inodes_new() to create anonymous inodes. Patch #1
describes the changes to anon_inodes.c and why DRM could make great use of this.
Patch #2 converts DRM core to use anon_inodes_new() instead of delayed
dev_mapping initialization (but kept simple, TTM can be converted later)
DRM core shares a single address_space across all inodes that belong to
the same DRM device. This allows efficient unmapping of user-space
mappings during buffer destruction. However, there is no easy way to get a
shared address_space for DRM devices during initialization. Therefore, we
currently d
Instead of delaying inode initialization until first ->open(), we can use
an anonymous inode. This avoids modifying FS internal inode fields and
provides us a private address_space right during initialization.
Delayed TTM dev_mapping initialization is currently left untouched to keep
this simple.
Hi Daniel,
Thank you for the patch.
On Wednesday 10 July 2013 17:25:04 Daniel Vetter wrote:
> So I've stumbled over drm_fasync and wondered what it does. Digging
> that up is quite a story.
>
> First I've had to read up on what this does and ended up being rather
> bewildered why peopled loved s
Hello,
I'm trying to understand how TTM buffer object mapping works on Linux,
to make this behave properly on FreeBSD.
Here's what I think I understand:
When a buffer object is mmap()'d, ttm_bo_vm_open() is called. When
there's a page fault, the page is looked up and inserted in the VMA
using
.
|.org|org
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/9beefb45/attachment.html>
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/d1bdd6f9/attachment.html>
On Wed, Jul 10, 2013 at 09:00:33PM -0400, Jerome Glisse wrote:
> On Wed, Jul 10, 2013 at 8:27 PM, Jean-S?bastien P?dron
> wrote:
> > Hello,
> >
> > I'm trying to understand how TTM buffer object mapping works on Linux, to
> > make this behave properly on FreeBSD.
> >
> > Here's what I think I unde
On Thu, Jul 11, 2013 at 01:45:29AM +0200, David Herrmann wrote:
> DRM core shares a single address_space across all inodes that belong to
> the same DRM device. This allows efficient unmapping of user-space
> mappings during buffer destruction. However, there is no easy way to get a
> shared addres
On Thu, Jul 11, 2013 at 01:45:30AM +0200, David Herrmann wrote:
> Instead of delaying inode initialization until first ->open(), we can use
> an anonymous inode. This avoids modifying FS internal inode fields and
> provides us a private address_space right during initialization.
>
> Delayed TTM de
On Thu, Jul 11, 2013 at 3:36 AM, Andy Lutomirski wrote:
> On Wed, Jul 10, 2013 at 10:07 AM, Torsten Kaiser
> wrote:
>> Commit 63e28a7a5ffce59b645ca9cbcc01e1e8be56bd75, "uvesafb: Clean up
>> MTRR code" contains the following change:
>>
>> @@ -1930,6 +1891,9 @@ static int uvesafb_setup(char *option
Dear Linux folks,
using a Linux 3.10 with the drm-next-3.11 tree from Alex Deuscher merged
and built with `make deb-pkg`, it failed the last boot.
[drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1).
The strange thing is that it worked the last time I tried with the same
Lin
Hi Daniel,
On Wednesday 10 July 2013 20:17:44 Daniel Vetter wrote:
> It has way too much potential for driver writers to do stupid things
> like delayed hw setup because the load sequence is somehow racy (e.g.
> the imx driver in staging). So don't call it for modesetting drivers,
> which reduces
Hi Daniel,
Thanks for the patch.
On Wednesday 10 July 2013 16:48:45 Daniel Vetter wrote:
> I've checked both implementations (radeon/nouveau) and they both grab
> the page array from ttm simply by dereferencing it and then wrapping
> it up with drm_prime_pages_to_sg in the callback and map it wit
mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/4881a8a5/attachment.html>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/f4ee69c8/attachment.html>
st just yet. Will report back as soon as possible.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/ed0c8033/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/5a7a6ce4/attachment-0001.html>
drm_gem_object_init() and drm_gem_private_object_init() do exactly the
same (except for shmem alloc) so make the first use the latter to reduce
code duplication.
Also drop the return code from drm_gem_private_object_init(). It seems
unlikely that we will extend it any time soon so no reason to kee
These don't make any sense, really..
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_pci.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 80c0b2b..a7b46ff 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pc
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/38e55943/attachment.html>
On Thu, Jul 11, 2013 at 9:54 AM, Laurent Pinchart
wrote:
> Hi Daniel,
>
> On Wednesday 10 July 2013 20:17:44 Daniel Vetter wrote:
>> It has way too much potential for driver writers to do stupid things
>> like delayed hw setup because the load sequence is somehow racy (e.g.
>> the imx driver in st
On Thu, Jul 11, 2013 at 11:56:32AM +0200, David Herrmann wrote:
> drm_gem_object_init() and drm_gem_private_object_init() do exactly the
> same (except for shmem alloc) so make the first use the latter to reduce
> code duplication.
>
> Also drop the return code from drm_gem_private_object_init().
On Thu, Jul 11, 2013 at 11:56:32AM +0200, David Herrmann wrote:
> drm_gem_object_init() and drm_gem_private_object_init() do exactly the
> same (except for shmem alloc) so make the first use the latter to reduce
> code duplication.
>
> Also drop the return code from drm_gem_private_object_init().
Hi
On Sun, Jul 7, 2013 at 7:17 PM, David Herrmann wrote:
> Use the new vma manager instead of the old hashtable. Also convert all
> drivers to use the new convenience helpers. This drops all the
> (map_list.hash.key << PAGE_SHIFT) non-sense.
>
> Locking and access-management is exactly the same a
On Thu, Jul 11, 2013 at 11:56 AM, David Herrmann
wrote:
> drm_gem_object_init() and drm_gem_private_object_init() do exactly the
> same (except for shmem alloc) so make the first use the latter to reduce
> code duplication.
>
> Also drop the return code from drm_gem_private_object_init(). It seem
Hi
On Thu, Jul 11, 2013 at 1:12 PM, Martin Peres wrote:
> On 07/07/2013 19:17, David Herrmann wrote:
>>
>> Hi
>>
>> This is v2 of the unified VMA offset manager series. The first draft is
>> available at LWN [1]. This series replaces the VMA offset managers in GEM
>> and
>> TTM with a unified imp
ding is far away from beeing perfect
either.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/f8e790a2/attachment.html>
On Thu, Jul 11, 2013 at 5:56 AM, David Herrmann
wrote:
> drm_gem_object_init() and drm_gem_private_object_init() do exactly the
> same (except for shmem alloc) so make the first use the latter to reduce
> code duplication.
>
> Also drop the return code from drm_gem_private_object_init(). It seems
Cc lists this time around ...
-Daniel
On Thu, Jul 11, 2013 at 2:06 PM, Daniel Vetter wrote:
> Hi Dave,
>
> One feature latecomer, I've forgotten to merge the patch to reeanble the
> Haswell power well feature now that the audio interaction is fixed up.
> Since that was the only unfixed issue with
On Thu, Jul 11, 2013 at 3:41 AM, Paul Menzel
wrote:
> Dear Linux folks,
>
>
> using a Linux 3.10 with the drm-next-3.11 tree from Alex Deuscher merged
> and built with `make deb-pkg`, it failed the last boot.
>
> [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1).
>
> The stra
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/d24b3874/attachment.html>
On Thu, Jul 11, 2013 at 2:24 AM, Daniel Vetter wrote:
> On Wed, Jul 10, 2013 at 09:00:33PM -0400, Jerome Glisse wrote:
>> On Wed, Jul 10, 2013 at 8:27 PM, Jean-S?bastien P?dron
>> wrote:
>> > Hello,
>> >
>> > I'm trying to understand how TTM buffer object mapping works on Linux, to
>> > make this
On Wed, Jul 10, 2013 at 8:11 AM, Daniel Vetter
wrote:
> Hi all,
>
> I've figured that it's again time for a bit of (late) drm spring cleanup. This
> series here consists of a pile of "rip old stuff out" patches interleaved with
> "disable old cruft for kms drivers and hide it better".
>
> Comment
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/b0f4db0b/attachment.html>
bed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/80d094f2/attachment.html>
erything's documented there, I'll finally close this bug.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/07345f01/attachment.html>
From: Alex Deucher
They still seem to cause instability on some r6xx parts.
As a follow up, we can switch to using CP DMA for bo
moves on r6xx as a lighter weight alternative to using
the 3D engine.
A version of this patch should also go to stable kernels.
Tested-by: J.N.
Signed-off-by: Alex D
From: Alex Deucher
Lighter weight than using the 3D engine.
v2: fix ring count
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r600.c| 81 ++
drivers/gpu/drm/radeon/r600d.h |1 +
drivers/gpu/drm/radeon/radeon_asic.h |3 +
3 files
1 - 100 of 122 matches
Mail list logo
