1. 29 10月, 2011 1 次提交
  2. 21 10月, 2011 1 次提交
    • A
      i915: Move i915_read/write out of line · f7000883
      Andi Kleen 提交于
      With the tracing code in there they are far too big to inline.
      
      .text savings compared to a non force inline kernel:
      
      i915_restore_display                        4393   12036   +7643
      i915_save_display                           4295   11459   +7164
      i915_handle_error                           2979    6666   +3687
      i915_driver_irq_handler                     2923    5086   +2163
      i915_ringbuffer_info                         458    1661   +1203
      i915_save_vga                                  -    1200   +1200
      i915_driver_irq_uninstall                    453    1624   +1171
      i915_driver_irq_postinstall                  913    2078   +1165
      ironlake_enable_drps                         719    1872   +1153
      i915_restore_vga                               -    1142   +1142
      intel_display_capture_error_state            784    2030   +1246
      intel_init_emon                              719    2016   +1297
      
      and more ...
      
      [AK: these are older numbers, with the new SNB forcewake checks
      it will be even worse]
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Acked-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NKeith Packard <keithp@keithp.com>
      f7000883
  3. 29 9月, 2011 1 次提交
  4. 28 9月, 2011 1 次提交
  5. 22 9月, 2011 1 次提交
  6. 20 9月, 2011 1 次提交
  7. 05 8月, 2011 1 次提交
  8. 04 8月, 2011 1 次提交
  9. 14 7月, 2011 3 次提交
  10. 12 7月, 2011 1 次提交
  11. 09 7月, 2011 1 次提交
  12. 08 7月, 2011 1 次提交
  13. 30 6月, 2011 2 次提交
  14. 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
  15. 18 5月, 2011 2 次提交
  16. 16 5月, 2011 1 次提交
  17. 14 5月, 2011 4 次提交
  18. 11 5月, 2011 1 次提交
  19. 07 3月, 2011 1 次提交
  20. 06 3月, 2011 1 次提交
  21. 22 2月, 2011 1 次提交
  22. 10 2月, 2011 1 次提交
  23. 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
  24. 02 2月, 2011 1 次提交
  25. 01 2月, 2011 1 次提交
  26. 26 1月, 2011 1 次提交
  27. 25 1月, 2011 1 次提交
  28. 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
  29. 19 1月, 2011 1 次提交
  30. 14 1月, 2011 1 次提交
  31. 12 1月, 2011 2 次提交