Instead of every time it isn't active: We only need to do that when
the pll is currently unused, i.e. when pll->refcount == 0. For
paranoia add a warning for the ibx case where plls have a fixed
mapping and hence should always be unused after the call to
intel_put_shared_dpll.

v2: Simplify control flow and use struct assignment instead of memcpy
as suggested by Damien.
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

With this all hw writes are also gone from the ->crtc_mode_set hook on
vlv. I wondered whether we should track more of the pll state in the
pipe config, but otoh as long as we don't have shared plls that's not
really useful - the cross-checking of the port clock should be
sufficient.

While at it also de-magic some of the pipe checks, this has been
irking me since a long time.

Whit this vlv is now ready for runtime PM on dpms. If we'd have
runtime PM support in general ...
Reviewed-by: NShobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

These two writes are the very last hw writes from the
->crtc_modeset_callback on pre-gen5 hardware. As usual vlv is a bit
different, so this here is just warm-up.
Reviewed-by: NShobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Again the same story: This code just transform sw state from the pipe
config into hardware state. And again we can't move the pll code, but
this time around because the state isn't properly tracked in the pipe
config.
Reviewed-by: NShobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Again this code just transforms sw state from the pipe config into
hardware state, so we can just move it around. Unfortunately again a
few forward declarations since intel_display.c is becoming a bit of a
mess.

Note that both for i9xx and ironlake code the only things remaining in
the ->crtc_mode_set hook is now the clock state computation and
sharing code. That needs to be moved into the compute config stage so
that we can catch impossible configurations earlier.

Also note that some of the DPLL hw setup code is still run from within
->crtc_mode_set, namele the pll->mode_set callback. We need to move
that first before we can do fancy things like enable runtime PM for
dpms off.

v2: Make it compile again after the rebase, bisectability issue
reported by Wu Fengguang.
Reviewed-by: NShobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now this really should be in the pipe config somewhere, but till now
it isn't. We can at least move it up a bit next to all the other pll
code since intel_dp_set_m_n really doesn't depend upon this.

This is just prep work so that moving all the hw frobbing code from
->crtc_mode_set to ->crtc_enable is clean.

v2: Do the same for haswell while at it, not just for ivb.
Reviewed-by: NShobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

All these functions simply convert sw state as encoded in the pipe
config or primary framebuffer into hardware state. So we can move them
all into the crtc enable hook. Unfortunately this means a little bit
of duplication between the i9xx and vlv functions, but since we
already have highly refactored code I think this is acceptable.

Also a pile of forward declarations unfortunately.

Note also that the various <platform>_update_pll functions are still
called from within the ->crtc_mode_set hook. Mostly they compute the
clock state for the pipe config, but unfortunately there are some
random register writes interspersed. Those need to be moved out first
before we can enable runtime PM for DPMS.
Reviewed-by: NShobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Before the process killer is invoked, oom-notifiers are executed for one
last try at recovering pages. We can hook into this callback to be sure
that everything that can be is purged from our page lists, and to give a
summary of how much memory is still pinned by the GPU in the case of an
oom. This should be really valuable for debugging OOM issues.

Note that the last-ditch effort call to shrink_all we've previously
called from our normal shrinker when we could free as much as the vm
demaned is moved into the oom notifier. Since the shrinker accounting
races against bind/unbind operations we might have called shrink_all
prematurely, which this approach with an oom notifier avoids.

