An error occurred fetching the project authors.
- 21 Nov, 2012 3 commits
-
-
Paulo Zanoni authored
Also document the WA name for the previous gens that implement it. Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
We need to enable a special bit, otherwise none of the DP functions requiring the PCH will work. Version 2: store the PCH ID inside dev_priv, as suggested by Daniel Vetter. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jean Delvare authored
DIV_ROUND_CLOSEST is faster if the compiler knows it will only be dealing with unsigned dividends. This optimization rips 32 bytes of binary code on x86_64. Signed-off-by:
Jean Delvare <khali@linux-fr.org> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: David Airlie <airlied@linux.ie> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 11 Nov, 2012 14 commits
-
-
Chris Wilson authored
The specs for gen2 say that the watermark values "should always be set assuming a 32bpp display mode, even though the display mode may be 15 or 16 bpp." Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jesse Barnes authored
This allows the power related code to run independently of the rest of the pipeline, extending the resume and init time improvements into userspace, which would otherwise have been blocked on the struct mutex if we were doing PCU communication. v2: Also convert the locking for the rps sysfs interface. Suggested-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v1) Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jesse Barnes authored
Communicating via the mailbox registers with the PCU can take quite awhile. And updating the ring frequency or enabling turbo is not something that needs to happen synchronously, so take it out of our init and resume paths to speed things up (~200ms on my T420). v2: add comment about why we use a work queue (Daniel) make sure work queue is idle on suspend (Daniel) use a delayed work queue since there's no hurry (Daniel) v3: make cleanup symmetric and just call cancel work directly (Daniel) v4: schedule the work using round_jiffies_up to batch work better (Chris) v5: fix the right schedule_delayed_work call (Chris) References: https://bugs.freedesktop.org/show_bug.cgi?id=54089Signed-of-by:
Jesse Barnes <jbarnes@virtuougseek.org> [danvet: bikeshed the placement of the new delayed work, move it to all the other gen6 power mgmt stuff.] Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jesse Barnes authored
Workaround for dual port PS dispatch on GT1. v2: pull in register definition & offset handling v3: use IVB GT1 macro to get the right regs (Ben) v4: add for VLV too (Ben) v5: don't read the reg, it's masked so we'll only enable the one extra bit (Chris) v6: use a _GT2 suffix for the second reg (Chris) Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by:
Antti Koskipää <antti.koskipaa@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jesse Barnes authored
This allows us to get the right vblank interrupt frequency. v2: pull in register definition Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by:
Antti Koskipää <antti.koskipaa@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jesse Barnes authored
References: https://bugs.freedesktop.org/show_bug.cgi?id=50250Reviewed-by:
Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by:
Antti Koskipää <antti.koskipaa@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jesse Barnes authored
v2: use correct register v3: remove extra hunks, pull in register definitions & offset check directly v4: add GT1 vs GT2 distinction for IVB portion (Ben) References: https://bugs.freedesktop.org/show_bug.cgi?id=50233Reviewed-by:
Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by:
Antti Koskipää <antti.koskipaa@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jesse Barnes authored
Needs to be set on every context restore as well, so set it as part of the initial state so we can save/restore it. Note this removes the IVB workaround value from VLV and uses the default value, just adding in the L3 cache aging disable bit, since the IVB value is wrong for VLV. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by:
Antti Koskipää <antti.koskipaa@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
Now that we no longer pretend to have flexibility in matching any north display block with any pch, we can ditch this. v2: Fix the embarassing rebase fail that Paulo Zanoni spotted. Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
Found in Bspec vol4h South Display Engine Registers [CPT, PPT], section "5.3.1 TRANS_CHICKEN_1—Transcoder Chicken Bits 1" v2: Make it compile. Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
We need to set the timing override chicken bit after fdi link training has completed and before we enable the transcoder. We also have to clear that bit again after disabling the pch transcoder. See "Graphics BSpec: vol4g North Display Engine Registers [IVB], Display Mode Set Sequence" and "Graphics BSpec: vol4h South Display Engine Registers [CPT, PPT], South Display Engine Transcoder and FDI Control, Transcoder Debug and DFT, TRANS_CHICKEN_2" bit 31: "Workaround : Enable the override prior to enabling the transcoder. Disable the override after disabling the transcoder." While at it, use the _PIPE macro for the other TRANS_DP register. v2: Keep the w/a as-is, but kill the original (but wrongly placed) workaround introduced in commit 3bcf603f Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Wed Jul 27 11:51:40 2011 -0700 drm/i915: apply timing generator bug workaround on CPT and PPT and commit d4270e57 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Tue Oct 11 10:43:02 2011 -0700 drm/i915: export a CPT mode set verification function Note that this old code has unconditionally set the w/a, which might explain why fdi link training sometimes silently fails, and especially why the auto-train did not seem to work properly. v3: Paulo Zanoni pointed out that this workaround is also required on the LPT PCH. And Arthur Ranyan confirmed that this workaround is requierd for all ports on the pch, not just DP: The important part is that the bit is set whenever the pch transcoder is enabled, and that it is _not_ set while the fdi link is trained. It is also important that the pch transcoder is fully disabled, i.e. we have to wait for bit 30 to clear before clearing the w/a bit. Hence move to workaround into enable/disable_transcoder, where the pch transcoder gets enabled/disabled. v4: Whitespace changes dropped. v5: Don't run the w/a on IBX, we only need it on CPT/PPT and LPT. v6: - resolve conflicts with Paulo's big hsw vga rework - s/!IBX/CPT since hsw paths are now all separate, and Paulo's patch to implement the equivalent w/a for LPT is already merged. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Paulo Zanoni <przanoni@gmail.com> Cc: Arthur Ranyan <arthur.j.runyan@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v5) Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v5) Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Zhenyu Wang authored
Fix power well control state by reading real register offset. Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
Comment says for eaglelake/cantiga, but it's listed in the ilk table, too. So apply it to both. Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 19 Oct, 2012 4 commits
-
-
Damien Lespiau authored
We were programming register 0x42020 twice on those platforms. Once should be enough. Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Damien Lespiau authored
With the consolidated registers, it appears that we're setting the same bis several times. Let's just collect the bits we want to set and program it once. v2: More cleanup. Also program 0x42004 and 0x45000 for FBC on non mobile platforms (Paulo Zanoni) Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> [danvet: Undo the functional change as discussed on irc.] Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Damien Lespiau authored
Register 0x42020 was defined twice under the names PCH_DSPCLK_GATE_D and ILK_DSPCLK_GATE. This patch consolidate the 2 sets of defines in one. The transforms done are: PCH_DSPCLK_GATE_D -> ILK_DSPCLK_GATE_D ILK_DSPCLK_GATE -> ILK_DSPCLK_GATE_D DPARBUNIT_CLOCK_GATE_DISABLE -> ILK_DPARBUNIT_CLOCK_GATE_DISABLE ILK_DPARB_CLK_GATE -> ILK_DPARBUNIT_CLOCK_GATE_DISABLE DPFDUNIT_CLOCK_GATE_DISABLE -> ILK_DPFDUNIT_CLOCK_GATE_DISABLE ILK_DPFD_CLK_GATE -> ILK_DPFDUNIT_CLOCK_GATE_DISABLE ILK_CLK_FBC -> ILK_DPFDUNIT_CLOCK_GATE_DISABLE DPFCRUNIT_CLOCK_GATE_DISABLE -> ILK_DPFCRUNIT_CLOCK_GATE_DISABLE ILK_DPFC_DIS1 -> ILK_DPFCRUNIT_CLOCK_GATE_DISABLE DPFCUNIT_CLOCK_GATE_DISABLE -> ILK_DPFCUNIT_CLOCK_GATE_DISABLE ILK_DPFC_DIS2 -> ILK_DPFCUNIT_CLOCK_GATE_DISABLE We have a VHRUNIT_CLOCK_GATE_DISABLE define for the pre-ILK DSPCLK_GATE_D. Even if the same bit is used in ILK_DSPCLK_GATE_D, other bits in the register change, so I went with re-defining it, well more precisely rename IVB_VRHUNIT_CLK_GATE, which is not specific to IVB+. So: IVB_VRHUNIT_CLK_GATE -> ILK_VHRUNIT_CLOCK_GATE_DISABLE VHRUNIT_CLOCK_GATE_DISABLE -> ILK_VHRUNIT_CLOCK_GATE_DISABLE (ILK+ code) This commit is only a renaming commit, further commits will clean up the logic. v2: Rename bit 5 and 7 to _ENABLE as setting them to 1 enables clock gating on their respective units, contrary to all of the other bits (Paulo Zanoni) Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
Single-threaded forcewake was only used on some early pre-production ivybridge machines, all the latest ones should use mt forcewake. And we already assume this in other places of the code (e.g. DERRMR support in the ddx, or the latest intel_gt_reset patch to reset any lingering forcewake references left behind by the bios), so don't bother here, too. Reviewed-by:
Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 18 Oct, 2012 1 commit
-
-
Chris Wilson authored
Some BIOSes may forcibly suspend RC6 during their operation which trigger a warning as we find the hardware in a perplexing state upon first use. So far that appears to be the worst symptom as fortuituously we use the same values as the BIOS for programming the FORCEWAKE register. Reported-by:
Oleksij Rempel <bug-track@fisher-privat.net> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 17 Oct, 2012 1 commit
-
-
Chris Wilson authored
No functional change, but reserves 0x2 for use by userspace. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 16 Oct, 2012 2 commits
-
-
Ben Widawsky authored
BIOS should be setting the minimum voltage for rc6 to be 450mV. Old or buggy BIOSen may not be doing this, so we correct it for them. Ideally customers should update the BIOS as only it would know the optimal values for the platform, so we leave that fact as a DRM_ERROR for the user to see. Unfortunately this isn't fixing any of the issues it was targeted to fix, but it is documented that we must do it. CC: Jesse Barnes <jbarnes@virtuousgeek.org> CC: Matt Turner <mattst88@gmail.com> Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: bikeshedded loglevel of the "your bios is broken message" to debug.] Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ben Widawsky authored
There is a special mechanism for communicating with the PCU already being used for the ring frequency stuff. As we'll be needing this for other commands, extract it now to make future code less error prone and the current code more reusable. I'm not entirely sure if this code matches 1:1 with the previous code behaviorally. Functionally however, it should be the same. CC: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: Fixup compile fail reported by Wu Fengguang.] Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 12 Oct, 2012 1 commit
-
-
Kenneth Graunke authored
A previous patch, namely: commit bf97b276 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Apr 11 20:42:41 2012 +0200 drm/i915: implement w/a for incorrect guarband clipping accidentally set bit 5 in 3D_CHICKEN, which has nothing to do with clipping. This patch changes it to be set in 3D_CHICKEN3, where it belongs. The game "Dante" demonstrates random clipping issues when guardband clipping is enabled and bit 5 of 3D_CHICKEN3 isn't set. So the workaround is actually necessary. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Oliver McFadden <oliver.mcfadden@linux.intel.com> Acked-by:
Paul Menzel <paulepanter@users.sourceforge.net> Signed-off-by:
Kenneth Graunke <kenneth@whitecape.org> Reviewed-by:
Mika Kuoppala <mika.kuoppala@intel.com> Cc: stable@vger.kernel.org Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 10 Oct, 2012 1 commit
-
-
Paulo Zanoni authored
Introduced in commit 87f8020e: drm/i915: implement WaDisableEarlyCull for VLV and IVB Notice that the original patch sent to the mailing list did not include the Haswell chunk, it was added later. The bit set by the commit does not exist on Haswell machines (at least that's what the documentation says). Also, the commit gives me a GPU hang every time we're loading the driver. So let's revert the Haswell chunk, making the patch do only what its title actually says. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 08 Oct, 2012 2 commits
-
-
Damien Lespiau authored
This workaround is only valid for IVB and VLV and the write triggers an error on HSW. Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
Paulo Zanoni <paulo.r.zanonI@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Damien Lespiau authored
For the next person that checks these kind of things, without having to dig up the register definition. Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 07 Oct, 2012 1 commit
-
-
Damien Lespiau authored
There's is another register (a read only, so no harm done) at 0x42020 on Haswell GPUs. Let's just remove the write from the copy&paste that introduced haswell_init_clock_gating(). A note for the interested reader, it does seem we have a duplication of the 0x42020 register definition, hence the removal of 2 writes. That duplication could be the object of a later patch. Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 04 Oct, 2012 3 commits
-
-
Jesse Barnes authored
Workaround for a culling optimization. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by:
Ben Widawsky <ben@bwidawsk.net> [danvet: Also apply to haswell, spotted by Damien.] Reviewed-by:
"Lespiau, Damien" <damien.lespiau@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jesse Barnes authored
References: https://bugs.freedesktop.org/show_bug.cgi?id=50250Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ben Widawsky authored
I can't even find how I figured this might be needed anymore. But sure enough, the value I'm reading back on platforms doesn't match what the docs recommends. It seemed to fix Chris' GT1 in limited testing as well. Tested-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 26 Sep, 2012 1 commit
-
-
Chris Wilson authored
Finishes commit 02d71956 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Aug 9 16:44:54 2012 +0200 drm/i915: properly guard ilk ips state The core functions were annotated with their locking requirements, but we overlooked that they were exported, without any control over the locking, to debugfs. So in order to enable debugfs to read the registers without triggering sanity checks, we change the exported entry points to properly take the required locks before calling the core routines. Reported-by:
yangguang <guang.a.yang@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55304Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 20 Sep, 2012 2 commits
-
-
Ben Widawsky authored
With the new "standardized" sysfs interfaces we need to be a bit more careful about setting the RPS values. Because the sysfs code and the rps workqueue can run at the same time, if the sysfs setter wins the race to the mutex, the workqueue can come in and set a value which is out of range (ie. we're no longer protecting by RPINTLIM). I was not able to actually make this error occur in testing. Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ben Widawsky authored
In order to keep our cached values in sync with the hardware, we need a posting read here. CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 10 Sep, 2012 1 commit
-
-
Daniel Vetter authored
Currently we've only frobbed this bit at irq_init time, but did not restore it at resume time. Move it to the gen3 clock gating function to fix this. Notice while reading through code. Cc: stable@vger.kernel.org (for 3.5 only) Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 03 Sep, 2012 3 commits
-
-
Ben Widawsky authored
The same designer from the previous patch has told us to never read FORCEWAKE. We only do this for the POSTING_READ(), so simply change that to something within the same cacheline (for no reason in particular other than it sounds nice). In the _mt case we can leverage the gtfifodbg check for the POSTING_READ. This partially reverts commit 6af2d180 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Jul 26 16:24:50 2012 +0200 drm/i915: fix forcewake related hangs on snb v2: commit message, comments about posting read from (Daniel) Note: vlv forcewake doesn't need any changes for this special treatment since FORCEWAKE_VLV is in a totally different register range, and the readback FORCEWAKE_ACK_VLV readback that follows is in the same range. Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Acked-by:
Chris Wilson <chris@chris-wilson.co.uk> [danvet: Added note.] Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ben Widawsky authored
A designer familiar with the hardware has stated that the forcewake timeout can theoretically be as high as a little over 1ms. Therefore we modify our code to use 2ms (appropriate fudge and because we don't want to round down). Hopefully this can't prevent spurious timeouts. Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Acked-by:
Chris Wilson <chris@chris-wilson.oc.uk> [danvet: again fix conflict with vlv patch.] Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ben Widawsky authored
It's used all over the place, and we want to be able to play around with the value, apparently. Note that it doesn't touch other timeouts of the same value (like gtfifo, and thread C0 wait). Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Reviewed-by:
Chris Wilson <chris@chris-wilson.oc.uk> [danvet: fixup conflict with vlv forcewake patches.] Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-