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
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
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
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
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 f
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
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/43d67e5c/attachment.html>
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
---
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
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/db59386d/attachment.html>
still shouldn't have crashed.)
--
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/ebe3d98b/attachment-0001.html>
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
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
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
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
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/fad9ffe8/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130711/dca7b098/attachment.html>
vel/attachments/20130711/5cbbc892/attachment.html>
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/857ebf8a/attachment.html>
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
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>
bed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/80d094f2/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/b0f4db0b/attachment.html>
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
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
>
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
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
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
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.
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
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=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
Priority: medium
Bug ID: 66836
Assignee: dri-devel@lists.freedesktop.org
Summary: [r600g] WoW is crashing with HD6450
Severity: normal
Classification: Unclassified
OS: Linux
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
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 +++--
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: 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
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
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
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
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
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
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,
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
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
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
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.
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
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 of
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
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=61470
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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.
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
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
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
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
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
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/d24b3874/attachment.html>
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 +++--
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: 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
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
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
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: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 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
https://bugs.freedesktop.org/show_bug.cgi?id=44772
Harald Judt changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
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
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=44772
Harald Judt changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
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 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().
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/38e55943/attachment.html>
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
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
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
Am 11.07.2013 09:41, schrieb Paul Menzel:
> 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
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
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>
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>
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
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/f4ee69c8/attachment.html>
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
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
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>
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 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 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
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
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
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 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
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 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
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/d1bdd6f9/attachment.html>
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
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
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
1 - 100 of 122 matches
Mail list logo
