This patch defines SKL specific PLANE_WM Watermark registers. It also
defines macros to get the addresses of different LP levels within a pipe.
v2: Reworked the register definitions and associated macros to make it more
generic and be able to use for_each_pipe in values computation.
Incorporated Damien's review comments and indentation.
v3: Added default values for lines and blocks. Provided mask for blocks.
v4: Prefix intermedidate (internal-only) macros with _ (Ville)
v5: Remove the lines and block defaults value (Ville)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v4)
Signed-off-by: Pradeep Bhat <pradeep.bhat@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch reads the memory latency values for all the 8 levels for
SKL. These values are needed for the Watermark computation.
v2: Incorporated the review comments from Damien on register
indentation.
v3: Updated the code to use the sandybridge_pcode_read for reading
memory latencies for GEN9.
v4: Don't put gen 9 in the middle of an ordered list of ifs
(Damien)
v5: take the rps.hw_lock around sandybridge_pcode_read() (Damien)
v6: Use gen >= 9 in the pcode_read() function for data1.
Move the defines near the gen6 ones and prefix them with PCODE.
Remove unused timeout define (the pcode_read() code has a larger
timeout already).
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Pradeep Bhat <pradeep.bhat@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There's some serious confusion regarding ELD valid bit that gets set and
cleared back and forth etc. Rewrite it all based on the documented audio
codec enable/disable sequences.
v3: replace vblank wait with a comment
v4: expand the comment on what should be done with the vblank wait
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Make audio related register defines conform to existing style: Add _MASK
where relevant, indent the defines for register contents, don't indent
the defines for register addresses, prefix pipe specific register
address defines with underscores, drop self explanatory comments.
No functional changes.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Userspace cares about whether or not swizzling depends on the page
address for its direct access into bound objects. Extend the get_tiling
ioctl to report the physical swizzling value in addition to the logical
swizzling value so that userspace can accurately determine when it is
possible for manual detiling.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Akash Goel <akash.goel@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Testcase: igt/gem_tiled_wc
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Always require PIN_GLOBAL when we want a mappable offset (PIN_MAPPABLE).
This causes the pin to fixup the global binding in cases were the vma
was already bound (and due to the proceeding bug, we considered it to be
already mappable).
References: https://bugs.freedesktop.org/show_bug.cgi?id=85671
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Add WARN_ON to check that PIN_MAP implies PIN_GLOBAL as
discussed on irc.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We use the obj->map_and_fenceable hint for when we already have a
valid mapping of this object in the aperture. This hint can only apply
to the GGTT and not to the aliasing-ppGTT. One user of the hint is
execbuffer relocation, which began to fail when it tried to follow the
hint and perform the relocate through the non-existent GGTT mapping.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85671
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently we program just DPSCNTR and DSPSTRIDE directly from the ring
interrupt handler, which is fine since the hardware guarantees that
those are update atomically. When we have atomic page flips we'll want
to be able to update also the offset registers, and then we need to use
the vblank evade mechanism to guarantee atomicity. Since that mechanism
introduces a wait, we need to do the actual register write from a work
when it is triggered by the ring interrupt.
v2: Explain the need for mmio_flip.work in the commit message (Paulo)
Initialize the mmio_flip work in intel_crtc_init() (Paulo)
Prevent new flips the previous flip work finishes (Paulo)
Don't acquire modeset locks for mmio flip work
Note: Paulo had reservations about the work item leaking over a plane
disable. But insofar as we do lack these checks that issue is already
present with the existing code.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A follow up patch will call this funcion from a work context for the
mmio flip, in which case we cannot acquire the modeset locks. That's
not a problem though, since the check is there to protect vblank and
the mode, but the code that changes that waits for pending flips
first.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Note that a later patch will use these functions in some other file
and drop the static. Hence the kerneldoc looks appropriate.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Add comment that the functions will become non-static
shortly.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
An earlier commit (c8725f3dc0: Do not call
retire_requests from wait_for_rendering) removed the use of the ring parameter
within wait_rendering__tail() but did not remove the parameter itself. As the
plan is to remove obj->ring which is where this parameter comes from, it is
simpler to just remove the parameter completely than to update it with a new
source.
For: VIZ-4377
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
CC: Chris Wilson <chris@chris-wilson.co.uk>
CC: Brad Volkin <bradley.d.volkin@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With this patch, the RPS sequence for runtime suspend/resume is
exactly like the sequence for S3 suspend/resume:
- flush_delayed_work(&dev_priv->rps.delayed_resume_work)
- intel_runtime_pm_disable_interrupts()
- intel_suspend_gt_powersave()
(suspended)
- intel_runtime_pm_enable_interrupts()
- intel_enable_gt_powersave()
With this, we get rid of WARNs that are currently intermittently
triggered by the system-suspend-execbuf subtest of runtime PM. Notice
that these WARNs could also be triggered in other ways that involved
doing lots of RPM suspend/resume cycles just after a system S3 resume.
Testcase: igt/pm_rpm/system-suspend-execbuf
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=82939
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fix the message, not the fault :)
This is what I see:
[ 282.108597] [drm:i915_check_and_clear_faults] Unexpected fault
[ 282.108597] Addr: 0x00000000\n Address space: PPGTT
[ 282.108597] Source ID: 24
[ 282.108597] Type: 0
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There are two leftover GTIIR writes in valleyview_irq_preinstall().
Looks like the were originally left behind by:
commit d18ea1b58a
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Jul 12 22:43:25 2013 +0200
drm/i915: unify PM interrupt preinstall sequence
and then the GTIIR reset was added back here:
commit f86f3fb005
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date: Tue Apr 1 15:37:14 2014 -0300
drm/i915: properly clear IIR at irq_uninstall on Gen5+
so we can kill the leftovers from the vlv code.
Cc: Paulo Zanoni <przanoni@gmail.com>
Suggested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The extra VLV_IIR writes at the end of vlv_display_irq_postinstall()
serve no purpose. Remove them.
The VLV_IMR/IER/IIR setup at the start of the function also seems a bit
pointless since it doesn't unmask/enable anything. But leave it be for
now.
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>
Split the vlv display irq postinstall code to a separate function so
that we can share it with chv.
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>
Pull the vlv display irq reset code to a new functions. The aim is to
share the code with chv.
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>
Genralize valleyview_display_irqs_install() and
valleyview_display_irqs_uninstall() enough so that they work on chv.
The only difference to vlv here being the third pipe that chv brings.
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>
Looks like we forgot to call gen5_gt_irq_reset() for vlv in the
uninstall phase. Do so.
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>
Replace the hand rolled IIR,IER,IMR disable sequences with
GEN5_IRQ_RESET().
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>
Follow the same ordering rules for the IIR,IER,IMR writes on vlv/chv
that we do on other gen5+ platforms.
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>
Looks like a leftover POSTING_READ(GEN8_PCU_IIR) in
cherryview_irq_preinstall() from some earlier age. GEN5_IRQ_RESET()
already does the posting read so this changes nothing, so kill it.
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>
Replace the hand rolled macros with gen8_gt_irq_reset() and
GEN5_IRQ_RESET() in cherryview_irq_uninstall().
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>
Some has given a name for the DPINVGTT status bitmask, so let's use it
instead of the magic number. Looks more like the chv code now.
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>
When disabling interrupts we do the writes in this order:
IMR,IER,IIR,IIR. But when enabling interrupts we don't do use the
mirrored order, and instead do IIR,IIR,IMR,IER.
I like consistency unless there's a good reason against it, which I
can't think of here, so change the enable order to IIR,IIR,IER,IMR.
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>
It will help future code if this function knows something about of the context
of the display setup object is being pinned for.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Write HWS_PGA address even in execlists mode as the global hardware status
page is still required. This address was previously uninitialized and
HWSP writes would clobber whatever buffer happened to reside at GGTT
address 0.
v2: Break out hardware status page setup into a separate function.
Issue: VIZ-2020
Signed-off-by: Thomas Daniel <thomas.daniel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The function was removed in:
commit 037bde19a4
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu Mar 27 08:24:19 2014 +0000
Revert "drm/i915: Disable/Enable PM Intrrupts based on the current freq."
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The function was removed in:
commit 0e32b39cee
Author: Dave Airlie <airlied@redhat.com>
Date: Fri May 2 14:02:48 2014 +1000
drm/i915: add DP 1.2 MST support (v0.7)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On pre-ddi platforms we don't shut down the link when changing link
training parameters. Except when clock recovery fails too hard and we
restart with channel eq training. Which doesn't make a lot of sense
really, since just stopping/restarting the DP port at this point
violates the modeset sequence documented in the Bspec.
So let's tempt fate and try this.
This patch is motivated by a WARN_ON triggered by
commit bc76e320f2
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue May 20 22:46:50 2014 +0200
drm/i915: Drop now misleading DDI comment from dp_link_down
References: https://bugs.freedesktop.org/show_bug.cgi?id=85670
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Acked-by: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris removed the code using it in:
commit be2d599b5d
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Sep 10 19:52:18 2014 +0100
drm/i915: Remove dead code, i915_gem_verify_gtt
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As Paulo said when introducing the enum, having more types is really
good to document what should go where (int foo(int, int, bool, bool).
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's really part of the "push all new_* state into current state
pointers" done in that function. So let's move it there to make this
clear.
Also, with the conversion done the num_shared_dpll check the function
does in it's loop is enough, so we can drop the check for the dpll
compute callback, too.
Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Now that shared DPLLs configuration is staged, there's no need to track
the current ones in the new pipe_config since those are released before
making the new pipe_config effective.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There's no users left after the conversion to calculate clocks before
disabling crtcs during mode set.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use the infrastructure added in a previous patch to choose shared DPLLs
and calculate clocks before touching the hardware.
v2: Don't set mode_set hooks since dev_priv is kzalloc()'d (Ville)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use the infrastructure added in a previous patch to choose shared DPLLs
and calculate clocks before touching the hardware.
v2: Don't set mode_set hooks since dev_priv is kzalloc()'d (Ville)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use the infrastructure added in a previous patch to choose shared DPLLs
and calculate clocks before touching the hardware.
v2: Don't set mode_set hooks since dev_priv is kzalloc()'d (Ville)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It is possible for a mode set to fail if there aren't shared DPLLS that
match the new configuration requirement or other errors in clock
computation. If that step is executed after disabling crtcs, in the
failure case the hardware configuration is changed and needs to be
restored. Doing those things early will allow the mode set to fail
before actually touching the hardware.
Follow up patches will convert different platforms to use the new
infrastructure.
v2: Keep pll->new_config valid only during mode set (Ville)
Use kmemdup() in i915_shared_dpll_start_config() (Ville)
Restore old pll config if something fails before commit (Ville)
Don't set compute_clock hooks since dev_priv is kzalloc()'d (Ville)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The new struct will be used in a follow up patch to allow a current and
a staged config to exist for the same shared DPLL.
v2: Rebase on by mask_to_refcount()->hweight32() change. (Damien)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This will be used in a follow up patch to properly release shared DPLLs
without relying on the shared_dpll field in pipe_config.
v2: Fix white space error (Ville)
Use hweight32() (Ville)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
More concise. Noticed while reviewing Ander's patch which touched a
lot of the pipe_has_type checks.
v2: Use new_config in one place Ander spotted.
Cc: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
This shouldn't change the behavior of those functions, since they are
called after the new_config is made effective and that points to the
current config. In a follow up patch, the mode set sequence will be
changed so this is called before disabling crtcs, and in that case
those functions should work on the staged config.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
[danvet: Flatten if by moving the check into the WARN.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
execlists_submit_context() always returns 0, which is redundant.
And its name is inaccurate, since it actually submits (up to)
TWO contextS. So we rename it, change it to "void", and remove
the WARN_ON() testing its return value.
Change-Id: Ie225b0eca7754c6093c8b8bd15550b251b6feb82
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If a ring failed to initialise for any reason then the error path would try to
clean up all rings including those that had not yet been allocated. The ring
clean up code did a check that the ring was valid before starting its work.
Unfortunately, that was after it had already dereferenced the ring to obtain a
dev_private pointer.
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When looking at the bug report logs with triggered
WARN_ON, the person doing bug triaging will have to
find exact kernel source and match file/line.
Attach the condition that triggered the WARN_ON
to kernel log. In most cases the context is self
evident and this way we can save developer time.
The drawback is ~16kbytes bigger i915.ko
Signed-off-by: Mika Kuoppala <miku@iki.fi>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When we suspend we turn everything off so the pps should be idle, and we
also (or at least should) disable all power wells which will reset the
power sequencer port assignment. So when we resume all power sequencers
should be in their reset state. However it's at least theoretically
possible that the BIOS would touch the power seuqencer(s), so to be safe
we ought to read out the current port assignment like we do at driver
init time.
To do that we can simply call vlv_initial_power_sequencer_setup() from
the encoder ->reset() hook before calling intel_edp_panel_vdd_sanitize().
There's no danger or clobbering the pps delays since we now have those
stored within intel_dp and we don't change them once initialized.
This will make sure that the vdd state gets correctly tracked post-resume
in case the BIOS enabled it.
We need to shuffle things around a bit to get the locking right, and
while at it, make intel_edp_panel_vdd_sanitize() static and move it
around a bit to avoid a forward declaration.
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The pps timestamp initialization was accidentally lost on vlv/chv in
commit a4a5d2f8a9
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Thu Sep 4 14:54:20 2014 +0300
drm/i915: Track which port is using which pipe's power sequencer
Restore it so that we avoid introducing random delays into the pps operations
during/after driver init time.
Cc: Imre Deak <imre.deak@intel.com>
Reported-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We'll never end up in the hooks with eld[0] unset, as that's checked by
drm_select_eld().
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Introduce functions to enable/disable the audio codec, incorporating the
ELD setup within enable. The disable is initially limited to HSW,
covering exactly what was done previously.
The only functional difference is that ELD valid is no longer set if
there is no connector with ELD, which should be the right thing to do
anyway. Otherwise the sequence remains the same, with warts and all, in
preparation for applying more sanity.
v2: add kernel doc.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
