Andrey Smirnov [Wed, 19 Jun 2019 05:27:04 +0000 (22:27 -0700)]
drm/bridge: tc358767: Simplify polling in tc_link_training()
Replace explicit polling in tc_link_training() with equivalent call to
tc_poll_timeout() for simplicity. No functional change intended (not
including slightly altered debug output).
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Andrey Gusakov <andrey.gusakov@cogentembedded.com> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Cory Tusar <cory.tusar@zii.aero> Cc: Chris Healy <cphealy@gmail.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190619052716.16831-4-andrew.smirnov@gmail.com
Andrey Smirnov [Wed, 19 Jun 2019 05:27:02 +0000 (22:27 -0700)]
drm/bridge: tc358767: Simplify tc_poll_timeout()
Implementation of tc_poll_timeout() is almost a 100% copy-and-paste of
the code for regmap_read_poll_timeout(). Replace copied code with a
call to the original. While at it change tc_poll_timeout to accept
"struct tc_data *" instead of "struct regmap *" for brevity. No
functional change intended.
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Andrey Gusakov <andrey.gusakov@cogentembedded.com> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Cory Tusar <cory.tusar@zii.aero> Cc: Chris Healy <cphealy@gmail.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190619052716.16831-2-andrew.smirnov@gmail.com
The panel bindings are outside the scope of the Rockchip LVDS interface
binding. The references are about to change too, so rather than update
them just drop the section on the panel bindings.
Daniel Vetter [Thu, 6 Jun 2019 22:27:50 +0000 (00:27 +0200)]
drm/vkms: totally reworked crc data tracking
The crc computation worker needs to be able to get at some data
structures and framebuffer mappings, while potentially more atomic
updates are going on. The solution thus far is to copy relevant bits
around, but that's very tedious.
Here's a new approach, which tries to be more clever, but relies on a
few not-so-obvious things:
- crtc_state is always updated when a plane_state changes. Therefore
we can just stuff plane_state pointers into a crtc_state. That
solves the problem of easily getting at the needed plane_states.
- with the flushing changes from previous patches the above also holds
without races due to the next atomic update being a bit eager with
cleaning up pending work - we always wait for all crc work items to
complete before unmapping framebuffers.
- we also need to make sure that the hrtimer fires off the right
worker. Keep a new distinct crc_state pointer, under the
vkms_output->lock protection for this. Note that crtc->state is
updated very early in the atomic commit, way before we arm the
vblank event - the vblank event should always match the buffers we
use to compute the crc. This also solves an issue in the hrtimer,
where we've accessed drm_crtc->state without holding the right locks
(we held none - oops).
- in the worker itself we can then just access the plane states we
need, again solving a bunch of ordering and locking issues.
Accessing plane->state requires locks, accessing the private
vkms_crtc_state->active_planes pointer only requires that the memory
doesn't get freed too early.
The idea behind vkms_crtc_state->active_planes is that this would
contain all visible planes, in z-order, as a first step towards a more
generic blending implementation.
Note that this patch also fixes races between prepare_fb/cleanup_fb
and the crc worker accessing ->vaddr.
Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Cc: Haneen Mohammed <hamohammed.sa@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Tested-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190606222751.32567-10-daniel.vetter@ffwll.ch
Daniel Vetter [Thu, 6 Jun 2019 22:27:47 +0000 (00:27 +0200)]
drm/vkms: flush crc workers earlier in commit flow
Currently, we flush pending CRC workers very late in the commit flow,
when we destroy all the old crtc states. Unfortunately, at that point,
the framebuffers are already unpinned (and our vaddr possible gone), so
this isn't good. Also, the plane_states we need might also already be
cleaned up, since cleanup order of state structures isn't well defined.
Fix this by waiting for all CRC workers of the old state to complete
before we start any of the cleanup work. For correct ordering and
avoiding races, we can only flush_work after
drm_atomic_helper_wait_for_vblanks() since we know that all subsequent
queue_work will be for the new state. Only once that's done is
flush_work() useful, before that we might flush the work, and then right
after the hrtimer that simulates vblank queues it again. Every time you
have a flush_work before cleaning up the work structure, the following
sequence must be obeyed, or it can go wrong:
1. Make sure no one else can re-queue the work anymore (in our case
that's done by a combination of first updating output->crc_state and
then waiting for the vblank to pass to make sure the hrtimer has noticed
that change).
2. flush_work()
3. Actually clean up stuff (which isn't done here).
Doing the flush_work before we even completed the output->state update,
much less waited for the vblank to make sure that's happened, missed the
point.
Note that this is not yet race-free because of the hrtimer and crc
worker look at the wrong state pointers, but that will be fixed in
subsequent patches.
Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Cc: Haneen Mohammed <hamohammed.sa@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Tested-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190606222751.32567-7-daniel.vetter@ffwll.ch
Daniel Vetter [Thu, 6 Jun 2019 22:27:43 +0000 (00:27 +0200)]
drm/vkms: Use spin_lock_irq in process context
The worker is always in process context, no need for the _irqsafe
version. Same for the set_source callback, that's only called from the
debugfs handler in a syscall.
Daniel Vetter [Thu, 6 Jun 2019 22:27:42 +0000 (00:27 +0200)]
drm/vkms: Fix crc worker races
The issue we have is that the crc worker might fall behind. We've
tried to handle this by tracking both the earliest frame for which it
still needs to compute a crc, and the last one. Plus when the
crtc_state changes, we have a new work item, which are all run in
order due to the ordered workqueue we allocate for each vkms crtc.
Trouble is there's been a few small issues in the current code:
- we need to capture frame_end in the vblank hrtimer, not in the
worker. The worker might run much later, and then we generate a lot
of crc for which there's already a different worker queued up.
- frame number might be 0, so create a new crc_pending boolean to
track this without confusion.
- we need to atomically grab frame_start/end and clear it, so do that
all in one go. This is not going to create a new race, because if we
race with the hrtimer then our work will be re-run.
- only race that can happen is the following:
1. worker starts
2. hrtimer runs and updates frame_end
3. worker grabs frame_start/end, already reading the new frame_end,
and clears crc_pending
4. hrtimer calls queue_work()
5. worker completes
6. worker gets re-run, crc_pending is false
Explain this case a bit better by rewording the comment.
v2: Demote warning level output to debug when we fail to requeue, this
is expected under high load when the crc worker can't quite keep up.
Chris Wilson [Wed, 26 Jun 2019 09:43:30 +0000 (10:43 +0100)]
drm: Allow range of 0 for drm_mm_insert_node_in_range()
We gracefully handle the caller specifying a zero range, so don't force
them to special case that condition if it naturally falls out of their
setup. What we don't check is if the end < start, so keep that as an
assert for an illegal call.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190626094330.3556-1-chris@chris-wilson.co.uk
Emil Velikov [Mon, 27 May 2019 08:17:31 +0000 (09:17 +0100)]
drm/etnaviv: drop DRM_AUTH usage from the driver
The authentication can be circumvented, by design, by using the render
node.
From the driver POV there is no distinction between primary and render
nodes, thus we can drop the token.
Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Christian Gmeiner <christian.gmeiner@gmail.com> Cc: etnaviv@lists.freedesktop.org Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190527081741.14235-3-emil.l.velikov@gmail.com
Signed-off-by: Jerry Han <jerry.han.hq@gmail.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Derek Basehore <dbasehore@chromium.org> Cc: Jitao Shi <jitao.shi@mediatek.com> Cc: Rock wang <rock_wang@himax.com.cn> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190425031842.17202-1-jerry.han.hq@gmail.com
The ETM0700G0DH6 is currently documented as using edt,etm070080dh6
compatible string, however the Linux kernel driver as well as a
couple of DTs use edt,etm0700g0dh6 compatible string. Add it into
the documentation.
Signed-off-by: Marek Vasut <marex@denx.de> Cc: Rob Herring <robh+dt@kernel.org> Cc: Jan Tuerk <jan.tuerk@emtrion.com> Cc: Thierry Reding <treding@nvidia.com> Cc: devicetree@vger.kernel.org
To: dri-devel@lists.freedesktop.org Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190503154749.5630-1-marex@denx.de
Guido Günther [Wed, 26 Jun 2019 10:37:51 +0000 (12:37 +0200)]
drm/panel: jh057n00900: Add regulator support
Allow to specify regulators for vcc and iovcc. According to the data
sheet the panel wants vcc (2.8V) and iovcc (1.8V) and there's no startup
dependency between the two.
Guido Günther [Wed, 26 Jun 2019 10:37:49 +0000 (12:37 +0200)]
drm/panel: jh057n00900: Don't use magic constant
0xBF isn't in any ST7703 data sheet so mark it as unknown. This avoids
confusion on whether there is a missing command in that
dsi_generic_write_seq() call.
Paul Cercueil [Mon, 3 Jun 2019 15:25:55 +0000 (17:25 +0200)]
drm/panel: Add Novatek NT39016 panel support
Add support for display panels built around the Novatek NT39016 display
controller, as found on e.g. the King Display KD035G6-54NT 24-bit
320x240 3.5" LCD panel which equips the GCW Zero open-source handheld
gaming console.
Paul Cercueil [Wed, 5 Jun 2019 22:22:46 +0000 (00:22 +0200)]
media: uapi: Add MEDIA_BUS_FMT_RGB888_3X8 media bus format
This patch adds MEDIA_BUS_FMT_RGB888_3X8, used for the GiantPlus
GPM940B0 24-bit TFT panel, where the RGB components are transferred
sequentially on a 8-bit bus.
Daniel Vetter [Fri, 14 Jun 2019 20:36:01 +0000 (22:36 +0200)]
drm/msm: Drop robj from msm_gem_new_impl
Only user was the prime import, and drm_prime.c takes care of that
now.
Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Acked-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Sean Paul <sean@poorly.run> Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20190614203615.12639-46-daniel.vetter@ffwll.ch
Daniel Vetter [Fri, 14 Jun 2019 20:35:58 +0000 (22:35 +0200)]
drm/etnaviv: Drop resv argument from etnaviv_gem_new_impl
Only user was the prime import, and drm_prime.c takes care of that
now.
Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Russell King <linux+etnaviv@armlinux.org.uk> Cc: Christian Gmeiner <christian.gmeiner@gmail.com> Cc: etnaviv@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20190614203615.12639-43-daniel.vetter@ffwll.ch
Daniel Vetter [Fri, 14 Jun 2019 20:36:00 +0000 (22:36 +0200)]
drm/mediatek: Use drm_atomic_helper_wait_for_fences
If we use the gem fb helper as the prepare_fb hook, plus the
drm_prime.c import helpers now automatically setting obj->resv, we can
use the shared helpers to wait for fences instead of rolling our own.
Note that this relies on mtk setting drm_fb->obj, which is already
done in mtk_drm_framebuffer_init().
Aside: Probably can use the default commit_tail with this again, but I
didn't check for that.
Reviewed-by: CK Hu <ck.hu@mediatek.com> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: CK Hu <ck.hu@mediatek.com> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-mediatek@lists.infradead.org Link: https://patchwork.freedesktop.org/patch/msgid/20190614203615.12639-45-daniel.vetter@ffwll.ch
Ville Syrjälä [Thu, 20 Jun 2019 14:26:37 +0000 (17:26 +0300)]
drm: WARN on illegal aspect ratio when converting a mode to umode
WARN if the incoming drm_display_mode has an illegal aspect ratio
when converting it to a user mode. This should never happen unless
the driver made a mistake and put an invalid value into the aspect
ratio.
Maxime Ripard [Mon, 24 Jun 2019 08:40:16 +0000 (10:40 +0200)]
drm/connector: Fix warning in debug message
The commit 555697d726f0 ("drm/modes: Support modes names on the command
line") added name support to the DRM modes, and added that name to the
debug message.
However, that code tests for whether or not the name variable is NULL and
only prints it if it's not. Except that that variable is an array, so it
will never be NULL.
The original intent was to print it only when the name has been specified.
Just printing the array directly will achieve the same thing since the
drm_cmdline_mode structure that holds it is itself contained in
drm_connector, that is allocated with its whole content zero'd.
That means that if the name is not declared, the array will be all zeros,
which will not print anything.
Cc: Nick Desaulniers <ndesaulniers@google.com> Reported-by: kbuild test robot <lkp@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Fixes: 555697d726f0 ("drm/modes: Support modes names on the command line") Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190624084016.12937-1-maxime.ripard@bootlin.com
Matt Redfearn [Tue, 30 Apr 2019 08:17:04 +0000 (08:17 +0000)]
drm/bridge/synopsys: dsi: Allow VPG to be enabled via debugfs
The Synopsys MIPI DSI IP contains a video test pattern generator which
is helpful in debugging video timing with connected displays.
Add a debugfs directory containing files which allow the VPG to be
enabled and disabled, and its orientation to be changed.
drm/lima: Reduce the amount of logs on deferred probe of clocks and reset controller
There is no point to print deferred probe messages as errors. Adjust
the printks for error paths of obtaining clocks and reset controller.
This removes the error message of lima_clk_init() call in favor or
specific failure messages inside.
drm/lima: Reduce the amount of logs on deferred probe
There is no point to print deferred probe (and its failures to get
resources) as an error. For example getting a regulator causes three
unneeded error messages:
lima 13000000.gpu: failed to get regulator: -517
lima 13000000.gpu: regulator init fail -517
lima 13000000.gpu: Fatal error during GPU init
Also do not print clock rates before the initialization finishes
because they will be duplicated after deferral. Each probe step already
prints error so remove the final error message "Fatal error during GPU
init".
In case of multiple probe tries this would pollute the dmesg.
Daniel Vetter [Fri, 14 Jun 2019 20:36:04 +0000 (22:36 +0200)]
drm/vgem: Ditch attach trickery in the fence ioctl
It looks like this was done purely to get a consistent place to look
up the reservation object pointer. With the drm_prime.c helper code
now also setting gem_object->resv for imported objects we can just use
that pointer directly, instead of first ensuring a dma-buf exists.
v2: Note that I screwed up the patch ordering, hence why this needed
a Fixes: tag - CI spotted the broken intermediate state.
Daniel Vetter [Fri, 14 Jun 2019 20:35:57 +0000 (22:35 +0200)]
drm/prime: automatically set gem_obj->resv on import
It's really the only reasonable thing to do, and it won't hurt drivers
which don't (yet) use drm_gem_object->resv.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190614203615.12639-42-daniel.vetter@ffwll.ch
Daniel Vetter [Fri, 14 Jun 2019 20:35:45 +0000 (22:35 +0200)]
drm/sti: Drop drm_gem_prime_export/import
They're the default.
Aside: Would be really nice to switch the others over to
drm_gem_object_funcs.
Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Vincent Abriou <vincent.abriou@st.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190614203615.12639-30-daniel.vetter@ffwll.ch
Daniel Vetter [Fri, 14 Jun 2019 20:35:37 +0000 (22:35 +0200)]
drm/msm: Drop drm_gem_prime_export/import
They're the default.
Aside: Would be really nice to switch the others over to
drm_gem_object_funcs.
Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Sean Paul <sean@poorly.run> Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20190614203615.12639-22-daniel.vetter@ffwll.ch
Daniel Vetter [Fri, 14 Jun 2019 20:35:36 +0000 (22:35 +0200)]
drm/meson: Drop drm_gem_prime_export/import
They're the default.
Aside: Would be really nice to switch the others over to
drm_gem_object_funcs.
Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Kevin Hilman <khilman@baylibre.com> Cc: linux-amlogic@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Link: https://patchwork.freedesktop.org/patch/msgid/20190614203615.12639-21-daniel.vetter@ffwll.ch
Daniel Vetter [Fri, 14 Jun 2019 20:35:35 +0000 (22:35 +0200)]
drm/mtk: Drop drm_gem_prime_export/import
They're the default.
Aside: Would be really nice to switch the others over to
drm_gem_object_funcs.
Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: CK Hu <ck.hu@mediatek.com> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-mediatek@lists.infradead.org Link: https://patchwork.freedesktop.org/patch/msgid/20190614203615.12639-20-daniel.vetter@ffwll.ch
Daniel Vetter [Fri, 14 Jun 2019 20:35:32 +0000 (22:35 +0200)]
drm/hisilicon: Drop drm_gem_prime_export/import
They're the default.
Aside: Would be really nice to switch the others over to
drm_gem_object_funcs.
Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Xinliang Liu <z.liuxinliang@hisilicon.com> Cc: "Noralf Trønnes" <noralf@tronnes.org> Cc: CK Hu <ck.hu@mediatek.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20190614203615.12639-17-daniel.vetter@ffwll.ch
projects / kernel.git / log