summaryrefslogtreecommitdiff
path: root/sound/sound_core.c
diff options
context:
space:
mode:
authorChris Wilson <chris@chris-wilson.co.uk>2010-08-20 08:13:36 (GMT)
committerDave Airlie <airlied@redhat.com>2010-09-06 22:04:11 (GMT)
commite58f637bb96d5a0ae0919b9998b891d1ba7e47c9 (patch)
tree6c6e7d588c284f5fafce4782aad66e29f62359c9 /sound/sound_core.c
parent54bfe496cec7586f76f713a277435dd3ac6fd4c4 (diff)
downloadlinux-fsl-qoriq-e58f637bb96d5a0ae0919b9998b891d1ba7e47c9.tar.xz
drm/kms: Add a module parameter to disable polling
Polling for a VGA device on an old system can be quite expensive, causing latencies on the order of 600ms. As we hold the mode mutex for this time and also need the same mutex to move the cursor, we trigger a user-visible stall. The real solution would involve improving the granulatity of the locking and so perhaps performing some of the probing not under the lock or some other updates can be done under different locks. Also reducing the cost of probing for a non-existent monitor would be worthwhile. However, exposing a parameter to disable polling is a simple workaround in the meantime. In order to accommodate users turning polling on and off at runtime, the polling is potentially re-enabled on every probe. This is coupled to the user calling xrandr, which seems to be a vaild time to reset the polling timeout since the information on the connection has just been updated. (The presumption being that all connections are probed in a single xrandr pass, which is currently valid.) References: Bug 29536 - 2.6.35 causes ~600ms latency every 10s https://bugs.freedesktop.org/show_bug.cgi?id=29536 Bug 16265 - Why is kslowd accumulating so much CPU time? https://bugzilla.kernel.org/show_bug.cgi?id=16265 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reported-and-tested-by: Bruno Prémont <bonbons@linux-vserver.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
Diffstat (limited to 'sound/sound_core.c')
0 files changed, 0 insertions, 0 deletions