https://bugs.freedesktop.org/show_bug.cgi?id=48880
--- Comment #23 from Luc Verhaegen <l...@skynet.be> 2012-04-19 08:15:14 PDT --- (In reply to comment #21) > (In reply to comment #20) > > What about the BIOS bug angle? Because kernel is not setting up the hardware > > directly, but asking the BIOS to do it, right? Is that out of the question? > > It's not out of the question, but I highly doubt it. The driver calculates > the > pll dividers and the atom table basically writes them to the pll registers. > If > there was a bug in the table, I'd expect it to cause problems across the > board, > not just on one mode on one monitor. We've had lots of these kind of bugs > over > the course of the driver's life. Some combinations of dividers and monitors > are just not happy. The trick is to tweak the algo just enough to fix the > problematic monitor while not breaking others. I'll test > RADEON_PLL_USE_FRAC_FB_DIV on the hw I have here and if all goes well, I'll > send it to Dave. The trick is testing a given version of the chip to the death and finding the frequency limits of the inner loop of the pll. I have always managed to fully clamp down pll ranges with a halfway decent CRT. It does take time and a structured approach though. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
