On Sat, 2010-06-12 at 09:28 +0100, Chris Wilson wrote:
> On Sat, 12 Jun 2010 14:32:21 +0800, Zhenyu Wang <zhenyuw@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.

- ajax