On Fri, 2011-10-14 at 23:13 -0700, Keith Packard wrote: > On Fri, 14 Oct 2011 12:43:50 -0400, Adam Jackson <a...@redhat.com> wrote: > > > These were just working around the math being wrong. > > One wonders whether this might break some machines which are currently > working. Should we emit an error or something if an eDP panel asks for > the impossible?
Probably, but I think in cases where that happens we should be considering the driver to be broken before the panel. No one's going to manufacture hardware that can't run Windows. The patch adding that check - fe27d53e5c597ee5ba5d72a29d517091f244e974 - references bug #28070. Relevant attachments: https://bugs.freedesktop.org/attachment.cgi?id=35584 [drm:drm_mode_debug_printmodeline], Modeline 25:"1920x1080" 60 137700 1920 1968 2000 2066 1080 1083 1088 1111 0x48 0xa [drm:intel_dp_mode_fixup], Display port link bw 06 lane count 2 clock 162000 https://bugs.freedesktop.org/attachment.cgi?id=35585 eDP block: type 6 Power Sequence: T3 3000 T7 400 T9 2000 T10 500 T12 5000 Panel color depth: 18bpp eDP sDRRs MSA timing delay: 0 Link params: rate: 1.62G lanes: x1 mode pre-emphasis: none vswing: 0.4V Old math: (137700 * 18 + 7) / 8 == 309825 New math: (137700 * 18 + 9) / 10 == 247860 I'm coming to believe that the eDP block's link parameters are nonsense and we should just trust DPCD. Which seems like a solid plan regardless. Sadly that dmesg doesn't include a DPCD dump, but, the threshold table looks like this: Rate / Lanes 1 2 4 1.62GHz 129600 259200 518400 2.7GHZ 216000 432000 864000 Note that the corrected math gives us a data rate that fits in 2x1.62, but the old math requires either more lanes or a higher rate. So I suspect the machine wasn't broken in the first place. - ajax
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