References: https://bugs.freedesktop.org/show_bug.cgi?id=72742Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Tested-by: Nlu hua <huax.lu@intel.com>
[danvet: Bikeshed logical | into || and pimp commit message.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We're using the reset domains bits for g4x on ilk. But on ilk those bits
actually shifted by one bit. Fix it up so that we use the correct bits.

We were actually always writing 0x2 to the reset domain bits, which
is a reserved value. In practice it looks like the hardware ignores that
value since nothing happens if I write that value when there's a 3D
workload running. Writing the _correct_ render domain value actually
makes the GPU stop.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We should be waiting for the reset bit to clear, not remain set.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

There are comments in the gen4-5 reset functions stating that we can't
reset render and media without also doing a display reset. But that's
exactly what the code does, ie. we don't perform a display reset. Drop
the bogus comments.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Try to flush out dirty pages into the swapcache (and from there into the
swapfile) when under memory pressure and forced to drop GEM objects from
memory. In effect, this should just allow us to discard unused pages for
memory reclaim and to start writeback earlier.

v2: Hugh Dickins warned that explicitly starting writeback from
shrink_slab was prone to deadlocks within shmemfs.

Cc: Hugh Dickins <hughd@google.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NRobert Beckett <robert.beckett@intel.com>
Reviewed-by: NRafael Barbalho <rafael.barbalho@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We can share a few lines of tricky lock handling we need to use for both
shrinker routines and in the process fix the return value for count()
when reporting a deadlock.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NRobert Beckett <robert.beckett@intel.com>
Reviewed-by: NRafael Barbalho <rafael.barbalho@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When the machine is under a lot of memory pressure and being stressed by
multiple GPU threads, we quite often report fewer than shrinker->batch
(i.e. SHRINK_BATCH) pages to be freed. This causes the shrink_control to
skip calling into i915.ko to release pages, despite the GPU holding onto
most of the physical pages in its active lists.

References: https://bugs.freedesktop.org/show_bug.cgi?id=72742Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NRobert Beckett <robert.beckett@intel.com>
Reviewed-by: NRafael Barbalho <rafael.barbalho@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

shmemfs first checks if there is enough memory to allocate the page
and reports ENOSPC should there be insufficient, along with
the usual ENOMEM for a genuine allocation failure.

We use ENOSPC in our driver to mean that we have run out of aperture
space and so want to translate the error from shmemfs back to
our usual understanding of ENOMEM. None of the the other GEM users
appear to distinguish between ENOMEM and ENOSPC in their error handling,
hence it is easiest to do the fixup in i915.ko

Cc: Hugh Dickins <hughd@google.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NRobert Beckett <robert.beckett@intel.com>
Reviewed-by: NRafael Barbalho <rafael.barbalho@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This patch adds a mmio base address variable for DSI display,
to make the DSI code generic, so that, if required, the same code
can be re-used for future platforms with different mmio base.
Signed-off-by: NShashank Sharma <shashank.sharma@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
[danvet: Appease checkpatch.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We can apperently miss them, but breaking the entire driver hampers
testing. So bail out after one minute, our customerary "this is a lost
cause" timeout.

References: https://bugs.freedesktop.org/show_bug.cgi?id=78383Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

So far we used the wrong opcodes to access the DSI registers, so the
register writes during DSI programming didn't actually succeed and left
the registers unchanged. This wasn't a problem for the initial modeset,
where the BIOS-programmed values happened to work, but after resuming
from s0ix these registers are reset and failing to program them results
in a blank screen.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

These opcodes are not specific for an endpoint, but are the same for all
endpoints. So rename them accordingly, using the name the VLV2 sideband
HAS uses. Also move the macros to the .c file, since they aren't used
anywhere else.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Fixed several switch statements, curly braces, dereference operators
and keywords.
Signed-off-by: NRobin Schroer <sulamiification@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Our two ->crtc_mode_set callbacks really don't care whether the fb is
pinned and set up already or not - all the state computation and
handling which originally looked at the framebuffer is already using
the indirection through the pipe configuration.

Eventually we want to move this up a bit more, but as long as the crtc
mode_set callback still exists (and as long as we don't need to pin an
entire pile of planes due to atomic modesets) there's not much point
in it. So I'll let this be for now.

v2: Don't forget about haswell ...
Reviewed-by: NAkash Goel <akash.goel@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

A lot of the code in set_base is uncessary when the crtc is off, so we
can get rid of it all. Also, we don't need to call the fbc/psr update
functions since the crtc enable/disable hooks do that already.

The only things we really need are:
- Pin the new framebuffer and potentially unpin the old framebuffer
  (if the crtc has been on and we only change the configuration).
- Update the plane registers.

The first step will move out of platform code with the very next
patch.

v2: Don't forget about haswell ...
Reviewed-by: NAkash Goel <akash.goel@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

My plan here is to split up set_base into a prepare step, which does
the pinning, and a commit stage, which updates the hw state. Eventually
we should be able to move the prepare step at the beginning of any
atomic update. For now I only want to move the commit step into the
crtc_enable callbacks.

As a prep step sprinkle intel_edp_psr_update all over the place so
that we don't have to concern ourselves with that in the commit step.

v2: Rebase on top of Ville's enable/disable functions for all planes.

v3: Rebase more.

Reviewed-by: Akash Goel <akash.goel@intel.com> (v2)
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Just for consistency, this patch won't fix anything really.

v2: Rebase over all the recent plane enabling shuffling.

Reviewed-by: Akash Goel <akash.goel@intel.com> (v1)
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Way back we've used this to reject framebuffers with unsupported
pixel formats. But since the modesetting reorg with the compute
config stage we reject those much earlier and just BUG() in this
callback. So switch to a void return type.
Reviewed-by: NAkash Goel <akash.goel@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

More fallout from

commit c8725f3d
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Mar 17 12:21:55 2014 +0000

    drm/i915: Do not call retire_requests from wait_for_rendering

is that we can completely fill all of memory using small objects, such
that we exhaust the filp space, and spend all of our time evicting
objects from the aperture. As such, we never fill the ring, and never
trigger the last resort flushing in

commit 1cf0ba14
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon May 5 09:07:33 2014 +0100

    drm/i915: Flush request queue when waiting for ring space

and so all the requests are left active and the objects keep that last
active reference. Eventually the system comes to a halt as it runs out
of memory.

The impact is mainly limited to test cases as regular userspace will
trigger retirement by manually checking whether an object is active.

Testcase: igt/gem_lut_handle
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78724Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Tested-by: NGuo Jinxian <jinxianx.guo@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Since commit 691e6415
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Apr 9 09:07:36 2014 +0100

    drm/i915: Always use kref tracking for all contexts.

we have contexts everywhere, and so we must be careful to distinguish
fake contexts, which do not have an associated bo, and real ones, which
do. In particular, we now need to be careful not to dereference NULL
pointers.

This is one such example, as the commit highlighted above failed to move
the unpinning of the default ctx object into the real-context-only
branch.
Reported-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78792Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Some platforms have a shared error interrupt, so if FIFO underrun
reporting gets disabled for one pipe/transcoder it gets disabled
for all pipes/transcoders.

When we disable FIFO underrun reporting we check whether the
interrupt was enabled or not. If it wasn't we might have missed
an underrun and we perform one last check right there. Currently
we print a debug message when an underrun is detect using this
mechanism. Promote the message to DRM_ERROR() to match the other
underrun error messages.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

By exporting the ability to map user address and inserting PTEs
representing their backing pages into the GTT, we can exploit UMA in order
to utilize normal application data as a texture source or even as a
render target (depending upon the capabilities of the chipset). This has
a number of uses, with zero-copy downloads to the GPU and efficient
readback making the intermixed streaming of CPU and GPU operations
fairly efficient. This ability has many widespread implications from
faster rendering of client-side software rasterisers (chromium),
mitigation of stalls due to read back (firefox) and to faster pipelining
of texture data (such as pixel buffer objects in GL or data blobs in CL).

v2: Compile with CONFIG_MMU_NOTIFIER
v3: We can sleep while performing invalidate-range, which we can utilise
to drop our page references prior to the kernel manipulating the vma
(for either discard or cloning) and so protect normal users.
v4: Only run the invalidate notifier if the range intercepts the bo.
v5: Prevent userspace from attempting to GTT mmap non-page aligned buffers
v6: Recheck after reacquire mutex for lost mmu.
v7: Fix implicit padding of ioctl struct by rounding to next 64bit boundary.
v8: Fix rebasing error after forwarding porting the back port.
v9: Limit the userptr to page aligned entries. We now expect userspace
    to handle all the offset-in-page adjustments itself.
v10: Prevent vma from being copied across fork to avoid issues with cow.
v11: Drop vma behaviour changes -- locking is nigh on impossible.
     Use a worker to load user pages to avoid lock inversions.
v12: Use get_task_mm()/mmput() for correct refcounting of mm.
v13: Use a worker to release the mmu_notifier to avoid lock inversion
v14: Decouple mmu_notifier from struct_mutex using a custom mmu_notifer
     with its own locking and tree of objects for each mm/mmu_notifier.
v15: Prevent overlapping userptr objects, and invalidate all objects
     within the mmu_notifier range
v16: Fix a typo for iterating over multiple objects in the range and
     rearrange error path to destroy the mmu_notifier locklessly.
     Also close a race between invalidate_range and the get_pages_worker.
v17: Close a race between get_pages_worker/invalidate_range and fresh
     allocations of the same userptr range - and notice that
     struct_mutex was presumed to be held when during creation it wasn't.
v18: Sigh. Fix the refactor of st_set_pages() to allocate enough memory
     for the struct sg_table and to clear it before reporting an error.
v19: Always error out on read-only userptr requests as we don't have the
     hardware infrastructure to support them at the moment.
v20: Refuse to implement read-only support until we have the required
     infrastructure - but reserve the bit in flags for future use.
v21: use_mm() is not required for get_user_pages(). It is only meant to
     be used to fix up the kernel thread's current->mm for use with
     copy_user().
v22: Use sg_alloc_table_from_pages for that chunky feeling
v23: Export a function for sanity checking dma-buf rather than encode
     userptr details elsewhere, and clean up comments based on
     suggestions by Bradley.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: "Gong, Zhipeng" <zhipeng.gong@intel.com>
Cc: Akash Goel <akash.goel@intel.com>
Cc: "Volkin, Bradley D" <bradley.d.volkin@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reviewed-by: NBrad Volkin <bradley.d.volkin@intel.com>
[danvet: Frob ioctl allocation to pick the next one - will cause a bit
of fuss with create2 apparently, but such are the rules.]
[danvet2: oops, forgot to git add after manual patch application]
[danvet3: Appease sparse.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Bit 31 in GEN6_PMINTRMSK is not an interrupt disable bit with gen8.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Otherwise, we do a NULL pointer dereference.

I've seen this happen while handling an error in
i915_gem_object_pin_to_display_plane():

If i915_gem_object_set_cache_level() fails, we call is_pin_display()
to handle the error. At this point, the object is still not pinned
to GGTT and maybe not even bound, so we have to check before we
dereference its GGTT vma.

The IGT kms_flip/bo-too-big tests for this bug.

v2: Chris Wilson says restoring the old value is easier, but that
is_pin_display is useful as a theory of operation. Take the solomonic
decision: at least this way is_pin_display is a little more robust
(until Chris can kill it off).

v3: Chris suggests the WARN in i915_gem_obj_to_ggtt has outlived its
usefulness: add a reminder to remove it.

Issue: VIZ-3772
Signed-off-by: NOscar Mateo <oscar.mateo@intel.com>
Testcase: igt/kms_flip/bo-too-big
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

All the callbacks are gone now.
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Looking at our current dsi driver I note that:
- We don't have any slave driver right now.
- There's zero support for the hardware state readout and cross check
  code.
- All the modeset state seems to be tracked in the intel_dsi structure
  instead of the pipe config.

Given all that I can't properly audit the dsi ->mode_set callback. So
just do it as the first thing in the ->pre_pll_enable hook and hope
for the best.
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

A bit more care required here since there are some very few things
between the call to encoder->mode_set and encoder->pre_enable. But
they're either book-keeping or only matter for the vga port on the
pch. So of no concern.

Note that with the new sequence we write the infoframes after
selecting the clock source, but that shouldn't matter. I've simply
opted for this to have simpler code.
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

All the hard work was already done, only thing left to do is remove
the empty callback. And a now rather misleading comment I've spotted
while reading through code.
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Similar to dp the only thing we do is call intel_write_eld and prepare
a bit of state for the enable hooks. The only difference is that we
write that to the hardware instead of keeping track of it somewhere in
software.

Still we can just move all this to the very first enable hook.
Reviewed-by: NNaresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Those functions are only used on vlv platforms, so no need to check.
Especially if we're not too consistent about it.
Reviewed-by: NNaresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

With all the preceding refactoring the dp mode_set callback only
computes a bit of state (all derived from the pipe config) and also
writes the eld. As long as we do that before we enable the audio bit
or depend upon the correct value in intel_dp->DP we'll be fine.

No other hw state is touched.

We therefore only need to check that clearing intel_dp->DP is save.
Which it is since when we re-enable we already mask out all the bits
the link training code sets. And we need to keep on doing that so that
the re-train loop walking over pre-emph/voltage-swing values still
works properly.
Reviewed-by: NNaresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Only ilk/snb/ivb need the port A pll setup, so move it to the
pre_enable hook for those platforms. We can savely do this since on
those platforms there's nothing that touches the hardware between the
encoder->mode_set and the encoder->pre_enable calls.

Also add a comment that port A is ilk+ only.
Reviewed-by: NNaresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Including state readout and cross-checking. This allows us to get rid
of crtc->eld_vld on hsw+. It also means that fastboot will be unhappy
if the BIOS hasn't set up the audio routing like we want it too.

Wrt fastboot and external screens I see a few options:
- Don't.
- Try to fix up eld, infoframes and audio settings after the fact. But
  that means some pretty extensive reworking of our code which
  currently does all this while the pipe/port is still off.

I won't bother with converting SDVO over to this because the audio
support for SDVO is very lacking:
- We don't update the eld.
- We don't update the audio state on the sdvo encoder.
- We don't check whether the platform can even feed audio to the sdvo
  encoder.

I've converted hdmi, dp & ddi all in one go since ddi needs both hdmi
and dp converted and so doing it step-by-step would have required a
few intermediate hacks.
Reviewed-by: NNaresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>