[PATCH 1/3] drm/radeon: do not reenable crtc after moving vram start address

[Brad Campbell]

On 28/07/12 04:32, j.glisse at gmail.com wrote:
> From: Jerome Glisse <jglisse at redhat.com>
>
> It seems we can not update the crtc scanout address. After disabling
> crtc, update to base address do not take effect after crtc being
> reenable leading to at least frame being scanout from the old crtc
> base address. Disabling crtc display request lead to same behavior.
>
> So after changing the vram address if we don't keep crtc disabled
> we will have the GPU trying to read some random system memory address
> with some iommu this will broke the crtc engine and will lead to
> broken display and iommu error message.
>
> So to avoid this, disable crtc. For flicker less boot we will need
> to avoid moving the vram start address.
>
> This patch should also fix :
>
> https://bugs.freedesktop.org/show_bug.cgi?id=42373

G'day Jerome,

I'm running a Mid 2011, iMac with three heads. Card :
01:00.0 VGA compatible controller: ATI Technologies Inc Device 6720

To make this usable (ie to not cook the machine), I must force the card 
into low power mode which I do with this patch :

diff --git a/drivers/gpu/drm/radeon/radeon_pm.c 
b/drivers/gpu/drm/radeon/radeon_pm.c
index 6fabe89..de85eda 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -102,7 +102,7 @@ static void radeon_pm_update_profile(struct 
radeon_device *rdev)
  		break;
  	case PM_PROFILE_LOW:
  		if (rdev->pm.active_crtc_count > 1)
-			rdev->pm.profile_index = PM_PROFILE_LOW_MH_IDX;
+			rdev->pm.profile_index = PM_PROFILE_LOW_SH_IDX;
  		else
  			rdev->pm.profile_index = PM_PROFILE_LOW_SH_IDX;
  		break;

The patch this mail refers to causes moving corruption (like noise) on 
about the right hand 1/3rd of the primary monitor.

Reverting either of these patches makes the corruption go away, however 
reverting my patch makes the machine unusable as it simply cooks.

I also have to revert : [PATCH] drm/radeon: fix bo creation retry path 
or the machine simply panics at X login, however I see that has already 
been queued for reversion.

Any advice you could offer to assist me in sorting this would be much 
appreciated.

Regards,
Brad.