http://bugs.freedesktop.org/show_bug.cgi?id=26735
--- Comment #11 from Török Edwin edwinto...@gmail.com 2010-02-25 01:17:26
PST ---
(In reply to comment #10)
Does it render properly without that patch?
No, I still get the same corruption if I revert that patch.
(In reply to comment #9)
Oh, sorry, but I don't like such a hidden changes, touching not
directly related things.
2010/2/25 Dave Airlie airl...@gmail.com:
diff --git a/drivers/gpu/drm/radeon/r600_audio.c
b/drivers/gpu/drm/radeon/r600_audio.c
index 0dcb690..7def989 100644
--- a/drivers/gpu/drm/radeon/r600_audio.c
http://bugs.freedesktop.org/show_bug.cgi?id=26195
--- Comment #5 from Rafał Miłecki zaj...@gmail.com 2010-02-25 01:29:59 PST
---
(In reply to comment #4)
If the kernel is booted with radeon.audio=0 it boots perfectly
If your GPU is RV730, you use all functions from rv770.c. This means you
Dave, we have some commits in drm-linus that are not present in
drm-radeon-testing. Maybe this is the case with other active branches
as well, don't know.
Could you rebase branches to be more clear, please? Maybe rebasing
agains .33 even?
--
Rafał
On Wed, Feb 24, 2010 at 06:04:57PM +0100, Thomas Hellstrom wrote:
Jerome Glisse wrote:
On Wed, Feb 24, 2010 at 01:37:42PM +0100, Thomas Hellstrom wrote:
Jerome Glisse wrote:
On Tue, Feb 23, 2010 at 02:05:50PM +0100, Thomas Hellstrom wrote:
Jerome Glisse wrote:
On Mon, Feb 22, 2010 at
On Thu, 2010-02-25 at 10:42 +0100, Rafał Miłecki wrote:
Dave, we have some commits in drm-linus that are not present in
drm-radeon-testing. Maybe this is the case with other active branches
as well, don't know.
Could you rebase branches to be more clear, please? Maybe rebasing
agains .33
W dniu 25 lutego 2010 10:46 użytkownik Michel Dänzer
mic...@daenzer.net napisał:
On Thu, 2010-02-25 at 10:42 +0100, Rafał Miłecki wrote:
Dave, we have some commits in drm-linus that are not present in
drm-radeon-testing. Maybe this is the case with other active branches
as well, don't know.
http://bugs.freedesktop.org/show_bug.cgi?id=26195
--- Comment #6 from Alex Deucher ag...@yahoo.com 2010-02-25 06:46:04 PST ---
(In reply to comment #5)
(In reply to comment #4)
If the kernel is booted with radeon.audio=0 it boots perfectly
If your GPU is RV730, you use all functions
http://bugzilla.kernel.org/show_bug.cgi?id=14442
--- Comment #29 from Oleksandr Yermolenko yaa@gmail.com 2010-02-25
15:27:16 ---
(In reply to comment #28)
Oleksandr, can you please open a separate bug report, attach full dmesg and
assign it to me. You're seeing a different problem
http://bugs.freedesktop.org/show_bug.cgi?id=26195
--- Comment #7 from Rafał Miłecki zaj...@gmail.com 2010-02-25 07:35:33 PST
---
(In reply to comment #6)
(In reply to comment #5)
(In reply to comment #4)
If the kernel is booted with radeon.audio=0 it boots perfectly
If your GPU
http://bugs.freedesktop.org/show_bug.cgi?id=26195
--- Comment #8 from Alex Deucher ag...@yahoo.com 2010-02-25 07:56:16 PST ---
r600_hdmi_init is called for all asics and the associated r600_hdmi* functions
are called during modesetting, this is likely where the problem lies. But you
are
This patch update radeon to the new no_wait splitted argument
TTM functionality.
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/radeon/radeon_object.c |6 ++--
drivers/gpu/drm/radeon/radeon_ttm.c| 39 +--
2 files changed, 24
There is case where we want to be able to wait only for the
GPU while not waiting for other buffer to be unreserved. This
patch split the no_wait argument all the way down in the whole
ttm path so that upper level can decide on what to wait on or
not.
This patch break the API to other modules,
This patch change the TTM API to allow driver to select btw choosing
to wait or not either for bo reserve or GPU wait separately. This is
needed for the unmappabled VRAM work.
Comments ?
Cheers,
Jerome
--
Download
This patch update radeon to the new no_wait splitted argument
TTM functionality.
Compile tested only (but thing should run as there is no
operating change from driver point of view)
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c |4 ++--
This patch update radeon to the new no_wait splitted argument
TTM functionality.
Compile tested only (but thing should run as there is no
operating change from driver point of view)
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 45
This add the support for the new fault callback, does change anything
from driver point of view, thought it should allow nouveau to add
support for unmappable VRAM.
Improvement: store the aperture base in a variable so that we don't
call a function to get it on each fault.
Patch hasn't been
This add the support for the new fault callback, does change anything
from driver point of view.
Improvement: store the aperture base in a variable so that we don't
call a function to get it on each fault.
Patch hasn't been tested.
V2 don't derefence bo-mem.mm_node as it's not NULL only for
This patch enable the use of unmappable VRAM thanks to
previous TTM infrastructure change.
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/radeon/evergreen.c |5 -
drivers/gpu/drm/radeon/r100.c |5 -
drivers/gpu/drm/radeon/r600.c |5 -
All TTM driver have been converted to new io_mem_reserve/free
interface which allow driver to choose and return proper io
base, offset to core TTM for ioremapping if necessary. This
patch remove what is now deadcode.
V2 adapt to match with change in first patch of the patchset
Signed-off-by:
Updated patchset, to apply cleanly on top of TTM split no_wait argument.
Compile tested for nouveau+vmwgfx, test in progress for radeon.
So with the new change radeon won't wait for bo reserving other bo
in fault path but will wait the GPU (hoping it doesn't lockup ;))
This should address concern
This add the support for the new fault callback and also the
infrastructure for supporting unmappable VRAM.
V2 validate BO with no_wait = true
V3 don't derefence bo-mem.mm_node as it's not NULL only for
VRAM or GTT
V4 update to splitted no_wait ttm change
Signed-off-by: Jerome Glisse
On fault the driver is given the opportunity to perform any operation
it sees fit in order to place the buffer into a CPU visible area of
memory. This patch doesn't break TTM users, nouveau, vmwgfx and radeon
should keep working properly. Future patch will take advantage of this
infrastructure and
This isn't needed anymore with the new TTM fault callback
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/radeon/radeon_ttm.c | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
This isn't needed anymore with the new TTM fault callback
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
This isn't needed anymore with the new TTM fault callback
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 11 ---
1 files changed, 0 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
http://bugzilla.kernel.org/show_bug.cgi?id=15166
Manuel Ullmann ullman.b...@gmx.de changed:
What|Removed |Added
Attachment #24987|0 |1
is obsolete|
http://bugzilla.kernel.org/show_bug.cgi?id=15166
Manuel Ullmann ullman.b...@gmx.de changed:
What|Removed |Added
Kernel Version|2.6.33-rc8, 2.6.32.8|2.6.32.6 - 2.6.33
Attached is conversion from DRM_INFO/DRM_ERROR to dev_info/dev_err
to apply it copy all doconv* file into the radeon subfolder of the
kernel run ./doconv.sh and then apply the 0001 patch which fix
compilation after conversion (place where struct radeon_device is
missing) then thing should compile
http://bugs.freedesktop.org/show_bug.cgi?id=26195
--- Comment #9 from Rafał Miłecki zaj...@gmail.com 2010-02-25 15:02:41 PST
---
(In reply to comment #8)
r600_hdmi_init is called for all asics and the associated r600_hdmi* functions
are called during modesetting, this is likely where the
http://bugs.freedesktop.org/show_bug.cgi?id=26195
--- Comment #10 from Michael Lothian m...@fireburn.co.uk 2010-02-25 15:24:03
PST ---
Yes I'm still around and I'll happily test any patches or git trees you're
willing to through at me to get audio working on my setup.
--
Configure
From: Dave Airlie airl...@linux.ie
Many new laptops now come with 2 gpus, one to be used for low power
modes and one for gaming/on-ac applications. These GPUs are typically
wired to the laptop panel and VGA ports via a multiplexer unit which
is controlled via ACPI methods.
4 combinations of
32 matches
Mail list logo
