23 Apr, 2014
1 commit
-
... our current modeset code isn't good enough yet to handle this. The
scenario is:1. BIOS sets up a cloned config with lvds+external screen on the same
pipe, e.g. pipe B.2. We read out that state for pipe B and assign the gmch_pfit state to
it.3. The initial modeset switches the lvds to pipe A but due to lack of
atomic modeset we don't recompute the config of pipe B.-> both pipes now claim (in the sw pipe config structure) to use the
gmch_pfit, which just won't work.Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74081
Tested-by: max
Cc: Alan Stern
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter
Signed-off-by: Jani Nikula
05 Apr, 2014
1 commit
-
Merge window -fixes pull request as usual. Well, I did sneak in Jani's
drm_i915_private_t typedef removal, need to have fun with a big sed job
too ;-)Otherwise:
- hdmi interlaced fixes (Jesse&Ville)
- pipe error/underrun/crc tracking fixes, regression in late 3.14-rc (but
not cc: stable since only really relevant for igt runs)
- large cursor wm fixes (Chris)
- fix gpu turbo boost/throttle again, was getting stuck due to vlv rps
patches (Chris+Imre)
- fix runtime pm fallout (Paulo)
- bios framebuffer inherit fix (Chris)
- a few smaller things* tag 'drm-intel-fixes-2014-04-04' of git://anongit.freedesktop.org/drm-intel: (196 commits)
Skip intel_crt_init for Dell XPS 8700
drm/i915: vlv: fix RPS interrupt mask setting
Revert "drm/i915/vlv: fixup DDR freq detection per Punit spec"
drm/i915: move power domain init earlier during system resume
drm/i915: Fix the computation of required fb size for pipe
drm/i915: don't get/put runtime PM at the debugfs forcewake file
drm/i915: fix WARNs when reading DDI state while suspended
drm/i915: don't read cursor registers on powered down pipes
drm/i915: get runtime PM at i915_display_info
drm/i915: don't read pp_ctrl_reg if we're suspended
drm/i915: get runtime PM at i915_reg_read_ioctl
drm/i915: don't schedule force_wake_timer at gen6_read
drm/i915: vlv: reserve the GT power context only once during driver init
drm/i915: prefer struct drm_i915_private to drm_i915_private_t
drm/i915/overlay: prefer struct drm_i915_private to drm_i915_private_t
drm/i915/ringbuffer: prefer struct drm_i915_private to drm_i915_private_t
drm/i915/display: prefer struct drm_i915_private to drm_i915_private_t
drm/i915/irq: prefer struct drm_i915_private to drm_i915_private_t
drm/i915/gem: prefer struct drm_i915_private to drm_i915_private_t
drm/i915/dma: prefer struct drm_i915_private to drm_i915_private_t
...
03 Apr, 2014
1 commit
-
- Inherit/reuse firmwar framebuffers (for real this time) from Jesse, less
flicker for fastbooting.
- More flexible cloning for hdmi (Ville).
- Some PPGTT fixes from Ben.
- Ring init fixes from Naresh Kumar.
- set_cache_level regression fixes for the vma conversion from Ville&Chris.
- Conversion to the new dp aux helpers (Jani).
- Unification of runtime pm with pc8 support from Paulo, prep work for runtime
pm on other platforms than HSW.
- Larger cursor sizes (Sagar Kamble).
- Piles of improvements and fixes all over, as usual.* tag 'drm-intel-next-2014-03-21' of git://anongit.freedesktop.org/drm-intel: (75 commits)
drm/i915: Include a note about the dangers of I915_READ64/I915_WRITE64
drm/i915/sdvo: fix questionable return value check
drm/i915: Fix unsafe loop iteration over vma whilst unbinding them
drm/i915: Enabling 128x128 and 256x256 ARGB Cursor Support
drm/i915: Print how many objects are shared in per-process stats
drm/i915: Per-process stats work better when evaluated per-process
drm/i915: remove rps local variables
drm/i915: Remove extraneous MMIO for RPS
drm/i915: Rename and comment all the RPS *stuff*
drm/i915: Store the HW min frequency as min_freq
drm/i915: Fix coding style for RPS
drm/i915: Reorganize the overclock code
drm/i915: init pm.suspended earlier
drm/i915: update the PC8 and runtime PM documentation
drm/i915: rename __hsw_do_{en, dis}able_pc8
drm/i915: kill struct i915_package_c8
drm/i915: move pc8.irqs_disabled to pm.irqs_disabled
drm/i915: remove dev_priv->pc8.enabled
drm/i915: don't get/put PC8 when getting/putting power wells
drm/i915: make intel_aux_display_runtime_get get runtime PM, not PC8
...Conflicts:
drivers/gpu/drm/i915/intel_display.c
drivers/gpu/drm/i915/intel_dp.c
02 Apr, 2014
3 commits
-
Now that CRTC's have a primary plane, there's no need to track the
framebuffer in the CRTC. Replace all references to the CRTC fb with the
primary plane's fb.This patch was generated by the Coccinelle semantic patching tool using
the following rules:@@ struct drm_crtc C; @@
- (C).fb
+ C.primary->fb@@ struct drm_crtc *C; @@
- (C)->fb
+ C->primary->fbv3: Generate patch via coccinelle. Actual removal of crtc->fb has been
moved to a subsequent patch.v2: Fixup several lingering crtc->fb instances that were missed in the
first patch iteration. [Rob Clark]Signed-off-by: Matt Roper
Reviewed-by: Rob Clark -
Ensure that existing driver loops over all planes do not change behavior
when we begin adding new types of planes (primary and cursor) to the DRM
plane list in future patches.v2: Switch to using drm_for_each_legacy_plane()
Cc: Intel Graphics Development
Signed-off-by: Matt Roper -
Atm we reserve/allocate and free the power context during GT power
enable/disable time. There is no need to do this, we can reserve/allocate
the buffer once during driver loading and free it during driver cleanup.
The re-reservation can also fail in case the driver previously manages to
allocate something on the given fixed address.The buffer isn't exepected to move even if allocated by the BIOS, for
safety add an assert to check this assumption.This also fixed a bug for Ville, where re-reserving the context failed
during a GPU reset (I assume because something else got allocated on its
fixed address).Tested-by: Ville Syrjälä
Signed-off-by: Imre Deak
Reviewed-by: Ville Syrjälä
Signed-off-by: Daniel Vetter
31 Mar, 2014
5 commits
-
No functional changes.
Signed-off-by: Jani Nikula
Signed-off-by: Daniel Vetter -
If vsyncshift comes out as negative, add one htotal to it to get the
corresponding positive value.This is rather theoretical as it would require a mode where the
hsync+back porch is very long and the active+front porch very short.Signed-off-by: Ville Syrjälä
Reviewed-by: Jesse Barnes
Signed-off-by: Daniel Vetter -
PIPECONF_INTERLACE_W_FIELD_INDICATION is only meant to be used for sdvo
since it implies a slightly weird vsync shift of htotal/2. For everything
else we should use PIPECONF_INTERLACE_W_SYNC_SHIFT and let the value in
the VSYNCSHIFT register take effect.The only exception is gen3 simply because VSYNCSHIFT didn't exist yet.
Gen2 doesn't support interlaced modes at all, so we can drop the
explicit gen2 checks.Signed-off-by: Ville Syrjälä
Reviewed-by: Jesse Barnes
Signed-off-by: Daniel Vetter -
When interlaced sdvo output is used, vsyncshift should supposedly
be (htotal-1)/2. In reality PIPECONF/TRANSCONF will override it by
using the legacy vsyncshift interlace mode which causes the hardware
to ignore the VSYNCSHIFT register.The only odd thing here is that on PCH platforms we program the
VSYNCSHIFT on both CPU and PCH, and it's not entirely clear if both
sides have to agree on the value or not. On the CPU side there's no
way to override the value via PIPECONF anymore, so if we want to make
the CPU side agree with the PCH side, we should probably program the
approriate value into VSYNCSHIFT manually. So let's do that, but for
now leave the PCH side to still use the legacy interlace mode in
TRANSCONF.We can also drop the gen2 check since gen2 doesn't support interlaced
modes at all.Signed-off-by: Ville Syrjälä
Reviewed-by: Jesse Barnes
Signed-off-by: Daniel Vetter -
This makes HDMI testers happier on VLV platforms. It may be that we
need it for any non-SVO platform, but I don't have any tests to back
that up, so I'm leaving other pre-ILK platforms alone for now.Tested-by: "Clint Taylor "
Signed-off-by: Jesse Barnes
Reviewed-by: Ville Syrjälä
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74964
Signed-off-by: Daniel Vetter
29 Mar, 2014
2 commits
-
If the cursor width is changed, we may need to recompute our WM to
prevent untold flickering. We hope that the registers are flushed on the
same vblank to prevent underruns...Cc: Damien Lespiau
Cc: Sagar Kamble
Signed-off-by: Chris Wilson
Reviewed-by: Damien Lespiau
Signed-off-by: Daniel Vetter -
Since
commit 5c673b60a9b3b23486f4eda75c72e91d31d26a2b
Author: Daniel Vetter
Date: Fri Mar 7 20:34:46 2014 +0100drm/i915: Don't enable display error interrupts from the start
we don't enable underrun interrupts any more at takeover time.
Unfortunately I've forgotten to also adjust the sw-side tracking.Since the code assumes that disabled pipes have underrun reporting
enabled set the disable flag only on all pipes which are active at
takeover time. Without this underrun reporting wasn't enabled
correctly on the first modeset. Note that for fastboot this is another
piece of state that needs to be fixed up by enabling the underrung
reporting after watermarks have beend fixed up.On ivb/hsw an additional effect of this regression was that also all
cpu crc reporting stopped working since the master error interrupt it
shared across all pipes and sources.Cc: Ville Syrjälä
Cc: Jani Nikula
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76150
[danvet: Augment the code comment and polish the commit message a bit,
as discussed with Jani.]
Reviewed-by: Jani Nikula
Tested-by: lu hua
Signed-off-by: Daniel Vetter
21 Mar, 2014
1 commit
-
With this patch we allow larger cursor planes of sizes 128x128
and 256x256.v2: Added more precise check on size while setting cursor plane.
v3: Changes related to restructuring cursor size restrictions
and DRM_DEBUG usage.v4: Indentation related changes for setting cursor control and
implementing DRM_CAP_CURSOR_WIDTH and DRM_CAP_CURSOR_HEIGHTTestcase: igt/kms_cursor_crc
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: David Airlie
Cc: dri-devel@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: G, Pallavi
Signed-off-by: Sagar Kamble
Reviewed-by: Imre Deak
Signed-off-by: Daniel Vetter
19 Mar, 2014
12 commits
-
Now that PC8 got much simpler, there are less things to document.
Also, runtime PM already has a nice documentation, so we don't need to
re-explain it on our driver.v2: - Rebase.
- Fix typo (Jesse).Reviewed-by: Jesse Barnes
Signed-off-by: Paulo Zanoni
Signed-off-by: Daniel Vetter -
After we removed all the intermediate abstractions, we can rename
these functions to just hsw_{en,dis}able_pc8.v2: - Rebase.
Reviewed-by: Jesse Barnes
Signed-off-by: Paulo Zanoni
Signed-off-by: Daniel Vetter -
When other platforms add runtime PM support they will also need to
disable interrupts, so move the variable to the runtime PM struct.Also notice that the longer-term goal is to completely kill the
regsave struct, and I even have patches for that.v2: - Rebase.
v3: - Rebase.Reviewed-by: Jesse Barnes
Signed-off-by: Paulo Zanoni
Signed-off-by: Daniel Vetter -
It was just being used on debugfs and on a WARN inside
hsw_set_power_well. But now that we PC8 is part of runtime PM and we
get/put runtime PM when we get/put any power domain, we shouldn't need
the WARN anymore.v2: - Rebase.
v3: - Rebase.Reviewed-by: Jesse Barnes
Signed-off-by: Paulo Zanoni
Signed-off-by: Daniel Vetter -
Because we already get/put runtime PM every time we get/put any power
domain, and now PC8 and runtime PM are the same thing.With this, we can also now kill the hsw_{en,dis}able_package_c8
functions.v2: - Rebase.
v3: - Rebase.
v4: - Rebase.Reviewed-by: Jesse Barnes
Signed-off-by: Paulo Zanoni
Signed-off-by: Daniel Vetter -
After the latest changes, the indirection is useless.
Reviewed-by: Jesse Barnes
Signed-off-by: Paulo Zanoni
Signed-off-by: Daniel Vetter -
Since after the latest patches it's only being used to prevent
getting/putting the runtime PM refcount.Reviewed-by: Jesse Barnes
Signed-off-by: Paulo Zanoni
Signed-off-by: Daniel Vetter -
... instead of PC8 references. Now that both are the same thing and we
are killing PC8, just get the runtime PM reference.Reviewed-by: Jesse Barnes
Signed-off-by: Paulo Zanoni
Signed-off-by: Daniel Vetter -
The requirements_met variable was used to track two things: enabled
CRTCs and the power well. After the latest chagnes, we get a runtime
PM reference whenever we get any of the power domains, and we get
power domains when we enable CRTCs or the power well, so we should
already be covered, not needing this specific tracking.v2: - Rebase.
v3: - Rebase.Signed-off-by: Paulo Zanoni
Reviewed-by: Imre Deak
Signed-off-by: Daniel Vetter -
Currently, when our driver becomes idle for i915.pc8_timeout (default:
5s) we enable PC8, so we save some power, but not everything we can.
Then, while PC8 is enabled, if we stay idle for more
autosuspend_delay_ms (default: 10s) we'll enter runtime PM and put the
graphics device in D3 state, saving even more power. The two features
are separate things with increasing levels of power savings, but if we
disable PC8 we'll never get into D3.While from the modularity point of view it would be nice to keep these
features as separate, we have reasons to merge them:
- We are not aware of anybody wanting a "PC8 without D3" environment.
- If we keep both features as separate, we'll have to to test both
PC8 and PC8+D3 code paths. We're already having a major pain to
make QA do automated testing of just one thing, testing both paths
will cost even more.
- Only Haswell+ supports PC8, so if we want to add runtime PM support
to, for example, IVB, we'll have to copy some code from the PC8
feature to runtime PM, so merging both features as a single thing
will make it easier for enabling runtime PM on other platforms.This patch only does the very basic steps required to have PC8 and
runtime PM merged on a single feature: the next patches will take care
of cleaning up everything.v2: - Rebase.
v3: - Rebase.
- Fully remove the deprecated i915 params since Daniel doesn't
consider them as part of the ABI.
v4: - Rebase.
- Fix typo in the commit message.
v5: - Rebase, again.
- Add a huge comment explaining the different forcewake usage
(Chris, Daniel).
- Use open-coded forcewake functions (Daniel).Signed-off-by: Paulo Zanoni
Reviewed-by: Imre Deak
Signed-off-by: Daniel Vetter -
When we merge PC8 and runtime PM, these new functions are going to be
called by the runtime suspend/resume functions, and their callers are
going to be removed.v2: - Rebase
Reviewed-by: Imre Deak (v1)
Signed-off-by: Paulo Zanoni
Signed-off-by: Daniel Vetter -
The name 'update_plane' was used both for the primary plane functions in
intel_display.c and the sprite/overlay functions in intel_sprite.c.
Rename the primary plane functions to 'update_primary_plane' to avoid
confusion.On a similar note, intel_display.c already had a function called
intel_disable_primary_plane() that programs the hardware to disable a
pipe's primary plane. When we hook up primary planes through the DRM
plane interface, one of the natural handler names will be
intel_primary_plane_disable(), which is very similar. To avoid
confusion, rename the existing intel_disable_primary_plane() to
intel_disable_primary_hw_plane() to make the two names a little more
distinct.Cc: Intel Graphics Development
Signed-off-by: Matt Roper
[danvet: Fix up conflicts.]
Signed-off-by: Daniel Vetter
18 Mar, 2014
3 commits
-
No need of any here.
Signed-off-by: Damien Lespiau
Signed-off-by: Daniel Vetter -
Linux 3.14-rc7
Backmerge to help out Intel guys.
-
Conflicts:
drivers/gpu/drm/i915/MakefileMakefile cleanup in drm-intel-next conflicts with a build-fix to move
intel_opregion under CONFIG_ACPI.Signed-off-by: Daniel Vetter
12 Mar, 2014
1 commit
-
We don't need to hold struct_mutex all through intel_pipe_set_base(),
just need to hold it while pinning/unpinning the buffers.So reduce the struct_mutext usage in intel_pipe_set_base() just like we
did for the sprite code in:
commit 82284b6becdbef6d8cd3fb43e8698510833a5129
Author: Ville Syrjälä
Date: Tue Oct 1 18:02:12 2013 +0300drm/i915: Reduce the time we hold struct mutex in sprite update_plane code
The FBC and PSR locking is still entirely fubar. That stuff was
previouly done while holding struct_mutex, so leave it there for now.Signed-off-by: Ville Syrjälä
Reviewed-by: Chris Wilson
Signed-off-by: Daniel Vetter
11 Mar, 2014
2 commits
-
Linux 3.14-rc6
I need the hdmi/dvi-dual link fixes in 3.14 to avoid ugly conflicts
when merging Ville's new hdmi cloning support into my -next treeConflicts:
drivers/gpu/drm/i915/Makefile
drivers/gpu/drm/i915/intel_dp.cMakefile cleanup conflicts with an acpi build fix, intel_dp.c is
trivial.Signed-off-by: Daniel Vetter
-
Currently we allow encoders to indicate whether they can be part of a
cloned set with just one flag. That's not flexible enough to describe
the actual hardware capabilities. Instead make it a bitmask of encoder
types with which the current encoder can be cloned.For now we set the bitmask to allow DVO+DVO and DVO+VGA, which should
match what the old boolean flag allowed. We will add some more cloning
options in the future.Note that this patch also removes the encoder.possible_clones setting
from encoder setup code - we compute this dynamically.Signed-off-by: Ville Syrjälä
Reviewed-by: Rodrigo Vivi
[danvet: Add Ville's explanation why removing the encoder
possible_clones is save.]
Signed-off-by: Daniel Vetter
10 Mar, 2014
2 commits
-
The stolen allocator objects loudly if the caller requests a zero-sized
object. This is a useful verbose check as in most cases the request
should have been pruned much early. Here we just want to silently return
before attempting the allocation.Regression from
commit 484b41dd70a9fbea894632d8926bbb93f05021c7
Author: Jesse Barnes
Date: Fri Mar 7 08:57:55 2014 -0800drm/i915: remove early fb allocation dependency on CONFIG_FB v2
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75963
Signed-off-by: Chris Wilson
Signed-off-by: Daniel Vetter -
During KMS takeover, we try to capture the current configuration and
preserve it across our initialisation. For a variety of reasons, we may
fail this, for example if the current mode was using the legacy VGA
plane. Under such circumstances, we discard the fb in the plane config
and tried to find a matching fb on another CRTC. This obviously also
failed, leaving the plane config fb dangling, pointing to the freed block.Regression from
commit 484b41dd70a9fbea894632d8926bbb93f05021c7
Author: Jesse Barnes
Date: Fri Mar 7 08:57:55 2014 -0800drm/i915: remove early fb allocation dependency on CONFIG_FB v2
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75963
Signed-off-by: Chris Wilson
Signed-off-by: Daniel Vetter
08 Mar, 2014
6 commits
-
By stuffing the fb allocation into the crtc, we get mode set lifetime
refcounting for free, but have to handle the initial pin & fence
slightly differently. It also means we can move the shared fb handling
into the core rather than leaving it out in the fbdev code.v2: null out crtc->fb on error (Daniel)
take fbdev fb ref and remove unused error path (Daniel)Requested-by: Daniel Vetter
Signed-off-by: Jesse Barnes
Signed-off-by: Daniel Vetter -
Retrieve current framebuffer config info from the regs and create an fb
object for the buffer the BIOS or boot loader left us. This should
allow for smooth transitions to userspace apps once we finish the
initial configuration construction.v2: check for non-native modes and adjust (Jesse)
fixup aperture and cmap frees (Imre)
use unlocked unref if init_bios fails (Jesse)
fix curly brace around DSPADDR check (Imre)
comment failure path for pin_and_fence (Imre)
v3: fixup fixup of aperture frees (Chris)
v4: update to current bits (locking & pin_and_fence hack) (Jesse)
v5: move fb config fetch to display code (Jesse)
re-order hw state readout on initial load to suit fb inherit (Jesse)
re-add pin_and_fence in fbdev code to make sure we refcount properly (Je
v6: rename to plane_config (Daniel)
check for valid object when initializing BIOS fb (Jesse)
split from plane_config readout and other display changes (Jesse)
drop use_bios_fb option (Chris)
update comments (Jesse)
rework fbdev_init_bios for clarity (Jesse)
drop fb obj ref under lock (Chris)
v7: use fb object from plane_config instead (Ville)
take ref on fb object (Jesse)
v8: put under i915_fastboot option (Jesse)
fix fb ptr checking (Jesse)
inform drm_fb_helper if we fail to enable a connector (Jesse)
drop unnecessary enabled[] modifications in failure cases (Chris)
split from BIOS connector config readout (Daniel)
don't memset the fb buffer if preallocated (Chris)
alloc ifbdev up front and pass to init_bios (Chris)
check for bad ifbdev in restore_mode too (Chris)
v9: fix up !fastboot bpp setting (Jesse)
fix up !fastboot helper alloc (Jesse)
make sure BIOS fb is sufficient for biggest active pipe (Jesse)
v10:fix up size calculation for proposed fbs (Chris)
go back to two pass pipe fb assignment (Chris)
add warning for active pipes w/o fbs (Chris)
clean up num_pipes checks in fbdev_init and fbdev_restore_mode (Chris)
move i915.fastboot into fbdev_init (Chris)
v11:make BIOS connector config usage unconditional (Daniel)
v12:fix up fb vs pipe size checking (Chris)Signed-off-by: Jesse Barnes
Signed-off-by: Daniel Vetter -
This should allow BIOS fb inheritance to work on ILK+ machines too.
v2: handle tiled BIOS fbs (Kristian)
split out common bits (Jesse)
v3: alloc fb obj out in _initSigned-off-by: Jesse Barnes
Signed-off-by: Daniel Vetter -
Read out the current plane configuration at init time into a new
plane_config structure. This allows us to track any existing
framebuffers attached to the plane and potentially re-use them in our
fbdev code for a smooth handoff.v2: update for new pitch_for_width function (Jesse)
comment how get_plane_config works with shared fbs (Jesse)
v3: s/ARGB/XRGB (Ville)
use pipesrc width/height (Ville)
fix fourcc comment (Bob)
use drm_format_plane_cpp (Ville)
v4: use fb for tracking fb data object (Ville)
v5: fix up gen2 pitch limits (Ville)
v6: read out stride as well (Daniel)
v7: split out init ordering changes (Daniel)
don't fetch config if !CONFIG_FB
v8: use proper height in get_plane_config (Chris)
v9: fix CONFIG_FB check for modular configs (Jani)
v10: add comment about stolen allocation stomping
v11: drop hw state readout hunk (Daniel)
v12: handle tiled BIOS fbs (Kristian)
pull out common bits (Jesse)
v13: move fb obj alloc out to _initSigned-off-by: Jesse Barnes
Signed-off-by: Daniel Vetter -
Early at init time, we can try to read out the plane config structure
and try to preserve it if possible.v2: alloc fb obj at init time after fetching plane config
Signed-off-by: Jesse Barnes
Signed-off-by: Daniel Vetter -
Based on an early draft from Jesse.
Add support for powering on/off the dynamic power wells on VLV by
registering its display and dpio dynamic power wells with the power
domain framework.For now power on all PHY TX lanes regardless of the actual lane
configuration. Later this can be optimized when the PHY side setup
enables only the required lanes. Atm, it enables all lanes in all
cases.v2:
- undef function local COND macro after its last use (Ville)
- Take dev_priv->irq_lock around the whole sequence of
intel_set_cpu_fifo_underrun_reporting_nolock() and
valleyview_disable_display_irqs(). They are short and releasing
the lock in between only makes proving correctness more difficult.
- sanitize local var names in vlv_power_well_enabled()
v3:
- rebase on latest -nightlySigned-off-by: Imre Deak
Reviewed-by: Jesse Barnes
[danvet: Resolve conflict due to my changes in the previous patch.
Also throw in an assert_spin_locked for safety. And finally appease
checkpatch.]
Signed-off-by: Daniel Vetter