Needed by the next patch, wanting to set the underrun reporting as part
of a bigger dev_priv->irq_lock'ed sequence.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Use more customary __ prefix instead of _nolock postfix.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We'll need to disable/re-enable the display-side IRQs when turning
off/on the VLV display power well. Factor out the helper functions
for this. For now keep the display IRQs enabled by default, so the
functionality doesn't change. This will be changed to enable/disable
the IRQs on-demand when adding support for VLV power wells in an
upcoming patch.
v2:
- take the irq spin lock for the whole enable/disable sequence as
these can be called with interrupts enabled
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Suggested by Daniel.
v2:
- sanitize the state checking condition, the original was rather
confusing (partly due to the unfortunate naming of
i915.disable_power_well) (Ville)
- simpler message+backtrace generation by using WARN instead of WARN_ON
(Ville)
- check if always-on power wells are truly on all the time
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need to do the same for other platforms in upcoming patches.
v2:
- s/p/pipe (Ville)
- Call the new helper with the vbl_lock already held. The part it
protects is short, so releasing it between pipes only makes proving
correctness more difficult.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Resolve conflict with Damien's s/p/pipe/ change.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In the upcoming patches we'll need to access the rest of the fields in
the punit power gating register, so prepare for that.
v2:
- add doc reference for the power well subsystem IDs (Jesse)
- remove IDs for non-existant DPIO_RX[23] subsystems (Jesse)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is a left-over from
commit b7e634cc8d
Author: Imre Deak <imre.deak@intel.com>
Date: Tue Feb 4 21:35:45 2014 +0200
drm/i915: vlv: don't unmask IIR[DISPLAY_PIPE_A/B_VBLANK] interrupt
where we stopped unmasking the vblank IRQs, but left them enabled in the
IER register. Disable them in IER too.
v2:
- remove comment becoming stale after this change (Ville)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We can read out the pipe HW state only if the required power domain is
on. If not we consider the pipe to be off.
v2:
- no change
v3:
- push down the power domain checks into the specific crtc
get_pipe_config handlers (Daniel)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Appease checkpatch.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since the encoder is tied to its port, we need to make sure the power
domain for that port is on before reading out the encoder HW state.
Note that this also covers also all connector get_hw_state handlers,
since all those just call the corresponding encoder get_hw_state
handler, which checks - after this change - for all power domains
the connector needs.
v2:
- no change
v3:
- push down the power domain checks into the specific encoder
get_hw_state handlers (Daniel)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The connector detect and get_mode handlers need to access the port
specific HW blocks to read the EDID etc. Get/put the port power domains
around these handlers.
v2:
- get port power domain for HDMI too (Ville)
- get port power domain for the DP,HDMI audio detect handlers (Jesse)
- Leave the intel_runtime_pm_get/put in the DP detect function in place.
Instead of just removing them, these should be moved to the appropriate
power_well enable/disable handlers. We can do this after Paulo's
'Merge PC8 with runtime PM, v2' patchset.
v3:
- rebased on latest -nightly
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Parts that poke port specific HW blocks like the encoder HW state
readout or connector hotplug detect code need a way to check whether
required power domains are on or enable/disable these. For this purpose
add a set of power domains that refer to the port HW blocks. Get the
proper port power domains during modeset.
For now when requesting the power domain for a DDI port get it for a 4
lane configuration. This can be optimized later to request only the 2
lane power domain, when proper support is added on the VLV PHY side for
this. Atm, the PHY setup code assumes a 4 lane config in all cases.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reading code free of special cases wins over the small overhead of
calling a noop handler. Suggested by Jesse.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Split the 'set' power well handler into an 'enable', 'disable' and
'sync_hw' handler. This maps more conveniently to higher level
operations, for example it allows us to push the hsw package c8 handling
into the corresponding hsw/bdw enable/disable handlers and the hsw BIOS
hand-over setting into the hsw/bdw sync_hw handler.
No functional change.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Appease checkpatch's whitespace complaints.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Whenever we request a power domain it has to guarantee that all HW
resources are enabled that are needed to access a HW register associated
with that power domain. In case a register is on an always-on power well
this won't result in turning on a power well, but it may require
enabling some other HW resource. One such resource is the HSW/BDW device
D0 state that is required for all register accesses and thus for all
power wells/power domains.
So far the init power domain (guaranteeing access to all HW registers)
was part of the default i9xx always-on power well, but not the HSW/BDW
always-on power wells. Add the domain to the latter power wells too.
Atm, all the always-on power wells have noop handlers, so this doesn't
change the functionality.
v2:
- clarify semantics of always-on power wells (Paulo)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These macros are used only locally, so move them to the .c file.
No functional change.
v2:
- add init power domain to always-on power wells in the following
- separate - patch (Paulo)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There are too many oustanding issues:
- Fence handling in the current code is broken. There's a patch series
from me, but it's blocked on and extended review (which includes
writing the testcases).
- IOMMU mapping handling is broken, we need to properly refcount it -
currently it gets destroyed when the first vma is unbound, so way
too early.
- There's a pending reset issue on snb. Since Mika's reset work and
full ppgtt have been pulled in in separate branches and ended up
intermittingly breaking each another it's unclear who's the exact
culprit here.
- We still have persistent evidince of crazy recursion bugs through
vma_unbind and ppgtt_relase, e.g.
https://bugs.freedesktop.org/show_bug.cgi?id=73383
This issue (and a few others meanwhile resolved) have blocked our
performance measuring/tuning group since 3 months.
- Secure batch dispatching is broken. This is blocking Brad Volkin's
command checker work since 3 months.
All these issues are confirmed to only happen when full ppgtt is
enabled, falling back to aliasing ppgtt resolves them. But even
aliasing ppgtt itself still has a regression:
- We currently unconditionally bind objects into the aliasing ppgtt,
which means all priviledged objects like ringbuffers are visible to
unpriviledged access again. On top of that this also breaks the
command checker for aliasing ppgtt, since it can't hide the
validated batch any more.
Furthermore topic/full-ppgtt has never been reviewed:
- Lifetime rules around vma unbinding/release are unclear, resulting
into this awesome hack called ppgtt_release. Which seems to take the
blame for most of the recursion fallout.
- Context/ring init works different on gpu reset than anywhere else.
Such differeneces have in the past always lead to really hard to
track down bugs.
- Aliasing ppgtt is treated in a bunch of places as a real address
space, but it isn't - the real address space is always the global
gtt in that case. This results in a bit a mess between contexts and
ppgtt object, further complication the context/ppgtt/vma lifetime
rules.
- We don't have any docs describing the overall concepts introduced
with full ppgtt. A short, concise overview describing vmas and some
of the strange bits around them (like the unbound vmas used by
execbuf, or the new binding rules) really is needed.
Note that a lot of the post topic/full-ppgtt merge fallout has already
been addressed, this entire list here of 10 issues really only contains
the still outstanding issues.
Finally the 3.15 merge window is approaching and I think we need to
use the remaining time to ensure that our fallback option of using
aliasing ppgtt is in solid shape. Hence I think it's time to throw the
switch. While at it demote the helper from static inline status
because really.
Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These functions will be needed by the valleyview specific power well
update functionality added in an upcoming patch, so move them earlier.
No functional change.
v2:
- no change
v3:
- rebase on latest -nightly
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v2)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These functions are used only by a single call site and are simple
enough to just fold them in.
Note that in later patches the parts folded in here are further
simplified as we'll remove hsw_{disable,enable}_package_c8 and the NULL
check of the power well enable/disable handlers. All this means that at
the end intel_display_power_get/put() becomes more understandable as we
don't need to jump between two functions when reading the code.
No functional change.
v2:
- clarify the rational for the change (Chris)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
one more radeon fix.
* 'drm-fixes-3.14' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon/atom: select the proper number of lanes in transmitter setup
Building radeon_ttm.o on 32 bit x86 triggers a warning:
In file included from include/asm-generic/bug.h:13:0,
from [...]/arch/x86/include/asm/bug.h:38,
from include/linux/bug.h:4,
from include/drm/drm_mm.h:39,
from include/drm/drm_vma_manager.h:26,
from include/drm/ttm/ttm_bo_api.h:35,
from drivers/gpu/drm/radeon/radeon_ttm.c:32:
drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_gtt_read':
include/linux/kernel.h:712:17: warning: comparison of distinct pointer types lacks a cast [enabled by default]
(void) (&_min1 == &_min2); \
^
drivers/gpu/drm/radeon/radeon_ttm.c:938:22: note: in expansion of macro 'min'
ssize_t cur_size = min(size, PAGE_SIZE - off);
^
Silence this warning by using min_t(). Since cur_size will never be
negative and its upper bound is PAGE_SIZE, we can change its type to
size_t and use min_t(size_t, [...]) here.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Moving the pm resume up in the init order to fix
dpm seems to have regressed somes cases with the old
pm code. Move it back to late resume.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Without this, a bo may get created in the cpu-inaccessible vram.
Before the CP engines get setup, all copies are done via cpu memcpy.
This means that the cpu tries to read from inaccessible memory, fails,
and the radeon module proceeds to disable acceleration.
Doing this has no downsides, as the real VRAM size gets set as soon as the
CP engines get init.
This is a candidate for 3.14 fixes.
v2: Add comment on why the function is used
Signed-off-by: Lauri Kasanen <cand@gmx.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
We have two names for the same register CHICKEN_PIPESL_1 and
HSW_PIPE_SLICE_CHICKEN_1. Unify it to just one.
Also rename the FBCQ disable bit to resemble the name we've
given to a similar bit on earlier platforms.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
gen7_enable_fbc() may write to some registers which we've already
touched, so use RMW so that we don't undo any previous updates.
Also note that we implemnt WaFbcAsynchFlipDisableFbcQueue:bdw.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Misplaced parens cause us to totally clobber the CHICKEN_PIPESL_1
registers with 0xffffffff. Move the parens to the correct place
to avoid this.
In particular this caused bit 30 of said registers to be set, which
caused the sprite CSC to produce incorrect results.
Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72220
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... it's this time of the year again. Originally we've frobbed this to
fix up some regressions, but maybe our DP code improved sufficiently
now that we can dare to do again what the spec recommends.
This reverts
commit 2514bc510d
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Thu Jun 21 15:13:50 2012 -0700
drm/i915: prefer wide & slow to fast & narrow in DP configs
I'm pretty sure I'll regret this patch, but otoh I expect we won't
make progress here without poking the devil occasionally.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73694
Cc: peter@colberg.org
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Itai BEN YAACOV <candeb@free.fr>
Tested-by: David En <d.engraf@arcor.de>
Reported-and-Tested-by: Marcus Bergner <marcusbergner@gmail.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As we now have intel_uncore_forcewake_reset() no need
to do explicit put after reset.
v2: rebase
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
While reading some code, out of boredom, stumbled on a tiny tiny fix.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
That macro was only ever used to convert ring->private into a gem object
(hence the forceful cast). ring->private doesn't even exist anymore as
it was transmogrified by Chris in:
commit 0d1aacac36
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Aug 26 20:58:11 2013 +0100
drm/i915: Embed the ring->private within the struct intel_ring_buffer
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Its last usage outside of i915_gem.c was removed in:
commit 1f70999f90
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Jan 27 22:43:07 2014 +0000
drm/i915: Prevent recursion by retiring requests when the ring is full
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch fixes the blank screen bug introduced in 3.14-rc1 on the
MacBook Air 6,2. The comments state that we need to force edp vdd so
lets put it back.
The regression was introduced by the following commit:
commit dff392dbd2
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date: Fri Dec 6 17:32:41 2013 -0200
drm/i915: don't touch the VDD when disabling the panel
v2: Wrap intel_disable_dp() with _vdd_on and _vdd_off
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74628
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In the future, we need to be able to specify per-pipe number of
planes/sprites. Let's start today!
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>
This macro is similar to for_each_pipe() we already have. Convert the
two call sites we have at the same time.
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>
Consistency throughout the code base is good and remove some room for
mistakes (as explained in the "drm/i915: Use a pipe variable to cycle
through the pipes" commit)
So, let's replace the for_each_pipe(i) occurences by for_each_pipe(pipe)
when it's reasonable and practical to do so (eg. when there isn't another
pipe variable already).
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
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>
'i' is already defined in the function scope and used elsewhere. Let's
use it instead.
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>
I recently fumbled a patch because I wrote twice num_sprites[i], and it
was the right thing to do in only 50% of the cases.
This patch ensures I need to write num_sprites[pipe], ie it should be
self-documented that it's per-pipe number of sprites without having to
look at what is 'i' this time around.
It's all a lame excuse, but it does make it harder to redo the same
mistake.
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>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
According to BSpec we need to always set this magic bit in ring buffer
mode.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If we need precisely N lanes to satisfy the FDI bandwidth requirement,
the code would still claim that we need N+1 lanes. Use DIV_ROUND_UP()
to get a more accurate answer.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On DDI there's no PLL as such to generate the pixel clock for VGA.
Instead we derive the pixel clock from the FDI link frequency. So
to make .compute_config match what .get_config does, we need to
set the port_clock based on the FDI link frequency.
Note that we don't even check the port_clock when selecting the
PLL for VGA output. We just assume SPLL at 1.35GHz is what we want,
and that does match with the asumption of FDI frequency of 2.7Ghz
we have in intel_fdi_link_freq().
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74955
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
as they don't exists.
v2: rename gen6_*_mt_* to gen7_*_mt_* as they never get called
with gen6 (Chris)
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net> (v1)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When we get control from BIOS there might be mt forcewake
bits already set. This causes us to do double mt get
without proper clear/ack sequence.
Fix this by clearing mt forcewake register on init,
like we do with older gens.
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
BDW is no longer flagged as preliminary hw, but without
i915.preliminary_hw_support module param set the logs are filled with
WARNs about it.
Just make semaphores off the BDW per-chip default for now.
CC: Ben Widawsky <ben@bwidawsk.net>
Reported-by: Sebastien Dufour <sebastien.dufour@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben and I believe this will be necessary on production hardware.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
[danvet: Shuffle lines to group all ROW_CHICKEN writes and add a
cautious comment that this might not be needed on production hw.]
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I believe this will be necessary on production hardware.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Fix whitespace fail spotted by checkpatch. Also add missing
:bdw w/a tag that Ville spotted.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
