For default graphic window, mixer_win_commit() sets display size
register as fb size. Calling setplane with smaller fb size than
mode size to default window causes distorted display result. So
this patch replaces fb size with mode size for display size from
the mixer_win_commit().
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Acked-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The hdmi outputs black screen only even though under the hood Xorg and
framebuffer console are fine : devices found and initialized, but
not a pixel out.
Commit 93bca243ec ("drm/exynos: remove struct exynos_drm_manager")
changed the call order of mixer_initialize with regards to
exynos_drm_crtc_create.
This changes breaks hdmi out on Odroid U2 (linux-next with added
Marek Szyprowski v4 hdmi patchset from linux-samsung-soc ML).
Restore the previous call ordering get hdmi to ouput proper pixels:
ie call mixer_initialize first then exynos_drm_crtc_create.
Fixes: 93bca243ec ("drm/exynos: remove struct exynos_drm_manager")
Signed-off-by: Alban Browaeys <prahal@yahoo.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Use driver internal struct as argument instead of struct exynos_drm_crtc
except functions of exynos_drm_crtc_ops and instead of struct
exynos_drm_display except functions of exynos_drm_display_ops.
It can reduce unnecessary variable declaration.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
We get wrong pipe value for crtc since commit 93bca243ec ("drm/exynos:
remove struct exynos_drm_manager"). We should should increase pipe value
before call exynos_drm_crtc_create.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The exynos_drm_dmabuf.c file doesn't include any module feature and it
isn't built to module.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The exynos drm driver has DRIVER_PRIME capability, then it's reasonable
to support dmabuf as default. Remove DRM_EXYNOS_DMABUF config, it will
prevent that user selects the option unnecessarily.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
If system provides IOMMU feature, Exynos DRM should use it by default,
because the Exynos DRM subdrivers don't work correctly when Exynos IOMMU
driver has been enabled and no IOMMU support has been compiled into Exynos
DRM driver.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Mixed need to have hdmi clock enabled to properly perform power on/off
sequences, so add handling of this clock directly to the mixer driver.
Dependency between hdmi clock and mixer module has been observed on
Exynos4 based boards.
Suggested-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
- Fixing accounting of active queues
- Preserving a register internal state
* tag 'drm-amdkfd-next-fixes-2015-02-03' of git://people.freedesktop.org/~gabbayo/linux:
drm/amdkfd: Preserve CP_MQD_IQ_RPTR internal state
drm/amdkfd: Fix dqm->queue_count tracking
drm-intel-next-2015-01-30:
- chv rps improvements from Ville
- atomic state handling prep work from Ander
- execlist request tracking refactoring from Nick Hoath
- forcewake code consolidation from Chris&Mika
- fastboot plane config refactoring and skl support from Damien
- some more skl pm patches all over (Damien)
- refactor dsi code to use drm dsi helpers and drm_panel infrastructure (Jani)
- first cut at experimental atomic plane updates (Matt Roper)
- piles of smaller things all over, as usual
* 'drm-intel-next' of git://anongit.freedesktop.org/drm-intel: (102 commits)
drm/i915: Remove bogus locking check in the hangcheck code
drm/i915: Update DRIVER_DATE to 20150130
drm/i915: Use pipe_config's cpu_transcoder for reading encoder hw state
drm/i915: Fix a use-after-free in intel_execlists_retire_requests
drm/i915: Split shared dpll setup out of __intel_set_mode()
drm/i915: Don't do posting reads on getting forcewake
drm/i915: Do uncore early sanitize after domain init
drm/i915: Handle CHV in vlv_set_rps_idle()
drm/i915: Remove nested work in gpu error handling
drm/i915/documentation: Add intel_uncore.c to drm.tmpl
drm/i915/dsi: remove intel_dsi_cmd.c and the unused functions therein
drm/i915/dsi: move dpi_send_cmd() to intel_dsi.c and make it static
drm/i915/dsi: remove old read/write functions in favor of new stuff
drm/i915/dsi: make the vbt panel driver use mipi_dsi_device for transfers
drm/i915/dsi: add drm mipi dsi host support
drm/i915/dsi: switch to drm_panel interface
drm/i915/skl: Enabling PSR on Skylake
Revert "drm/i915: Fix mutex->owner inspection race under DEBUG_MUTEXES"
drm/i915: Be consistent on printing seqnos
drm/i915: Display current hangcheck status in debugfs
...
You can _never_ assert that a lock is not held, except in some very
restricted corner cases where it's guranteed that your code is running
single-threade (e.g. driver load before you've published any pointers
leading to that lock).
In addition the early return breaks a bunch of testcases since with
highly concurrent hangcheck stress tests the reset fails to work and
the test doesn't recover and time out.
This regression has been introduced in
commit b8d24a0656
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date: Wed Jan 28 17:03:14 2015 +0200
drm/i915: Remove nested work in gpu error handling
Aside: It is possible to check whether a given task doesn't hold a
lock, but only when lockdep is enabled, using the lockdep_assert_held
stuff.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88908
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Currently when a mode is rejected the reason is printed as a raw number.
Having to manually decode that to a enum drm_mode_status value is
tiresome. Have the code do the decoding instead and print the result
in a human readable format.
Just having an array of strings indexed with the mode status doesn't
work since the enum includes negative values. So we offset the status
by +3 which makes all the indexes non-negative. Also add a bit of
paranoia into the code to catch out of bounds accesses in case
someone adds more enum values but forgets to update the code.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
DRM_GEM_CMA_HELPER is depend on HAVE_DMA_ATTRS, or it will break the
building. The related error (with allmodconfig under xtensa):
CC [M] drivers/gpu/drm/drm_gem_cma_helper.o
drivers/gpu/drm/drm_gem_cma_helper.c: In function 'drm_gem_cma_create':
drivers/gpu/drm/drm_gem_cma_helper.c:110:19: error: implicit declaration of function 'dma_alloc_writecombine' [-Werror=implicit-function-declaration]
cma_obj->vaddr = dma_alloc_writecombine(drm->dev, size,
^
drivers/gpu/drm/drm_gem_cma_helper.c:110:17: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
cma_obj->vaddr = dma_alloc_writecombine(drm->dev, size,
^
drivers/gpu/drm/drm_gem_cma_helper.c: In function 'drm_gem_cma_free_object':
drivers/gpu/drm/drm_gem_cma_helper.c:193:3: error: implicit declaration of function 'dma_free_writecombine' [-Werror=implicit-function-declaration]
dma_free_writecombine(gem_obj->dev->dev, cma_obj->base.size,
^
drivers/gpu/drm/drm_gem_cma_helper.c: In function 'drm_gem_cma_mmap_obj':
drivers/gpu/drm/drm_gem_cma_helper.c:330:8: error: implicit declaration of function 'dma_mmap_writecombine' [-Werror=implicit-function-declaration]
ret = dma_mmap_writecombine(cma_obj->base.dev->dev, vma,
^
Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Useful to avoid recompiling to disable fbdev. Useful because otherwise
the first modeset happens under console_lock (ie. debugging sadness).
Signed-off-by: Rob Clark <robdclark@gmail.com>
Combining -Werror with all the extra warning flags that W=1 adds doesn't
go so well. Especially because some of the warnings triggered are from
included headers. So just drop -Werror.
Signed-off-by: Rob Clark <robdclark@gmail.com>
In case we request a number of SMP blocks which is lower than
the already reserved blocks, we should not try to allocate a
negative number, but 0 blocks instead.
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
So after clarification from qcom, it seems mdp4 and mdp5 support
*de*interlacing but not generating an interlaced signal. Which would
explain why interlaced modes never worked properly.
So disable in the one connector which was claiming to support
interlaced.
Signed-off-by: Rob Clark <robdclark@gmail.com>
The gnome-shell wayland compositor triggers a setcrtc with an fb that is
still being rendered, triggering the call to _wait_fence_interruptable().
But a NULL timeout means "don't wait, return -EBUSY if not ready", which
in turn causes the setcrtc to fail.
Signed-off-by: Rob Clark <robdclark@gmail.com>
This patch implements the hardware accelarated cursor
support for MDP5 platforms.
Signed-off-by: Beeresh Gopal <gbeeresh@codeaurora.org>
Signed-off-by: Wentao Xu <wentaox@codeaurora.org>
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
In the same idea mdp5_cfg was added, this change allows us to quickly
add new instances, such as apq8084's HDMI in this case.
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
This change add the regulator/clock configuration for MDP5 v1.3.
This config is close to the one already existing for 8x74, except
that one more regulator is needed (hpd-5v-en).
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Instead of reporting BUG_ON when resources arrays are not
dimensioned correctly, this patch does a dynamic allocation of
these arrays. This is needed for the following patches that add a
regulator for a new target.
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
mdp5_ctl_set_intf()'s second argument should be "int", not "enum mdp5_intf".
The passed in value is "intf", not "intf_id".
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Modified the hard-coded hdmi connector/encoder implementations in msm drm
driver to support both edp and hdmi.
V1: Initial change
V2: Address Thierry's change
Signed-off-by: Hai Li <hali@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
This change adds a new eDP connector in msm drm driver. With this
change, eDP panel can work with msm platform under drm framework.
v1: Initial change
v2: Address Rob's comments
Use generated header file for register definitions
Change to devm_* APIs
v3: Address Thierry's comments and rebase on top of atomic changes
Remove edp_bridge_mode_fixup
Remove backlight control code and rely on pwm-backlight
Remove continuous splash screen support for now
Change to gpiod_* APIs
v4: Fix kbuild test issue
Signed-off-by: Hai Li <hali@codeaurora.org>
[robclark: v5: rebase on drm_bridge changes in drm-next]
Signed-off-by: Rob Clark <robdclark@gmail.com>
The patch add support for YUV frame format
for MDP4 platform.
Signed-off-by: Beeresh Gopal <gbeeresh@codeaurora.org>
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
This change adds the NV12 format support for public planes.
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Both MDP4 and MDP5 share some code as far as YUV support is
concerned. This change adds this information and will be followed
by the actual MDP4 and MDP5 YUV support patches.
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Resync from rnndb database, to pull in register defines for:
* eDP
* HDMI/HDCP
* mdp4/mdp5 YUV support
* mdp5 hw cursor support
Signed-off-by: Rob Clark <robdclark@gmail.com>
On !SMP systems spinlocks do not exist. Thus checking of they
are active will always fail.
Use
assert_spin_locked(lock);
instead of
BUG_ON(!spin_is_locked(lock));
to not BUG() on all UP systems.
Signed-off-by: Bruno Prémont <bonbons@linux-vserver.org>
[robclark: drop stray ')']
Signed-off-by: Rob Clark <robdclark@gmail.com>
3d3f8b1f8b ("drm/bridge: make bridge registration independent of drm
flow") resulted that the hdmi bridge object would be leaked at teardown.
Just switch over to devm_kzalloc() as the easy way to solve this.
Signed-off-by: Rob Clark <robdclark@gmail.com>
As a result of atomic DPMS support, the various prepare/commit hooks get
called in a way that msm dislikes. We were expecting prepare/commit to
bracket a modeset, which is no longer the case. This was needed to hold
various extra clk's (such as interface clks) on while we are touching
registers, and in the case of mdp4 holding vblank enabled.
The most straightforward way to deal with this, since we already have
our own atomic_commit(), is to just handle prepare/commit internally to
the driver (with some additional vfuncs for mdp4 vs mdp5), and switch
everything over to instead use the new enable/disable hooks. It doesn't
really change too much, despite the code motion. What used to be in the
encoder/crtc dpms() fxns is split out into enable/disable.
We should be able to drop our own enable-state tracking, as the atomic
helpers should do this for us. But keeping that for the short term for
extra debugging as atomic stablizes.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Only the legacy helpers use these entry points. Don't populate them
with transitional helpers, since that just makes things more confusing.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
[robclark: reword commit msg]
Signed-off-by: Rob Clark <robdclark@gmail.com>
We had _power_up(), but drivers also need to be able to power down.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
The atmel-hlcdc driver selects DRM_GEM_CMA_HELPER which makes use of
symbols only available when HAVE_DMA_ATTRS is selected.
Add a dependency on the ARM architecture which select this option.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
The msm gpu drivers depend on both the DT mechanism and the
common clk handling code, if they are not enabled, we get
a number of build errors:
In file included from drivers/gpu/drm/msm/hdmi/hdmi.h:27:0,
from drivers/gpu/drm/msm/hdmi/hdmi_bridge.c:18:
drivers/gpu/drm/msm/msm_drv.h:45:24: fatal error: mach/board.h: No such file or directory
#include <mach/board.h>
^
drivers/gpu/drm/msm/hdmi/hdmi_phy_8960.c:503:2: error: implicit declaration of function 'devm_clk_register' [-Werror=implicit-function-declaration]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Dave Airlie <airlied@gmail.com>
When page flipping, we need to mark the new fb as active and unmark the active
flag for the old fb (if different).
Signed-off-by: Haixia Shi <hshi@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Dave Airlie <airlied@gmail.com>
The shmobile drm driver selects BACKLIGHT_CLASS_DEVICE
as of 0a5a5499ad "drm: shmobile: Add dependency on
BACKLIGHT_CLASS_DEVICE", but that option in turn depends
on BACKLIGHT_LCD_SUPPORT, so we actually have to select
both, or alternatively use 'depends on BACKLIGHT_CLASS_DEVICE'.
Further, the driver uses FB_SH_MOBILE_MERAM if that is
enabled, but this breaks if MERAM is a module while
the DRM driver is built-in. To solve this, add a dependency
on "FB_SH_MOBILE_MERAM || !FB_SH_MOBILE_MERAM", which forces
DRM_SHMOBILE to be a module if FB_SH_MOBILE_MERAM set to 'm'.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Dave Airlie <airlied@gmail.com>
The newly added sti driver requires the drm_panel helpers,
and we get a link error if they are not enabled
ERROR: "drm_panel_attach" [drivers/gpu/drm/sti/stidvo.ko] undefined!
ERROR: "of_drm_find_panel" [drivers/gpu/drm/sti/stidvo.ko] undefined!
This adds a 'select' statement as we have for the other drivers.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Dave Airlie <airlied@gmail.com>
When the reset controller subsystem is disabled, this driver
fails to build:
drivers/gpu/drm/rockchip/rockchip_drm_vop.c: In function 'vop_initial':
drivers/gpu/drm/rockchip/rockchip_drm_vop.c:1267:2: error: implicit declaration of function 'devm_reset_control_get' [-Werror=implicit-function-declaration]
The easiest solution is to add a dependency in Kconfig to avoid
that case.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Dave Airlie <airlied@gmail.com>
The simple panel code uses the backlight interface to
find a device, which fails when backlight is disabled:
drivers/built-in.o: In function `panel_simple_platform_probe':
:(.text+0xd3c48): undefined reference to `of_find_backlight_by_node'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Dave Airlie <airlied@gmail.com>
The sharp panel code uses the backlight interface to
find a device, which fails when backlight is disabled:
drivers/built-in.o: In function `sharp_panel_probe':
:(.text+0x5ceac): undefined reference to `of_find_backlight_by_node'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Dave Airlie <airlied@gmail.com>
The run-length encoding algorithm should compare 16-bit encoded pixel
values instead of comparing raw pixel values. It allows pixels
with similar but different colors to be encoded as repeat pixels, and
thus potentially save USB bandwidth.
Signed-off-by: Haixia Shi <hshi@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Tested-by: Haixia Shi <hshi@chromium.org>
Signed-off-by: Dave Airlie <airlied@gmail.com>
The get_config() functions for ddi and dp_mst, used to read the value
of cpu_transcoder from the crtc->config instead of the state passed as
an argument. On the hardware state readout path, that happens to work
since the proper value is written to it before encoder->get_config() is
called. However, in the check_crtc() path, the state will be read from
the cpu_transcoder in the software tracking, instead of the one just
read out from hw. Using the field in the supplied intel_crtc_state
should do the right thing in both cases.
v2: Fix intel_ddi_get_config() too. (Ander)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Remove request from list before unreferencing it, in case it's actually
the only reference. (Found by Tvrtko Ursulin)
This issue has been most likely introduced in
commit 6d3d8274bc
Author: Nick Hoath <nicholas.hoath@intel.com>
Date: Thu Jan 15 13:10:39 2015 +0000
drm/i915: Subsume intel_ctx_submit_request in to drm_i915_gem_request
Signed-off-by: Nick Hoath <nicholas.hoath@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This simplifies __intel_set_mode() a little.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The checking for ack and also any subsequent mmio access
will serialize with setting the forcewake bit. Drop the
posting read as superfluous.
Note that in the put side we still want to keep the posting read
as it will ensure that the hw sees our forcewake release in a
timely manner and doesn't keep the hw powered up.
Comment from Chris:
On Wed, Jan 28, 2015 at 05:54:14PM +0200, Mika Kuoppala wrote:
> Ville Syrjälä <ville.syrjala@linux.intel.com> writes:
> > IIRC the posting read from same cache line actually fixed real bugs. So
> > I'm a bit worried about dropping them. But I suppose it's possible only
> > the _put side was important for those bugs.
>
> I found these:
>
> commit 6af2d180f8
> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> Date: Thu Jul 26 16:24:50 2012 +0200
>
> drm/i915: fix forcewake related hangs on snb
>
> commit 8dee3eea3c
> Author: Ben Widawsky <ben@bwidawsk.net>
> Date: Sat Sep 1 22:59:50 2012 -0700
>
> drm/i915: Never read FORCEWAKE
>
> https://bugs.freedesktop.org/show_bug.cgi?id=51738
> https://bugs.freedesktop.org/show_bug.cgi?id=52424
>
> The snb here seems to survive gem_dummy_reloc_loop and
> gem_ring_sync_loop in here with the get side posting removed.
Note that we kept the once associated with #52424, but judging by my
comments in #51738 the posting read is just a band aid anyway as a full
mb() itself was not adequate.
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: paste relevant review discussion in.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
intel_uncore_early_sanitize() will reset the forcewake registers. When
forcewake domains were introduced, the domain init was done after the
sanitization of the forcewake registers. And as the resetting of
registers use the domain accessors, we tried to reset the forcewake
registers with unitialized forcewake domains and failed.
Fix this by sanitizing after all the domains have been initialized. Do
per domain clearing of forcewake register on domain init so that
IVB can do early access to ECOBUS do determine the final configuration.
This regression was introduced in
commit 05a2fb157e
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date: Mon Jan 19 16:20:43 2015 +0200
drm/i915: Consolidate forcewake code
v2: Carve out ellc detect, fw_domain_reset for ivb/ecobus (Chris)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88805
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reported-by: Olof Johansson <olof@lixom.net>
Tested-by: Darren Hart <dvhart@linux.intel.com> (v1)
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>
