• S
    drm/dp: Use large transactions for I2C over AUX · 1d002fa7
    Simon Farnsworth 提交于
    Older DisplayPort to DVI-D Dual Link adapters designed by Bizlink have bugs
    in their I2C over AUX implementation (fixed in newer revisions). They work
    fine with Windows, but fail with Linux.
    
    It turns out that they cannot keep an I2C transaction open unless the
    previous read was 16 bytes; shorter reads can only be followed by a zero
    byte transfer ending the I2C transaction.
    
    Copy Windows's behaviour, and read 16 bytes at a time. If we get a short
    reply, assume that there's a hardware bottleneck, and shrink our read size
    to match. For this purpose, use the algorithm in the DisplayPort 1.2 spec,
    in the hopes that it'll be closest to what Windows does.
    
    Also provide an unsafe module parameter for testing smaller transfer sizes,
    in case there are sinks out there that cannot work with Windows.
    
    Note also that despite the previous comment in drm_dp_i2c_xfer, this speeds
    up native DP EDID reads; Ville Syrjälä <ville.syrjala@linux.intel.com> found
    the following changes in his testing:
    
    Device under test:     old  -> with this patch
    DP->DVI (OUI 001cf8):  40ms -> 35ms
    DP->VGA (OUI 0022b9):  45ms -> 38ms
    Zotac DP->2xHDMI:      25ms ->  4ms
    Asus PB278 monitor:    22ms ->  3ms
    
    A back of the envelope calculation shows that peak theoretical transfer rate
    for 1 byte reads is around 60 kbit/s; with 16 byte reads, this increases to
    around 500 kbit/s, which explains the increase in speed.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55228
    Tested-by: Aidan Marks <aidanamarks@gmail.com> (v3)
    Signed-off-by: NSimon Farnsworth <simon.farnsworth@onelan.co.uk>
    Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
    Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
    1d002fa7
drm_dp_helper.c 17.8 KB