2012/8/20 Joonyoung Shim :
> On 08/20/2012 03:17 PM, InKi Dae wrote:
>>
>> 2012/8/20 Joonyoung Shim :
>>>
>>> On 08/20/2012 11:29 AM, InKi Dae wrote:
2012/8/20 Joonyoung Shim :
>
> On 08/17/2012 06:50 PM, Inki Dae wrote:
>>
>> this patch changes ctx variable name in exynos
Please can someone tell me if this patch will end up in kernel 3.6 or 3.7.
If it is merged in Linus's tree in the coming days, I'll try to
complete R600-R700 MSAA support (and therefore GL3.0) for Mesa 9.0.
Marek
On Sun, Aug 19, 2012 at 2:22 AM, Marek Ol??k wrote:
> MSAA is impossible without t
On 08/20/2012 03:17 PM, InKi Dae wrote:
2012/8/20 Joonyoung Shim :
On 08/20/2012 11:29 AM, InKi Dae wrote:
2012/8/20 Joonyoung Shim :
On 08/17/2012 06:50 PM, Inki Dae wrote:
this patch changes ctx variable name in exynos_drm_hdmi_context
structure to client because the use of ctx variable mak
2012/8/20 Joonyoung Shim :
> On 08/20/2012 11:29 AM, InKi Dae wrote:
>>
>> 2012/8/20 Joonyoung Shim :
>>>
>>> On 08/17/2012 06:50 PM, Inki Dae wrote:
this patch changes ctx variable name in exynos_drm_hdmi_context
structure to client because the use of ctx variable makes it confused.
https://bugs.freedesktop.org/show_bug.cgi?id=53111
--- Comment #14 from Alexandre Demers
2012-08-19 23:04:33 UTC ---
Created attachment 65813
--> https://bugs.freedesktop.org/attachment.cgi?id=65813
bad rendereing on test 7, where it used to lock
--
Configure bugmail: https://bugs.freedeskto
https://bugs.freedesktop.org/show_bug.cgi?id=53111
--- Comment #13 from Alexandre Demers
2012-08-19 23:03:48 UTC ---
(In reply to comment #12)
> I tried to trace RenderFeatTest (one of the other applications locking my
> system). It did as with the piglit test: it didn't crash. However, the
> r
2012/8/20 Joonyoung Shim :
> On 08/20/2012 02:15 PM, InKi Dae wrote:
>>
>> sorry, again.
>>
>> 2012/8/20 InKi Dae :
>>>
>>> 2012/8/20 Joonyoung Shim :
On 08/20/2012 11:23 AM, InKi Dae wrote:
>
> 2012/8/20 Joonyoung Shim :
>>
>> On 08/17/2012 06:50 PM, Inki Dae wrote:
>
2012/8/20 Joonyoung Shim :
> On 08/20/2012 01:31 PM, InKi Dae wrote:
>>
>> 2012/8/20 Joonyoung Shim :
>>>
>>> On 08/20/2012 10:52 AM, InKi Dae wrote:
2012/8/20 Joonyoung Shim :
>
> On 08/17/2012 06:50 PM, Inki Dae wrote:
>>
>> this patch separates sub driver's probe call a
Dear Marek,
thank you for all your work on MSAA.
Am Sonntag, den 19.08.2012, 21:23 +0200 schrieb Marek Olšák:
Unfortunately you do not provide any commit message. What is the problem
and what are the symptoms? When was it introduced? How is it solved in
your patch?
> Signed-off-by: Marek Olšá
On Mon, Aug 20, 2012 at 3:13 PM, Randy Dunlap wrote:
> On 08/17/12 15:55, Dave Airlie wrote:
>
>> On Sat, Aug 18, 2012 at 8:54 AM, Dave Airlie wrote:
>>> On Sat, Aug 18, 2012 at 8:28 AM, Randy Dunlap wrote:
On 08/17/2012 03:25 PM, Justin M. Forbes wrote:
> for , we have verified ca
On 08/20/2012 02:15 PM, InKi Dae wrote:
sorry, again.
2012/8/20 InKi Dae :
2012/8/20 Joonyoung Shim :
On 08/20/2012 11:23 AM, InKi Dae wrote:
2012/8/20 Joonyoung Shim :
On 08/17/2012 06:50 PM, Inki Dae wrote:
this patch adds buf_cnt variable in exynos_drm_fb structure and
that means a buffe
https://bugs.freedesktop.org/show_bug.cgi?id=53111
--- Comment #12 from Alexandre Demers
2012-08-19 22:22:24 UTC ---
I tried to trace RenderFeatTest (one of the other applications locking my
system). It did as with the piglit test: it didn't crash. However, the
rendering is corrupted where it l
sorry, again.
2012/8/20 InKi Dae :
> 2012/8/20 Joonyoung Shim :
>> On 08/20/2012 11:23 AM, InKi Dae wrote:
>>>
>>> 2012/8/20 Joonyoung Shim :
On 08/17/2012 06:50 PM, Inki Dae wrote:
>
> this patch adds buf_cnt variable in exynos_drm_fb structure and
> that means a buffer coun
On 08/17/12 15:55, Dave Airlie wrote:
> On Sat, Aug 18, 2012 at 8:54 AM, Dave Airlie wrote:
>> On Sat, Aug 18, 2012 at 8:28 AM, Randy Dunlap wrote:
>>> On 08/17/2012 03:25 PM, Justin M. Forbes wrote:
>>>
for , we have verified cases on inteldrmfb, radeondrmfb, and
cirrusdrmfb.
>>>
On 08/17/12 15:55, Dave Airlie wrote:
> On Sat, Aug 18, 2012 at 8:54 AM, Dave Airlie wrote:
>> On Sat, Aug 18, 2012 at 8:28 AM, Randy Dunlap
>> wrote:
>>> On 08/17/2012 03:25 PM, Justin M. Forbes wrote:
>>>
for , we have verified cases on inteldrmfb, radeondrmfb, and
cirrusdrmfb.
2012/8/20 Joonyoung Shim :
> On 08/20/2012 11:23 AM, InKi Dae wrote:
>>
>> 2012/8/20 Joonyoung Shim :
>>>
>>> On 08/17/2012 06:50 PM, Inki Dae wrote:
this patch adds buf_cnt variable in exynos_drm_fb structure and
that means a buffer count to drm framebuffer and also adds two
fu
On 08/20/2012 11:29 AM, InKi Dae wrote:
2012/8/20 Joonyoung Shim :
On 08/17/2012 06:50 PM, Inki Dae wrote:
this patch changes ctx variable name in exynos_drm_hdmi_context
structure to client because the use of ctx variable makes it confused.
I don't prefer "client" name. This is not client an
On 08/20/2012 11:23 AM, InKi Dae wrote:
2012/8/20 Joonyoung Shim :
On 08/17/2012 06:50 PM, Inki Dae wrote:
this patch adds buf_cnt variable in exynos_drm_fb structure and
that means a buffer count to drm framebuffer and also adds two
functions to get/set the buffer count from/to exynos_drm_fb s
Commit d0f3c7e41d30859a638083654002b9b6faf7f67b ("drm/nouveau: give a
slightly larger pci(e)gart aperture on all chipsets") removed a test:
that caused an 8x increase in gart aperture, instead of a 2x one, for
on-board cards >= NV_40.
Signed-off-by: Michele Ballabio
---
Hi,
in Linux 3.5.
On 08/20/2012 01:31 PM, InKi Dae wrote:
2012/8/20 Joonyoung Shim :
On 08/20/2012 10:52 AM, InKi Dae wrote:
2012/8/20 Joonyoung Shim :
On 08/17/2012 06:50 PM, Inki Dae wrote:
this patch separates sub driver's probe call and encoder/connector
creation
so that exynos drm core module can take exc
2012/8/20 Joonyoung Shim :
> On 08/20/2012 10:52 AM, InKi Dae wrote:
>>
>> 2012/8/20 Joonyoung Shim :
>>>
>>> On 08/17/2012 06:50 PM, Inki Dae wrote:
this patch separates sub driver's probe call and encoder/connector
creation
so that exynos drm core module can take exception whe
Signed-off-by: Marek Ol??k
---
drivers/gpu/drm/radeon/r600_cs.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index 1bec5b8..ab74e6b 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/
https://bugs.freedesktop.org/show_bug.cgi?id=42373
--- Comment #31 from Alexandre Demers 2012-08-20
03:01:28 UTC ---
(In reply to comment #16)
> Created attachment 64759 [details] [review]
> Fixup mc programing
>
> This patch should fix your issue.
This patch doesn't apply correctly on kernel
https://bugs.freedesktop.org/show_bug.cgi?id=43655
--- Comment #19 from Alexandre Demers 2012-08-20
03:00:22 UTC ---
Fixed by attachment 64759 (proposed in bug 42373 which is similar to this bug
but is not the same since it is not fixed by the attachment)
--
Configure bugmail: https://bugs.fre
2012/8/20 Joonyoung Shim :
> On 08/17/2012 06:50 PM, Inki Dae wrote:
>>
>> crtc and encoder's dpms callback will be called before connector's dpms
>> is called so drm_helper_connector_dpms doesn't need to be called.
>
>
> I can't understand this description. I know crtc and encoder dpms are called
2012/8/20 Joonyoung Shim :
> On 08/17/2012 06:50 PM, Inki Dae wrote:
>>
>> this patch changes ctx variable name in exynos_drm_hdmi_context
>> structure to client because the use of ctx variable makes it confused.
>
>
> I don't prefer "client" name. This is not client and server relationship.
>
Oka
2012/8/20 Joonyoung Shim :
> On 08/17/2012 06:50 PM, Inki Dae wrote:
>>
>> this patch adds buf_cnt variable in exynos_drm_fb structure and
>> that means a buffer count to drm framebuffer and also adds two
>> functions to get/set the buffer count from/to exynos_drm_fb structure.
>> if pixel format i
On 08/17/2012 06:50 PM, Inki Dae wrote:
the values set to registers will be updated into real registers
at vsync so dma operation could be malfunctioned when accessed
to memory after gem buffer was released. this patch makes sure
that hw overlay is disabled before the gem buffer is released.
Sig
2012/8/20 Joonyoung Shim :
> On 08/17/2012 06:50 PM, Inki Dae wrote:
>>
>> encoder's mode_set callback isn't specific to hardware so it doesn't
>> need to call exynos_drm_encoder_dpms().
>
>
> Then, where is exynos_drm_encoder_dpms() called?
>
with this patch series, exynos_drm_encoder_dpms() will
On 08/20/2012 10:52 AM, InKi Dae wrote:
2012/8/20 Joonyoung Shim :
On 08/17/2012 06:50 PM, Inki Dae wrote:
this patch separates sub driver's probe call and encoder/connector
creation
so that exynos drm core module can take exception when some operation was
failed properly.
Which exceptions? I
2012/8/20 Joonyoung Shim :
> On 08/17/2012 06:50 PM, Inki Dae wrote:
>>
>> this patch separates sub driver's probe call and encoder/connector
>> creation
>> so that exynos drm core module can take exception when some operation was
>> failed properly.
>
>
> Which exceptions? I don't know this patch
On 08/17/2012 06:37 PM, Leela Krishna Amudala wrote:
Hello,
On Fri, Aug 17, 2012 at 6:55 AM, Joonyoung Shim wrote:
Hi,
2012/8/16 Leela Krishna Amudala :
Add device tree based discovery support for DRM-FIMD driver.
Signed-off-by: Leela Krishna Amudala
---
Documentation/devicetree/bindings
On 08/17/2012 06:50 PM, Inki Dae wrote:
this patch changes ctx variable name in exynos_drm_hdmi_context
structure to client because the use of ctx variable makes it confused.
I don't prefer "client" name. This is not client and server relationship.
Signed-off-by: Inki Dae
Signed-off-by: Kyu
On 08/17/2012 06:50 PM, Inki Dae wrote:
if old_crtc isn't same as encoder->crtc then it means that
user changed crtc id to another one so a plane to old_crtc
should be disabled so that current plane can be updated safely
and plane->crtc should be set to new crtc(encoder->crtc)
Signed-off-by: Ink
On 08/17/2012 06:50 PM, Inki Dae wrote:
this patch adds buf_cnt variable in exynos_drm_fb structure and
that means a buffer count to drm framebuffer and also adds two
functions to get/set the buffer count from/to exynos_drm_fb structure.
if pixel format is not DRM_FORMAT_NV12MT then it gets a buf
On 08/17/2012 06:50 PM, Inki Dae wrote:
encoder's mode_set callback isn't specific to hardware so it doesn't
need to call exynos_drm_encoder_dpms().
Then, where is exynos_drm_encoder_dpms() called?
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm
On 08/17/2012 06:50 PM, Inki Dae wrote:
crtc and encoder's dpms callback will be called before connector's dpms
is called so drm_helper_connector_dpms doesn't need to be called.
I can't understand this description. I know crtc and encoder dpms are called
by drm_helper_connector_dpms.
Signed-o
On 08/17/2012 06:50 PM, Inki Dae wrote:
this patch separates sub driver's probe call and encoder/connector creation
so that exynos drm core module can take exception when some operation was
failed properly.
Which exceptions? I don't know this patch gives any benefit to us.
Signed-off-by: Ink
https://bugs.freedesktop.org/show_bug.cgi?id=44800
--- Comment #13 from Marko Kohtala 2012-08-19
18:09:19 UTC ---
I applied "drm/radeon: cleanup and fix crtc while programming mc" and
"drm/radeon: fence virtual address and free it once idle [3.5] v2" on top of
3.5.2.
Did not change this. I saw
https://bugzilla.kernel.org/show_bug.cgi?id=46231
Summary: Radeon NI: evergreen_resume fails after GPU lockup
Product: Drivers
Version: 2.5
Kernel Version: 3.6-rc2
Platform: All
OS/Version: Linux
Tree: Mainline
Status
https://bugs.freedesktop.org/show_bug.cgi?id=53111
--- Comment #14 from Alexandre Demers 2012-08-19
23:04:33 UTC ---
Created attachment 65813
--> https://bugs.freedesktop.org/attachment.cgi?id=65813
bad rendereing on test 7, where it used to lock
--
Configure bugmail: https://bugs.freedeskto
https://bugs.freedesktop.org/show_bug.cgi?id=53111
--- Comment #13 from Alexandre Demers 2012-08-19
23:03:48 UTC ---
(In reply to comment #12)
> I tried to trace RenderFeatTest (one of the other applications locking my
> system). It did as with the piglit test: it didn't crash. However, the
> r
---
radeon/radeon_surface.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index 892dca6..98f4aaf 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -165,7 +165,7 @@ static void surf_minify(struct radeon_s
https://bugs.freedesktop.org/show_bug.cgi?id=53111
--- Comment #12 from Alexandre Demers 2012-08-19
22:22:24 UTC ---
I tried to trace RenderFeatTest (one of the other applications locking my
system). It did as with the piglit test: it didn't crash. However, the
rendering is corrupted where it l
On Mon, Aug 20, 2012 at 7:51 AM, Marek Olšák wrote:
> Please can someone tell me if this patch will end up in kernel 3.6 or 3.7.
>
> If it is merged in Linus's tree in the coming days, I'll try to
> complete R600-R700 MSAA support (and therefore GL3.0) for Mesa 9.0.
I'll try and get it merged to
Please can someone tell me if this patch will end up in kernel 3.6 or 3.7.
If it is merged in Linus's tree in the coming days, I'll try to
complete R600-R700 MSAA support (and therefore GL3.0) for Mesa 9.0.
Marek
On Sun, Aug 19, 2012 at 2:22 AM, Marek Olšák wrote:
> MSAA is impossible without t
On Sat, Aug 18, 2012 at 8:22 PM, Marek Ol??k wrote:
> MSAA is impossible without them.
Reviewed-by: Jerome Glisse
> Signed-off-by: Marek Ol??k
> ---
> drivers/gpu/drm/radeon/r600_cs.c | 94
> +-
> drivers/gpu/drm/radeon/r600d.h | 17 ++
> dri
On Sun, Aug 19, 2012 at 9:25 AM, Marek Ol??k wrote:
Reviewed-by: Jerome Glisse
> ---
> radeon/radeon_surface.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
> index 892dca6..98f4aaf 100644
> --- a/radeon/radeon_sur
Commit d0f3c7e41d30859a638083654002b9b6faf7f67b ("drm/nouveau: give a
slightly larger pci(e)gart aperture on all chipsets") removed a test:
that caused an 8x increase in gart aperture, instead of a 2x one, for
on-board cards >= NV_40.
Signed-off-by: Michele Ballabio
---
Hi,
in Linux 3.5.
Signed-off-by: Marek Olšák
---
drivers/gpu/drm/radeon/r600_cs.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index 1bec5b8..ab74e6b 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/
https://bugs.freedesktop.org/show_bug.cgi?id=53707
--- Comment #6 from ojab 2012-08-19 11:28:23 UTC ---
It also happens with default xorg.conf (without "ColorTiling2D" and
"AccelDFS").
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=53707
--- Comment #5 from ojab 2012-08-19 11:15:46 UTC ---
Created attachment 65773
--> https://bugs.freedesktop.org/attachment.cgi?id=65773
Kernel log, second panic
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
---
https://bugs.freedesktop.org/show_bug.cgi?id=53707
ojab changed:
What|Removed |Added
Attachment #65771|application/octet-stream|text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=53707
--- Comment #4 from ojab 2012-08-19 11:15:03 UTC ---
Created attachment 65772
--> https://bugs.freedesktop.org/attachment.cgi?id=65772
glxinfo
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receivin
https://bugs.freedesktop.org/show_bug.cgi?id=53707
--- Comment #3 from ojab 2012-08-19 11:13:50 UTC ---
Created attachment 65771
--> https://bugs.freedesktop.org/attachment.cgi?id=65771
Xorg.log
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receivi
https://bugs.freedesktop.org/show_bug.cgi?id=53707
--- Comment #2 from ojab 2012-08-19 11:13:09 UTC ---
Created attachment 65770
--> https://bugs.freedesktop.org/attachment.cgi?id=65770
Karnel panic #2
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are
https://bugs.freedesktop.org/show_bug.cgi?id=53707
ojab changed:
What|Removed |Added
Attachment #65768|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=53707
Bug #: 53707
Summary: [RS780] Kernel panick after opening 6K?6K image in
firefox
Classification: Unclassified
Product: DRI
Version: DRI CVS
Platform: Other
OS/
https://bugs.freedesktop.org/show_bug.cgi?id=44800
--- Comment #13 from Marko Kohtala 2012-08-19
18:09:19 UTC ---
I applied "drm/radeon: cleanup and fix crtc while programming mc" and
"drm/radeon: fence virtual address and free it once idle [3.5] v2" on top of
3.5.2.
Did not change this. I saw
On Sat, Aug 18, 2012 at 8:22 PM, Marek Olšák wrote:
> MSAA is impossible without them.
Reviewed-by: Jerome Glisse
> Signed-off-by: Marek Olšák
> ---
> drivers/gpu/drm/radeon/r600_cs.c | 94
> +-
> drivers/gpu/drm/radeon/r600d.h | 17 ++
> dri
On Sun, Aug 19, 2012 at 9:25 AM, Marek Olšák wrote:
Reviewed-by: Jerome Glisse
> ---
> radeon/radeon_surface.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
> index 892dca6..98f4aaf 100644
> --- a/radeon/radeon_sur
https://bugs.freedesktop.org/show_bug.cgi?id=52256
--- Comment #7 from Christian K?nig 2012-08-19
10:25:18 UTC ---
I also have DP link problems on the trinity testing board I have.
Always thought that this is just a problem because it is a beta or even alpha
board, but that doesn't seems to be
https://bugs.freedesktop.org/show_bug.cgi?id=52256
--- Comment #6 from LRN 2012-08-19 10:19:17 UTC ---
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=f59abbf28696389c91c2697c7db31f20cfa91d8a
doesn't work either.
Are you sure there are no patches that i could try? I've tr
---
radeon/radeon_surface.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index 892dca6..98f4aaf 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -165,7 +165,7 @@ static void surf_minify(struct radeon_s
https://bugzilla.kernel.org/show_bug.cgi?id=46181
--- Comment #1 from Lakshminarayanan 2012-08-19
05:34:14 ---
PS: This problem ahs been there for the past year atleast and i have tried all
kernels from 2.35 to 3.5.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
https://bugzilla.kernel.org/show_bug.cgi?id=46181
Summary: No Brightness control-nouveau
Product: Drivers
Version: 2.5
Kernel Version: 3.4.9-1-ARCH
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=53707
--- Comment #6 from ojab 2012-08-19 11:28:23 UTC ---
It also happens with default xorg.conf (without "ColorTiling2D" and
"AccelDFS").
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=53707
--- Comment #5 from ojab 2012-08-19 11:15:46 UTC ---
Created attachment 65773
--> https://bugs.freedesktop.org/attachment.cgi?id=65773
Kernel log, second panic
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
---
https://bugs.freedesktop.org/show_bug.cgi?id=53707
ojab changed:
What|Removed |Added
Attachment #65771|application/octet-stream|text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=53707
--- Comment #4 from ojab 2012-08-19 11:15:03 UTC ---
Created attachment 65772
--> https://bugs.freedesktop.org/attachment.cgi?id=65772
glxinfo
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receivin
https://bugs.freedesktop.org/show_bug.cgi?id=53707
--- Comment #3 from ojab 2012-08-19 11:13:50 UTC ---
Created attachment 65771
--> https://bugs.freedesktop.org/attachment.cgi?id=65771
Xorg.log
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receivi
https://bugs.freedesktop.org/show_bug.cgi?id=53707
--- Comment #2 from ojab 2012-08-19 11:13:09 UTC ---
Created attachment 65770
--> https://bugs.freedesktop.org/attachment.cgi?id=65770
Karnel panic #2
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are
https://bugs.freedesktop.org/show_bug.cgi?id=53707
ojab changed:
What|Removed |Added
Attachment #65768|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=53707
Bug #: 53707
Summary: [RS780] Kernel panick after opening 6K×6K image in
firefox
Classification: Unclassified
Product: DRI
Version: DRI CVS
Platform: Other
OS/
https://bugs.freedesktop.org/show_bug.cgi?id=52256
--- Comment #7 from Christian König 2012-08-19
10:25:18 UTC ---
I also have DP link problems on the trinity testing board I have.
Always thought that this is just a problem because it is a beta or even alpha
board, but that doesn't seems to be
https://bugs.freedesktop.org/show_bug.cgi?id=52256
--- Comment #6 from LRN 2012-08-19 10:19:17 UTC ---
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=f59abbf28696389c91c2697c7db31f20cfa91d8a
doesn't work either.
Are you sure there are no patches that i could try? I've tr
MSAA is impossible without them.
Signed-off-by: Marek Ol??k
---
drivers/gpu/drm/radeon/r600_cs.c | 94 +-
drivers/gpu/drm/radeon/r600d.h | 17 ++
drivers/gpu/drm/radeon/radeon_drv.c |3 +-
drivers/gpu/drm/radeon/reg_srcs/r600 |8 ---
4 f
77 matches
Mail list logo
