1. 18 12月, 2010 1 次提交
  2. 17 12月, 2010 5 次提交
  3. 16 12月, 2010 6 次提交
  4. 15 12月, 2010 5 次提交
  5. 14 12月, 2010 4 次提交
  6. 10 12月, 2010 10 次提交
  7. 09 12月, 2010 2 次提交
    • C
      drm/i915/ringbuffer: Handle wrapping of the autoreported HEAD · 8c0a6bfe
      Chris Wilson 提交于
      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: NFang, Xun <xunx.fang@intel.com>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32259Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      8c0a6bfe
    • D
      drm/i915/dp: Fix I2C/EDID handling with active DisplayPort to DVI converter · 8316f337
      David Flynn 提交于
      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: NDavid Flynn <davidf@rd.bbc.co.uk>
      [ickle: fix up some surrounding checkpatch warnings]
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: stable@kernel.org
      8316f337
  8. 08 12月, 2010 7 次提交