0x719B:0x1002:0x0602: FireMV 2250 Problem with PLL programming
Folks, I need some help from someone who understands the PLL programming. I have a FireMV2250 with RV516 GPU. I just came across an old CRT monitor that has a mode for which I can't synthesize a pixel clock. The mode is the following: Mode "1800x1440": 299.70 MHz, 120.85 kHz, 80.0 Hz Modeline "1800x1440" 299.70 1800 1941 2133 2480 1440 1442 1449 1510 -hsync +vsync My initial problem is the following message in the log file: (II) RADEONHD(0): Minimum Pixel ClockPLL Frequency Output: 900000 (WW) RADEONHD(0): Higher minimum PLL output detected than the default: 648000 9000000. Please contact the authors ASAP. (II) RADEONHD(0): Maximum Pixel ClockPLL Frequency Output: 1100000 OK, one of the numbers in this message is off by a factor of 10 but that's only a problem in the print. Internally the numbers are used correctly. The message is telling me that the ATOM BIOS specifies the minimum PLL clock output to be 900 MHz. And that is higher than the default of 648 MHz. I am to contact the authors ASAP, so here it is. My second problem is that after warning me, the code then uses the clock range specified by the ATOM BIOS, the 900-1100 MHZ. It does not use the default range of 648-1100 MHz. This makes some pixel clock frequencies, like the 299.7 MHz in the above mode, not achievable. Remember that <pixel clock> = <PLL clock> / <post divisor>. I made a table of the first few post divisors and the pixel clock range they can achieve: PLL output range post divisor pixel clock range 900-1100 / 2 = 450-550 * no overlap with next range 900-1100 / 3 = 300-366 * no overlap with next range 900-1100 / 4 = 225-275 * no overlap with next range 900-1100 / 5 = 180-220 900-1100 / 6 = 150-183 900-1100 / 7 = 128-157 Note that there are gaps between the achievable pixel clock ranges. Some pixel clocks just can't be synthesized with these constraints. So should the code be fixed to ignore the ATOMBIOS specified range and use the default range? With the default range there are no gaps in the pixel clock since it is wider. Or should the range be widened only a little to make all frequencies achievable? By my calculations the range of 732-1100 would be sufficient. Thanks for your help. Ales Fiala Hewlett Packard -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Apr 22, 10 17:40:40 -0600, Ales Fiala wrote:
(II) RADEONHD(0): Minimum Pixel ClockPLL Frequency Output: 900000 (WW) RADEONHD(0): Higher minimum PLL output detected than the default: 648000 9000000. Please contact the authors ASAP.
(II) RADEONHD(0): Maximum Pixel ClockPLL Frequency Output: 1100000 So should the code be fixed to ignore the ATOMBIOS specified range and use the default range? With the default range there are no gaps in the pixel clock since it is wider. Or should the range be widened only a little to make all frequencies achievable? By my calculations the range of 732-1100 would be sufficient.
Can you try whether ignoring the AtomBIOS data completely helps? It
might well be that the BIOS is broken (and other drivers just don't rely
on the data).
AFAIK you are the first person who has a BIOS with a higher minimum PLL
freq :-)
If the lower values work for you I'd suggest to only use the AtomBIOS
values if they are lower than the default.
Matthias
--
Matthias Hopf
Matthias Hopf wrote:
On Apr 22, 10 17:40:40 -0600, Ales Fiala wrote:
(II) RADEONHD(0): Minimum Pixel ClockPLL Frequency Output: 900000 (WW) RADEONHD(0): Higher minimum PLL output detected than the default: 648000 9000000. Please contact the authors ASAP.
(II) RADEONHD(0): Maximum Pixel ClockPLL Frequency Output: 1100000 So should the code be fixed to ignore the ATOMBIOS specified range and use the default range? With the default range there are no gaps in the pixel clock since it is wider. Or should the range be widened only a little to make all frequencies achievable? By my calculations the range of 732-1100 would be sufficient.
Can you try whether ignoring the AtomBIOS data completely helps? It might well be that the BIOS is broken (and other drivers just don't rely on the data).
AFAIK you are the first person who has a BIOS with a higher minimum PLL freq :-)
If the lower values work for you I'd suggest to only use the AtomBIOS values if they are lower than the default.
Matthias
If I ignore the ATOMBIOS value and just use the default value then everything works. I suppose that a defect in the BIOS is the only explanation. Certainly ATI wouldn't on purpose pick a range that makes some pixel clocks unachievable. I will use your suggestion. Thanks Ales -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
participants (2)
-
Ales Fiala
-
Matthias Hopf