Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1032217AbbKEKoK (ORCPT ); Thu, 5 Nov 2015 05:44:10 -0500 Received: from pegasos-out.vodafone.de ([80.84.1.38]:45347 "EHLO pegasos-out.vodafone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1031985AbbKEKnl (ORCPT ); Thu, 5 Nov 2015 05:43:41 -0500 X-Spam-Flag: NO X-Spam-Score: 0.201 Authentication-Results: rohrpostix2.prod.vfnet.de (amavisd-new); dkim=pass header.i=@vodafone.de X-DKIM: OpenDKIM Filter v2.6.8 pegasos-out.vodafone.de 3B8664C3347 Subject: Re: Mobility Radeon HD 4530/4570/545v: flicker in 1920x1080 To: Alex Deucher , Pavel Machek References: <20151031201344.GA30459@amd> <563522C5.1000206@amd.com> <20151031212259.GA6253@amd> <20151103220919.GA4824@amd> <20151103230329.GA4167@amd> <5639B580.1050409@vodafone.de> <20151104221000.GA3608@amd> Cc: "Deucher, Alexander" , "linux-fbdev@vger.kernel.org" , =?UTF-8?Q?Christian_K=c3=b6nig?= , Maling list - DRI developers , kernel list From: =?UTF-8?Q?Christian_K=c3=b6nig?= Message-ID: <563B32C7.3080202@vodafone.de> Date: Thu, 5 Nov 2015 11:43:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5854 Lines: 138 On 04.11.2015 23:13, Alex Deucher wrote: > On Wed, Nov 4, 2015 at 5:10 PM, Pavel Machek wrote: >> Hi! >> >>>>>>> index dac78ad..b86f06a 100644 >>>>>>> --- a/drivers/gpu/drm/radeon/atombios_crtc.c >>>>>>> +++ b/drivers/gpu/drm/radeon/atombios_crtc.c >>>>>>> @@ -569,6 +569,8 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc, >>>>>>> radeon_crtc->pll_flags = 0; >>>>>>> >>>>>>> if (ASIC_IS_AVIVO(rdev)) { >>>>>>> + radeon_crtc->pll_flags |= RADEON_PLL_PREFER_MINM_OVER_MAXP; >>>>>>> + >>>>>>> if ((rdev->family == CHIP_RS600) || >>>>>>> (rdev->family == CHIP_RS690) || >>>>>>> (rdev->family == CHIP_RS740)) >>>>>>> >>>>>> Help.. maybe... it is tricky to tell. It definitely does _not_ fix the >>>>>> issue completely. >>>>> You could also try the old pll algorithm: >>>> I reverted the patch above, and switched to the old algorithm. >>>> >>>> The flicker is still there. (But maybe its less horrible, like with >>>> RADEON_PLL_PREFER_MINM_OVER_MAXP). >>> The flickering would vanish completely if that's the reason for the issue >>> you are seeing. >>> Try setting ref_div_min and ref_div_max to 2 in >>> radeon_compute_pll_avivo(). >> Ok, I did this, but no luck, still flickers. But the flicker only >> happens when something changes on screen, like dragging a big >> window. Is that consistent with wrong PLL timings? > Does it go away with radeon.dpm=0? Sounds more like either memory > reclocking happening outside of vblank, or underflow to the display > controllers. Sounds like my suspicion was right, that doesn't seem to be a PLL issue after all. Just to rule out the obvious your system works fine with windows and you don't have a extra long cable for the monitor or something like this? Regards, Christian. > > Alex > >> diff --git a/config.32 b/config.32 >> index 00e5dd2..4734158 100644 >> --- a/config.32 >> +++ b/config.32 >> @@ -1090,7 +1090,7 @@ CONFIG_DEVTMPFS_MOUNT=y >> CONFIG_PREVENT_FIRMWARE_BUILD=y >> CONFIG_FW_LOADER=y >> CONFIG_FIRMWARE_IN_KERNEL=y >> -CONFIG_EXTRA_FIRMWARE="radeon/R700_rlc.bin" >> +CONFIG_EXTRA_FIRMWARE="radeon/R700_rlc.bin radeon/RV710_smc.bin radeon/RV710_uvd.bin" >> CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware" >> # CONFIG_FW_LOADER_USER_HELPER_FALLBACK is not set >> CONFIG_ALLOW_DEV_COREDUMP=y >> diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c >> index dac78ad..dcc4f4d 100644 >> --- a/drivers/gpu/drm/radeon/atombios_crtc.c >> +++ b/drivers/gpu/drm/radeon/atombios_crtc.c >> @@ -569,6 +569,8 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc, >> radeon_crtc->pll_flags = 0; >> >> if (ASIC_IS_AVIVO(rdev)) { >> + //radeon_crtc->pll_flags |= RADEON_PLL_PREFER_MINM_OVER_MAXP; >> + >> if ((rdev->family == CHIP_RS600) || >> (rdev->family == CHIP_RS690) || >> (rdev->family == CHIP_RS740)) >> diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c >> index 6743174..bebaf4f 100644 >> --- a/drivers/gpu/drm/radeon/radeon_display.c >> +++ b/drivers/gpu/drm/radeon/radeon_display.c >> @@ -947,6 +947,7 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll, >> fb_div_max = pll->max_feedback_div; >> >> if (pll->flags & RADEON_PLL_USE_FRAC_FB_DIV) { >> + printk("radeon: fractional divider\n"); >> fb_div_min *= 10; >> fb_div_max *= 10; >> } >> @@ -966,6 +967,9 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll, >> else >> ref_div_max = pll->max_ref_div; >> >> + ref_div_min = 2; >> + ref_div_max = 2; >> + >> /* determine allowed post divider range */ >> if (pll->flags & RADEON_PLL_USE_POST_DIV) { >> post_div_min = pll->post_div; >> @@ -1020,6 +1024,8 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll, >> diff = abs(target_clock - (pll->reference_freq * fb_div) / >> (ref_div * post_div)); >> >> + printk("post_div = %d, diff = %d\n", post_div, diff); >> + >> if (diff < diff_best || (diff == diff_best && >> !(pll->flags & RADEON_PLL_PREFER_MINM_OVER_MAXP))) { >> >> @@ -1028,6 +1034,7 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll, >> } >> } >> post_div = post_div_best; >> + printk("Selected post_div = %d\n", post_div); >> >> /* get the feedback and reference divider for the optimal value */ >> avivo_get_fb_ref_div(nom, den, post_div, fb_div_max, ref_div_max, >> @@ -1062,7 +1069,7 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll, >> *ref_div_p = ref_div; >> *post_div_p = post_div; >> >> - DRM_DEBUG_KMS("%d - %d, pll dividers - fb: %d.%d ref: %d, post %d\n", >> + printk("%d - %d, pll dividers - fb: %d.%d ref: %d, post %d\n", >> freq, *dot_clock_p * 10, *fb_div_p, *frac_fb_div_p, >> ref_div, post_div); >> } >> >> >>> But I'm not 100% convinced that this is actually a PLL problem, try to >>> compile the firmware it complains about into the kernel as well. >> Did that, too. >> >> Best regards, >> Pavel >> -- >> (english) http://www.livejournal.com/~pavelmachek >> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/