fix one regression and one endian issue.
* 'drm-fixes-3.18' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon: fix endian swapping in vbios fetch for tdp table
drm/radeon: disable native backlight control on pre-r6xx asics (v2)
Just use the acpi interface. That's what windows uses on this
generation and it's the only thing that seems to work reliably
on these generation parts.
You can still force the native backlight interface by setting
radeon.backlight=1
Bug:
https://bugzilla.kernel.org/show_bug.cgi?id=88501
v2: merge into above if/else block
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
It's magic, but it seems to work.
This fixes a regression introduced in
commit 1bb9e632a0
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue Jul 8 10:02:43 2014 +0200
drm/i915: Only unbind vgacon, not other console drivers
My best guess is that the vga fbdev driver falls over if we rip out
parts of vgacon. Hooray.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82439
Cc: stable@vger.kernel.org (v3.16+)
Reported-and-tested-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
This reverts the regressing
commit 6547fbdbff
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Dec 14 23:38:29 2012 +0100
drm/i915: Implement WaSetupGtModeTdRowDispatch
that causes GPU hangs immediately on boot.
Reported-by: Leo Wolf <jclw@ymail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79996
Cc: stable@vger.kernel.org (v3.8+)
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
[Jani: amended the commit message slightly.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
This is a single patch that fixes the VBLANK machinery after:
7ffd7a6851 drm: Always reject drm_vblank_get() after drm_vblank_off()
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABAgAGBQJUZK8FAAoJEN0jrNd/PrOh4nYP/jmwr7NEyXTLe1KK+Q1oynRf
hh0UtInwq8Y6EffORBlues3wwutXS6dgPwaHuwkytefYBpYmQyWBjQwQoutG7ZQ8
rnwca+bF9M3RvGe4J+hfPIFacIMY2HRatk34vGrNQqy5jlgXxlEo3PRMgGscK/P1
ZQla039fioszgk3MAQRJZKQRXFqJmw51hIJPorAtM4m7rj0NlTpgW4kO/xdo684C
ZDKJGjihWuVTexsSN5H+Q6J73oAnoSXMCnev/bfMXEUr6M4ybij+iGmvELxTxE29
zf0rjO57H4ir9Y6n+rm30492GiipEO1Z+yYJi551Fh86ItOXmF8uyP5GEr5qWxw2
SHXvKp7PieMalsYiXwWpxvg82XTywkbi2f8JWRTQ6zjhmpKcIbUYgyUk3GZl9n/E
dd2ikOyWaGw+UNKy9UqZ0DhJUdigIoxn7AK5MsqbM9HkiFVX35g2Bf3IE10D7kxR
gdU4j4gbCB+7nnWpo+ZaUFueOYHMnXb3pwi9A6CJN8QXIfgKZCfp2mEEFX1Bd/A8
hGxtv0yuhN1MzF2J7A2/1QMLTVXunLjQ8dtQwkJPZKUuJqouAKA8rG8CqlhDlxG2
Gj8SBDhsbTl/hQ+E+BpPONTioqrGUsYr7DDaMTpfHt/OV/XNYmpr+N1tcdEXmgP1
siv74ApcdBvC97zbcjkl
=oKTG
-----END PGP SIGNATURE-----
Merge tag 'drm/tegra/for-3.18-rc5' of git://people.freedesktop.org/~tagr/linux into drm-fixes
drm/tegra: Fixes for v3.18-rc5
This is a single patch that fixes the VBLANK machinery after:
7ffd7a6851 drm: Always reject drm_vblank_get() after drm_vblank_off()
* tag 'drm/tegra/for-3.18-rc5' of git://people.freedesktop.org/~tagr/linux:
drm/tegra: dc: Add missing call to drm_vblank_on()
One modesetting, one gk20a fix.
* 'linux-3.18' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
drm/nouveau/nv50/disp: Fix modeset on G94
drm/gk20a/fb: fix setting of large page size bit
one regression fix.
* tag 'drm-intel-fixes-2014-11-13' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Fix obj->map_and_fenceable across tiling changes
When the CRTC is enabled, make sure the VBLANK machinery is enabled.
Failure to do so will cause drm_vblank_get() to not enable the VBLANK on
the CRTC and VBLANK-synchronized page-flips won't work.
While at it, get rid of the legacy drm_vblank_pre_modeset() and
drm_vblank_post_modeset() calls that are replaced by drm_vblank_on()
and drm_vblank_off().
Reported-by: Alexandre Courbot <acourbot@nvidia.com>
Tested-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Commit 1dce626404 introduced a regression
spotted on several G94 (FDObz #85160). This device seems to expect the
vblank period to be set after setting scale instead of before.
V2: shove this in a separate function
This is a candidate bug-fix for 3.18
Signed-off-by: Roy Spliet <rspliet@eclipso.eu>
Tested-by: Zlatko Calusic <zcalusic@bitsync.net>
Tested-by: Michael Riesch <michael@riesch.at>
Tested-by: "poma" <pomidorabelisima@gmail.com>
Tested-by: Adam Williamson <adamw@happyassassin.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Commit "ltc/gf100-: fix cbc issues on certain boards" moved the setting
of the large page size bit from bar/nvc0 to fb/nvc0. GK20A uses its own
FB device and the change was thus not applied to it - fix this.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
atom scratch register race fix.
* 'drm-fixes-3.18' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon: add locking around atombios scratch space usage
Now exynos drm driver incurs infinite loop issue on multi-platform
reported by Matwey V.Korniliv like below,
http://comments.gmane.org/gmane.comp.video.dri.devel/117622
This issue is because non kms drivers enabled are probed before
a component master tries to bring up. This patch set resolves
the infinite loop issue and also includes fixups relevant to exynos
drm internal issues.
* 'exynos-drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos:
drm/exynos: fix possible infinite loop issue
drm/exynos: g2d: fix null pointer dereference
drm/exynos: resolve infinite loop issue on non multi-platform
drm/exynos: resolve infinite loop issue on multi-platform
While developing MST support I noticed I often got the wrong data
back from a transaction, in a racy fashion. I noticed the scratch
space wasn't locked against concurrent users.
Based on a patch by Alex, but I've made it a bit more obvious when
things are locked.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
As obj->map_and_fenceable computation has changed to only be set when
the object is bound inside the global GTT (and is suitable aligned to a
fence region) we need to accommodate those changes when the tiling is
adjusted. The easiest solution is to unbind from the global GTT if we
are currently fenceable, but will not be after the tiling change.
The bug has been exposed by
commit f8fcadba218fe6d23b2e353fea1cf0a4be4c9454
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Oct 31 13:53:52 2014 +0000
drm/i915: Only mark as map-and-fenceable when bound into the GGTT
which tried to fix an oversight from
commit e6a844687c
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Aug 11 12:00:12 2014 +0200
drm/i915: Force CPU relocations if not GTT mapped
which changed the handling of obj->map_and_fenceable.
Note that the alignment check is a vestige from our attempts to reduce
the alignment requirements of tiled but unfenced buffers on
gen2/3. Also, that was when unbinding from the GTT meant UC writes and
clflushing, so we went to great pains to avoid such.
That leaves the actual bug of setting map_and_fenceable to true if we're
not bound to ggtt, which violates the change introduced in the above
patch. Unbinding in that case really looks like the simplest and safest
option, we have to do it anyway.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85896
Testcase: igt/gem_concurrent_blit/gttX*
Tested-by: huax.lu@intel.com
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: Valtteri Rantala <valtteri.rantala@intel.com>
[Jani: amend commit message per input from Daniel and bisect result from
Valtteri]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
This patch fixes a null pointer dereference issue incurred by
calling g2d_remove when exynos_drm_platform_probe is failed.
cmdlist_pool of g2d is allocated when g2d sub driver is probed.
So if exynos_drm_platform_probe is failed, the g2d sub driver is
not probed and the cmdlist_pool is still NULL.
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This patch resovles the infinite loop issue incurred
when Exyno drm driver is enabled but all kms drivers
are disabled on Exynos board by returning -EPROBE_DEFER
only in case that there is kms device registered.
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This patch resolves temporarily infinite loop issue incurred
when Exynos drm driver is enabled and multi-platform kernel
is used by registering Exynos drm device object only in case
of Exynos SoC. So this patch will be replaced with more generic
way later.
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Black screen, screen corruption, hardware state corruption fixes.
* tag 'drm-intel-fixes-2014-11-07' of git://anongit.freedesktop.org/drm-intel:
drm/i915: safeguard against too high minimum brightness
drm/i915: vlv: fix gunit HW state corruption during S4 suspend
drm/i915: Disable caches for Global GTT.
Use gart rather than vram to avoid having to deal with
the HDP cache.
Port of adfed2b058
(drm/radeon: use gart memory for DMA ring tests)
to the IB tests.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
The power management code calls into the display code for
certain things. If certain power management sysfs attributes
are called before the driver has finished initializing all of
the hardware we can run into problems with uninitialized
modesetting state. Add a check to make sure modesetting
init has completed to the bandwidth update callbacks to
fix this. Can be triggered by the tlp and laptop start
up scripts depending on the timing.
bugs:
https://bugzilla.kernel.org/show_bug.cgi?id=83611https://bugs.freedesktop.org/show_bug.cgi?id=85771
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
CE ram size is 32k/0k/0k for GFX/CS0/CS1 with CIK
Ported from amdgpu driver.
Signed-off-by: Jammy Zhou <Jammy.Zhou@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Never trust (your interpretation of) the VBT. Regression from
commit 6dda730e55
Author: Jani Nikula <jani.nikula@intel.com>
Date: Tue Jun 24 18:27:40 2014 +0300
drm/i915: respect the VBT minimum backlight brightness
causing div by zero if VBT minimum brightness equals maximum brightness.
Despite my attempts I've failed in my detective work to figure out what
the root cause is. This is not the real fix, but we have to do
something.
Reported-by: Mike Auty <mike.auty@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=86551
Cc: stable@vger.kernel.org (v3.17+)
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
During S4 freeze we don't call intel_suspend_complete(), which would
save the gunit HW state, but during S4 thaw/restore events we call
intel_resume_prepare() which restores it, thus ending up in a corrupted
HW state.
Fix this by calling intel_suspend_complete() from the corresponding
freeze_late event handler.
The issue was introduced in
commit 016970beb0
Author: Sagar Kamble <sagar.a.kamble@intel.com>
Date: Wed Aug 13 23:07:06 2014 +0530
CC: Sagar Kamble <sagar.a.kamble@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Global GTT doesn't have pat_sel[2:0] so it always point to pat_sel = 000;
So the only way to avoid screen corruptions is setting PAT 0 to Uncached.
MOCS can still be used though. But if userspace is trusting PTE for
cache selection the safest thing to do is to let caches disabled.
BSpec: "For GGTT, there is NO pat_sel[2:0] from the entry,
so RTL will always use the value corresponding to pat_sel = 000"
- System agent ggtt writes (i.e. cpu gtt mmaps) already work before
this patch, i.e. the same uncached + snooping access like on gen6/7
seems to be in effect.
- So this just fixes blitter/render access. Again it looks like it's
not just uncached access, but uncached + snooping. So we can still
hold onto all our assumptions wrt cpu clflushing on LLC machines.
v2: Cleaner patch as suggested by Chris.
v3: Add Daniel's comment
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=85576
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: James Ausmus <james.ausmus@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Stable@vger.kernel.org
Tested-by: James Ausmus <james.ausmus@intel.com>
Reviewed-by: James Ausmus <james.ausmus@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
During system suspend after connector switch off its dpms field
is set to connector previous dpms state. To properly resume dpms field
should be set to its actual state (off) before resuming to previous dpms state.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Before DPMS off driver disables vblank.
It should be balanced by vblank enable after DPMS on.
The patch fixes issue with page_flip ioctl not being able
to acquire vblank counter introduced by patch:
drm: Always reject drm_vblank_get() after drm_vblank_off()
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
HPD events can be generated by components even if drm_dev is not fully
initialized, to skip such events kms poll initialization should
be performed at the end of load callback followed directly by forced
connection detection.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
In case of error during plane initialization load callback
incorrectly return success, this patch fixes it.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
All KMS objects are destroyed by drm_mode_config_cleanup in proper order
so component drivers should not care about it.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Initialization of vblank with MAX_CRTC caused attempts
to disabling vblanks for non-existing crtcs in case
drm used fewer crtcs. The patch fixes it.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
When screen objects are enabled, the bpp is assumed to be 32, otherwise
it is set to 16.
v2:
* Use u32 instead of u64 for assumed_bpp.
* Fixed mechanism to check for screen objects
* Limit the back buffer size to VRAM.
Signed-off-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Cc: <stable@vger.kernel.org>
The hash key computation in vmw_cmdbuf_res_remove incorrectly didn't take
the resource type into account, contrary to all the other related functions.
This becomes important when the cmdbuf resource manager handles more than
one resource type.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
After:
commit d059f652e7
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
AuthorDate: Fri Jul 25 18:07:40 2014 +0200
drm: Handle legacy per-crtc locking with full acquire ctx
drm_mode_cursor_common() was switched to use drm_modeset_(un)lock_crtc()
which uses full aquire ctx. So dropping/reaquiring the lock via
drm_modeset_(un)lock() directly isn't the right thing to do, as lockdep
kindly points out.
The 'FIXME's about sorting out whether vmwgfx *really* needs to lock-all
for cursor updates still apply.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Tested-by: Thomas Hellstrom <thellstrom@vmware.com>
- dpm stability fixes for SI and KV
- remove an invalid pci id
- kmalloc_array fixes
- minor cleanups
* 'drm-fixes-3.18' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon: remove some buggy dead code
drm/radeon: remove invalid pci id
drm/radeon: dpm fixes for asrock systems
radeon: clean up coding style differences in radeon_get_bios()
drm/radeon: Use drm_malloc_ab instead of kmalloc_array
drm/radeon/dpm: disable ulv support on SI
bunch of DP fixes, and some backlight fix.
* tag 'drm-intel-fixes-2014-10-30' of git://anongit.freedesktop.org/drm-intel:
drm/i915/dp: only use training pattern 3 on platforms that support it
drm/i915: Ignore VBT backlight check on Macbook 2, 1
drm/i915: Fix GMBUSFREQ on vlv/chv
drm/i915: Ignore long hpds on eDP ports
drm/i915: Do a dummy DPCD read before the actual read
Ivybridge + 30" monitor prints a drm error on every modeset, since IVB
doesn't support DP3 we should even bother trying to use it.
This regression has been introduced in
commit 06ea66b6bb
Author: Todd Previte <tprevite@gmail.com>
Date: Mon Jan 20 10:19:39 2014 -0700
drm/i915: Enable 5.4Ghz (HBR2) link rate for Displayport 1.2-capable
devices
Reported-by: Dave Airlie <airlied@redhat.com>
Reference: http://mid.gmane.org/1414566170-9868-1-git-send-email-airlied@gmail.com
Cc: Todd Previte <tprevite@gmail.com>
Cc: stable@vger.kernel.org (3.15+)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The calculation of "num_shader_engines" has a precedence bug because
the right shift happens before the mask, but this variable is never used
so we can just delete it.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
commit c675949ec5
Author: Jani Nikula <jani.nikula@intel.com>
Date: Wed Apr 9 11:31:37 2014 +0300
drm/i915: do not setup backlight if not available according to VBT
prevents backlight setup on Macbook 2,1. Apply quirk to ignore the VBT
check so backlight is set up properly.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81438
Signed-off-by: Jens Stein Jørgensen <jens.s.stein@gmail.com>
Cc: stable@vger.kernel.org (3.15+)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Should avoid kmalloc failures due to large number of array entries.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81991
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Three changes for the Armada DRM driver:
1. Add back the flags which tell the DRM core that we can do vblank. This
was removed in error during the recent restructuring, and came to light
while trying textured Xv rendering.
2. Fixing a refcount leak with Xv overlay.
3. As per recent discussion, the drm_vblank_pre_modeset() calls can cause
deadlock with other changes to generic code. This change prevents those
deadlocks by switching to the drm_crtc_vblank_*() calls instead.
* 'drm-armada-fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
drm/armada: convert to use vblank_on/off calls
drm/armada: fix page_flip refcounting leak
drm/armada: add IRQ support back
vlv_cdclk_freq is in kHz but we need MHz for the GMBUSFREQ divider.
This is a regression from:
commit f8bf63fdcb
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Fri Jun 13 13:37:54 2014 +0300
drm/i915: Kill duplicated cdclk readout code from i2c
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Turning vdd on/off can generate a long hpd pulse on eDP ports. In order
to handle hpd we would need to turn on vdd to perform aux transfers.
This would lead to an endless cycle of
"vdd off -> long hpd -> vdd on -> detect -> vdd off -> ..."
So ignore long hpd pulses on eDP ports. eDP panels should be physically
tied to the machine anyway so they should not actually disappear and
thus don't need long hpd handling. Short hpds are still needed for link
re-train and whatnot so we can't just turn off the hpd interrupt
entirely for eDP ports. Perhaps we could turn it off whenever the panel
is disabled, but just ignoring the long hpd seems sufficient.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Todd Previte <tprevite@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Sometimes we seem to get utter garbage from DPCD reads. The resulting
buffer is filled with the same byte, and the operation completed without
errors. My HP ZR24w monitor seems particularly susceptible to this
problem once it's gone into a sleep mode.
The issue seems to happen only for the first AUX message that wakes the
sink up. But as the first AUX read we often do is the DPCD receiver
cap it does wreak a bit of havoc with subsequent link training etc. when
the receiver cap bw/lane/etc. information is garbage.
A sufficient workaround seems to be to perform a single byte dummy read
before reading the actual data. I suppose that just wakes up the sink
sufficiently and we can just throw away the returned data in case it's
crap. DP_DPCD_REV seems like a sufficiently safe location to read here.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Todd Previte <tprevite@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Dave Airlie
Alex Deucher
Daniel Vetter
Thierry Reding
Roy Spliet
Alexandre Courbot
Chris Wilson
Inki Dae
Jammy Zhou
Jani Nikula
Imre Deak
Rodrigo Vivi
Andrzej Hajda
Sinclair Yeh
Thomas Hellstrom
Rob Clark
Dan Carpenter
jens stein
Wilfried Klaebe
Michel Dänzer
Ville Syrjälä