On Tue, Nov 20, 2012 at 12:24 PM, Paulo Zanoni <[email protected]> wrote: > I think here we should keep the gmch_m and gmch_n calculations used in > the DP code instead of this one, since it matches the spec a little > better... The spec says that gmch_m should be "dot clock * bytes per > pixel" and gmch_n should be "ls_clk * number of lanes". So the lines > that are currently inside intel_dp_compute_m_n look better: > > m_n->gmch_m = (pixel_clock * bpp) >> 3; > m_n->gmch_n = link_clock * nlanes; > > (Also, in this case we'll need even higher numbers before we overflow) > > I applied a version with the DP values locally and tested. So my > version of this patch is Reviewed-by and Tested-by me.
How exactly should dot_clock * bytes_per_pixel work for e.g. 6bpc? Note that the above essentially just does part of the ratio reduction intel_reduce does and doesn't gain us any headroom for overflows, since in both cases we compute pixel_clock * bpp. The only difference is that we don't compute link_clock *nlanes * 8, but since the data can (almost) fill the link bw, we don't really gain anything. So imo computing the ration of bits that flow through the link is much more natural, and trying to compute the ration as bytes only obfuscates things. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
