1. 26 1月, 2018 1 次提交
  2. 27 10月, 2017 1 次提交
  3. 29 9月, 2017 1 次提交
  4. 27 9月, 2017 1 次提交
  5. 18 9月, 2017 1 次提交
  6. 22 8月, 2017 1 次提交
  7. 29 5月, 2017 2 次提交
  8. 26 5月, 2017 1 次提交
  9. 21 4月, 2017 1 次提交
  10. 20 4月, 2017 1 次提交
  11. 07 3月, 2017 2 次提交
  12. 26 1月, 2017 1 次提交
  13. 11 1月, 2017 1 次提交
  14. 26 10月, 2016 1 次提交
  15. 25 10月, 2016 1 次提交
  16. 15 9月, 2016 8 次提交
  17. 03 8月, 2016 1 次提交
  18. 19 7月, 2016 1 次提交
  19. 17 6月, 2016 1 次提交
  20. 12 5月, 2016 1 次提交
  21. 26 4月, 2016 1 次提交
  22. 24 11月, 2015 1 次提交
  23. 02 10月, 2015 1 次提交
  24. 09 9月, 2015 1 次提交
  25. 01 9月, 2015 1 次提交
  26. 21 8月, 2015 1 次提交
  27. 27 7月, 2015 1 次提交
  28. 18 5月, 2015 1 次提交
  29. 12 3月, 2015 1 次提交
    • 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
  30. 10 3月, 2015 2 次提交