1. Dec 14, 2010
  2. Dec 10, 2010
  3. Dec 09, 2010
    • Chris Wilson's avatar
      drm/i915/ringbuffer: Handle wrapping of the autoreported HEAD · 8c0a6bfe
      Chris Wilson authored
      
      
      If the tail advances beyond the autoreport HEAD value, then we need to
      fallback to an uncached read of the HEAD register in order to ascertain
      the correct amount of remaining space in the ringbuffer.
      
      Reported-by: default avatarFang, Xun <xunx.fang@intel.com>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32259
      
      
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      8c0a6bfe
    • David Flynn's avatar
      drm/i915/dp: Fix I2C/EDID handling with active DisplayPort to DVI converter · 8316f337
      David Flynn authored
      
      
      The DisplayPort standard (1.1a) states that:
        The I2C-over-AUX Reply field is valid only when Native AUX CH Reply
        field is AUX_ACK (00). When Native AUX CH Reply field is not 00, then,
        I2C-over-AUX Reply field must be 00 and be ignored.
      
      This fixes broken EDID reading when using an active DisplayPort to
      duallink DVI converter.  If the AUX CH replier chooses to defer the
      transaction, a short read occurs and erroneous data is returned as
      the i2c reply due to a lack of length checking and failure to check
      for AUX ACK.
      
      As a result, broken EDIDs can look like:
           0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
      00: bc bc bc ff bc bc bc ff bc bc bc ac bc bc bc 45    ???.???.???????E
      10: bc bc bc 10 bc bc bc 34 bc bc bc ee bc bc bc 4c    ???????4???????L
      20: bc bc bc 50 bc bc bc 00 bc bc bc 40 bc bc bc 00    ???P???.???@???.
      30: bc bc bc 01 bc bc bc 01 bc bc bc a0 bc bc bc 40    ???????????????@
      40: bc bc bc 00 bc bc bc 00 bc bc bc 00 bc bc bc 55    ???.???.???.???U
      50: bc bc bc 35 bc bc bc 31 bc bc bc 20 bc bc bc fc    ???5???1??? ????
      60: bc bc bc 4c bc bc bc 34 bc bc bc 46 bc bc bc 00    ???L???4???F???.
      70: bc bc bc 38 bc bc bc 11 bc bc bc 20 bc bc bc 20    ???8??????? ???
      80: bc bc bc ff bc bc bc ff bc bc bc ff bc bc bc ff    ???.???.???.???.
      ...
      
      which can lead to:
      [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder
      [drm:drm_edid_block_valid] *ERROR* Raw EDID:
      <3>30 30 30 30 30 30 30 32 38 32 30 32 63 63 31 61  000000028202cc1a
      <3>28 00 02 8c 00 00 00 00 18 00 00 00 00 00 00 00  (...............
      <3>20 4c 61 73 74 20 62 65 61 63 6f 6e 3a 20 33 32   Last beacon: 32
      <3>32 30 6d 73 20 61 67 6f 46 00 05 8c 00 00 00 00  20ms agoF.......
      <3>36 00 00 00 00 00 00 00 00 0c 57 69 2d 46 69 20  6.........Wi-Fi
      <3>52 6f 75 74 65 72 01 08 82 84 8b 96 24 30 48 6c  Router......$0Hl
      <3>03 01 01 06 02 00 00 2a 01 00 2f 01 00 32 04 0c  .......*../..2..
      <3>12 18 60 dd 09 00 10 18 02 00 00 01 00 00 18 00  ..`.............
      
      Signed-off-by: default avatarDavid Flynn <davidf@rd.bbc.co.uk>
      [ickle: fix up some surrounding checkpatch warnings]
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: stable@kernel.org
      8316f337
  4. Dec 08, 2010
  5. Dec 07, 2010
  6. Dec 06, 2010