Bug 217666 - video mode set too high for ATI ES1000
Summary: video mode set too high for ATI ES1000
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: xorg-x11-drv-ati (Show other bugs)
(Show other bugs)
Version: 5.0
Hardware: All Linux
Target Milestone: ---
: ---
Assignee: Adam Jackson
QA Contact:
Depends On:
Blocks: 200812
TreeView+ depends on / blocked
Reported: 2006-11-29 09:27 UTC by LisaWu
Modified: 2009-06-19 10:14 UTC (History)
10 users (show)

Fixed In Version: 5.0.0
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-01-26 03:16:51 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
limit the rn50 pixel clock range within its capacity (912 bytes, patch)
2006-11-30 02:12 UTC, LisaWu
no flags Details | Diff

Description LisaWu 2006-11-29 09:27:15 UTC
Description of problem:

RHEL5 beta2 will set 1280x1024@75hz to ATI ES1000. This mode is beyond what 
the ES1000 can handle when using 32bpp at 200Mhz.

RHEL2 beta2 use xorg-x11-drv-ati-6.6.3-1 version driver. This driver has 
enlarged the pixel clock range for ES1000.Thus some large modes that exceed 
ES1000 capacity are added to the valid mode list. However, these big modes 
will lead to uncertain status of ES1000 at 200Mhz memory clock.

According to ES1000 chip spec. At 200Mhz memory clock ES1000 cannot support 
modes bigger than:
8bpp  1920x1440@60hz
16bpp 1600x1200@75hz
32bpp 1280x1024@60hz

please refer to bug #182511 for detailed information: 

Version-Release number of selected component (if applicable):
RHEL2 beta2 with xorg-x11-drv-ati-6.6.3-1

Steps to Reproduce:
1.install RHEL5 beta2 on ATI ES1000 system. 
2.choose a monitor that can support high modes to the system
3.at 24bpp choose resolution 1280x1024
5.excute xrandr to check the modes

Actual results:

mode 1280x1024@75hz at 24bpp is added to the valid mode list

Expected results:

at 24bpp,200Mhz memory clock, ES1000 cannot handle mode larger than 

Comment 1 LisaWu 2006-11-30 02:12:24 UTC
Created attachment 142459 [details]
limit the rn50 pixel clock range within its capacity

Comment 2 Adam Jackson 2006-12-01 20:22:12 UTC
Trivially correct, thanks.  Built as xorg-x11-drv-ati 6.6.3-3.el5, should go out
in the next weekly snapshot.

Comment 3 Jay Turner 2006-12-13 18:46:56 UTC
This patch caused a regression on several machines here in RDU.  See bug 211504.

Comment 4 LisaWu 2006-12-15 08:18:17 UTC
Hi, Jay, I am not authorized to see bug 211504, would you please do me a favor 
to grant it to me? 
as a matter of fact, in our patch, we only change the empirical value from 24 
to 18, the code is in function RADEONGetClockInfo of radeon_driver.c : 

if (info->ChipFamily == CHIP_FAMILY_RV100 &&!info->HasCRTC2)
    pll->max_pll_freq=min(pll->max_pll_freq, 18*info->mclk*100/pScrn-
nothing else has been changed in our patch. Would it possible you just 
mannually change the empirical value and then build the driver again?

Comment 5 Xin-Yun Liu (Wolke Liu) 2006-12-22 06:18:00 UTC
no right to access bug 211504

Comment 6 Amit Bhutani 2007-01-15 17:26:21 UTC
Dell would like to know if the MODIFIED state of this issue is still accurate ?
We do see the rn50-pixel-clock-limit.patch in the RCS6 which contains
xorg-x11-drv-ati-6.6.3-3.2.el5. Question is, does this resolve the issue ??

Since this issue was found and fixed in RHEL3 and RHEL4 (caused a lot of
heart-ache), we would hate to see this resurrect right back into RHEL5. Hence
raising severity to get the right visibility. 

Can the involved parties: Alan J, Jay T, please comment on this ASAP since
time's running out.

Comment 7 LisaWu 2007-01-19 05:43:28 UTC
xorg-x11-drv-ati-6.6.3-3.2.el5 resolves the issue. thanks for the cooperation 
from you all.

Comment 8 Amit Bhutani 2007-01-19 16:17:24 UTC
Setting to VERIFIED based on Comment #7.

Comment 9 Jay Turner 2007-01-26 03:16:51 UTC
xorg-x11-drv-ati-6.6.3-3.2.el5 included in 20070124.1.

Note You need to log in before you can comment on or make changes to this bug.