On 2010.06.14 10:28:55 -0400, 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. >
Right, 64-bit math is needed for this like what has been done for FDI link. -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
signature.asc
Description: Digital signature
_______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx