drm/i915: clear up the fdi dotclock semantics for M/N computation
We currently mutliply the link_bw of the fdi link with the pixel multiplier, which is wrong: The FDI link doesn't suddenly grow more bandwidth. In reality the pixel mutliplication only happens in the PCH, before the pixels are fed into the port. But since we our code treats the uses the target clock after pixels are doubled (tripled, ...) already, we need to correct this. Semantically it's clearer to divide the target clock to get the fdi dotclock instead of multiplying the bw, so do that instead. Note that the target clock is already multiplied by the same factor, so the division will never loose accuracy for the M/N computation. The lane computation otoh used the wrong value, we also need to feed the fdi dotclock to that. Split out on a request from Paulo Zanoni. v2: Also fix the lane computation, it used the target clock to compute the bw requirements, not the fdi dotclock (i.e. adjusted with the pixel multiplier). Since sdvo only uses the pixel multiplier for low-res modes (with a dotclock below 100MHz) we wouldn't ever have rejected a bogus mode, but just used an inefficient fdi config. v3: Amend the commit message to explain better what the change for the fdi lane config computation is all about. Requested by Paulo. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Showing
Please register or sign in to comment