1. 29 9月, 2011 1 次提交
  2. 28 9月, 2011 1 次提交
  3. 22 9月, 2011 1 次提交
  4. 20 9月, 2011 1 次提交
  5. 05 8月, 2011 1 次提交
  6. 04 8月, 2011 1 次提交
  7. 14 7月, 2011 3 次提交
  8. 12 7月, 2011 1 次提交
  9. 09 7月, 2011 1 次提交
  10. 08 7月, 2011 1 次提交
  11. 30 6月, 2011 2 次提交
  12. 29 6月, 2011 1 次提交
    • B
      drm/i915: forcewake fix after reset · 25732821
      Ben Widawsky 提交于
      The failure is as follows:
      
      1. Userspace gets forcewake lock, lock count >=1
      2. GPU hang/reset occurs (forcewake bit is reset)
      3. count is now incorrect
      
      The failure can only occur when using the forcewake userspace lock.
      
      This has the unfortunate consequence of messing up the driver as well as
      userspace, unless userspace closes the debugfs file, the kernel will
      never end up waking the GT since the refcount will be > 1.
      
      The solution is to try to recover the correct forcewake state based on
      the refcount. There is a period of time where userspace reads/writes may
      occur after the reset, before the GT has been forcewaked. The interface
      was never designed to be a perfect solution for userspace reads/writes,
      and the kernel portion is fixed by this patch.
      Suggested-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NKeith Packard <keithp@keithp.com>
      25732821
  13. 18 5月, 2011 2 次提交
  14. 16 5月, 2011 1 次提交
  15. 14 5月, 2011 4 次提交
  16. 11 5月, 2011 1 次提交
  17. 07 3月, 2011 1 次提交
  18. 06 3月, 2011 1 次提交
  19. 22 2月, 2011 1 次提交
  20. 10 2月, 2011 1 次提交
  21. 07 2月, 2011 2 次提交
    • D
      drm: rework PCI/platform driver interface. · 8410ea3b
      Dave Airlie 提交于
      This abstracts the pci/platform interface out a step further,
      we can go further but this is far enough for now to allow USB
      to be plugged in.
      
      The drivers now just call the init code directly for their
      device type.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      8410ea3b
    • D
      drm: dumb scanout create/mmap for intel/radeon (v3) · ff72145b
      Dave Airlie 提交于
      This is just an idea that might or might not be a good idea,
      it basically adds two ioctls to create a dumb and map a dumb buffer
      suitable for scanout. The handle can be passed to the KMS ioctls to create
      a framebuffer.
      
      It looks to me like it would be useful in the following cases:
      a) in development drivers - we can always provide a shadowfb fallback.
      b) libkms users - we can clean up libkms a lot and avoid linking
      to libdrm_*.
      c) plymouth via libkms is a lot easier.
      
      Userspace bits would be just calls + mmaps. We could probably
      mark these handles somehow as not being suitable for acceleartion
      so as top stop people who are dumber than dumb.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      ff72145b
  22. 02 2月, 2011 1 次提交
  23. 01 2月, 2011 1 次提交
  24. 26 1月, 2011 1 次提交
  25. 25 1月, 2011 1 次提交
  26. 23 1月, 2011 1 次提交
    • C
      drm/i915: Recognise non-VGA display devices · 934f992c
      Chris Wilson 提交于
      Starting with SandyBridge (though possible with earlier hacked BIOSes),
      the BIOS may initialise the IGFX as secondary to a discrete GPU. Prior,
      it would simply disable the integrated GPU. So we adjust our PCI class
      mask to match any DISPLAY_CLASS device.
      
      In such a configuration, the IGFX is not a primary VGA controller and
      so should not take part in VGA arbitration, and the error return from
      vga_client_register() is expected.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: stable@kernel.org
      934f992c
  27. 19 1月, 2011 1 次提交
  28. 14 1月, 2011 1 次提交
  29. 12 1月, 2011 3 次提交
  30. 05 1月, 2011 1 次提交