[Intel-gfx] [PATCH 24/29] drm/i915: program iCLKIP on Lynx Point
Daniel Vetter
daniel at ffwll.ch
Mon Apr 16 10:56:05 CEST 2012
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
More information about the Intel-gfx
mailing list