1. 16 5月, 2011 1 次提交
    • C
      drm: Take lock around probes for drm_fb_helper_hotplug_event · 752d2635
      Chris Wilson 提交于
      We need to hold the dev->mode_config.mutex whilst detecting the output
      status. But we also need to drop it for the call into
      drm_fb_helper_single_fb_probe(), which indirectly acquires the lock when
      attaching the fbcon.
      
      Failure to do so exposes a race with normal output probing. Detected by
      adding some warnings that the mutex is held to the backend detect routines:
      
      [   17.772456] WARNING: at drivers/gpu/drm/i915/intel_crt.c:471 intel_crt_detect+0x3e/0x373 [i915]()
      [   17.772458] Hardware name: Latitude E6400
      [   17.772460] Modules linked in: ....
      [   17.772582] Pid: 11, comm: kworker/0:1 Tainted: G        W 2.6.38.4-custom.2 #8
      [   17.772584] Call Trace:
      [   17.772591]  [<ffffffff81046af5>] ? warn_slowpath_common+0x78/0x8c
      [   17.772603]  [<ffffffffa03f3e5c>] ? intel_crt_detect+0x3e/0x373 [i915]
      [   17.772612]  [<ffffffffa0355d49>] ?  drm_helper_probe_single_connector_modes+0xbf/0x2af [drm_kms_helper]
      [   17.772619]  [<ffffffffa03534d5>] ?  drm_fb_helper_probe_connector_modes+0x39/0x4d [drm_kms_helper]
      [   17.772625]  [<ffffffffa0354760>] ?  drm_fb_helper_hotplug_event+0xa5/0xc3 [drm_kms_helper]
      [   17.772633]  [<ffffffffa035577f>] ? output_poll_execute+0x146/0x17c [drm_kms_helper]
      [   17.772638]  [<ffffffff81193c01>] ? cfq_init_queue+0x247/0x345
      [   17.772644]  [<ffffffffa0355639>] ? output_poll_execute+0x0/0x17c [drm_kms_helper]
      [   17.772648]  [<ffffffff8105b540>] ? process_one_work+0x193/0x28e
      [   17.772652]  [<ffffffff8105c6bc>] ? worker_thread+0xef/0x172
      [   17.772655]  [<ffffffff8105c5cd>] ? worker_thread+0x0/0x172
      [   17.772658]  [<ffffffff8105c5cd>] ? worker_thread+0x0/0x172
      [   17.772663]  [<ffffffff8105f767>] ? kthread+0x7a/0x82
      [   17.772668]  [<ffffffff8100a724>] ? kernel_thread_helper+0x4/0x10
      [   17.772671]  [<ffffffff8105f6ed>] ? kthread+0x0/0x82
      [   17.772674]  [<ffffffff8100a720>] ? kernel_thread_helper+0x0/0x10
      Reported-by: NFrederik Himpe <fhimpe@telenet.be>
      References: https://bugs.freedesktop.org/show_bug.cgi?id=36394Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      752d2635
  2. 09 5月, 2011 1 次提交
  3. 04 5月, 2011 2 次提交
  4. 27 4月, 2011 2 次提交
  5. 05 4月, 2011 2 次提交
  6. 01 4月, 2011 1 次提交
  7. 31 3月, 2011 1 次提交
  8. 24 3月, 2011 1 次提交
  9. 21 3月, 2011 1 次提交
  10. 04 3月, 2011 2 次提交
  11. 03 3月, 2011 1 次提交
  12. 02 3月, 2011 1 次提交
  13. 01 3月, 2011 1 次提交
  14. 28 2月, 2011 1 次提交
  15. 25 2月, 2011 1 次提交
  16. 23 2月, 2011 8 次提交
  17. 07 2月, 2011 4 次提交
    • D
      drm: add usb framework · a250b9fd
      Dave Airlie 提交于
      This adds an initial framework to plug USB graphics devices
      into the drm/kms subsystem.
      
      I've started writing a displaylink driver using this interface.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      a250b9fd
    • 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
    • A
      drm: remove i830 driver · 7f506847
      Arnd Bergmann 提交于
      This driver is one of the last users of the big kernel
      lock, which is going away. All the hardware supported
      by this driver also works with the newer i915 driver,
      and recent X.org releases only work with that driver
      anyway.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: dri-devel@lists.freedesktop.org
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      7f506847
  18. 02 2月, 2011 1 次提交
  19. 31 1月, 2011 1 次提交
    • C
      drm/i915: Suppress spurious vblank interrupts · 78c6e170
      Chris Wilson 提交于
      Hugh Dickins found that characters in xterm were going missing and oft
      delayed. Being the curious type, he managed to associate this with the
      new high-precision vblank patches; disabling these he found, restored
      the orderliness of his characters.
      
      The oddness begins when one realised that Hugh was not using vblanks at
      all on his system (fvwm and some xterms). Instead, all he had to go on
      were warning of a pipe underrun, curiously enough at around 60Hz. He
      poked and found that in addition to the underrun warning, the hardware
      was flagging the start of a new frame, a vblank, which in turn was
      kicking off the pending vblank processing code.
      
      There is little we can do for the underruns on Hugh's machine, a
      Crestline [965GM], which must have its FIFO watermarks set to 8.
      However, we do not need to process the vblank if we know that they are
      disabled...
      Reported-by: NHugh Dickins <hughd@google.com>
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      78c6e170
  20. 28 1月, 2011 2 次提交
  21. 26 1月, 2011 1 次提交
  22. 25 1月, 2011 1 次提交
  23. 15 1月, 2011 1 次提交
  24. 07 1月, 2011 2 次提交