On 04.11.2015 00:03, Pavel Machek wrote:
Hi!
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:
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().
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.
Regards,
Christian.
Thanks,
Pavel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
