From mboxrd@z Thu Jan 1 00:00:00 1970 From: Brad Campbell Subject: Re: [PATCH 1/3] drm/radeon: do not reenable crtc after moving vram start address Date: Wed, 05 Sep 2012 12:39:17 +0800 Message-ID: <5046D775.8020108@fnarfbargle.com> References: <1343421145-14257-1-git-send-email-j.glisse@gmail.com> <1343421145-14257-2-git-send-email-j.glisse@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from fnarfbargle.com (fnarfbargle.com [93.93.131.67]) by gabe.freedesktop.org (Postfix) with ESMTP id 399AB9E77C for ; Tue, 4 Sep 2012 22:00:08 -0700 (PDT) In-Reply-To: <1343421145-14257-2-git-send-email-j.glisse@gmail.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: j.glisse@gmail.com Cc: Jerome Glisse , dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On 28/07/12 04:32, j.glisse@gmail.com wrote: > From: Jerome Glisse > > 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.