Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964978AbbKCWZD (ORCPT ); Tue, 3 Nov 2015 17:25:03 -0500 Received: from mail-yk0-f173.google.com ([209.85.160.173]:35215 "EHLO mail-yk0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755135AbbKCWZA (ORCPT ); Tue, 3 Nov 2015 17:25:00 -0500 MIME-Version: 1.0 In-Reply-To: <20151103220919.GA4824@amd> References: <20151031201344.GA30459@amd> <563522C5.1000206@amd.com> <20151031212259.GA6253@amd> <20151103220919.GA4824@amd> Date: Tue, 3 Nov 2015 17:25:00 -0500 Message-ID: Subject: Re: Mobility Radeon HD 4530/4570/545v: flicker in 1920x1080 From: Alex Deucher To: Pavel Machek Cc: =?UTF-8?Q?Christian_K=C3=B6nig?= , "Deucher, Alexander" , "linux-fbdev@vger.kernel.org" , kernel list , Maling list - DRI developers Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4134 Lines: 104 On Tue, Nov 3, 2015 at 5:09 PM, Pavel Machek wrote: > Hi! > >> >> >4.3-rc7 kernel, graphics works reasonably well in 1600x1200 mode. But >> >> >my monitor is native 1920x1080, so that mode looks pretty ugly on >> >> >screen. If I go to 1920x1080, I see colored horizontal lines (often >> >> >black) as soon as there's graphics activity. >> >> > >> >> >pavel@half:~$ xrandr >> >> >Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192 >> >> >VGA-0 connected 1920x1080+0+0 (normal left inverted right x axis y >> >> >axis) 478mm x 268mm >> >> > 1920x1080 60.00*+ >> >> > 1600x1200 60.00 >> >> > 1680x1050 59.95 >> >> > 1280x1024 75.02 60.02 >> >> > 1440x900 59.89 >> >> > 1024x768 75.08 60.00 >> >> > 800x600 75.00 60.32 >> >> > 640x480 75.00 60.00 >> >> > 720x400 70.08 >> >> > pavel@half:~$ xrandr --output VGA-0 --mode 1600x1200 >> >> > pavel@half:~$ xrandr --output VGA-0 --mode 1920x1080 >> >> > pavel@half:~$ xrandr --output VGA-0 --mode 1600x1200 >> >> > > >> >> >Any ideas? >> >> >> >> Alex probably knows more about this, but it sounds like problems with >> >> switching the memory clocks on 3D load. >> > >> >> Try to disable power management completely with radeon.dpm=0 on the kernel >> >> command line or nailing the hardware at a specific power level using >> >> sysfs. >> > >> > I tried that, but it still flickers. >> >> It's probably pll stability. There seem to be a number of regressions >> since the pll code was rewritten to support matching the hdmi clocks >> more closely. Does this patch help? >> >> diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c >> b/drivers/gpu/drm/radeon/atombios_crtc.c >> 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: diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c index dac78ad..8c6e8fa 100644 --- a/drivers/gpu/drm/radeon/atombios_crtc.c +++ b/drivers/gpu/drm/radeon/atombios_crtc.c @@ -1094,8 +1094,8 @@ static void atombios_crtc_set_pll(struct drm_crtc *crtc, struct drm_display_mode radeon_compute_pll_legacy(pll, radeon_crtc->adjusted_clock, &pll_clock, &fb_div, &frac_fb_div, &ref_div, &post_div); else if (ASIC_IS_AVIVO(rdev)) - radeon_compute_pll_avivo(pll, radeon_crtc->adjusted_clock, &pll_clock, - &fb_div, &frac_fb_div, &ref_div, &post_div); + radeon_compute_pll_legacy(pll, radeon_crtc->adjusted_clock, &pll_clock, + &fb_div, &frac_fb_div, &ref_div, &post_div); else radeon_compute_pll_legacy(pll, radeon_crtc->adjusted_clock, &pll_clock, &fb_div, &frac_fb_div, &ref_div, &post_div); > >> Unfortunately, it can't be applied as is because we had a similar >> patch which was reverted because it regressed a bunch of other >> systems. The actual pll limits probably need to be tweaked. > > Any ideas how to tweak the pll limits? Adjust the the algorithm in radeon_compute_pll_avivo() in radeon_display.c Alex -- 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/