[PATCH] drm/radeon: disable dpm on rv770 by default

[PATCH] drm/radeon: disable dpm on rv770 by default

[Alex Deucher]

There seem to be stability issues on a number of cards.

bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=76286
https://bugzilla.redhat.com/show_bug.cgi?id=1085785
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741619

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: matthias.graf@st.ovqu.de
Cc: bp@alien8.de
Cc: stable@vger.kernel.org
---
 drivers/gpu/drm/radeon/radeon_pm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_pm.c b/drivers/gpu/drm/radeon/radeon_pm.c
index ee738a5..0c4473d 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -1257,6 +1257,7 @@ int radeon_pm_init(struct radeon_device *rdev)
 	case CHIP_RV670:
 	case CHIP_RS780:
 	case CHIP_RS880:
+	case CHIP_RV770:
 	case CHIP_BARTS:
 	case CHIP_TURKS:
 	case CHIP_CAICOS:
@@ -1273,7 +1274,6 @@ int radeon_pm_init(struct radeon_device *rdev)
 		else
 			rdev->pm.pm_method = PM_METHOD_PROFILE;
 		break;
-	case CHIP_RV770:
 	case CHIP_RV730:
 	case CHIP_RV710:
 	case CHIP_RV740:
-- 
1.8.3.1

Re: [PATCH] drm/radeon: disable dpm on rv770 by default

[Christian König]

Am 18.04.2014 15:08, schrieb Alex Deucher:
> There seem to be stability issues on a number of cards.
>
> bugs:
> https://bugs.freedesktop.org/show_bug.cgi?id=76286
> https://bugzilla.redhat.com/show_bug.cgi?id=1085785
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741619
>
> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
> Cc: matthias.graf@st.ovqu.de
> Cc: bp@alien8.de
> Cc: stable@vger.kernel.org

Added to my 3.15 queue.

Christian.

> ---
>   drivers/gpu/drm/radeon/radeon_pm.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_pm.c b/drivers/gpu/drm/radeon/radeon_pm.c
> index ee738a5..0c4473d 100644
> --- a/drivers/gpu/drm/radeon/radeon_pm.c
> +++ b/drivers/gpu/drm/radeon/radeon_pm.c
> @@ -1257,6 +1257,7 @@ int radeon_pm_init(struct radeon_device *rdev)
>   	case CHIP_RV670:
>   	case CHIP_RS780:
>   	case CHIP_RS880:
> +	case CHIP_RV770:
>   	case CHIP_BARTS:
>   	case CHIP_TURKS:
>   	case CHIP_CAICOS:
> @@ -1273,7 +1274,6 @@ int radeon_pm_init(struct radeon_device *rdev)
>   		else
>   			rdev->pm.pm_method = PM_METHOD_PROFILE;
>   		break;
> -	case CHIP_RV770:
>   	case CHIP_RV730:
>   	case CHIP_RV710:
>   	case CHIP_RV740:

Re: [PATCH] drm/radeon: disable dpm on rv770 by default

[Andy Furniss]

Alex Deucher wrote:
> There seem to be stability issues on a number of cards.
>
> bugs: https://bugs.freedesktop.org/show_bug.cgi?id=76286
> https://bugzilla.redhat.com/show_bug.cgi?id=1085785
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741619

Well TBH I don't know whether the following is useful info or not - it
could just be an unrelated waste of your time.

I have run my 4890 with dpm=1 from when it first appeared without issue
till recently.

As in the bug above I can't now use two screens - but the thing is,  I
use a (getting old) LFS, I don't use the TV that much, but when I
noticed the issue I tried to bisect and I reached the commit after my
working start point.

It turned out that my working was the last kernel I compiled with GCC
4.6.3. I had upgraded to GCC 4.8.2 and no kernel built with that can
handle 2 screens without locking, no sysrq, no network but very rarely
may unlock for a short while (did a dmesg when this happened, nothing
unusual logged then it locked again).

I built my GCC 4.6.3 again and built the same recent kernel (I run drm 
next or
fixes) and I have so far not been able to lock it with 2 screens.

Of course it could just be something on my LFS is too old for recent
GCC, or because I don't use TV much I am being lucky with 4.6.3.

I will when I get time build 4.8.2 again and see if dpm=0 works for me.

Re: [PATCH] drm/radeon: disable dpm on rv770 by default

[Alex Deucher]

On Sat, Apr 19, 2014 at 2:02 PM, Andy Furniss <adf.lists@gmail.com> wrote:
> Alex Deucher wrote:
>>
>> There seem to be stability issues on a number of cards.
>>
>> bugs: https://bugs.freedesktop.org/show_bug.cgi?id=76286
>> https://bugzilla.redhat.com/show_bug.cgi?id=1085785
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741619
>
>
> Well TBH I don't know whether the following is useful info or not - it
> could just be an unrelated waste of your time.
>
> I have run my 4890 with dpm=1 from when it first appeared without issue
> till recently.
>
> As in the bug above I can't now use two screens - but the thing is,  I
> use a (getting old) LFS, I don't use the TV that much, but when I
> noticed the issue I tried to bisect and I reached the commit after my
> working start point.
>
> It turned out that my working was the last kernel I compiled with GCC
> 4.6.3. I had upgraded to GCC 4.8.2 and no kernel built with that can
> handle 2 screens without locking, no sysrq, no network but very rarely
> may unlock for a short while (did a dmesg when this happened, nothing
> unusual logged then it locked again).
>
> I built my GCC 4.6.3 again and built the same recent kernel (I run drm next
> or
> fixes) and I have so far not been able to lock it with 2 screens.
>
> Of course it could just be something on my LFS is too old for recent
> GCC, or because I don't use TV much I am being lucky with 4.6.3.
>
> I will when I get time build 4.8.2 again and see if dpm=0 works for me.

I ran into similar issues right after dpm support was released.  I'd
done most of my development on gcc 4.6 and everything worked fine and
upon upgrading to 4.7 or 4.8, tons of stuff broke.  It ended up at
least partially being related to indexing variable sized arrays:
48fa04c3fcdb4f6ac041976bedaf19ca5bee20c0
f90555cbe629e14c6af1dcec1933a3833ecd321f
607f2c2791ec81e5abca6213ff037e9405378be1
a7ee824a6255e347ea76e2f00827e81bbe01004e
plus some others, but there may still be problematic cases.

Alex

Re: [PATCH] drm/radeon: disable dpm on rv770 by default

[Andy Furniss]

Alex Deucher wrote:

> I ran into similar issues right after dpm support was released.  I'd
> done most of my development on gcc 4.6 and everything worked fine
> and upon upgrading to 4.7 or 4.8, tons of stuff broke.  It ended up
> at least partially being related to indexing variable sized arrays:
> 48fa04c3fcdb4f6ac041976bedaf19ca5bee20c0
> f90555cbe629e14c6af1dcec1933a3833ecd321f
> 607f2c2791ec81e5abca6213ff037e9405378be1
> a7ee824a6255e347ea76e2f00827e81bbe01004e plus some others, but there
> may still be problematic cases.

Ahh, thanks for that, at least I know now there's no point in me
building a whole new LFS.