[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 Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

More information about the Intel-gfx mailing list