Comment # 25
on bug 76564
from jeroen
(In reply to comment #24)
> (In reply to comment #23)
> > (In reply to comment #21)
> > > (In reply to comment #20)
> > > >
> > > > When I look at the xrandr output I wonder if the reference frequency is not
> > > > 75MHz for fgrlx? Can the reference even change is this not fixed by the
> > > > hardware?
> > >
> > > As far as I know, it's fixed. I'm not really sure what fglrx is doing.
> > > Anyway, it's probably easier to just fix the open source driver.
> > >
> > > the modes are:
> > > 1920x1080 (0x55) 148.5MHz +HSync +VSync *current +preferred
> > > h: width 1920 start 2448 end 2492 total 2640 skew 0 clock
> > > 56.2KHz
> > > v: height 1080 start 1084 end 1089 total 1125 clock
> > > 50.0Hz
> > >
> > > 1920x1080 (0x5a) 74.2MHz +HSync +VSync
> > > h: width 1920 start 2558 end 2602 total 2750 skew 0 clock
> > > 27.0KHz
> > > v: height 1080 start 1084 end 1089 total 1125 clock
> > > 24.0Hz
> > >
> > > and the driver ends up calculating the dividers as such:
> > >
> > > for 148.5MHz target clock:
> > > (100Mhz * 23.8) / (2 * 8) = 148.75Mhz
> > >
> > > for 74.2MHz target clock:
> > > (100Mhz * 23.7) / (2 * 16) = 74.0625Mhz
> > >
> > > One would need to tweak radeon_compute_pll_avivo() in radeon_display.c to
> > > try and get dividers that are closer to the target clock.
> >
> > Isn't that what the OSS driver is currently doing? If you look in the post
> > history those are the exact values that are currently being used
>
> The problem is that the frequencys are exact enough so that the display
> device (Monitor/TV/Whatever) accepts them, but not 100% precise.
>
> E.g. for the 50Hz mode we wanted 148.5MHz pixel clock, but got 148.75Mhz
> instead. And for the 24Hz mode we wanted 74.2MHz but got 74.0625Mhz instead.
>
> So as Alex said somebody would need to dig into that and try to improve the
> numbers without toasting the hardware.
So that would mean for example using fb=29.7 Ref=2 post=10?
Or would that fry the hardware?
Why must it exactly match? Because for fgrlx it seems roughly 30% higher than
needed