From: Christian König
Changing the UVD BOs offset on suspend/resume doesn't work cause the VCPU
internally keeps pointers to it. Just keep it always pinned and save the
content manually.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=66425
v2: fix compiler warning
Signed-off-by: Christian
Op 12-07-13 08:33, Dan Carpenter schreef:
> 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
From: Christian König
Currently doesn't matter cause we allocate the fence in the
lower 265MB anyway.
Reported-by: Frank Huang
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/r600.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/r600.c
https://bugs.freedesktop.org/show_bug.cgi?id=66450
Christian König changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=66847
Priority: medium
Bug ID: 66847
Assignee: dri-devel@lists.freedesktop.org
Summary: compilation broken with llvm 3.3
Severity: normal
Classification: Unclassified
OS: All
https://bugs.freedesktop.org/show_bug.cgi?id=66847
--- Comment #1 from Andreas Boll ---
The llvm backends of r600g and the radeonsi on mesa 9.1 are only compatible
with tstellar's llvm-3.2 branch.
The llvm backends of r600g and the radeonsi on mesa 9.2 should be compatible
with the official llvm
https://bugs.freedesktop.org/show_bug.cgi?id=66847
--- Comment #2 from Michel Dänzer ---
(In reply to comment #1)
> So I think we should abort in configure if someone wants to build mesa 9.1
> with enabled llvm backend and llvm != 3.2.
Agreed.
--
You are receiving this mail because:
You are th
https://bugs.freedesktop.org/show_bug.cgi?id=43829
--- Comment #27 from klausenb...@hotmail.com ---
(In reply to comment #26)
> Created attachment 82347 [details] [review]
> possible fix
>
> Does the attached patch help?
Have just tested, and it dont change anything.
I still also don't know what
https://bugs.freedesktop.org/show_bug.cgi?id=66847
--- Comment #3 from Andreas Boll ---
Created attachment 82362
--> https://bugs.freedesktop.org/attachment.cgi?id=82362&action=edit
possible fix (untested)
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=66847
--- Comment #4 from Marc Dietrich ---
You should also remove "or newer". Also "master" isn't the right branch (which
one is the right?). While you are at it, checking for r600 target isn't enough,
because it also needs "host".
I have the feeling
https://bugs.freedesktop.org/show_bug.cgi?id=66847
--- Comment #5 from Andreas Boll ---
(In reply to comment #4)
> You should also remove "or newer".
Yes, will do.
> Also "master" isn't the right branch
> (which one is the right?).
master is the right branch. See http://cgit.freedesktop.org/~
https://bugs.freedesktop.org/show_bug.cgi?id=66847
Andreas Boll changed:
What|Removed |Added
Attachment #82362|0 |1
is obsolete|
I have no idea what this bogus restriction on placement is, but it breaks
decoding 1080p
VDPAU at boot speed. With this patch applied I only need to bump the vdec clock
to
get real-time 1080p decoding. It prevents a lot of VRAM <-> VRAM buffer moves.
Signed-off-by: Maarten Lankhorst
---
diff --
On Fri, Jul 12, 2013 at 2:50 AM, Christian König
wrote:
> 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 alterna
https://bugs.freedesktop.org/show_bug.cgi?id=64201
--- Comment #38 from Aaron Watry ---
(In reply to comment #37)
> Any news?
Sorry to leave you hanging here... I was still able to reproduce the lockups
as of a week ago on a Cedar (5400), but I replaced my desktop 6850 with a 7850
about a month
https://bugs.freedesktop.org/show_bug.cgi?id=66837
--- Comment #1 from Alex Deucher ---
Created attachment 82366
--> https://bugs.freedesktop.org/attachment.cgi?id=82366&action=edit
possible fix
Does the attached patch help?
--
You are receiving this mail because:
You are the assignee for th
On Fri, Jul 12, 2013 at 4:05 AM, Christian König
wrote:
> From: Christian König
>
> Currently doesn't matter cause we allocate the fence in the
> lower 265MB anyway.
>
> Reported-by: Frank Huang
> Signed-off-by: Christian König
Applied to my fixes tree. Thanks!
Alex
> ---
> drivers/gpu/drm
On Fri, 12 Jul 2013, Christian König wrote:
Hi Ilija,
well that's very interesting and no it's quite unlikely that this is cause by
the DMA ring because the radeon_sa_bo structure should be allocated on system
memory and the GPU can usually only access it if you map it through GART.
OK
On Fri, Jul 12, 2013 at 3:40 AM, Christian König
wrote:
> From: Christian König
>
> Changing the UVD BOs offset on suspend/resume doesn't work cause the VCPU
> internally keeps pointers to it. Just keep it always pinned and save the
> content manually.
>
> Fixes: https://bugs.freedesktop.org/show
https://bugs.freedesktop.org/show_bug.cgi?id=66452
--- Comment #1 from Eugene Shalygin ---
Playback of WMV3 streams using UVD sometimes leads to computer hangs (see
below). After upgrade of ffmpeg to version 2.0 from 1.2 these hangs happen much
more often, almost every time I try to play a WMV3 s
https://bugs.freedesktop.org/show_bug.cgi?id=66452
--- Comment #2 from Eugene Shalygin ---
Created attachment 82368
--> https://bugs.freedesktop.org/attachment.cgi?id=82368&action=edit
kernel log during a hang
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=66384
--- Comment #1 from Michel Dänzer ---
I think this is because the DRI2 MSC counters differ between CRTCs, so a DRI2
buffer swap or MSC wait times out.
AFAICT it might be tricky to fix this, at least without DRI3.
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=66452
--- Comment #3 from Eugene Shalygin ---
Previous log was accured with Gentoo 3.9 kernel when I managed to kill player
process before complete hang. Since neither keyboard nor ssh does not work
after a short time after the hang, it is hard for me
k(UVD too)(with something similar to Michael's tip of course).
kernel: drm-next-3.11 or linux-next-20130712
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Hello,
When: 2013-07-10_3@10-36-22 -0700
Who: Andy Lutomirski
What:
> 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_s
https://bugzilla.kernel.org/show_bug.cgi?id=50091
cornel panceac changed:
What|Removed |Added
CC||cpanc...@gmail.com
--- Comment #31 from
https://bugs.freedesktop.org/show_bug.cgi?id=66847
--- Comment #7 from Marc Dietrich ---
arr, yes, master is right (I had an unclean tree), and also yes, r600 llvm in
mesa is marked experimental and needs to be enabled explicitly, so all is fine
- sorry.
Patch looks also fine (tested).
--
You
https://bugzilla.kernel.org/show_bug.cgi?id=42678
Ľubomír Mlích changed:
What|Removed |Added
CC||hater.z...@seznam.cz
--- Comment #22 from
From: Alex Deucher
There are cases where we need more than 4k alignment. No
functional change with this commit.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon.h|1 +
drivers/gpu/drm/radeon/radeon_gart.c |1 +
drivers/gpu/drm/radeon/radeon_object.h |2 +-
d
From: Alex Deucher
Covers requirements of all current asics.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon.h |5 +
drivers/gpu/drm/radeon/radeon_gart.c | 12 ++--
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeo
https://bugs.freedesktop.org/show_bug.cgi?id=66837
Simone Scanzoni changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=66837
--- Comment #3 from Alex Deucher ---
Pushed:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=e0a7565832b567a2ffc65b08d21500ba5d914415
--
You are receiving this mail because:
You are the assignee for the bug.
___
From: Rafael J. Wysocki
According to Matthew Garrett, "Windows 8 leaves backlight control up
to individual graphics drivers rather than making ACPI calls itself.
There's plenty of evidence to suggest that the Intel driver for
Windows [8] doesn't use the ACPI interface, including the fact that
it'
https://bugs.freedesktop.org/show_bug.cgi?id=66836
--- Comment #3 from Marek Olšák ---
This should be fixed by:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=06b38dbab287026625de302e80e9806db206c43e
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugzilla.kernel.org/show_bug.cgi?id=60381
--- Comment #10 from rafael castillo ---
pretty much the same here
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedeskt
https://bugs.freedesktop.org/show_bug.cgi?id=42162
--- Comment #14 from Johan Brannlund ---
The bug is still there with 3.10-rc7.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.free
https://bugs.freedesktop.org/show_bug.cgi?id=42162
--- Comment #15 from Johan Brannlund ---
Created attachment 82375
--> https://bugs.freedesktop.org/attachment.cgi?id=82375&action=edit
Log from 3.10-rc7 suspend/resume cycle
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=66805
--- Comment #3 from Tom Stellard ---
Does this LLVM branch fix the crash:
http://cgit.freedesktop.org/~tstellar/llvm/log/?h=si-sgpr-copies
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=43829
--- Comment #28 from Johan Brannlund ---
These problems seem similar to the bug I reported:
https://bugs.freedesktop.org/show_bug.cgi?id=42162 . One common thread is that
many of the affected machines are HP laptops. Maybe the HP ACPI implementat
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
e the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130712/981d5249/attachment.html>
ht now.
--
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/20130712/d3f9886d/attachment.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
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 alexdeucher at 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 shou
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 fra
Am 11.07.2013 21:53, schrieb j.glisse at 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
From: Christian K?nig
Changing the UVD BOs offset on suspend/resume doesn't work cause the VCPU
internally keeps pointers to it. Just keep it always pinned and save the
content manually.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=66425
v2: fix compiler warning
Signed-off-by: Christian
Op 12-07-13 08:33, Dan Carpenter schreef:
> 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
From: Christian K?nig
Currently doesn't matter cause we allocate the fence in the
lower 265MB anyway.
Reported-by: Frank Huang
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/r600.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/r600.c
|--- |FIXED
--
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/20130712/c7b1a361/attachment.html>
--- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130712/10b36997/attachment.html>
- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130712/9e2e770f/attachment-0001.html>
ou are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130712/a487ee97/attachment.html>
ed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130712/0ce8a62f/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130712/68060fc3/attachment.html>
ecause:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130712/8f961db2/attachment.html>
be enough.
--
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/20130712/73cf/attachment.html>
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130712/5985bb85/attachment.html>
I have no idea what this bogus restriction on placement is, but it breaks
decoding 1080p
VDPAU at boot speed. With this patch applied I only need to bump the vdec clock
to
get real-time 1080p decoding. It prevents a lot of VRAM <-> VRAM buffer moves.
Signed-off-by: Maarten Lankhorst
---
diff --
On Fri, Jul 12, 2013 at 2:50 AM, Christian K?nig
wrote:
> Am 11.07.2013 21:35, schrieb alexdeucher at 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 alte
t a month back and I've been focusing most of my efforts there.
--
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/201307
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130712/9538e87c/attachment.html>
On Fri, Jul 12, 2013 at 4:05 AM, Christian K?nig
wrote:
> From: Christian K?nig
>
> Currently doesn't matter cause we allocate the fence in the
> lower 265MB anyway.
>
> Reported-by: Frank Huang
> Signed-off-by: Christian K?nig
Applied to my fixes tree. Thanks!
Alex
> ---
> drivers/gpu/drm
On Fri, 12 Jul 2013, Christian K?nig wrote:
> Hi Ilija,
>
> well that's very interesting and no it's quite unlikely that this is cause by
> the DMA ring because the radeon_sa_bo structure should be allocated on system
> memory and the GPU can usually only access it if you map it through GART.
On Fri, Jul 12, 2013 at 3:40 AM, Christian K?nig
wrote:
> From: Christian K?nig
>
> Changing the UVD BOs offset on suspend/resume doesn't work cause the VCPU
> internally keeps pointers to it. Just keep it always pinned and save the
> content manually.
>
> Fixes: https://bugs.freedesktop.org/show
eedesktop.org/archives/dri-devel/attachments/20130712/ff82cb4a/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130712/e5df44c7/attachment.html>
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/20130712/a524cd71/attachment.html>
me to get a log with kernel
3.10
--
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/20130712/8c464877/attachment.html>
rks ok(UVD too)(with something similar to Michael's tip of course).
kernel: drm-next-3.11 or linux-next-20130712
--
You are receiving this mail because:
You are watching the assignee of the bug.
Hello,
When: 2013-07-10_3 at 10-36-22 -0700
Who: Andy Lutomirski
What:
> 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 uvesaf
https://bugzilla.kernel.org/show_bug.cgi?id=50091
cornel panceac changed:
What|Removed |Added
CC||cpanceac at gmail.com
--- Comment #31 fr
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/20130712/73745cfb/attachment-0001.html>
https://bugzilla.kernel.org/show_bug.cgi?id=42678
?ubom?r Ml?ch changed:
What|Removed |Added
CC||hater.zlin at seznam.cz
--- Comment #22 f
From: Alex Deucher
There are cases where we need more than 4k alignment. No
functional change with this commit.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon.h|1 +
drivers/gpu/drm/radeon/radeon_gart.c |1 +
drivers/gpu/drm/radeon/radeon_object.h |2 +-
d
From: Alex Deucher
Covers requirements of all current asics.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon.h |5 +
drivers/gpu/drm/radeon/radeon_gart.c | 12 ++--
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeo
--- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130712/fa26bac9/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130712/851dcfe2/attachment-0001.html>
Hi,
Based on the outcomes of the "Best practice device tree design for display
subsystems" discussion I have drafted a DT binding. Comments much appreciated.
At a high level, it uses a "super node" as something for the driver to bind
to, needed because there is no clear one device that controls a
On Fri, 12 Jul 2013 12:44:28 -0400 (EDT)
Daniel Drake wrote:
> Hi,
>
> Based on the outcomes of the "Best practice device tree design for display
> subsystems" discussion I have drafted a DT binding. Comments much appreciated.
>
> At a high level, it uses a "super node" as something for the dri
On Fri, Jul 12, 2013 at 12:39 PM, Jean-Francois Moine
wrote:
> - I think it is better to keep the names 'lcd' for the memory to dumb panel
> sub-devices and 'dcon' for the dumb panel to LCD/VGA sub-device, as
> named in the spec.
I agree it is worth keeping the spec-defined names, if they do
84 matches
Mail list logo
