In preparation for sysfs error state access,
export ref error state ref counting interface.
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In preparation for accessing error state from sysfs, export
error state to string conversion function. Also tuck buffer
error handling inside the function.
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If the crtc is active, we can simply flip a new fb onto it, provided the
other mode setting reqs are met. Otherwise, we'll need to do a full
mode set to re-enable the crtc.
v2: check for crtc active and set mode_changed accordingly
v3: add module parameter, i915.fastboot, to control no fb -> fb flip behavior
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Need better pfit tracking to do this right.
v2: use fastboot param around this hack
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We already fetch and track other state into the main CRTC and encoder
structs, and for fastboot we need to do the same with the mode and clock
data we read out.
v2: fix debug print
v3: use fastboot param around state copy
v4: set clock and flags for crtc here instead of in setup_hw_state
v5: rename function to intel_crtc_mode_from_pipe_config for consistency (Chris)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need this for comparing modes between configuration changes.
The tricky part is to allow us to reuse the new get_clock stuff to
recover the lvds clock on gen2/3 when neither the vbt has an lvds mode
nor the panel a (useful) EDID.
v2: try harder to calulate non-simple pixel clocks (Daniel)
call get_clock after getting the encoder config, needed for pixel multiply
(Jesse)
v3: drop get_clock now that the pixel_multiply has been moved into
get_pipe_config
v4: re-add get_clock; we need to get the pixel multiplier in the
encoder, so need to calculate the clock value after the encoder's
get_config is called
v5: drop hsw clock_get, still needs to be written
v6: add fuzzy clock check (Daniel)
v7: wrap fuzzy clock check under !IS_HASWELL
use port_clock field rather than a new CPU eDP clock field in crtc_config
v8: remove stale pixel_multiplier sets (Daniel)
multiply by pixel_multiplier in 9xx clock get too (Daniel)
v9: make sure we set pixel_multiplier before calling clock_get from mode_get
for LVDS (Daniel)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Add some explanation to the commit message about why we have
to jump through a few hoops. Also remove the rebase-fail hunk from
intel_sdvo.c]
[danvet: Squash in the fixup from Jesse to also call ->get_clock in
the modeset state checker.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Handling all the state properly for fastboot is still not yet done by
far, but we need some way to be able to test what we currently have.
So hide the not-yet-quite-complete stuff behind a module option.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Add a real commit message.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that we painstakingly track the shared pch dplls we can finally
implement pixel mutliplier readout support for pch ports, too.
v2: Undo the temporary hack to disable the sdvo pixel multiplier
cross-checking.
Cc: Imre Deak <imre.deak@intel.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
for file in `ls drivers/gpu/drm/i915/*.c` ; do
sed -i "s/mm.gtt_mtrr/gtt.mtrr/" $file;
done
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Resolve conflict with Damien's FBC_CHIP_DEFAULT no fbc
reason.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The original pte_encode function needed the dev argument so we could do
platform specific handling via IS_GENX, etc. With the merging of a pte
encoding function there should never been a need to quirk away gen
specific details.
The patch doesn't do much but makes the upcoming reworks in gtt/ppgtt/mm
slightly (albeit, ever so) easier.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There isn't any special reason to do this other than it makes it obvious
that the two members are connected.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A previous patch had set up the ppgtt and ggtt to use the same scratch
page, but still kept around both pointers. Kill it, it's not needed and
gets in our way for upcoming cleanups.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Nothing outside of i915_gem_gtt.c and more specifically, the relevant
gen specific init function should need to know about number of PDEs, or
PTEs per PD. Exposing this will only lead to circumventing using the
upcoming VM abstraction.
To accomplish this, move the defines into the .c file, rename the PDE
define to be GEN6, and make the PTE count less of a magic number.
The remaining code in the global gtt setup is a bit messy, but an
upcoming patch will clean that one up.
v2: Don't hardcode number of PDEs (Daniel + Jesse)
Reworded commit message to reflect change.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Not only was there an extra, but since we now kzalloc the error state,
we don't need either.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The DPLL lock bit, and the DPIO phy status bits are read-only and
controlled by the hardware, so they will never be set by the driver.
Mask them out when reading the hw state, so that the state
comparison won't fail.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuosugeek.org>
[danvet: Jesse asked for a code comment and I wholeheartly agree, so
added one.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
i9xx doesn't use pre_enable at all, so we can fold this in now.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that we have the proper pipe config to track this, we don't need
to write any registers any more.
Note that for platforms without DPLL_MD (pre-gen4) which store the
pixel mutliplier in the DPLL register I've decided to keep the
seemingly "redundant" write: The comment right below saying "do this
trice for luck" doesn't instill confidence ...
v2: Drop a few now unnecessary local variables and switch the enable
function to take a struct intel_crtc * to simply arguments.
v3: Rebase on top of the newly-colored BUG_ON.
v4: Amend commit message to alliviate Imre's comment about the
redudant DPLL write for the pixel mutliplier.
Cc: Imre Deak <imre.deak@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In addition to existing stuff we also need to track DPLL_MD on gen4
and vlv. This is prep work so that we can move the dpll enable
sequence out from the ->mode_set callback into the crtc enabling
functions.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The ->pre_enable hook is only used for the cpu edp port on ilk-ivb, so
we can safely move it up across the fdi pll enabling.
Unfortunately we can't (yet) merge in the pre_pll enable hook despite
that only lvds uses it on ilk-ivb: Since the same lvds hook is also
need on i9xx platforms we need to fix up the pll enabling sequence
there, too.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Lots of bangin my head against the wall^UExperiments have shown that
we really need to enable the lvds port before we enable plls. Strangely
that seems to include the fdi rx pll on the pch.
Note that the pch pll assert can fire since the lvds port has it's own
special clock source settings in the DPLL register, which means it
will never have a shared dpll (since there's only one LVDS port).
Anyway, encode this new evidence with a few nice WARNs.
v2: Incorporate review comments from Imre.
- Explain why lvds can't have a shared dpll.
- Update the WARN output.
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Mostly since I _really_ don't want to touch the vlv hell.
No code change, just duplication. Also kill a now seriously outdated
code comment - the remark about the dvo encoder is now handled with
the pipe A quirk.
v2: Update the BUG_ONs as suggested by Jani (both in vlv_ and i9xx_
functions, since the split happens here).
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just yet another prep step to be able to do all this up-front, before
we've set up any of the shared dplls in the new state. This will
eventually be useful for atomic modesetting.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's been splattered over 3 different places all doing random things.
Now we have (mostly) the same sequence as i8xx/i9xx, but all called
from the crtc_enable hook (through the pll->enable function):
- write new dividers
- enable vco and wait for stable clocks
- write again for the pixel mutliplier
I've left the seemingly random 200 usec delay in there, just in case.
Also move the encoder->pre_pll_enable hook into the crtc_enable
function, at the same spot we currently have a hack to enable the lvds
port. Since that hack is now redundant, kill it.
While doing this patch I've learned the hard way that we can only fire
up the LVDS port if both the pch dpll _and_ the fdi rc pll are not yet
enabled. Otherwise things go haywire, at least on cpt.
v2: It is paramount to write the FPx divisors before we enable the
the vco by writing to the DPLL registers, for otherwise the divisors
won't get updated. This is in line with the i8xx/i9xx dpll.
v3: To keep the nice abstraction add a ->mode_set callback to set the
divisors. Also streamline the enabling/disabling code a bit by
removing some cargo-cult duplication and clearing registers where
possible in the ->disable hook.
v4: Remove now unused local variable.
Acked-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Once we've found the the context object programmed in CCID, there's no
need to look the other objects in the list.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A genuine 'static' omission and 2 other warnings triggered by not
including the header where those functions where defined.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Caught with checkpatch.pl.
Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When running on my snb machine, recent kernels display successively:
[drm:intel_update_fbc], fbc set to per-chip default
[drm:intel_update_fbc], fbc disabled per module param
But no module param is set. This happens because the check for the
module parameter uses a variable that has been overridden inside the
"per-chip default" code.
Fix up the logic and add another reason for the FBC to the be disabled.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This function has no user outside of intel_pm.c.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We currently print a DRM_DEBUG_KMS message on the happy path and don't
print anything on the "failed to allocate" path. On some desktop
environments (e.g., Unity) I see the "scheduling delayed FBC enable"
thousands and thousands of times on my dmesg.
So kill the useless message for the happy case, saving a lot of dmesg
space, and properly signal the "kzalloc fail" case.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Zoltan Nyul <zoltan.nyul@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So it appears that I have encountered some bogosity when trying to call
i915_error_printf() with many arguments from print_error_buffers(). The
symptom is that the vsnprintf parser tries to interpret an integer arg
as a character string, the resulting OOPS indicating stack corruption.
Replacing the single call with its 13 format specifiers and arguments
with multiple calls to i915_error_printf() worked fine. This patch goes
one step further and introduced i915_error_puts() to pass the strings
simply.
It may not fix the root cause, but it does prevent my box from dying and
I think helps make print_error_buffers() more friendly.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66077
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Harmonise the completion logic between the non-blocking and normal
wait_rendering paths, and move that logic into a common function.
In the process, we note that the last_write_seqno is by definition the
earlier of the two read/write seqnos and so all successful waits will
have passed the last_write_seqno. Therefore we can unconditionally clear
the write seqno and its domains in the completion logic.
v2: Add the missing ring parameter, because sometimes it is good to have
things compile.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In the introduction of the non-blocking wait, I cut'n'pasted the wait
completion code from normal locked path. Unfortunately, this neglected
that the normal path returned early if the wait returned early. The
result is that read-only waits may return whilst the GPU is still
writing to the bo.
Fixes regression from
commit 3236f57a01 [v3.7]
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Aug 24 09:35:09 2012 +0100
drm/i915: Use a non-blocking wait for set-to-domain ioctl
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66163
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On DevCPT, the control register for Transcoder DP Sync Polarity is
TRANS_DP_CTL, not DP_CTL.
Without this patch, Many call trace occur on CPT machine with DP monitor.
The call trace is like: *ERROR* mismatch in adjusted_mode.flags(expected X,found X)
v2: use intel-crtc to simple patch, suggested by Daniel.
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
[danvet: Extend the encoder->get_config comment to specify that we now
also depend upon intel_encoder->base.crtc being correct. Also bikeshed
s/intel_crtc/crtc/.]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65287
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Our interrupt handler (in hardirq context) could race with the timer
(in softirq context), hence we need to hold the spinlock around the
call to ->hdp_irq_setup in intel_hpd_irq_handler, too.
But as an optimization (and more so to clarify things) we don't need
to do the irqsave/restore dance in the hardirq context.
Note also that on ilk+ the race isn't just against the hotplug
reenable timer, but also against the fifo underrun reporting. That one
also modifies the SDEIMR register (again protected by the same
dev_priv->irq_lock).
To lock things down again sprinkle a assert_spin_locked. But exclude
the functions touching SDEIMR for now, I want to extract them all into
a new helper function (like we do already for pipestate, display
interrupts and all the various gt interrupts).
v2: Add the missing 't' Egbert spotted in a comment.
v3: Actually fix the right misspelled comment (Paulo).
Cc: Egbert Eich <eich@suse.de>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The usual pattern for our sub-function irq_handlers is that they check
for the no-irq case themselves. This results in more streamlined code
in the upper irq handlers.
v2: Rebase on top of the i965g/gm sdvo hpd fix.
Cc: Egbert Eich <eich@suse.de>
Reviewed-by: Egbert Eich <eich@suse.de>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Everywhere the same.
Note that this patch leaves unnecessary braces behind, but the next
patch will kill those all anyway (including the if itself) so I've
figured I can keep the diff a bit smaller.
v2: Rebase on top of the i965g/gm sdvo hpd fix.
Cc: Egbert Eich <eich@suse.de>
Reviewed-by: Egbert Eich <eich@suse.de>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We already have a vfunc for this (and other parts of the hpd storm
handling code already use it).
v2: Rebase on top of the i965g/gm sdvo hpd fix.
Cc: Egbert Eich <eich@suse.de>
Reviewed-by: Egbert Eich <eich@suse.de>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The combination of Paulo's fifo underrun detection code and Egbert's
hpd storm handling code unfortunately made the hpd storm handling code
racy.
To avoid duplicating tricky interrupt locking code over all platforms
start with a bit of refactoring. This patch is the very first step
since in the end the irq storm handling code will handle all hotplug
logic (and so also encapsulate the locking nicely).
v2: Rebase on top of the i965g/gm sdvo hpd fix.
Cc: Egbert Eich <eich@suse.de>
Reviewed-by: Egbert Eich <eich@suse.de>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
By the time we write DEIER in the postinstall hook the interrupt
handler could run any time. And it does modify DEIER to handle
interrupts.
Hence the DEIER read-modify-write cycle for enabling the PCU event
source is racy. Close this races the same way we handle vblank
interrupts: Unconditionally enable the interrupt in the IER register,
but conditionally mask it in IMR. The later poses no such race since
the interrupt handler does not touch DEIMR.
Also update the comment, the clearing has already happened
unconditionally above.
v2: Actually shove the updated comment into the right train^W commit,
as spotted by Paulo.
Cc: Paulo Zanoni <przanoni@gmail.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The haswell unclaimed register handling code forgot to take the
spinlock. Since this is in the context of the non-rentrant interupt
handler and we only have one interrupt handler it is sufficient to
just grab the spinlock - we do not need to exclude any other
interrupts from running on the same cpu.
To prevent such gaffles in the future sprinkle assert_spin_locked over
these functions. Unfornately this requires us to hold the spinlock in
the ironlake postinstall hook where it is not strictly required:
Currently that is run in single-threaded context and with userspace
exlcuded from running concurrent ioctls. Add a comment explaining
this.
v2: ivb_can_enable_err_int also needs to be protected by the spinlock.
To ensure this won't happen in the future again also sprinkle a
spinlock assert in there.
v3: Kill the 2nd call to ivb_can_enable_err_int I've accidentally left
behind, spotted by Paulo.
Cc: Paulo Zanoni <przanoni@gmail.com>
Reviewed-by: Paulo Zanoni <przanoni@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With updates to the spec, we can actually see the context layout, and
how many dwords are allocated. That table suggests we need 70720 bytes
per HW context. Rounded up, this is 18 pages. Looking at what lives
after the current 4 pages we use, I can't see too much important (mostly
it's d3d related), but there are a couple of things which look scary. I
am hopeful this can explain some of our odd HSW failures.
v2: Make the context only 17 pages. The power context space isn't used
ever, and execlists aren't used in our driver, making the actual total
66944 bytes.
v3: Add a comment to the code. (Jesse & Paulo)
Reported-by: "Azad, Vinit" <vinit.azad@intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We forgot to add VLV_DISPLAY_BASE to the VLV sprite registers, which
caused the sprites to not work at all.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The PIPECONF color range bit doesn't appear to be effective, on HDMI
outputs at least. The color range bit in the port register works though,
so let's use it.
I have not yet verified whether the PIPECONF bit works on DP outputs.
This reverts commit 83a2af88f8.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
LPF is short for "low pass filter".
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The current PLL settings produce a rather unstable picture when
I hook up a VLV to my HP ZR24w display via a VGA cable.
According to VLV2A0_DP_eDP_HDMI_DPIO_driver_vbios_notes_9, we should
use the the same LPF coefficients for DAC as we do for HDMI and RBR DP.
And indeed that seems to cure the shivers.
v2: Add the name of the relevant document to the commit message
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If the current GPU frquency is below RPe, and we're asked to increase
it, just go directly to RPe. This should provide better performance
faster than letting the frequency trickle up in response to the up
threshold interrupts.
For now just do it for VLV, since that matches quite closely how VLV
used to operate when the rps delayed timer kept things at RPe always.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
