- 27 Jun, 2019 13 commits
-
-
Andrey Smirnov authored
Replace explicit polling loop with equivalent call to tc_poll_timeout() 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:
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:
-
Andrey Smirnov authored
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:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
-
Rob Herring authored
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. Cc: Sandy Huang <hjc@rock-chips.com> Cc: "Heiko Stübner" <heiko@sntech.de> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: dri-devel@lists.freedesktop.org Cc: linux-rockchip@lists.infradead.org Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20190624215649.8939-2-robh@kernel.org
-
Colin Ian King authored
There is an if block that is missing the { } curly brackets. Add these in. Addresses-Coverity: ("Structurally dead code") Fixes: 94dc57b1 ("drm/mgag200: Rewrite cursor handling") Signed-off-by:Colin Ian King <colin.king@canonical.com> Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20190614143911.21806-1-colin.king@canonical.com
-
Daniel Vetter authored
We're now guaranteed to no longer race against prepare_fb/cleanup_fb, which means we can access ->vaddr without having to hold a lock. Before the previous patches it was fairly easy to observe the cursor ->vaddr being invalid, but that's now gone, so we can upgrade to a full WARN_ON. 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:
-
Daniel Vetter authored
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 authored
irqs are already off. Signed-off-by:
-
Daniel Vetter authored
The crc core code can cope with some late crc, the race is kinda unavoidable. So no need to flush pending workers, they'll complete in time. Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Cc: Haneen Mohammed <hamohammed.sa@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Daniel Vetter authored
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 authored
Just prep work, more will be done here in following 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 authored
Plus add a comment about what it actually protects. It's very little. Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Cc: Haneen Mohammed <hamohammed.sa@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Daniel Vetter authored
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. Cc: Shayenne Moura <shayenneluzmoura@gmail.com> Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Cc: Haneen Mohammed <hamohammed.sa@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Daniel Vetter authored
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. Cc: Shayenne Moura <shayenneluzmoura@gmail.com> Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Cc: Haneen Mohammed <hamohammed.sa@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
- 26 Jun, 2019 27 commits
-
-
Chris Wilson authored
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 authored
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: Gerd Hoffmann <kraxel@redhat.com> Cc: virtualization@lists.linux-foundation.org Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
Emil Velikov <emil.velikov@collabora.com> Acked-by:
Gerd Hoffmann <kraxel@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190527081741.14235-12-emil.l.velikov@gmail.com
-
Emil Velikov authored
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: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Emil Velikov authored
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. Note: the outstanding DRM_AUTH instance is: - (badly coped) legacy DRI1 ioctl, which is a noop Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Emil Velikov authored
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. Note: the outstanding DRM_AUTH instance is: - legacy DRI1 ioctl, which is already neutered Cc: Ben Skeggs <bskeggs@redhat.com> Cc: nouveau@lists.freedesktop.org Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190527081741.14235-8-emil.l.velikov@gmail.com
-
Emil Velikov authored
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: Rob Clark <robdclark@gmail.com> Cc: Sean Paul <sean@poorly.run> Cc: freedreno@lists.freedesktop.org Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Emil Velikov authored
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: Qiang Yu <yuq825@gmail.com> Cc: lima@lists.freedesktop.org Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
Qiang Yu <yuq825@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190527081741.14235-6-emil.l.velikov@gmail.com
-
Emil Velikov authored
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: Inki Dae <inki.dae@samsung.com> Cc: Joonyoung Shim <jy0922.shim@samsung.com> Cc: Seung-Woo Kim <sw0312.kim@samsung.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Tobias Jakobi <tjakobi@math.uni-bielefeld.de> Signed-off-by:
Inki Dae <inki.dae@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190527081741.14235-4-emil.l.velikov@gmail.com
-
Emil Velikov authored
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:
Christian Gmeiner <christian.gmeiner@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190527081741.14235-3-emil.l.velikov@gmail.com
-
Emil Velikov authored
Currently vmw_execbuf_ioctl() open-codes the permission checking, size extending and copying that is already done in core drm. Kill all the duplication, adding a few comments for clarity. Cc: VMware Graphics <linux-graphics-maintainer@vmware.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by:
-
Emil Velikov authored
According to the docs - prevents firstopen/lastclose races. Yet never used in practise. Cc: VMware Graphics <linux-graphics-maintainer@vmware.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Emil Velikov authored
Core DRM is safe when the callback is NULL. Cc: VMware Graphics <linux-graphics-maintainer@vmware.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Emil Velikov authored
Cc: Ben Skeggs <bskeggs@redhat.com> Cc: nouveau@lists.freedesktop.org Signed-off-by:
-
Emil Velikov authored
DRM_UNLOCKED doesn't do anything for non-legacy drivers. Remove it. Cc: intel-gfx@lists.freedesktop.org Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190522154702.16269-3-emil.l.velikov@gmail.com
-
Emil Velikov authored
DRM_UNLOCKED doesn't do anything for non-legacy drivers. Remove it. Cc: Thierry Reding <treding@nvidia.com> Cc: linux-tegra@vger.kernel.org Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190522154702.16269-1-emil.l.velikov@gmail.com
-
Jerry Han authored
The Boe Himax8279d is a 8.0" panel with a 1200x1920 resolution and connected to DSI using four lanes. V8: - Modify communication address V7: - Add the information of the reviewer V6: - Add the information of the reviewer V5: - Added changelog V4: - None V3: - None V2: - Add compatible device "boe,himax8279d10p" (Sam) - Add the necessary property descriptions (Sam) 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:
-
Marek Vasut authored
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:
-
Guido Günther authored
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. Signed-off-by:
Guido Günther <agx@sigxcpu.org> Reviewed-by:
-
Guido Günther authored
Document the vcc-supply and iovcc-supply properties of the Rocktech jh057n00900 panel. Signed-off-by:
-
Guido Günther authored
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. Signed-off-by:
-
Guido Günther authored
Add a mail alias as reviewer for the rocktech jh057n00900 panel driver. Signed-off-by:
-
Robert Chiras authored
This patch adds Raydium RM67191 TFT LCD panel driver (MIPI-DSI protocol). Signed-off-by:
Robert Chiras <robert.chiras@nxp.com> Reviewed-by:
Fabio Estevam <festevam@gmail.com> Signed-off-by:
-
Robert Chiras authored
Add dt-bindings documentation for Raydium RM67191 DSI panel. Signed-off-by:
-
Paul Cercueil authored
The Sharp LS020B1DD01D is a simple 2.0" 240x160 16-bit TFT panel. Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Tested-by:
Artur Rojek <contact@artur-rojek.eu> Reviewed-by:
-
Paul Cercueil authored
Add the DRM_BUS_FLAG_SHARP_SIGNALS to the drm_bus_flags enum. This flags can be used when the display must be driven with the Sharp-specific signals SPL, CLS, REV, PS. Signed-off-by:
-
Paul Cercueil authored
The LS020B1DD01D is a 2.0" 240x160 16-bit TFT LCD panel. Signed-off-by:
-
Paul Cercueil authored
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. Signed-off-by:
Maarten ter Huurne <maarten@treewalker.org> Reviewed-by:
-
