On Sat, Feb 15, 2014 at 10:18:22PM +0100, Hans de Goede wrote: > Hi, > > Yes, almost, so what rounding algorithm are you using for the approximation, > I know of at least one monitor where round to closest does not work, where > as round down does work.
No rounding algorithm as such. Just go through the divider ranges, calculate the target multiplier, then round up and down. Then keep the best set of divider and multiplier. Works well, and is reasonably fast and very accurate. But we do indeed have an issue here, and we need to be stricter around the displays limits, due to the coarseness of our dotclock. I think i got withing .2% across the board, which could be up to 400kHz in the high ranges, where i am used to get within a few KHz accuracy. So we do need to care about the edges of the monitors bandwidth. We can work the heuristics for this out later on. > Note this is a too small sample size to say anything sensible about this, > but it likely does mean that since the allwinner pll-s are too limited to > make all dotclocks we may need some sort of quirk table. > > Note I'm not claiming that you should not round by default, just saying > that we'll need some way to add monitor quirks. Or just make sure that we do not round down below the monitors claimed lowest bandwidth, and do not round up above the monitors claimed highest bandwidth. > Anyways once you've some code ready to share I'll run it against the trouble > some monitor and send you a patch to add quirk support if that monitor needs > it. We'll figure out the good heuristic together there :) Luc Verhaegen. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
