[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