- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121224/f88c2193/attachment-0001.html>
-- next part --
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory
C
On 12/21/2012 11:50 PM, Terje Bergstr?m wrote:
> On 21.12.2012 16:36, Thierry Reding wrote:
>> On Fri, Dec 21, 2012 at 01:39:21PM +0200, Terje Bergstrom wrote:
>>> +static struct platform_driver tegra_drm_platform_driver = {
>>> + .driver = {
>>> + .name = "tegradrm",
>>
>> This should
On Mon, Dec 24, 2012 at 09:26:17PM +0100, balducci at units.it wrote:
> hello everybody,
>
> apologies if I am missing any blatant point; my knowledge about
> KMS/DRM etc. is very poor, so I am asking for help here (hoping to be
> at the right place)
>
> Starting with kernel-3.7 I am not able to
On Sun, Dec 23, 2012 at 6:31 AM, Borislav Petkov wrote:
> On Sun, Dec 23, 2012 at 01:22:12PM +0100, Borislav Petkov wrote:
>> Right, let me try that and report back.
>
> Yep, looks like reverting the above commit fixes it - the boston.com
> website loads just fine.
>
> Thanks.
>
> --
> Regards/Gru
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/20121224/d4acf2e8/attachment.html>
hello everybody,
apologies if I am missing any blatant point; my knowledge about
KMS/DRM etc. is very poor, so I am asking for help here (hoping to be
at the right place)
Starting with kernel-3.7 I am not able to boot any more in KMS: as
soon as the screen resolution changes in the very early sta
On 12/21/2012 11:50 PM, Terje Bergström wrote:
> On 21.12.2012 16:36, Thierry Reding wrote:
>> On Fri, Dec 21, 2012 at 01:39:21PM +0200, Terje Bergstrom wrote:
>>> +static struct platform_driver tegra_drm_platform_driver = {
>>> + .driver = {
>>> + .name = "tegradrm",
>>
>> This should
https://bugs.freedesktop.org/show_bug.cgi?id=58734
Priority: medium
Bug ID: 58734
Assignee: dri-devel@lists.freedesktop.org
Summary: Dungeon Defenders fails to launch crash
Severity: normal
Classification: Unclassified
OS: Li
org/archives/dri-devel/attachments/20121224/389911c8/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20121224/cd0ae29b/attachment.html>
vel/attachments/20121224/007d9ae5/attachment.html>
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121224/7e42f57f/attachment.html>
le-debug
llvm is 3.2 from tstellard's branch (HEAD:
15265bc80edeceb5bcfc4d0b85be751be9275a7d )
--
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/20121224/ed222fcc/attachment-0001.html>
Hi Rob,
(CC'ing Hans Verkuil)
On Wednesday 19 December 2012 10:05:27 Rob Clark wrote:
> On Wed, Dec 19, 2012 at 9:37 AM, Tomi Valkeinen wrote:
> > On 2012-12-19 17:26, Rob Clark wrote:
> >> And, there are also external HDMI encoders (for example connected over
> >> i2c) that can also be shared be
Hi Rob,
On Wednesday 19 December 2012 09:26:40 Rob Clark wrote:
> On Wed, Dec 19, 2012 at 8:57 AM, Jani Nikula wrote:
> > On Tue, 18 Dec 2012, Laurent Pinchart wrote:
> >> On Monday 17 December 2012 18:53:37 Jani Nikula wrote:
> >>> I can see the need for a framework for DSI panels and such (in fa
be enforced. A display controller driver developer who wants to
control the on-SoC encoder without conforming to the CDF model will be totally
free to do so and won't be blamed.
--
Regards,
Laurent Pinchart
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121224/31720f81/attachment.pgp>
Hi Jani,
On Wednesday 19 December 2012 16:57:56 Jani Nikula wrote:
> On Tue, 18 Dec 2012, Laurent Pinchart wrote:
> > On Monday 17 December 2012 18:53:37 Jani Nikula wrote:
> >> I can see the need for a framework for DSI panels and such (in fact Tomi
> >> and I have talked about it like 2-3 years
Hi Sylwester,
On Tuesday 18 December 2012 11:59:35 Sylwester Nawrocki wrote:
> On 12/18/2012 07:21 AM, Rob Clark wrote:
> > On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie wrote:
> >> So this might be a bit off topic but this whole CDF triggered me
> >> looking at stuff I generally avoid:
> >>
> >
Hi Marcus,
On Tuesday 18 December 2012 11:39:11 Marcus Lorentzon wrote:
> On 12/18/2012 06:04 AM, Dave Airlie wrote:
> >> Many developers showed interest in the first RFC, and I've had the
> >> opportunity to discuss it with most of them. I would like to thank (in
> >> no particular order) Tomi Va
Hi Tomasz,
On Friday 21 December 2012 11:00:52 Tomasz Figa wrote:
> On Tuesday 18 of December 2012 08:31:30 Vikas Sajjan wrote:
> > On 17 December 2012 20:55, Laurent Pinchart wrote:
> > > Hi Vikas,
> > >
> > > Sorry for the late reply. I now have more time to work on CDF, so
> > > delays should
Hi Inki,
On Tuesday 18 December 2012 18:38:31 Inki Dae wrote:
> 2012/12/18 Daniel Vetter
> > On Tue, Dec 18, 2012 at 7:21 AM, Rob Clark wrote:
> > >> The other thing I'd like you guys to do is kill the idea of fbdev and
> > >> v4l drivers that are "shared" with the drm codebase, really just
> >
Hi Daniel,
On Tuesday 18 December 2012 09:30:00 Daniel Vetter wrote:
> On Tue, Dec 18, 2012 at 7:21 AM, Rob Clark wrote:
> >> The other thing I'd like you guys to do is kill the idea of fbdev and
> >> v4l drivers that are "shared" with the drm codebase, really just
> >> implement fbdev and v4l on
Hi Rob,
On Tuesday 18 December 2012 00:21:32 Rob Clark wrote:
> On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie wrote:
> >> Many developers showed interest in the first RFC, and I've had the
> >> opportunity to discuss it with most of them. I would like to thank (in
> >> no particular order) Tomi V
Hi Dave,
On Tuesday 18 December 2012 15:04:02 Dave Airlie wrote:
> > Many developers showed interest in the first RFC, and I've had the
> > opportunity to discuss it with most of them. I would like to thank (in no
> > particular order) Tomi Valkeinen for all the time he spend helping me to
> > dra
This eliminates the need for explicit clk_put and makes the
cleanup and exit path code simpler.
Cc: Eunchul Kim
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_drm_gsc.c | 13 -
1 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exy
devm_request_and_ioremap API checks for NULL. Hence explicit
NULL check is not necessary. Saves some code.
Cc: Eunchul Kim
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_drm_gsc.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/exynos
devm_* APIs are device managed and get freed automatically when the
device detaches. Thus explicit freeing is not needed. This saves some
code.
Cc: Eunchul Kim
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_drm_gsc.c | 15 +++
1 files changed, 3 insertions(+), 12 de
This eliminates the need for explicit clk_put and makes the
cleanup and exit path code simpler.
Cc: Eunchul Kim
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_drm_rotator.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_d
devm_request_and_ioremap API checks for NULL. Hence explicit
NULL check is not necessary. Saves some code.
Cc: Eunchul Kim
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_drm_rotator.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/exy
devm_* APIs are device managed and get freed automatically when the
device detaches. Thus explicit freeing is not needed. This saves some
code.
Cc: Eunchul Kim
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_drm_rotator.c | 18 --
1 files changed, 4 insertions(+)
This eliminates the need for explicit clk_put and makes the
cleanup and exit path code simpler.
Cc: Eunchul Kim
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c | 46 ++---
1 files changed, 10 insertions(+), 36 deletions(-)
diff --git a/drivers
devm_request_and_ioremap API checks for NULL. Hence explicit
NULL check is not necessary. Saves some code.
Cc: Eunchul Kim
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/exyno
devm_* APIs are device managed and get freed automatically when the
device detaches. Thus explicit freeing is not needed. This saves some
code.
Cc: Eunchul Kim
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c | 30 +-
1 files changed, 9 inse
devm_kzalloc makes the code simpler by eliminating the need for
explicit freeing.
Cc: Eunchul Kim
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c |9 ++---
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/d
Compile tested against linux-next tree (20121224).
Sachin Kamat (10):
drm/exynos: Use devm_kzalloc in exynos_drm_ipp.c
drm/exynos: Remove explicit freeing using devm_* APIs in
exynos_drm_fimc.c
drm/exynos: Remove redundant NULL check
drm/exynos: Use devm_clk_get in exynos_drm_fimc.c
Hi Vikas,
On Tuesday 18 December 2012 08:31:30 Vikas Sajjan wrote:
> On 17 December 2012 20:55, Laurent Pinchart wrote:
> > Hi Vikas,
> >
> > Sorry for the late reply. I now have more time to work on CDF, so delays
> > should be much shorter.
> >
> > On Thursday 06 December 2012 10:51:15 Vikas S
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121224/559689d8/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #53 from runetmem...@gmail.com ---
Yesterday I installed 3.8rc1 and also can confirm - fix works for me too.
Thanks!
Michael, if you also doesn't have this problem anymore please close the ticket.
--
You are receiving this mail beca
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121224/954e0467/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20121224/f4c11b4b/attachment.html>
On Mon, Dec 24, 2012 at 09:26:17PM +0100, baldu...@units.it wrote:
> hello everybody,
>
> apologies if I am missing any blatant point; my knowledge about
> KMS/DRM etc. is very poor, so I am asking for help here (hoping to be
> at the right place)
>
> Starting with kernel-3.7 I am not able to boo
Hi Laurent,
On Wed, Dec 19, 2012 at 6:51 PM, Laurent Pinchart
wrote:
> Hi Tomi,
>
> On Friday 14 December 2012 16:27:26 Tomi Valkeinen wrote:
>> Hi,
>>
>> I have been testing Common Display Framework on OMAP, and making changes
>> that I've discussed in the posts I've sent in reply to the CDF ser
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #52 from Johannes Hirte ---
Fix works for me.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://li
https://bugs.freedesktop.org/show_bug.cgi?id=58655
Alex Deucher changed:
What|Removed |Added
CC||dcherkas...@gmail.com
--- Comment #4 from
https://bugs.freedesktop.org/show_bug.cgi?id=58724
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=58724
--- Comment #1 from Dmitry Cherkassov ---
Forgot to add:
* The device is Radeon HD 6970 (cayman)
* Kernel is 3.7.0-rc5 (tip of Alex's drm-fixes-3.7 branch)
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=58724
Priority: medium
Bug ID: 58724
Assignee: dri-devel@lists.freedesktop.org
Summary: [r600g] [bisected]: "rework flusing ...v7" commit by
Jerome causes problems
Severity: normal
Hi Rob,
(CC'ing Hans Verkuil)
On Wednesday 19 December 2012 10:05:27 Rob Clark wrote:
> On Wed, Dec 19, 2012 at 9:37 AM, Tomi Valkeinen wrote:
> > On 2012-12-19 17:26, Rob Clark wrote:
> >> And, there are also external HDMI encoders (for example connected over
> >> i2c) that can also be shared be
Hi Rob,
On Wednesday 19 December 2012 09:26:40 Rob Clark wrote:
> On Wed, Dec 19, 2012 at 8:57 AM, Jani Nikula wrote:
> > On Tue, 18 Dec 2012, Laurent Pinchart wrote:
> >> On Monday 17 December 2012 18:53:37 Jani Nikula wrote:
> >>> I can see the need for a framework for DSI panels and such (in fa
Hi Tomi,
On Wednesday 19 December 2012 17:07:50 Tomi Valkeinen wrote:
> On 2012-12-19 16:57, Jani Nikula wrote:
> > It just seems to me that, at least from a DRM/KMS perspective, adding
> > another layer (=CDF) for HDMI or DP (or legacy outputs) would be
> > overengineering it. They are pretty wel
Hi Jani,
On Wednesday 19 December 2012 16:57:56 Jani Nikula wrote:
> On Tue, 18 Dec 2012, Laurent Pinchart wrote:
> > On Monday 17 December 2012 18:53:37 Jani Nikula wrote:
> >> I can see the need for a framework for DSI panels and such (in fact Tomi
> >> and I have talked about it like 2-3 years
Hi Sylwester,
On Tuesday 18 December 2012 11:59:35 Sylwester Nawrocki wrote:
> On 12/18/2012 07:21 AM, Rob Clark wrote:
> > On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie wrote:
> >> So this might be a bit off topic but this whole CDF triggered me
> >> looking at stuff I generally avoid:
> >>
> >
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/20121224/d25e0690/attachment.html>
Hi Marcus,
On Tuesday 18 December 2012 11:39:11 Marcus Lorentzon wrote:
> On 12/18/2012 06:04 AM, Dave Airlie wrote:
> >> Many developers showed interest in the first RFC, and I've had the
> >> opportunity to discuss it with most of them. I would like to thank (in
> >> no particular order) Tomi Va
Hi Tomasz,
On Friday 21 December 2012 11:00:52 Tomasz Figa wrote:
> On Tuesday 18 of December 2012 08:31:30 Vikas Sajjan wrote:
> > On 17 December 2012 20:55, Laurent Pinchart wrote:
> > > Hi Vikas,
> > >
> > > Sorry for the late reply. I now have more time to work on CDF, so
> > > delays should
Hi Inki,
On Tuesday 18 December 2012 18:38:31 Inki Dae wrote:
> 2012/12/18 Daniel Vetter
> > On Tue, Dec 18, 2012 at 7:21 AM, Rob Clark wrote:
> > >> The other thing I'd like you guys to do is kill the idea of fbdev and
> > >> v4l drivers that are "shared" with the drm codebase, really just
> >
https://bugs.freedesktop.org/show_bug.cgi?id=44499
--- Comment #16 from smoki ---
Created attachment 72076
--> https://bugs.freedesktop.org/attachment.cgi?id=72076&action=edit
corruption in gliv
--
You are receiving this mail because:
You are the assignee for the bug.
Hi Daniel,
On Tuesday 18 December 2012 09:30:00 Daniel Vetter wrote:
> On Tue, Dec 18, 2012 at 7:21 AM, Rob Clark wrote:
> >> The other thing I'd like you guys to do is kill the idea of fbdev and
> >> v4l drivers that are "shared" with the drm codebase, really just
> >> implement fbdev and v4l on
Hi Rob,
On Tuesday 18 December 2012 00:21:32 Rob Clark wrote:
> On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie wrote:
> >> Many developers showed interest in the first RFC, and I've had the
> >> opportunity to discuss it with most of them. I would like to thank (in
> >> no particular order) Tomi V
https://bugs.freedesktop.org/show_bug.cgi?id=44499
--- Comment #15 from smoki ---
Created attachment 72075
--> https://bugs.freedesktop.org/attachment.cgi?id=72075&action=edit
corruption in STK
Actually corruption can be easely seen in supertuxkart, non-fbo case usage.
That is before this
Hi Dave,
On Tuesday 18 December 2012 15:04:02 Dave Airlie wrote:
> > Many developers showed interest in the first RFC, and I've had the
> > opportunity to discuss it with most of them. I would like to thank (in no
> > particular order) Tomi Valkeinen for all the time he spend helping me to
> > dra
https://bugs.freedesktop.org/show_bug.cgi?id=58660
Alex Deucher changed:
What|Removed |Added
Summary|Radeon HD 6950 completely |Radeon HD 6950 completely
Hi Vikas,
On Tuesday 18 December 2012 08:31:30 Vikas Sajjan wrote:
> On 17 December 2012 20:55, Laurent Pinchart wrote:
> > Hi Vikas,
> >
> > Sorry for the late reply. I now have more time to work on CDF, so delays
> > should be much shorter.
> >
> > On Thursday 06 December 2012 10:51:15 Vikas S
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121224/2c9c6870/attachment.html>
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121224/ff20bd94/attachment.html>
e assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121224/56efba9d/attachment-0001.html>
x86_64, Xorg Edgers PPA enabled.
Hardware:
A8-3500M with Radeon HD 6620G.
--
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/20121224/576bc6fe/attachment.html>
||
--
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/20121224/ab84e705/attachment.html>
d culling on rv280 with tcl this year.
Happy holidays :).
--
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/20121224/cad18970/attachment.html>
This eliminates the need for explicit clk_put and makes the
cleanup and exit path code simpler.
Cc: Eunchul Kim
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_drm_gsc.c | 13 -
1 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exy
devm_request_and_ioremap API checks for NULL. Hence explicit
NULL check is not necessary. Saves some code.
Cc: Eunchul Kim
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_drm_gsc.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/exynos
devm_* APIs are device managed and get freed automatically when the
device detaches. Thus explicit freeing is not needed. This saves some
code.
Cc: Eunchul Kim
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_drm_gsc.c | 15 +++
1 files changed, 3 insertions(+), 12 de
This eliminates the need for explicit clk_put and makes the
cleanup and exit path code simpler.
Cc: Eunchul Kim
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_drm_rotator.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_d
devm_request_and_ioremap API checks for NULL. Hence explicit
NULL check is not necessary. Saves some code.
Cc: Eunchul Kim
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_drm_rotator.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/exy
devm_* APIs are device managed and get freed automatically when the
device detaches. Thus explicit freeing is not needed. This saves some
code.
Cc: Eunchul Kim
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_drm_rotator.c | 18 --
1 files changed, 4 insertions(+)
This eliminates the need for explicit clk_put and makes the
cleanup and exit path code simpler.
Cc: Eunchul Kim
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c | 46 ++---
1 files changed, 10 insertions(+), 36 deletions(-)
diff --git a/drivers
devm_request_and_ioremap API checks for NULL. Hence explicit
NULL check is not necessary. Saves some code.
Cc: Eunchul Kim
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/exyno
devm_* APIs are device managed and get freed automatically when the
device detaches. Thus explicit freeing is not needed. This saves some
code.
Cc: Eunchul Kim
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c | 30 +-
1 files changed, 9 inse
devm_kzalloc makes the code simpler by eliminating the need for
explicit freeing.
Cc: Eunchul Kim
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c |9 ++---
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/d
Compile tested against linux-next tree (20121224).
Sachin Kamat (10):
drm/exynos: Use devm_kzalloc in exynos_drm_ipp.c
drm/exynos: Remove explicit freeing using devm_* APIs in
exynos_drm_fimc.c
drm/exynos: Remove redundant NULL check
drm/exynos: Use devm_clk_get in exynos_drm_fimc.c
--- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121224/909dbb80/attachment.html>
be a logic fix and most likely *is* valid
for radeon/radeon_state.c.
--
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/2012
https://bugs.freedesktop.org/show_bug.cgi?id=58696
Andreas Boll changed:
What|Removed |Added
Component|Drivers/DRI/R600|Drivers/Gallium/r600
--
You are receivin
:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121224/38be2f5a/attachment-0001.html>
is 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/20121224/eb349bba/attachment.html>
85 matches
Mail list logo
