ause:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121015/3e8ddd39/attachment.html>
> -Original Message-
> From: Rahul Sharma [mailto:rahul.sharma at samsung.com]
> Sent: Saturday, October 13, 2012 1:01 AM
> To: dri-devel at lists.freedesktop.org
> Cc: t.stanislaws at samsung.com; sw0312.kim at samsung.com;
inki.dae at samsung.com;
> jy0922.shim at samsung.com; kyungmin.
radeon_i2c_fini() walks thru the list of I2C bus recs rdev->i2c_bus[]
to destroy each of them.
radeon_ext_tmds_enc_destroy() however also has code to destroy it's
associated I2C bus rec which has been obtained by radeon_i2c_lookup()
and is therefore also in the i2c_bus[] list.
This causes a double
On Fri, 12 Oct 2012, Rob Clark wrote:
> From: Rob Clark
Nitpick: no commit message, and subject fails to mention
drm_connector_attach_property -> drm_object_attach_property. Regardless,
for this patch,
Reviewed-by: Jani Nikula
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/i915/intel_di
On Fri, 12 Oct 2012, Rob Clark wrote:
> From: Rob Clark
>
> Replace references to and remove the connector property fxns, which
> have been superseded with the more general object property fxns:
"fxns"? meh.
For this patch,
Reviewed-by: Jani Nikula
>
> + drm_connector_attach_property -> dr
u 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/20121015/25c81d18/attachment.html>
On Wed October 10 2012 16:46:21 Tomasz Stanislawski wrote:
> This patch adds description and usage examples for importing
> DMABUF file descriptor in V4L2.
>
> Signed-off-by: Tomasz Stanislawski
> Signed-off-by: Kyungmin Park
> CC: linux-doc at vger.kernel.org
> ---
> Documentation/DocBook/medi
On Wed October 10 2012 16:46:36 Tomasz Stanislawski wrote:
> This patch adds description and usage examples for exporting
> DMABUF file descriptor in V4L2.
>
> Signed-off-by: Tomasz Stanislawski
> Signed-off-by: Kyungmin Park
> CC: linux-doc at vger.kernel.org
> ---
> Documentation/DocBook/medi
On Wed October 10 2012 16:46:37 Tomasz Stanislawski wrote:
> This patch adds extension to V4L2 api. It allow to export a mmap buffer as
> file
> descriptor. New ioctl VIDIOC_EXPBUF is added. It takes a buffer offset used by
> mmap and return a file descriptor on success.
>
> Signed-off-by: Tomasz
ri-devel/attachments/20121015/06ed03e6/attachment.html>
esktop.org/archives/dri-devel/attachments/20121015/dbebd693/attachment-0001.html>
iving 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/20121015/fb88118d/attachment.html>
Hello Steffen,
To which version of the kernel we can expect this patch set to be merged into?
Because I'm waiting for this from long time to add DT support for my
display controller :)
Best Wishes,
Leela Krishna Amudala.
On Thu, Oct 4, 2012 at 11:29 PM, Steffen Trumtrar
wrote:
>
> Hi!
>
> In ac
On 10/12/2012 09:49 AM, Maarten Lankhorst wrote:
>
> I suppose there will stay a small race though,
Hmm, where?
>>> When you enter the ddestroy path, you drop the lock and hope the buffer
>>> doesn't reserved
>>> away from under you.
>> Yes, that code isn't fully correct, it's missing a c
On 10/12/2012 12:09 PM, Maarten Lankhorst wrote:
> Op 12-10-12 07:57, Thomas Hellstrom schreef:
>> On 10/11/2012 10:55 PM, Maarten Lankhorst wrote:
>>> Op 11-10-12 21:26, Thomas Hellstrom schreef:
On 10/11/2012 08:42 PM, Maarten Lankhorst wrote:
>> Anyway, if you plan to remove the fe
Hi Leela,
On Mon, Oct 15, 2012 at 04:24:43PM +0530, Leela Krishna Amudala wrote:
> Hello Steffen,
>
> To which version of the kernel we can expect this patch set to be merged into?
> Because I'm waiting for this from long time to add DT support for my
> display controller :)
>
I have no idea, s
.org/archives/dri-devel/attachments/20121015/93378482/attachment.html>
-
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121015/d3378827/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/20121015/0bbdfb2b/attachment.html>
or the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121015/915ffebf/attachment.html>
k for "RADEON_VA".
--
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/20121015/d323a5f0/attachment.html>
how can i check?
>
> Use "setenv" in a terminal and look for "RADEON_VA".
Oh, i have nothing like that in env
--
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/20121015/28f5bd73/attachment-0001.html>
Op 15-10-12 14:27, Thomas Hellstrom schreef:
> On 10/12/2012 12:09 PM, Maarten Lankhorst wrote:
>> Op 12-10-12 07:57, Thomas Hellstrom schreef:
>>> On 10/11/2012 10:55 PM, Maarten Lankhorst wrote:
Op 11-10-12 21:26, Thomas Hellstrom schreef:
> On 10/11/2012 08:42 PM, Maarten Lankhorst wrot
On Mon, Oct 15, 2012 at 2:21 AM, Egbert Eich wrote:
> radeon_i2c_fini() walks thru the list of I2C bus recs rdev->i2c_bus[]
> to destroy each of them.
> radeon_ext_tmds_enc_destroy() however also has code to destroy it's
> associated I2C bus rec which has been obtained by radeon_i2c_lookup()
> and
Platform device drivers usually use the driver-private data for their
own purposes. Having it overwritten by drm_platform_init() is confusing
and error-prone.
Signed-off-by: Thierry Reding
---
Note that I don't have any hardware to test the shmobile changes on so
it would be good to get a Tested-
From: Alex Deucher
Hi Dave,
This is the first -fixes pull for 3.7. I would have preferred
to have gotten it out a bit sooner, but I was on holiday last week.
- Cleanup of the new 2 level page table code it get it in
better shape and using less memory.
- Fix some display issues related to the
Op 15-10-12 17:37, Maarten Lankhorst schreef:
>>> To make multi-object reservation work, the fix is to add a ticket "lock" of
>>> which all the
>>> reservation objects are a nested lock of. Since in this case the ticket
>>> lock would prevent
>>> deadlocks, this is acceptable. Having 2 ticket 'l
On 10/15/2012 05:37 PM, Maarten Lankhorst wrote:
> Op 15-10-12 14:27, Thomas Hellstrom schreef:
>> On 10/12/2012 12:09 PM, Maarten Lankhorst wrote:
>>> Op 12-10-12 07:57, Thomas Hellstrom schreef:
On 10/11/2012 10:55 PM, Maarten Lankhorst wrote:
> Op 11-10-12 21:26, Thomas Hellstrom schree
Acked-by: Thomas Hellstrom
On 10/12/2012 04:57 PM, Maarten Lankhorst wrote:
> Nobody uses it, so might as well simplify the code some.
>
> Signed-off-by: Maarten Lankhorst
> Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/ttm/ttm_bo.c | 41
>
>
Op 15-10-12 20:40, Thomas Hellstrom schreef:
> On 10/15/2012 05:37 PM, Maarten Lankhorst wrote:
>> Op 15-10-12 14:27, Thomas Hellstrom schreef:
>>> On 10/12/2012 12:09 PM, Maarten Lankhorst wrote:
Op 12-10-12 07:57, Thomas Hellstrom schreef:
> On 10/11/2012 10:55 PM, Maarten Lankhorst wrot
On Mon, Oct 15, 2012 at 08:34:17PM +0200, Maarten Lankhorst wrote:
> Op 15-10-12 17:37, Maarten Lankhorst schreef:
> >>> To make multi-object reservation work, the fix is to add a ticket "lock"
> >>> of which all the
> >>> reservation objects are a nested lock of. Since in this case the ticket
>
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121015/cd7092b9/attachment.html>
the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121015/3543f1c2/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/20121015/ed2c474e/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=46241
Florian Mickler changed:
What|Removed |Added
CC||florian at mickler.org
--- Comment
From: Randy Dunlap
Fix printk format warnings in gpu/drm/radeon/:
drivers/gpu/drm/radeon/radeon_atpx_handler.c:151:3: warning: format '%lu'
expects type 'long unsigned int', but argument 2 has type 'size_t'
drivers/gpu/drm/radeon/radeon_acpi.c:204:3: warning: format '%lu' expects type
'long un
Already partially fixed in:
http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3.7&id=a1871936c0f4f10850a5671c5deb1a92fcca1155
which is in my radeon -fixes pull request. But Luca's patch missed the
one in radeon_atpx_handler.c. I can fix that one separately or Dave
can drop Luca's patch
On Fri, 12 Oct 2012, Rob Clark wrote:
> From: Rob Clark
>
> Replace references to and remove the connector property fxns, which
> have been superseded with the more general object property fxns:
"fxns"? meh.
For this patch,
Reviewed-by: Jani Nikula
>
> + drm_connector_attach_property -> dr
https://bugs.freedesktop.org/show_bug.cgi?id=55919
--- Comment #6 from Roland Egger ---
Hi,
thank you. Running configure fails, so I just ran
make linux
after little manually configurating the file in the configs directory.
I'll try to find the old libdrm and will try to use it.
--
You are rec
On Wed October 10 2012 16:46:21 Tomasz Stanislawski wrote:
> This patch adds description and usage examples for importing
> DMABUF file descriptor in V4L2.
>
> Signed-off-by: Tomasz Stanislawski
> Signed-off-by: Kyungmin Park
> CC: linux-...@vger.kernel.org
> ---
> Documentation/DocBook/media/v
On Wed October 10 2012 16:46:36 Tomasz Stanislawski wrote:
> This patch adds description and usage examples for exporting
> DMABUF file descriptor in V4L2.
>
> Signed-off-by: Tomasz Stanislawski
> Signed-off-by: Kyungmin Park
> CC: linux-...@vger.kernel.org
> ---
> Documentation/DocBook/media/v
On Wed October 10 2012 16:46:37 Tomasz Stanislawski wrote:
> This patch adds extension to V4L2 api. It allow to export a mmap buffer as
> file
> descriptor. New ioctl VIDIOC_EXPBUF is added. It takes a buffer offset used by
> mmap and return a file descriptor on success.
>
> Signed-off-by: Tomasz
https://bugs.freedesktop.org/show_bug.cgi?id=55919
--- Comment #7 from Roland Egger ---
I fetched libdrm-2.4.24
and after configure I got:
libdrm 2.4.24 will be compiled with:
libkms yes
Intel API yes
vmwgfx API no
Radeon API yes
Nouveau APIno
Therefor I trie
https://bugs.freedesktop.org/show_bug.cgi?id=55919
--- Comment #8 from Roland Egger ---
I tested configure and had to install
glproto-1.4.16, dri2proto-2.8 and libdrm-2.4.24 and set the PKG_CONFIG_PATH
Afterwards configure fails with
checking for llvm-config... no
configure: error: LLVM is requi
https://bugs.freedesktop.org/show_bug.cgi?id=55919
--- Comment #9 from Roland Egger ---
After successful configure I got:
glxconfig.c:52:11: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
before ‘int’
glxconfig.c:223:11: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
before ‘str
Hello Steffen,
To which version of the kernel we can expect this patch set to be merged into?
Because I'm waiting for this from long time to add DT support for my
display controller :)
Best Wishes,
Leela Krishna Amudala.
On Thu, Oct 4, 2012 at 11:29 PM, Steffen Trumtrar
wrote:
>
> Hi!
>
> In ac
On 10/12/2012 09:49 AM, Maarten Lankhorst wrote:
I suppose there will stay a small race though,
Hmm, where?
When you enter the ddestroy path, you drop the lock and hope the buffer doesn't
reserved
away from under you.
Yes, that code isn't fully correct, it's missing a check for still on dde
On 10/12/2012 12:09 PM, Maarten Lankhorst wrote:
Op 12-10-12 07:57, Thomas Hellstrom schreef:
On 10/11/2012 10:55 PM, Maarten Lankhorst wrote:
Op 11-10-12 21:26, Thomas Hellstrom schreef:
On 10/11/2012 08:42 PM, Maarten Lankhorst wrote:
Anyway, if you plan to remove the fence lock and protec
Hi Leela,
On Mon, Oct 15, 2012 at 04:24:43PM +0530, Leela Krishna Amudala wrote:
> Hello Steffen,
>
> To which version of the kernel we can expect this patch set to be merged into?
> Because I'm waiting for this from long time to add DT support for my
> display controller :)
>
I have no idea, s
https://bugs.freedesktop.org/show_bug.cgi?id=55692
--- Comment #18 from Alexandre Demers ---
Is VM enabled or disabled on your system? I'm experiencing a similar bug with
kernel 3.7-rc1, but it is working fine with 3.6. VM is enabled on my system,
I'll try to disable it when I'll get home to see
https://bugs.freedesktop.org/show_bug.cgi?id=55692
--- Comment #19 from Serkan Hosca ---
(In reply to comment #18)
> Is VM enabled or disabled on your system? I'm experiencing a similar bug
> with kernel 3.7-rc1, but it is working fine with 3.6. VM is enabled on my
> system, I'll try to disable i
https://bugs.freedesktop.org/show_bug.cgi?id=55006
--- Comment #8 from spamfang1...@yahoo.de ---
Another thing which might be helpful in finding the bug might be this:
When i add radeon.agpmode=-1 to the kernel 2.6.32 commandline, the system shows
the same freeze behaviour as with 3.2 and 3.5, BU
https://bugs.freedesktop.org/show_bug.cgi?id=55692
--- Comment #20 from Serkan Hosca ---
mesa-git is working fine on linux 3.6 and mesa-git dont have the "ef557ea
winsys/radeon: disable virtual memory on Cayman" commit
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=55692
--- Comment #21 from Alexandre Demers ---
(In reply to comment #19)
> (In reply to comment #18)
> > Is VM enabled or disabled on your system? I'm experiencing a similar bug
> > with kernel 3.7-rc1, but it is working fine with 3.6. VM is enabled o
https://bugs.freedesktop.org/show_bug.cgi?id=55692
--- Comment #22 from Serkan Hosca ---
(In reply to comment #21)
> (In reply to comment #19)
> > (In reply to comment #18)
> > > Is VM enabled or disabled on your system? I'm experiencing a similar bug
> > > with kernel 3.7-rc1, but it is working
Op 15-10-12 14:27, Thomas Hellstrom schreef:
> On 10/12/2012 12:09 PM, Maarten Lankhorst wrote:
>> Op 12-10-12 07:57, Thomas Hellstrom schreef:
>>> On 10/11/2012 10:55 PM, Maarten Lankhorst wrote:
Op 11-10-12 21:26, Thomas Hellstrom schreef:
> On 10/11/2012 08:42 PM, Maarten Lankhorst wrot
This patch adds drm-exynos and drm-exynos-hdmi device registration to the
drm driver. It was happening in machine init code earlier which is not
acceptable for dt enabled platforms.
Patch which cleans the respective code from arch/arm is "arm: exynos:
removing exynos-drm device registration from
This patch moved the exynos-drm platform device registration to the drm driver.
When DT is enabled, platform devices needs to be registered within the driver
code. This patch fits the requirement of both DT and Non DT based drm drivers.
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/exyn
This patch moved the exynos-drm-hdmi platform device registration to the drm
driver. When DT is enabled, platform devices needs to be registered within the
driver code. This patch fits the requirement of both DT and Non DT based drm
drivers.
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos
On Mon, Oct 15, 2012 at 2:21 AM, Egbert Eich wrote:
> radeon_i2c_fini() walks thru the list of I2C bus recs rdev->i2c_bus[]
> to destroy each of them.
> radeon_ext_tmds_enc_destroy() however also has code to destroy it's
> associated I2C bus rec which has been obtained by radeon_i2c_lookup()
> and
Platform device drivers usually use the driver-private data for their
own purposes. Having it overwritten by drm_platform_init() is confusing
and error-prone.
Signed-off-by: Thierry Reding
---
Note that I don't have any hardware to test the shmobile changes on so
it would be good to get a Tested-
From: Alex Deucher
Hi Dave,
This is the first -fixes pull for 3.7. I would have preferred
to have gotten it out a bit sooner, but I was on holiday last week.
- Cleanup of the new 2 level page table code it get it in
better shape and using less memory.
- Fix some display issues related to the
Op 15-10-12 17:37, Maarten Lankhorst schreef:
>>> To make multi-object reservation work, the fix is to add a ticket "lock" of
>>> which all the
>>> reservation objects are a nested lock of. Since in this case the ticket
>>> lock would prevent
>>> deadlocks, this is acceptable. Having 2 ticket 'l
On 10/15/2012 05:37 PM, Maarten Lankhorst wrote:
Op 15-10-12 14:27, Thomas Hellstrom schreef:
On 10/12/2012 12:09 PM, Maarten Lankhorst wrote:
Op 12-10-12 07:57, Thomas Hellstrom schreef:
On 10/11/2012 10:55 PM, Maarten Lankhorst wrote:
Op 11-10-12 21:26, Thomas Hellstrom schreef:
On 10/11/2
Acked-by: Thomas Hellstrom
On 10/12/2012 04:57 PM, Maarten Lankhorst wrote:
Nobody uses it, so might as well simplify the code some.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Jerome Glisse
---
drivers/gpu/drm/ttm/ttm_bo.c | 41
drivers/gpu
Op 15-10-12 20:40, Thomas Hellstrom schreef:
> On 10/15/2012 05:37 PM, Maarten Lankhorst wrote:
>> Op 15-10-12 14:27, Thomas Hellstrom schreef:
>>> On 10/12/2012 12:09 PM, Maarten Lankhorst wrote:
Op 12-10-12 07:57, Thomas Hellstrom schreef:
> On 10/11/2012 10:55 PM, Maarten Lankhorst wrot
On Mon, Oct 15, 2012 at 08:34:17PM +0200, Maarten Lankhorst wrote:
> Op 15-10-12 17:37, Maarten Lankhorst schreef:
> >>> To make multi-object reservation work, the fix is to add a ticket "lock"
> >>> of which all the
> >>> reservation objects are a nested lock of. Since in this case the ticket
>
https://bugs.freedesktop.org/show_bug.cgi?id=43829
Florian Mickler changed:
What|Removed |Added
CC||flor...@mickler.org
--- Comment #15 fr
https://bugs.freedesktop.org/show_bug.cgi?id=17902
Florian Mickler changed:
What|Removed |Added
CC||flor...@mickler.org
--- Comment #88 fr
https://bugs.freedesktop.org/show_bug.cgi?id=49981
Florian Mickler changed:
What|Removed |Added
CC||flor...@mickler.org
--- Comment #23 fr
https://bugzilla.kernel.org/show_bug.cgi?id=46241
Florian Mickler changed:
What|Removed |Added
CC||flor...@mickler.org
--- Comment #8
From: Randy Dunlap
Fix printk format warnings in gpu/drm/radeon/:
drivers/gpu/drm/radeon/radeon_atpx_handler.c:151:3: warning: format '%lu'
expects type 'long unsigned int', but argument 2 has type 'size_t'
drivers/gpu/drm/radeon/radeon_acpi.c:204:3: warning: format '%lu' expects type
'long un
Already partially fixed in:
http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3.7&id=a1871936c0f4f10850a5671c5deb1a92fcca1155
which is in my radeon -fixes pull request. But Luca's patch missed the
one in radeon_atpx_handler.c. I can fix that one separately or Dave
can drop Luca's patch
The calculation led to the number 8192, which is too high.
---
radeon/radeon_surface.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index 66c2444..eb587d2 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -939,6 +939
Applied.
Thanks,
Inki Dae
2012/10/16 Rahul Sharma :
> This patch adds drm-exynos and drm-exynos-hdmi device registration to the
> drm driver. It was happening in machine init code earlier which is not
> acceptable for dt enabled platforms.
>
> Patch which cleans the respective code from arch/arm
Hi Ben,
FYI, kernel build failed on
tree: git://people.freedesktop.org/~danvet/drm-intel.git drm-intel-next-queued
head: 861b675336a1f686f480d92990251e99a3ec0956
commit: 686279dbcbc69f71ce86efdccaa8cad762cba2ea [42/44] drm/i915: Extract PCU
communication
config: x86_64-allyesconfig # make AR
https://bugs.freedesktop.org/show_bug.cgi?id=55829
--- Comment #5 from meng ---
Xonotic (xonotic-linux64-sdl) can also repoduce this problem with above
version. Pls see Xorg.0.log and bt of xonotic.
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=55829
--- Comment #6 from meng ---
Created attachment 68594
--> https://bugs.freedesktop.org/attachment.cgi?id=68594&action=edit
backtrace of xonotic
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=55829
--- Comment #7 from meng ---
Created attachment 68595
--> https://bugs.freedesktop.org/attachment.cgi?id=68595&action=edit
Xorg.0.log of xonotic
--
You are receiving this mail because:
You are the assignee for the bug.
___
Fixed include error for drm_mode.h
Signed-off-by: Andy Gross
---
drivers/staging/omapdrm/omap_crtc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_crtc.c
b/drivers/staging/omapdrm/omap_crtc.c
index 732f2ad..5249223 100644
--- a/drivers/st
Hi Linus,
fixes for i915, nouveau and radeon
i915: haswell stability, modeset rework fallout, ums fix
nouveau: misc fixes from code rework
radeon: pll rework fixes, more 2 level PTE cleanups.
core: warning fixes on 32-bit.
Dave.
The following changes since commit ddffeb8c4d0331609ef2581d84de4d
Dear Marek,
Am Dienstag, den 16.10.2012, 02:21 +0200 schrieb Marek Olšák:
> The calculation led to the number 8192, which is too high.
what is the reason it is limited to 4096? Hardware limitation?
What are the ramifications? GPU hangs, rendering errors?
> ---
> radeon/radeon_surface.c |2
82 matches
Mail list logo
