On Mon, Apr 16, 2012 at 09:26:40AM +0100, Chris Wilson wrote: > On Sun, 15 Apr 2012 21:44:15 -0300, Eugeni Dodonov <eugeni at dodonov.net> wrote: > > On Sun, Apr 15, 2012 at 20:49, Daniel Vetter <daniel at ffwll.ch> wrote: > > > > > > I'm honestly not too happy with this table, because somewhere in there > > > we'll have an annoying type, and there's almost zero chance we'll ever > > > find that. So I prefer if we can replicate the pixel clock computation > > > from some stupid excel sheet ... > > > > > > > The latest specs say that the table is the recommended way for configuring > > known clocks settings, for both iCLKIP and WR PLL, and the > > algorithm/formula should be used as fallback only. > > Which implies that they do not match the values generated by the > algorithm. If you are going to keep the table, at least trim it so that > we aren't wasting bytes in unused precised. And split into the distinct > auxdivider, etc. Well, if the algo and the table do not match, I want to know where. Because even worse than a table is a table+algo - practically guarantees a bug in the algo because it's only ever used as a fallback. > > But I'll add them as well. One never knows when a new and previously > > unthinkable mode pops up :). > > Indeed. I'd throw it back at the hardware people, what are they doing in > kilobytes of data that can't be down in a few bytes of algorithm? Safe for a good reason I'd really prefer the algo over kilobytes of tables ... -Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
