Commen=
t # 27
on bug 76564<=
/a>
from Christian K=C3=B6nig
(In reply to comment #=
26)
> (In reply to comment #25)
> > (In reply to comment #24<=
/a>)
> > > (In reply to comment=
#23)
> > > The problem is that the frequencys are exact enough so that =
the display
> > > device (Monitor/TV/Whatever) accepts them, but not 100% prec=
ise.
> > >=20
> > > E.g. for the 50Hz mode we wanted 148.5MHz pixel clock, but g=
ot 148.75Mhz
> > > instead. And for the 24Hz mode we wanted 74.2MHz but got 74.=
0625Mhz instead.
> > >=20
> > > So as Alex said somebody would need to dig into that and try=
to improve the
> > > numbers without toasting the hardware.
> >=20
> > So that would mean for example using fb=3D29.7 Ref=3D2 post=
=3D10?
> >=20
> > Or would that fry the hardware?
>=20
> That should work. You aren't likely to fry the hw. You just don't wa=
nt to
> set a 400 Mhz clock as you monitor properly won't like it. The hard p=
art is
> adjusting the algorithm to reliably calculate a good value for a wide =
range
> of clocks.
I'm not sure if those values would work. A post divider of 10 might result =
in a
to high VCO and that could indeed damage the hardware (even if that's rather
unlikely).
Essentially the target clock multiplied with the post divider must be in a
certain range. I think between pll->pll_out_max and pll->pll_out_min.
I think the problem is that we don't try to choose a good value to match the
target frequency as close as possible in avivo_get_post_div, but just a val=
ue
that either matches the maximum or minimum VCO frequency.