1. 04 Mar, 2011 1 commit
  2. 01 Mar, 2011 1 commit
    • Jan Niehusmann's avatar
      drm/i915: fix memory corruption with GM965 and >4GB RAM · 6927faf3
      Jan Niehusmann authored
      
      
      On a Thinkpad x61s, I noticed some memory corruption when
      plugging/unplugging the external VGA connection. The symptoms are that
      4 bytes at the beginning of a page get overwritten by zeroes.
      The address of the corruption varies when rebooting the machine, but
      stays constant while it's running (so it's possible to repeatedly write
      some data and then corrupt it again by plugging the cable).
      
      Further investigation revealed that the corrupted address is
      (dev_priv->status_page_dmah->busaddr & 0xffffffff), ie. the beginning of
      the hardware status page of the i965 graphics card, cut to 32 bits.
      
      So it seems that for some memory access, the hardware uses only 32 bit
      addressing. If the hardware status page is located >4GB, this
      corrupts unrelated memory.
      Signed-off-by: default avatarJan Niehusmann <jan@gondor.com>
      Acked-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: stable@kernel.org
      6927faf3
  3. 28 Feb, 2011 2 commits
  4. 24 Feb, 2011 2 commits
  5. 23 Feb, 2011 7 commits
  6. 22 Feb, 2011 3 commits
  7. 21 Feb, 2011 1 commit
    • Indan Zupancic's avatar
      drm/i915: Do not handle backlight combination mode specially · 951f3512
      Indan Zupancic authored
      The current code does not follow Intel documentation: It misses some things
      and does other, undocumented things. This causes wrong backlight values in
      certain conditions. Instead of adding tricky code handling badly documented
      and rare corner cases, don't handle combination mode specially at all. This
      way PCI_LBPC is never touched and weird things shouldn't happen.
      
      If combination mode is enabled, then the only downside is that changing the
      brightness has a greater granularity (the LBPC value), but LBPC is at most
      254 and the maximum is in the thousands, so this is no real functional loss.
      
      A potential problem with not handling combined mode is that a brightness of
      max * PCI_LBPC is not bright enough. However, this is very unlikely because
      from the documentation LBPC seems to act as a scaling factor and doesn't look
      like it's supposed to be changed after boot. The value at boot should always
      result in a bright enough screen.
      
      IMPORTANT: However, although usually the above is true, it may not be when
      people ran an older (2.6.37) kernel which messed up the LBPC register, and
      they are unlucky enough to have a BIOS that saves and restores the LBPC value.
      Then a good kernel may seem to not work: Max brightness isn't bright enough.
      If this happens people should boot back into the old kernel, set brightness
      to the maximum, and then reboot. After that everything should be fine.
      
      For more information see the below links. This fixes bugs:
      
        http://bugzilla.kernel.org/show_bug.cgi?id=23472
        http://bugzilla.kernel.org/show_bug.cgi?id=25072
      
      Signed-off-by: default avatarIndan Zupancic <indan@nul.nu>
      Tested-by: default avatarAlex Riesen <raa.lkml@gmail.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      951f3512
  8. 17 Feb, 2011 3 commits
  9. 16 Feb, 2011 6 commits
  10. 14 Feb, 2011 10 commits
  11. 13 Feb, 2011 4 commits