And if not, complain loudly. None in-kernel module should trigger
that, but let us find out for sure. On the other hand, all the
out-of-tree modules will hit that. Give them some time (maybe one
release) to catch up.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If P2M leaf is completly packed with INVALID_P2M_ENTRY or with
1:1 PFNs (so IDENTITY_FRAME type PFNs), we can swap the P2M leaf
with either a p2m_missing or p2m_identity respectively. The old
page (which was created via extend_brk or was grafted on from the
mfn_list) can be re-used for setting new PFNs.
This also means we can remove git commit:
5bc6f9888d
xen/p2m: Reserve 8MB of _brk space for P2M leafs when populating back
which tried to fix this.
and make the amount that is required to be reserved much smaller.
CC: stable@vger.kernel.org # for 3.5 only.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Commit 8aeb00ff85: "ext4: fix overhead calculation used by
ext4_statfs()" introduced a O(n**2) calculation which makes very large
file systems take forever to mount. Fix this with an optimization for
non-bigalloc file systems. (For bigalloc file systems the overhead
needs to be set in the the superblock.)
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: stable@vger.kernel.org
While in ext4_validate_block_bitmap(), if an block allocation bitmap
is found to be invalid, we call ext4_error() while the block group is
still locked. This causes ext4_commit_super() to call a function
which might sleep while in an atomic context.
There's no need to keep the block group locked at this point, so hoist
the ext4_error() call up to ext4_validate_block_bitmap() and release
the block group spinlock before calling ext4_error().
The reported stack trace can be found at:
http://article.gmane.org/gmane.comp.file-systems.ext4/33731
Reported-by: Dave Jones <davej@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: stable@vger.kernel.org
page_get_cache() isn't called from anything, so remove it.
Signed-off-by: David Rientjes <rientjes@google.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
The series removes bunch of dssdev references from the omapdss output drivers.
This is made to let us move to a common panel framework later, and also allows
us to implement OMAP's writeback support, which has been proven difficult with
the current output drivers.
OMAPDSS: APPLY: Constify timings argument in dss_mgr_set_timings
OMAPDSS: DPI: Add locking for DPI interface
OMAPDSS: Displays: Add locking in generic DPI panel driver
OMAPDSS: DPI: Maintain our own timings field in driver data
OMAPDSS: DPI displays: Take care of panel timings in the driver itself
OMAPDSS: DSI: Maintain own copy of timings in driver data
OMAPDSS: DSI: Add function to set panel size for command mode panels
OMAPDSS: DSI: Update manager timings on a manual update
OMAPDSS: HDMI: Use our own omap_video_timings field when setting interface timings
OMAPDSS: HDMI: Add locking for hdmi interface set timing functions
OMAPDSS: SDI: Create a function to set timings
OMAPDSS: SDI: Maintain our own timings field in driver data
OMAPDSS: VENC: Split VENC into interface and panel driver
OMAPDSS: VENC: Maintain our own timings field in driver data
OMAPDSS: RFBI: Remove partial update support
OMAPDSS: RFBI: Add function to set panel size
OMAPDSS: DSI: Maintain copy of pixel format in driver data
OMAPDSS: RFBI: Maintain copy of pixel size in driver data
OMAPDSS: RFBI: Maintain copy of number of data lines in driver data
OMAPDSS: DPI: Maintain copy of number of data lines in driver data
OMAPDSS: SDI: Maintain copy of data pairs in driver data
OMAPDSS: DSI: Maintain copy of operation mode in driver data
OMAPDSS: DSI: Rename dsi_videomode_data to dsi_videomode_timings
OMAPDSS: DSI: Maintain copy of video mode timings in driver data
OMAPDSS: RFBI: Maitain copy of rfbi timings in driver data
OMAPDSS: VENC: Maintain copy of venc type in driver data
OMAPDSS: VENC: Maintian copy of video output polarity info in private data
Fixes the following:
WARNING: line over 80 characters
ERROR: spaces required around that ':' (ctx:VxW)
WARNING: Prefer pr_warn(... to pr_warning(...
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
Fixes the following:
WARNING: Prefer pr_warn(... to pr_warning(...
pr_warning("Waiting for status bits 0x%x to clear timed out\n",
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
The implementation in devm_request_and_ioremap() already shows error message,
so no need to show dev_err again if devm_request_and_ioremap() fails.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Philip, Avinash <avinashphilip@ti.com>
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
This patch adds missing device pointer to struct pwm_chip. If the
device pointer is NULL, pwmchip_add() will return error.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
Fixes the following sparse warnings:
drivers/pwm/core.c:152:6: warning:
symbol 'of_pwmchip_add' was not declared. Should it be static?
drivers/pwm/core.c:165:6: warning:
symbol 'of_pwmchip_remove' was not declared. Should it be static?
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
cachep->dflags is never referenced, so remove it.
Acked-by: Christoph Lameter <cl@linux.com>
Signed-off-by: David Rientjes <rientjes@google.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
The core ptrace access checking routine holds a task lock, and when
reporting a failure, Yama takes a separate task lock. To avoid a
potential deadlock with two ptracers taking the opposite locks, do not
use get_task_comm() and just use ->comm directly since accuracy is not
important for the report.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Suggested-by: Oleg Nesterov <oleg@redhat.com>
CC: stable@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: John Johansen <john.johansen@canonical.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
Previous attempts to add platform probing of the Audio related devices
only call from non-DT initialisation functions. This patch extends that
functionality to the Device Tree related ones too.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The platform attempts to register platform device 'snd_soc_u8500'
which doesn't actually exist. Here we change the reference to the
correct one 'snd_soc_mop500'.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
There is yet another way to mux the keyboard, so fix up that
group.
Signed-off-by: Patrice Chotard <patrice.chotard@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The .conf_reg of MX51_PAD_SD2_CMD__CSPI_MOSI should be 0x7bc rather
than NO_PAD. This error will cause SD2 probe failure.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
In function pinctrl_get_locked, pointer p is returned on
error, and also return on no_error.
So, we just return it with no error test.
It's pretty the same in function pinctrl_lookup_state_locked:
state is returned in every case, so we drop the error test
and just return state.
Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
As struct device is used as a function argument, it should at
least be declared (device.h is not included).
Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The irqdomain conversion failed to notice that we do not always
have a DT node to dereference, fix this up by using a simple
dev_err() that also tells the name of the device.
Cc: Loic Pallardy <loic.pallardy@st.com>
Cc: Patrice Chotard <patrice.chotard@stericsson.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2ec8663f9c03a96f2c328c7c483603c31d62ad37 (lmo) rsp.
497e5ff03f (kernel.org) [MIPS: Malta: Move
PIIX4 PCI fixup to where it belongs.] attempted to move this PCI fixup
but really only added it at it's new location without deleting the old
instance.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The ath79 platform code allows to run a single kernel image on various
SoCs which are based on the 24Kc and 74Kc cores. The current code
explicitely disables the DSP ASE, but that is available in the 74Kc core.
Remove the override in order to let the kernel to detect the availability
of the DSP ASE at runtime.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/4222/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The current implementation of synchronise_count_{master,slave} blocks
slave CPUs in early boot until all of them come up. This no longer
works because blocking a CPU with interrupts off after notifying the
CPU to be online causes problems with the current kernel.
Specifically, after the workqueue changes
(commit a08489c569 "Pull workqueue changes from Tejun Heo")
the CPU_ONLINE notification callback workqueue_cpu_up_callback()
will hang on wait_for_completion(&idle_rebind.done), if the slave
CPUs are blocked for synchronize_count_slave().
The changes are to update synchronize_count_{master,slave}() to handle
one CPU at a time and to call synchronise_count_master() in __cpu_up()
so that the CPU_ONLINE notification goes out only after the COP0 COUNT
register is synchronized.
[ralf@linux-mips.org: This matter only to those few platforms which are
using the cp0 counter as their clocksource which are XLP, XLR and MIPS'
CMP solution.]
Signed-off-by: Jayachandran C <jchandra@broadcom.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/4216/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
BCM6338 and BCM6348 have a message control register width of 8 bits, instead
of 16-bits like what the SPI driver assumes right now. Also the SPI message
type shift value of 14 is actually 6 for these SoCs.
This resulted in transmit FIFO corruption because we were writing 16-bits
to an 8-bits wide register, thus spanning on the first byte of the transmit
FIFO, which had already been filed in bcm63xx_spi_fill_txrx_fifo().
Fix this by passing the message control register width and message type
shift through platform data back to the SPI driver so that it can use
it properly.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
Cc: linux-mips@linux-mips.org
Cc: grant.likely@secretlab.ca
Cc: spi-devel-general@lists.sourceforge.net
Cc: jonas.gorski@gmail.com
Patchwork: https://patchwork.linux-mips.org/patch/3983/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
In case a series of R_MIPS_HI16 relocations was not followed by an
R_MIPS_LO16 relocation we were leaking the hi16 relocation chain.
Handle that error and return an error.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The relocation code was essentially taken from the 2.4 modutils which
perform relocation in userspace. In 2.6 relocation of multiple modules
may be performed in parallel by the in-kernel loader so the global
variable mips_hi16_list won't fly anymore. Fix race by moving it into
mod_arch_specific.
[ralf@linux-mips.org: folded in Tony's followup fix. Thanks Tony!]
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Tony Wu <tung7970@gmail.com>
Cc: linux-mips@linux-mips.org
Patchwork: http://patchwork.linux-mips.org/patch/4189/
Commit 6f5d2e970452b5c86906adcb8e7ad246f535ba39 (lmo) /
477c4b0740 (kernel.org) [[MIPS: VPE: Free
relocation chain on error.] fixed the same issue in the vpe loader in 2009
but back then the same bug in module.c went unfixed.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Reported-by: Akhilesh Kumar <akhilesh.lxr@gmail.com>
Without this udelay(1) PCI idsel does not work correctly on the
"singleboard" (T-Mobile Surfbox) for the MiniPCI device. The result is
that PCI configuration fails and the MiniPCI card is not detected
correctly. Instead of
PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [mem 0x40000000-0x4fffffff]
pci_bus 0000:00: root bus resource [io 0x1000-0xffff]
pci 0000:00:03.0: BAR 0: assigned [mem 0x40000000-0x4000ffff]
pci 0000:00:00.0: BAR 0: assigned [mem 0x40010000-0x40010fff]
pci 0000:00:00.1: BAR 0: assigned [mem 0x40011000-0x40011fff]
We see only the CardBus device:
PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [mem 0x40000000-0x4fffffff]
pci_bus 0000:00: root bus resource [io 0x1000-0xffff]
pci 0000:00:00.0: BAR 0: assigned [mem 0x40000000-0x40000fff]
pci 0000:00:00.1: BAR 0: assigned [mem 0x40001000-0x40001fff]
Later the device driver shows this error:
ath5k 0000:00:03.0: cannot remap PCI memory region
ath5k: probe of 0000:00:03.0 failed with error -5
I assume that the logic chip which usually supresses the signal to the CardBus
card has some settling time and without the delay it would still let the
Cardbus interfere with the response from the MiniPCI card.
What I cannot explain is why this behaviour shows up now and not in earlier
kernel versions before. Maybe older PCI code was slower?
Signed-off-by: Bruno Randolf <br1@einfach.org>
Cc: linux-mips@linux-mips.org
Cc: manuel.lauss@googlemail.com
Cc: florian@openwrt.org
Patchwork: https://patchwork.linux-mips.org/patch/4087/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
It is needed in order to get rid of the following errors:
arch/mips/ath79/clock.c:353:13: error: redefinition of 'clk_get'
include/linux/clk.h:281:27: note: previous definition of 'clk_get' was here
arch/mips/ath79/clock.c:377:5: error: redefinition of 'clk_enable'
include/linux/clk.h:295:19: note: previous definition of 'clk_enable' was here
arch/mips/ath79/clock.c:383:6: error: redefinition of 'clk_disable'
include/linux/clk.h:300:20: note: previous definition of 'clk_disable' was here
arch/mips/ath79/clock.c:388:15: error: redefinition of 'clk_get_rate'
include/linux/clk.h:302:29: note: previous definition of 'clk_get_rate' was here
arch/mips/ath79/clock.c:394:6: error: redefinition of 'clk_put'
include/linux/clk.h:291:20: note: previous definition of 'clk_put' was here
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/4170/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The currently assigned IRQ number to the OHCI controller is incorrect for
the AR7240 SoC, and that leads to the following error message from the
OHCI driver:
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ath79-ohci ath79-ohci: Atheros built-in OHCI controller
ath79-ohci ath79-ohci: new USB bus registered, assigned bus number 1
ath79-ohci ath79-ohci: irq 14, io mem 0x1b000000
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
usb 1-1: new full-speed USB device number 2 using ath79-ohci
ath79-ohci ath79-ohci: Unlink after no-IRQ? Controller is probably using the wrong IRQ.
Fix this by using the correct IRQ number.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/4168/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Since 3.6.0-rc1, We are getting many messages like:
WARNING: at kernel/irq/irqdomain.c:444 irq_domain_associate_many+0x23c/0x260()
Modules linked in:
Call Trace:
[<ffffffff814cb698>] dump_stack+0x8/0x34
[<ffffffff81133d00>] warn_slowpath_common+0x78/0xa8
[<ffffffff81187e44>] irq_domain_associate_many+0x23c/0x260
[<ffffffff81187f38>] irq_create_mapping+0xd0/0x220
[<ffffffff81188104>] irq_create_of_mapping+0x7c/0x158
[<ffffffff813e5f08>] irq_of_parse_and_map+0x28/0x40
.
.
.
Both the CIU and GPIO interrupt domains were somewhat screwed up.
For the CIU domain, we need to call irq_domain_associate() for each of
the preassigned irq numbers. For the GPIO domain, we were applying
the register bit offset in octeon_irq_gpio_xlat, but it should be done
in octeon_irq_gpio_map instead.
Also: Reserve all 8 'core' irqs for the 'core' irq_chip so that they
don't get used by the other domains. Remove unused OCTEON_IRQ_*
symbols.
Signed-off-by: David Daney <david.daney@cavium.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/4190/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Added new haswell_write_eld() to initialize Haswell HDMI audio registers
to generate an unsolicited response to the audio controller driver to
indicate that the controller sequence should start.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Wang Xingchao <xingchao.wang@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need to call these before we transfer the damaged areas to the device
not before/after we setup the long lived vmaps.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In order for udl vmap to work properly, we need to push the object
into the CPU domain before we start copying the data to the USB device.
This along with the udl change avoids userspace explicit mapping to
be used.
v2: add a flag for userspace to query to know if Intel kernel driver can
deal with the vmap flushing properly. In theory udl would need a flag also,
but I intend to push the patches very close to each other and other drivers
should do the right thing from the start.
I've added a test to my intel-gpu-tools prime branch, however testing
this is a bit messy since the only way to get udl to vmap is to rendering
something. I've tested this with real code as well to make sure it works.
Signed-off-by: Dave Airlie <airlied@redhat.com>
[danvet: resolved conflict, which required reallocating the PARAM
number to 21.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is left over from the old PLL sharing code and isn't useful now
that PLLs are shared when possible.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
New-ish devices have 3 pipes, so let's not just hardcode 2 but use the
for_each_pipe() macro and make struct intel_display_error_state is big
enough.
V2: Also add the number of pipes emitted (Chris Wilson)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Yet again the too close relationship between the fb helper and the
crtc helper code strikes. This time around the fb helper resets all
encoder->crtc pointers to NULL before starting to set up it's own
mode. Which is total bullocks, because this will clobber the existing
output routing, which the new drm/i915 code depends upon to be
absolutely correct.
The crtc helper itself doesn't really care about that, since it
disables unused encoders in a rather roundabout way anyway.
Two places call drm_setup_crts:
- For the initial fb config. I've auditted all current drivers, and
they all allocate their encoders with kzalloc. So there's no need to
clear encoder->crtc once more.
- When processing hotplug events while showing the fb console. This
one is a bit more tricky, but both the crtc helper code and the new
drm/i915 modeset code disable encoders if their crtc is changed and
that encoder isn't part of the new config. Also, both disable any
disconnected outputs, too.
Which only leaves encoders that are on, connected, but for some odd
reason the fb helper code doesn't want to use. That would be a bug
in the fb configuration selector, since it tries to light up as many
outputs as possible.
v2: Kill the now unused encoders variable.
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use _PIPE macro to get correct register definition for IBX/CPT, discard
old variable "i" way.
Signed-off-by: Wang Xingchao <xingchao.wang@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
[danvet: Added the DIP_PORT_SEL #define from a preceeding patch in the
series that needs more work.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
HDMI audio related registers will be configured in write_eld callback.
Signed-off-by: Wang Xingchao <xingchao.wang@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Simply to make the ilk+ crtc disable path clearer and more symmetric
with the enable function.
Also switch to intel_crtc for the enable function.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... and move a few others only used by i915_dma.c into the dri1
dungeon.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
All dvo drivers only support 2 dpms states, and our dvo driver
even switches of the dvo port for anything else than DPMS_ON. Hence
ditch this complexity and simply use bool enable.
While reading through this code I've noticed that the mode_set
function of ch7017 is a bit peculiar - it disable the lvds again, even
though the crtc helper code should have done that ... This might be to
work around an issue at driver load, we pretty much ignore the hw
state when taking over.
v2: Also do the conversion for the new ns2501 driver.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since it's redundant - we can get the attached encoder in the
functions themselves.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A few things need adjustement:
- Change the dpms state by calling the dpms connector function and
not some crtc helper internal callbacks. Otherwise this will break
once we switch to our own dpms handling.
- Instead of tracking and restoring intel_crtc->dpms_mode use the
connector's dpms variable - the former relies on the dpms compuation
rules used by the crtc helper. And it would break when the encoder
is cloned and the other output has a different dpms state. But luckily
no one is crazy enough for that.
- Properly clear the connector -> encoder -> crtc linking, even when
failing (note that the crtc helper removes the encoder -> crtc link
in disabled_unused_functions for us).
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that all affected i830M systems have the pipe A quirk set,
we don't need to do any special dances in the overlay code any
longer. And reading through the code I'm rather dubios that it
actually does what it claims to do ...
As a nice benefit this rips out a users of the crtc helper dpms
callback.
v2: As suggested by Chris Wilson, replace the code by an appropriate
WARN to ensure that the pipe A is indeed running.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With the pipe A quirk properly fixed up for i830M, this shouldn't be
required any longer.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
