The order of the calls does matter indeed. Swapping the call order of
intel_dp_destroy() and intel_dp_encoder_destroy() fixes the problem.
This is because i2c_del_adapter unregisters the device which parent is
intel_connector, and connectors are removed in intel_dp_destroy(). Thus
intel_dp_encoder_destroy() must be called before intel_dp_destroy().
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=24822
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Keith Packard <keithp@keithp.com>
... even though it was disabled. A mistake in the handling of fence reuse
caused us to skip the vital delay of waiting for the object to finish
rendering before changing the register. This resulted in us changing the
fence register whilst the bo was active and so causing the blits to
complete using the wrong stride or even the wrong tiling. (Visually the
effect is that small blocks of the screen look like they have been
interlaced). The fix is to wait for the GPU to finish using the memory
region pointed to by the fence before changing it.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34584
Cc: Andy Whitcroft <apw@canonical.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[Note for 2.6.38-stable, we need to reintroduce the interruptible passing]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Dave Airlie <airlied@linux.ie>
A broken implementation of is_pot() prevented the detection of when a
singular pipe was enabled. Eric Anholt pointed out the existence of
is_power_of_2() so use that instead of our broken code!
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35402
Signed-off-by: Yuanhan Liu <yuanhan.liu@intel.com>
Tested-by: xunx.fang@intel.com
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When i915_gem_retire_requests_ring calls i915_gem_request_remove_from_client,
the client_list for that request may already be removed in i915_gem_release.
So we may call twice list_del(&request->client_list), resulting in an
oops like this report:
[126167.230394] BUG: unable to handle kernel paging request at 00100104
[126167.230699] IP: [<f8c2ce44>] i915_gem_retire_requests_ring+0xd4/0x240 [i915]
[126167.231042] *pdpt = 00000000314c1001 *pde = 0000000000000000
[126167.231314] Oops: 0002 [#1] SMP
[126167.231471] last sysfs file: /sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT1/current_now
[126167.231901] Modules linked in: snd_seq_dummy nls_utf8 isofs btrfs zlib_deflate libcrc32c ufs qnx4 hfsplus hfs minix ntfs vfat msdos fat jfs xfs exportfs reiserfs cryptd aes_i586 aes_generic binfmt_misc vboxnetadp vboxnetflt vboxdrv parport_pc ppdev snd_hda_codec_hdmi snd_hda_codec_conexant snd_hda_intel snd_hda_codec snd_hwdep arc4 snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq uvcvideo videodev snd_timer snd_seq_device joydev iwlagn iwlcore mac80211 snd cfg80211 soundcore i915 drm_kms_helper snd_page_alloc psmouse drm serio_raw i2c_algo_bit video lp parport usbhid hid sky2 sdhci_pci ahci sdhci libahci
[126167.232018]
[126167.232018] Pid: 1101, comm: Xorg Not tainted 2.6.38-6-generic-pae #34-Ubuntu Gateway MC7833U /
[126167.232018] EIP: 0060:[<f8c2ce44>] EFLAGS: 00213246 CPU: 0
[126167.232018] EIP is at i915_gem_retire_requests_ring+0xd4/0x240 [i915]
[126167.232018] EAX: 00200200 EBX: f1ac25b0 ECX: 00000040 EDX: 00100100
[126167.232018] ESI: f1a2801c EDI: e87fc060 EBP: ef4d7dd8 ESP: ef4d7db0
[126167.232018] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[126167.232018] Process Xorg (pid: 1101, ti=ef4d6000 task=f1ba6500 task.ti=ef4d6000)
[126167.232018] Stack:
[126167.232018] f1a28000 f1a2809c f1a28094 0058bd97 f1aa2400 f1a2801c 0058bd7b 0058bd85
[126167.232018] f1a2801c f1a28000 ef4d7e38 f8c2e995 ef4d7e30 ef4d7e60 c14d1ebc f6b3a040
[126167.232018] f1522cc0 000000db 00000000 f1ba6500 ffffffa1 00000000 00000001 f1a29214
[126167.232018] Call Trace:
Unfortunately the call trace reported was cut, but looking at debug
symbols the crash is at __list_del, when probably list_del is called
twice on the same request->client_list, as the dereferenced value is
LIST_POISON1 + 4, and by looking more at the debug symbols before
list_del call it should have being called by
i915_gem_request_remove_from_client
And as I can see in the code, it seems we indeed have the possibility
to remove a request->client_list twice, which would cause the above,
because we do list_del(&request->client_list) on both
i915_gem_request_remove_from_client and i915_gem_release
As Chris Wilson pointed out, it's indeed the case:
"(...) I had thought that the actual insertion/deletion was serialised
under the struct mutex and the intention of the spinlock was to protect
the unlocked list traversal during throttling. However, I missed that
i915_gem_release() is also called without struct mutex and so we do need
the double check for i915_gem_request_remove_from_client()."
This change does the required check to avoid the duplicate remove of
request->client_list.
Bugzilla: http://bugs.launchpad.net/bugs/733780
Cc: stable@kernel.org # 2.6.38
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the pipe or plane is already enabled, then we do not need to enable
it again and can skip the delay. Similarly if it is already disabled
when we want to disable it, we can also skip it.
This fixes a regression from b24e717988, which caused the LVDS
output on one PineView machine to become corrupt after changing
orientation several times.
References: https://bugs.freedesktop.org/show_bug.cgi?id=34601
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Keith Packard <keithp@keithp.com>
Tested-by: mengmeng.meng@intel.com
... as wait_for_vblank (and friends) will do a flush of the MMIO writes
anyway.
References: https://bugs.freedesktop.org/show_bug.cgi?id=34601
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
This commit changed an internal radeon structure, that meant a new driver
in -next had to be fixed up, merge in the commit and fix up the driver.
Also fixes a trivial nouveau merge.
Conflicts:
drivers/gpu/drm/nouveau/nouveau_mem.c
At least on my HP 2540p this is wrong at bootup, fine
at any other time once a lid event has occured. This is due to
_REG vs _INI ordering in the ACPI tables.
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'intel/drm-intel-next' of ../drm-next: (755 commits)
drm/i915: Only wait on a pending flip if we intend to write to the buffer
drm/i915/dp: Sanity check eDP existence
drm/i915: Rebind the buffer if its alignment constraints changes with tiling
drm/i915: Disable GPU semaphores by default
drm/i915: Do not overflow the MMADDR write FIFO
Revert "drm/i915: fix corruptions on i8xx due to relaxed fencing"
drm/i915: Don't save/restore hardware status page address register
drm/i915: don't store the reg value for HWS_PGA
drm/i915: fix memory corruption with GM965 and >4GB RAM
Linux 2.6.38-rc7
Revert "TPM: Long default timeout fix"
drm/i915: Re-enable GPU semaphores for SandyBridge mobile
drm/i915: Replace vblank PM QoS with "Interrupt-Based AGPBUSY#"
Revert "drm/i915: Use PM QoS to prevent C-State starvation of gen3 GPU"
drm/i915: Allow relocation deltas outside of target bo
drm/i915: Silence an innocuous compiler warning for an unused variable
fs/block_dev.c: fix new kernel-doc warning
ACPI: Fix build for CONFIG_NET unset
mm: <asm-generic/pgtable.h> must include <linux/mm_types.h>
x86: Use u32 instead of long to set reset vector back to 0
...
Conflicts:
drivers/gpu/drm/i915/i915_gem.c
This reverts commit 951f3512db
drm/i915: Do not handle backlight combination mode specially
since this commit introduced other regressions due to untouched LBPC
register, e.g. the backlight dimmed after resume.
In addition to the revert, this patch includes a fix for the original
issue (weird backlight levels) by removing the wrong bit shift for
computing the current backlight level.
Also, including typo fixes (lpbc -> lbpc).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34524
Acked-by: Indan Zupancic <indan@nul.nu>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: <stable@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Some hardware claims to have both an LVDS panel and an eDP output.
Whilst this may be true in a rare case, more often it is just broken
hardware. If we see an eDP device we know that it must be connected and
so we can confirm its existence with a simple probe.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34165
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=24822
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Early gen3 and gen2 chipset do not have the relaxed per-surface tiling
constraints of the later chipsets, so we need to check that the GTT
alignment is correct for the new tiling. If it is not, we need to
rebind.
Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Andi Kleen narrowed his GPU hangs on his Sugar Bay (SNB desktop) rev 09
down to the use of GPU semaphores, and we already know that they appear
broken up to Huron River (mobile) rev 08. (I'm optimistic that disabling
GPU semaphores is simply hiding another bug by the latency and
side-effects of the additional device interaction it introduces...)
However, use of semaphores is a massive performance improvement... Only
as long as the system remains stable. Enable at your peril.
Reported-by: Andi Kleen <andi-fd@firstfloor.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33921
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Whilst the GT is powered down (rc6), writes to MMADDR are placed in a
FIFO by the System Agent. This is a limited resource, only 64 entries, of
which 20 are reserved for Display and PCH writes, and so we must take
care not to queue up too many writes. To avoid this, there is counter
which we can poll to ensure there are sufficient free entries in the
fifo.
"Issuing a write to a full FIFO is not supported; at worst it could
result in corruption or a system hang."
Reported-and-Tested-by: Matt Turner <mattst88@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34056
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This reverts commit c2e0eb1670.
As it turns out, userspace already depends upon being able to enable
tiling on existing bo which it promises to be large enough for its
purposes i.e. it will not access beyond the end of the last full-tile
row.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35016
Reported-and-tested-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
It's cleaned before saving and re-initialized after restoring.
So don't need to save/restore it. And also new chip has new address
for hardware status page register, don't write to old address.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
On a Thinkpad x61s, I noticed some memory corruption when
plugging/unplugging the external VGA connection. The symptoms are that
4 bytes at the beginning of a page get overwritten by zeroes.
The address of the corruption varies when rebooting the machine, but
stays constant while it's running (so it's possible to repeatedly write
some data and then corrupt it again by plugging the cable).
Further investigation revealed that the corrupted address is
(dev_priv->status_page_dmah->busaddr & 0xffffffff), ie. the beginning of
the hardware status page of the i965 graphics card, cut to 32 bits.
So it seems that for some memory access, the hardware uses only 32 bit
addressing. If the hardware status page is located >4GB, this
corrupts unrelated memory.
Signed-off-by: Jan Niehusmann <jan@gondor.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
This seems to be running stably on my test laptop, so hopefully the
reported hangs where just symptoms of other bugs.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
I stumbled over this magic bit in the gen3 INSTPM:
Bit11 Interrupt-Based AGPBUSY# Enable:
‘0’ = Pending GMCH interrupts will not cause AGPBUSY# assertion.
‘1’ = Pending GMCH interrupts will cause AGPBUSY# assertion and hence
can cause the CPU to exit C3. There is no suppression of cacheable
writes.
Note that in either case in C3 the interrupts are not lost. They will be
forwarded to the ICH when the GMCH is out of C3.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@kernel.org
Using PM latency request turns out to be very fragile and only works for
some systems, depending upon the ACPI implementation. However, I've
stumbled across a promising bit in INSTPM: "Interrupt-Based AGPBUSY#".
This reverts commit b0b544cd37.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Userspace has a legitimate requirement to use a delta that points to
outside of the target bo, and so we need to enable this. (As this is an
abi break, albeit a relaxation of the current restrictions, mark the change
with a new flag.)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
drivers/gpu/drm/i915/i915_irq.c: In function ‘ironlake_irq_postinstall’:
drivers/gpu/drm/i915/i915_irq.c:1618: warning: unused variable ‘pipe’
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
After disabling, we're meant to teardown the bo used for the contexts,
not recurse into ourselves again and preventing module unload.
Reported-and-tested-by: Ben Widawsky <bwidawsk@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
It looks like gen2 has a peculiar interleaved 2-row inter-tile
layout. Probably inherited from i81x which had 2kb tiles (which
naturally fit an even-number-of-tile-rows scheme to fit onto 4kb
pages). There is no other mention of this in any docs (also not
in the Intel internal documention according to Chris Wilson).
Problem manifests itself in corruptions in the second half of the
last tile row (if the bo has an odd number of tiles). Which can
only happen with relaxed tiling (introduced in a00b10c360).
So reject set_tiling calls that don't satisfy this constrain to
prevent broken userspace from causing havoc. While at it, also
check the size for newer chipsets.
LKML: https://lkml.org/lkml/2011/2/19/5
Reported-by: Indan Zupancic <indan@nul.nu>
Tested-by: Indan Zupancic <indan@nul.nu>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
... and fixup some methods to accept the constant argument.
Now that constant module arrays are loaded into read-only memory, using
const appropriately has some benefits beyond warning the programmer
about likely mistakes.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Merge in the conflicting eDP fix.
Conflicts:
drivers/gpu/drm/i915/i915_irq.c
drivers/gpu/drm/i915/intel_display.c
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to prevent "crushed blacks" on TVs, the range of the RGB output
may be limited to 16-235. This used to be available through Xorg under
the "Broadcast RGB" option, so reintroduce support for KMS.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34543
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The code paths for modesetting are growing in complexity as we may need
to move the buffers around in order to fit the scanout in the aperture.
Therefore we face a choice as to whether to thread the interruptible status
through the entire pinning and unbinding code paths or to add a flag to
the device when we may not be interrupted by a signal. This does the
latter and so fixes a few instances of modesetting failures under stress.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we just need a temporary array whilst performing the relocations for
the execbuffer, first attempt to allocate using kmalloc even if it is
not of order page-0. This avoids the overhead of remapping the
discontiguous array and so gives a moderate boost to execution
throughput.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Seems like we are forever to be cursed with buggy firmware, so allow the
user to explicitly set the panel connection status.
Of secondary utility for cases where I run laptops with the lid closed,
but still want to configure the LVDS.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Dave Airlie spotted that we had a potential bug should we ever rearrange
the drm_i915_gem_object so not the base drm_gem_object was not its first
member. He noticed that we often convert the return of
drm_gem_object_lookup() immediately into drm_i915_gem_object and then
check the result for nullity. This is only valid when the base object is
the first member and so the superobject has the same address. Play safe
instead and use the compiler to convert back to the original return
address for sanity testing.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In a few places I replaced reads of per-pipe registers with the actual
register offsets themselves (converting I915_READ(reg) to _PIPE(reg)).
Alexey caught this on his 9xx machine because the cursor control write
was affected. A quick audit showed a few more places where I'd borked
a read, so here's a patch to fix things up.
Reported-by: Alexey Fisher <bug-track@fisher-privat.net>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[ickle: compilation fix]
Tested-by: Alexey Fisher <bug-track@fisher-privat.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This reverts commit 633f2ea266 and the
attempted fix dcbe6f2b3d.
There is a single clock source used for both SSC (some LVDS and DP) and
non-SSC (VGA, DVI) outputs. So we need to be careful to only enable SSC
as necessary. However, fiddling with DREFCLK was causing DP links to be
dropped and we do not have a fix ready, so revert.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
eDP on the CPU doesn't need the PCH set up at all, it can in fact cause
problems. So avoid FDI training and PCH PLL enabling in that case.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We can enable some safely, but FDI and transcoder interrupts can occur
and block other interrupts from being detected (like port hotplug
events). So keep them disabled by default (they can be re-enabled for
debugging display bringup, but should generally be off).
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the gpu is hung, then whatever was inside the render cache is lost
and there is little point waiting for it. Or complaining if we see an
EIO or EAGAIN instead. So, if the GPU is indeed in its death throes when
we need to rewrite the registers for a new framebuffer, just ignore the
error and proceed with the update.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The current code does not follow Intel documentation: It misses some things
and does other, undocumented things. This causes wrong backlight values in
certain conditions. Instead of adding tricky code handling badly documented
and rare corner cases, don't handle combination mode specially at all. This
way PCI_LBPC is never touched and weird things shouldn't happen.
If combination mode is enabled, then the only downside is that changing the
brightness has a greater granularity (the LBPC value), but LBPC is at most
254 and the maximum is in the thousands, so this is no real functional loss.
A potential problem with not handling combined mode is that a brightness of
max * PCI_LBPC is not bright enough. However, this is very unlikely because
from the documentation LBPC seems to act as a scaling factor and doesn't look
like it's supposed to be changed after boot. The value at boot should always
result in a bright enough screen.
IMPORTANT: However, although usually the above is true, it may not be when
people ran an older (2.6.37) kernel which messed up the LBPC register, and
they are unlucky enough to have a BIOS that saves and restores the LBPC value.
Then a good kernel may seem to not work: Max brightness isn't bright enough.
If this happens people should boot back into the old kernel, set brightness
to the maximum, and then reboot. After that everything should be fine.
For more information see the below links. This fixes bugs:
http://bugzilla.kernel.org/show_bug.cgi?id=23472http://bugzilla.kernel.org/show_bug.cgi?id=25072
Signed-off-by: Indan Zupancic <indan@nul.nu>
Tested-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Grab the latest stabilisation bits from -fixes and some suspend and
resume fixes from linus.
Conflicts:
drivers/gpu/drm/i915/i915_drv.h
drivers/gpu/drm/i915/i915_irq.c
Share the lid detection code for the all panels for consistent behaviour
and a single place to add the eventual quirks for crap hardware.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We can enable some safely, but FDI and transcoder interrupts can occur
and block other interrupts from being detected (like port hotplug
events). So keep them disabled by default (they can be re-enabled for
debugging display bringup, but should generally be off).
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If the gpu is hung, then whatever was inside the render cache is lost
and there is little point waiting for it. Or complaining if we see an
EIO or EAGAIN instead. So, if the GPU is indeed in its death throes when
we need to rewrite the registers for a new framebuffer, just ignore the
error and proceed with the update.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Disable any PCH ports associated with a pipe when disabling it. This
should prevent transcoder disable failures due to ports still being on.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[ickle: introduce *_PIPE_ENABLED() macro]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
... so we handle that for i915_gem_fault() in the same manner as
ERESTARTSYS, or we send a SIGBUS to the faulting application.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The irony of the patch to fix the resume regression on PineView causing
a further regression on Ironlake is not lost on me.
Reported-by: Jeff Chua <jeff.chua.linux@gmail.com>
Reported-by: Björn Schließmann <chronoss@gmx.de>
Tested-by: Björn Schließmann <chronoss@gmx.de>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=28802
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The documentation recommends that we should use a polling method for TV
detection as this is more power efficient than the interrupt based
mechanism (as the encoder can be completely switched off). A secondary
effect is that leaving the hotplug enabled seems to be causing pipe
underruns as reported by Hugh Dickins on his Crestline.
Tested-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[This is a candidate for stable, but needs minor porting to 2.6.37]
