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

Brad Campbell brad at fnarfbargle.com
Wed Sep 5 10:07:02 PDT 2012



> 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

Thanks for that. I was naive enough to expect that answer, yet ask anyway.

Is there anyone that can point me towards a configuration (three heads) with functioning power management?

Regards,
Brad


More information about the dri-devel mailing list