|
Description
Gildas Le Nadan
2010-12-21 09:33:04 UTC
Created attachment 41345 [details]
Xorg.log
Created attachment 41346 [details] [review] UMS register dump as per #28331 Created attachment 41347 [details] [review] KMS register dump as per #28331 Created attachment 41348 [details] [review] patch proposed by Alex Deucher This patch, proposed by Alex on irc, applied with a drift of 20 lines or so did NOT fix the problem. How about this?
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c
index b0ab185..fa92120 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -521,12 +521,6 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
pll->flags = 0;
if (ASIC_IS_AVIVO(rdev)) {
- if ((rdev->family == CHIP_RS600) ||
- (rdev->family == CHIP_RS690) ||
- (rdev->family == CHIP_RS740))
- pll->flags |= (/*RADEON_PLL_USE_FRAC_FB_DIV |*/
- RADEON_PLL_PREFER_CLOSEST_LOWER);
-
if (ASIC_IS_DCE32(rdev) && mode->clock > 200000) /* range limits??? */
pll->flags |= RADEON_PLL_PREFER_HIGH_FB_DIV;
else
(In reply to comment #5) > How about this? > > diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c > b/drivers/gpu/drm/radeon/atombios_crtc.c > index b0ab185..fa92120 100644 > --- a/drivers/gpu/drm/radeon/atombios_crtc.c > +++ b/drivers/gpu/drm/radeon/atombios_crtc.c > @@ -521,12 +521,6 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc, > pll->flags = 0; > > if (ASIC_IS_AVIVO(rdev)) { > - if ((rdev->family == CHIP_RS600) || > - (rdev->family == CHIP_RS690) || > - (rdev->family == CHIP_RS740)) > - pll->flags |= (/*RADEON_PLL_USE_FRAC_FB_DIV |*/ > - RADEON_PLL_PREFER_CLOSEST_LOWER); > - > if (ASIC_IS_DCE32(rdev) && mode->clock > 200000) /* > range limits??? */ > pll->flags |= RADEON_PLL_PREFER_HIGH_FB_DIV; > else No problem is still there. See register dump kms2.regs Created attachment 41351 [details] [review] after proposed patch #2 was applied Created attachment 41376 [details] [review] add new pll flag This patch adds a new pll flag to prefer slightly higher frequencies if the target clock cannot be hit exactly. With the patch from comment 8, try these possible fixes: diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c index b0ab185..0be8015 100644 --- a/drivers/gpu/drm/radeon/atombios_crtc.c +++ b/drivers/gpu/drm/radeon/atombios_crtc.c @@ -525,7 +525,7 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc, (rdev->family == CHIP_RS690) || (rdev->family == CHIP_RS740)) pll->flags |= (/*RADEON_PLL_USE_FRAC_FB_DIV |*/ - RADEON_PLL_PREFER_CLOSEST_LOWER); + RADEON_PLL_PREFER_CLOSEST_HIGHER); if (ASIC_IS_DCE32(rdev) && mode->clock > 200000) /* range limits??? */ pll->flags |= RADEON_PLL_PREFER_HIGH_FB_DIV; Or: diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c index b0ab185..91facc8 100644 --- a/drivers/gpu/drm/radeon/atombios_crtc.c +++ b/drivers/gpu/drm/radeon/atombios_crtc.c @@ -525,7 +525,7 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc, (rdev->family == CHIP_RS690) || (rdev->family == CHIP_RS740)) pll->flags |= (/*RADEON_PLL_USE_FRAC_FB_DIV |*/ - RADEON_PLL_PREFER_CLOSEST_LOWER); + RADEON_PLL_NO_ODD_POST_DIV); if (ASIC_IS_DCE32(rdev) && mode->clock > 200000) /* range limits??? */ pll->flags |= RADEON_PLL_PREFER_HIGH_FB_DIV; Created attachment 41379 [details]
patch+RADEON_PLL_PREFER_CLOSEST_HIGHER
registers for kms with new pll patch applied + RADEON_PLL_PREFER_CLOSEST_HIGHER
Screen flickers slightly less than previously but is still unusable
Created attachment 41380 [details]
patch + RADEON_PLL_NO_ODD_POST_DIV
registers for kms with new pll patch applied + RADEON_PLL_NO_ODD_POST_DIV
Screen flickers slightly less than without patch but is still unusable
(In reply to comment #9) > With the patch from comment 8, try these possible fixes: > > diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c > b/drivers/gpu/drm/radeon/atombios_crtc.c > index b0ab185..0be8015 100644 > --- a/drivers/gpu/drm/radeon/atombios_crtc.c > +++ b/drivers/gpu/drm/radeon/atombios_crtc.c > @@ -525,7 +525,7 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc, > (rdev->family == CHIP_RS690) || > (rdev->family == CHIP_RS740)) > pll->flags |= (/*RADEON_PLL_USE_FRAC_FB_DIV |*/ > - RADEON_PLL_PREFER_CLOSEST_LOWER); > + RADEON_PLL_PREFER_CLOSEST_HIGHER); > > if (ASIC_IS_DCE32(rdev) && mode->clock > 200000) /* > range limits??? */ > pll->flags |= RADEON_PLL_PREFER_HIGH_FB_DIV; > > Or: > > diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c > b/drivers/gpu/drm/radeon/atombios_crtc.c > index b0ab185..91facc8 100644 > --- a/drivers/gpu/drm/radeon/atombios_crtc.c > +++ b/drivers/gpu/drm/radeon/atombios_crtc.c > @@ -525,7 +525,7 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc, > (rdev->family == CHIP_RS690) || > (rdev->family == CHIP_RS740)) > pll->flags |= (/*RADEON_PLL_USE_FRAC_FB_DIV |*/ > - RADEON_PLL_PREFER_CLOSEST_LOWER); > + RADEON_PLL_NO_ODD_POST_DIV); > > if (ASIC_IS_DCE32(rdev) && mode->clock > 200000) /* > range limits??? */ > pll->flags |= RADEON_PLL_PREFER_HIGH_FB_DIV; None of the proposed solutions fix the problem for good although there is some improvement over the flickering frequency. How about: pll->flags |= (RADEON_PLL_USE_FRAC_FB_DIV | RADEON_PLL_PREFER_CLOSEST_HIGHER); Can you also attach a copy of your vbios? (as root) (use lspci to get the bus id) cd /sys/bus/pci/devices/<pci bus id> echo 1 > rom cat rom > /tmp/vbios.rom echo 0 > rom Also try:
pll->flags |= (RADEON_PLL_USE_FRAC_FB_DIV |
RADEON_PLL_PREFER_CLOSEST_HIGHER |
RADEON_PLL_NO_ODD_POST_DIV);
Created attachment 41406 [details]
vbios.rom
Here for Xmas, have a poodle vbios
(In reply to comment #13) > How about: > > pll->flags |= (RADEON_PLL_USE_FRAC_FB_DIV | RADEON_PLL_PREFER_CLOSEST_HIGHER); > > Can you also attach a copy of your vbios? > (as root) > (use lspci to get the bus id) > cd /sys/bus/pci/devices/<pci bus id> > echo 1 > rom > cat rom > /tmp/vbios.rom > echo 0 > rom With this one screen is completely unusable (similar to the initial situation). Will attach kms_frac_closest.regs Created attachment 41407 [details]
registers with KMS patch and RADEON_PLL_USE_FRAC_FB_DIV | RADEON_PLL_PREFER_CLOSEST_HIGHER
(In reply to comment #14) > Also try: > > pll->flags |= (RADEON_PLL_USE_FRAC_FB_DIV | > RADEON_PLL_PREFER_CLOSEST_HIGHER | > RADEON_PLL_NO_ODD_POST_DIV); No image at all with this one. See kms_frac_closest_odd.regs Created attachment 41408 [details]
registers with KMS patch and RADEON_PLL_USE_FRAC_FB_DIV | RADEON_PLL_PREFER_CLOSEST_HIGHER |RADEON_PLL_NO_ODD_POST_DIV
Created attachment 41430 [details] [review] adjust up the clock slightly on rs6xx TDMS Does this patch help? (In reply to comment #20) > Created an attachment (id=41430) [details] > adjust up the clock slightly on rs6xx TDMS > > Does this patch help? This patch seems to help when combined with "RADEON_PLL_USE_FRAC_FB_DIV | RADEON_PLL_PREFER_CLOSEST_HIGHER |RADEON_PLL_NO_ODD_POST_DIV". For now after a single session of 2h, it even seems more stable than ums (where occasional losses of images happen maybe every 20-30mins on average). I've tried other combinations as well with various success: - RADEON_PLL_PREFER_CLOSEST_LOWER => unstable-ish - RADEON_PLL_USE_FRAC_FB_DIV => black - RADEON_PLL_PREFER_CLOSEST_LOWER | RADEON_PLL_USE_FRAC_FB_DIV => not very stable - RADEON_PLL_PREFER_CLOSEST_HIGHER => not stable - RADEON_PLL_USE_FRAC_FB_DIV | RADEON_PLL_PREFER_CLOSEST_HIGHER => not stable I can provide the registers for the different tests if that could be of any uses. You might also try making slight changes to the clock adjustment: adjusted_clock += 50; e.g., try 40, 45, 55, 60, 65, etc. (In reply to comment #22) > You might also try making slight changes to the clock adjustment: > adjusted_clock += 50; > e.g., try 40, 45, 55, 60, 65, etc. As far as I can tell the problem seems to be solved with adjusted_clock += 50; and RADEON_PLL_USE_FRAC_FB_DIV | RADEON_PLL_PREFER_CLOSEST_HIGHER |RADEON_PLL_NO_ODD_POST_DIV. After 3 hours of use (including watching video), 1 reboot and 1 cold boot, the screen never flicked, which not only means the bug concerned by this bug report is fixed, but apparently there is even an improvement over the previous situation. Created attachment 41852 [details] [review] ppll stability fixes for rs690 I've sent this patch and the one from attachment 41376 [details] [review] to Dave. re-opening as there are still some issues as we discussed on IRC. (In reply to comment #25) > re-opening as there are still some issues as we discussed on IRC. After our discussion on IRC caused by the fact your patch was slightly different than what I've tested, I've done the following tests: 1) DVI LCD screen VIEWSONIC 1680x1050 with DVI-DVI Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 8192 x 8192 DVI-0 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 474mm x 296mm 1680x1050 60.0 + 1400x1050 60.0 1280x1024 75.0 60.0 1440x900 59.9 1280x960 60.0 1152x864 75.0 1024x768 75.1 70.1 60.0 832x624 74.6 800x600 72.2 75.0 60.3 56.2 640x480 72.8 75.0 66.7 60.0 720x400 70.1 640x400 70.0 OK 1680x1050 1280x1024 832x624 800x600 720x400 unstable 1400x1050 640x480 640x400 KO 1440x900 1280x960 1152x864 1024x768 2) LCD screen IIYAMA 1920x1200 with HDMI connector on HDMI Screen 0: minimum 320 x 200, current 640 x 480, maximum 8192 x 8192 DVI-0 disconnected (normal left inverted right x axis y axis) HDMI-0 connected 640x480+0+0 (normal left inverted right x axis y axis) 519mm x 324mm 1920x1200 60.0 + 1680x1050 60.0 + 1600x1200 60.0 1280x1024 76.0 75.0 72.0 60.0 1440x900 75.0 59.9 1152x864 75.0 1280x720 60.0 1024x768 75.1 70.1 60.0 832x624 74.6 800x600 72.2 75.0 60.3 640x480 72.8 75.0 66.7 60.0 720x400 70.1 KO except below 832x624. With 800x600, the image contain noise (flickering horizontal color lines). /!\ when connecting the VIEWSONIC with a HDMI-DVI cable, results are similar, i-e no image except below 832x624. 3) ANALOG screen SILICON GRAPHICS connected on DVI with VGA adapter DVI-0 connected 1024x768+0+0 (normal left inverted right x axis y axis) 350mm x 280mm 1280x1024 75.0 1024x768 75.1 OK for both resolutions I have a "flicker" problem, too. While option radeon.new_pll=0 fixes the problem at kernel 2.6.35 and 2.6.36, now with 2.6.37 this option is gone. But my computer NOT starts directly flickering after kernel modesetting is initialized. It starts after performing some cpu usage like compiling. First there are many white lines flickering at the screen, then the screen going black. Flickering Video: http://youtu.be/oKsQ4Ga1pKA I have IBM Thinkpad T60 / Gentoo Linux with ATI Technologies Inc Radeon Mobility X1400 (In reply to comment #27) > I have a "flicker" problem, too. While option radeon.new_pll=0 fixes the > problem at kernel 2.6.35 and 2.6.36, now with 2.6.37 this option is gone. new_pll=0 became the default. Okay, but without new_pll=0 in 2.6.35/36 i had the completely identical error. Created attachment 41943 [details] [review] possible fix Does this patch fix the issues? Hi, I've compiled kernel 3.0 and apparently things are way better now. Connection on the viewsonic using dvi seem to be stable for all definitions. I'll confirm after a few days using 1680x1050. Vga connection to the analog SGI screen seem OK too. On the Iiyama 24" with the HDMI attachment, I have noted the "turn black 3 secs and display image again" syndrom is still there though (I'd say once every 5-!0 mn on average). Gildas -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/966. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.