On Mon, 2010-06-14 at 22:28 +0800, Adam Jackson wrote:
> On Sat, 2010-06-12 at 09:28 +0100, Chris Wilson wrote:
> > On Sat, 12 Jun 2010 14:32:21 +0800, Zhenyu Wang <zhen...@linux.intel.com>
> > wrote:
> > > static void
> > > -intel_dp_compute_m_n(int bytes_per_pixel,
> > > +intel_dp_compute_m_n(int bpp,
> > > int nlanes,
> > > int pixel_clock,
> > > int link_clock,
> > > struct intel_dp_m_n *m_n)
> > > {
> > > m_n->tu = 64;
> > > - m_n->gmch_m = pixel_clock * bytes_per_pixel;
> > > + m_n->gmch_m = (pixel_clock * bpp) >> 3;
> > > m_n->gmch_n = link_clock * nlanes;
> > > intel_reduce_ratio(&m_n->gmch_m, &m_n->gmch_n);
> > > m_n->link_m = pixel_clock;
> >
> > This rounds the gmch_m down. Is this correct?
>
> It's not, though thanks to the magic of PLLs it's probably close enough.
> However...
>
> > And how close to overflow is pixel_clock today?
>
> % echo $(( (2 ** 31 - 1) / 24. ))
> 89478485.291666672
>
> 89MHz isn't even a single LVDS link. Looks like that math needs to be
> 64-bit.
Yes. 64-bit math is required on the above scenario if the actual pixel
clock is directly used.
But the pixel clock in code uses the KHz as the unit. E.g. If the actual
pixel clock is 89000 KHz, then 89000 will be used for the calculation.
In such case it seems that the 32-bit math is enough.
Thanks.
Yakui
>
> - ajax
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
