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

[Jerome Glisse]

On Wed, Sep 5, 2012 at 12:39 AM, Brad Campbell <brad at fnarfbargle.com> wrote:
> 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.

Low profile is not suited to drive 2 monitors and hence is not supported.

Cheers,
Jerome