Skip to content

L
linux
An error occurred fetching the project authors.
Switch branch/tag
  1. 15 Aug, 2011 1 commit
  3. 28 Jul, 2011 1 commit
  5. 25 Jul, 2011 1 commit
    • Keith Packard's avatar
      drm/i915: Hold mode_config->mutex during hotplug processing · a65e34c7
      Keith Packard authored 
      Hotplug detection is a mode setting operation and must hold the
struct_mutex or risk colliding with other mode setting operations.

In particular, the display port hotplug function attempts to re-train
the link if the monitor is supposed to be running when plugged back
in. If that happens while mode setting is underway, the link will get
scrambled, leaving it in an inconsistent state.

This is a special case -- usually the driver mode setting entry points
are covered by the upper level DRM code, but in this case the function
is invoked as a work function not under the control of DRM.
Signed-off-by: default avatarKeith Packard <keithp@keithp.com>
Cc: stable@kernel.org
Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      a65e34c7
  7. 01 Jul, 2011 1 commit
  9. 30 Jun, 2011 1 commit
  11. 29 Jun, 2011 1 commit
  13. 21 Jun, 2011 1 commit
  15. 17 Jun, 2011 1 commit
    • Daniel J Blueman's avatar
      drm/i915: Fix gen6 (SNB) missed BLT ring interrupts. · 498e720b
      Daniel J Blueman authored 
      The failure appeared in dmesg as:

[drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt
ring idle [waiting on 35064155, at 35064155], missed IRQ?

This works around that problem on by making the blitter command
streamer write interrupt state to the Hardware Status Page when a
MI_USER_INTERRUPT command is decoded, which appears to force the seqno
out to memory before the interrupt happens.

v1->v2: Moved to prior interrupt handler installation and RMW flags as
per feedback.
v2->v3: Removed RMW of flags (by anholt)

Cc: stable@kernel.org
Signed-off-by: default avatarDaniel J Blueman <daniel.blueman@gmail.com>
Signed-off-by: default avatarEric Anholt <eric@anholt.net>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk> [v1]
Tested-by: Eric Anholt <eric@anholt.net> [v1,v3]
	   (incidence of the bug with a testcase went from avg 2/1000 to
	   0/12651 in the latest test run (plus more for v1))
Tested-by: Kenneth Graunke <kenneth@whitecape.org> [v1]
Tested-by: Robert Hooker <robert.hooker@canonical.com> [v1]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33394Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      498e720b
  17. 04 Jun, 2011 1 commit
  19. 18 May, 2011 1 commit
  21. 14 May, 2011 3 commits
  23. 10 May, 2011 4 commits
  25. 01 Mar, 2011 3 commits
  27. 22 Feb, 2011 1 commit
  29. 16 Feb, 2011 1 commit
  31. 07 Feb, 2011 3 commits
  33. 31 Jan, 2011 1 commit
    • Chris Wilson's avatar
      drm/i915: Suppress spurious vblank interrupts · 78c6e170
      Chris Wilson authored 
      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: default avatarHugh Dickins <hughd@google.com>
Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      78c6e170
  35. 28 Jan, 2011 1 commit
  37. 24 Jan, 2011 3 commits
  39. 23 Jan, 2011 1 commit
  41. 20 Jan, 2011 1 commit
  43. 19 Jan, 2011 1 commit
    • Chris Wilson's avatar
      drm/i915: Use PM QoS to prevent C-State starvation of gen3 GPU · b0b544cd
      Chris Wilson authored 
      945 class hardware has an interesting quirk in which the vblank
interrupt is not raised if the CPU is in a low power state. (We also
suspect that the memory bus is clocked to the CPU/c-state and not the
GPU so there are secondary starvation issues.) In order to prevent the
most obvious issue of the low of the vblank interrupt (stuttering
compositing that only updates when the mouse is moving) is to install a
PM QoS request to prevent low c-states whilst the GPU is active.
Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      b0b544cd
  45. 13 Jan, 2011 1 commit
  47. 11 Jan, 2011 5 commits
  49. 18 Dec, 2010 1 commit
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7