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
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/857ebf8a/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130711/dca7b098/attachment.html>
vel/attachments/20130711/5cbbc892/attachment.html>
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/fad9ffe8/attachment.html>
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 f
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
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>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/db59386d/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/43d67e5c/attachment.html>
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
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 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
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
101 - 122 of 122 matches
Mail list logo
