- 21 Jun, 2019 25 commits
-
-
Daniel Vetter authored
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: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20190614203615.12639-25-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
They're the default. Aside: Would be really nice to switch the others over to drm_gem_object_funcs. Reviewed-by:
-
Daniel Vetter authored
They're the default. Aside: Would be really nice to switch the others over to drm_gem_object_funcs. Reviewed-by:
Stefan Agner <stefan@agner.ch> Signed-off-by:
-
Daniel Vetter authored
They're the default. Aside: Would be really nice to switch the others over to drm_gem_object_funcs. Reviewed-by:
-
Daniel Vetter authored
They're the default. Aside: Would be really nice to switch the others over to drm_gem_object_funcs. Reviewed-by:
Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
-
Daniel Vetter authored
They're the default. Aside: Would be really nice to switch the others over to drm_gem_object_funcs. Reviewed-by:
CK Hu <ck.hu@mediatek.com> Signed-off-by:
-
Daniel Vetter authored
They're the default. Aside: Would be really nice to switch the others over to drm_gem_object_funcs. Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Daniel Vetter authored
They're the default. Aside: Would be really nice to switch the others over to drm_gem_object_funcs. Reviewed-by:
-
Daniel Vetter authored
They're the default. Aside: Would be really nice to switch the others over to drm_gem_object_funcs. Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
-
Daniel Vetter authored
They're the default. Aside: Would be really nice to switch the others over to drm_gem_object_funcs. Reviewed-by:
-
Daniel Vetter authored
They're the default. We can't do the same on the import side, due to the exynos_drm->dma_dev not necessarily matching the overall drm device. Aside: Would be really nice to switch the others over to drm_gem_object_funcs. Reviewed-by:
-
Daniel Vetter authored
They're the default. Aside: Would be really nice to switch the others over to drm_gem_object_funcs. Reviewed-by:
Christian Gmeiner <christian.gmeiner@gmail.com> Reviewed-by:
-
Daniel Vetter authored
They're the default. Aside: Would be really nice to switch the others over to drm_gem_object_funcs. Reviewed-by:
-
Daniel Vetter authored
They're the default. Aside: Would be really nice to switch the others over to drm_gem_object_funcs. Reviewed-by:
James Qian Wang (Arm Technology China) <james.qian.wang@arm.com> Acked-by:
Liviu Dudau <liviu.dudau@arm.com> Signed-off-by:
-
Daniel Vetter authored
They're the default. Aside: Would be really nice to switch the others over to drm_gem_object_funcs. Reviewed-by:
-
Daniel Vetter authored
This completes Emil's series of removing DRM_UNLOCKED from modern drivers. It's entirely cargo-culted since we ignore it on non-DRIVER_LEGACY drivers since: commit ea487835 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Sep 28 21:42:40 2015 +0200 drm: Enforce unlocked ioctl operation for kms driver ioctls Now justifying why we can do this for legacy drives too (and hence close the source of all the bogus copypasting) is a bit more involved. DRM_UNLOCKED was introduced in: commit ed8b6704 Author: Arnd Bergmann <arnd@arndb.de> Date: Wed Dec 16 22:17:09 2009 +0000 drm: convert drm_ioctl to unlocked_ioctl As a immediate hack to keep i810 happy, which would have deadlocked without this trickery. The old BKL is automatically dropped in schedule(), and hence the i810 vs. mmap_sem deadlock didn't actually cause a real deadlock. But with a mutex it would. The solution was to annotate these as DRM_UNLOCKED and mark i810 unsafe on SMP machines. This conversion caused a regression, because unlike the BKL a mutex isn't dropped over schedule (that thing again), which caused a vblank wait in one thread to block the entire desktop and all its apps. Back then we did vblank scheduling by blocking in the client, awesome isn't it. This was fixed quickly in (ok not so quickly, took 2 years): commit 8f4ff2b0 Author: Ilija Hadzic <ihadzic@research.bell-labs.com> Date: Mon Oct 31 17:46:18 2011 -0400 drm: do not sleep on vblank while holding a mutex All the other DRM_UNLOCKED annotations for all the core ioctls was work to reach finer-grained locking for modern drivers. This took years, and culminated in: commit fdd5b877 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sat Dec 10 22:52:54 2016 +0100 drm: Enforce BKL-less ioctls for modern drivers DRM_UNLOCKED was never required by any legacy drivers, except for the vblank_wait IOCTL. Therefore we will not regress these old drivers by going back to where we've been in 2011. For all modern drivers nothing will change. To make this perfectly clear, also add a comment to DRM_UNLOCKED. v2: Don't forget about drm_ioc32.c (Michel). Cc: Michel Dänzer <michel@daenzer.net> Cc: Emil Velikov <emil.l.velikov@gmail.com> Acked-by:
Michel Dänzer <michel@daenzer.net> Signed-off-by:
-
Daniel Vetter authored
The idea is that gem_prime_export is deprecated in favor of obj_funcs.export. That's much easier to do if both have matching function signatures. Reviewed-by:
Christian König <christian.koenig@amd.com> Acked-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Daniel Vetter authored
This is a no-op on atomic drivers because with atomic it's simply too complicated to get all the locking and workers and nonblocking synchronization correct, from essentially an NMI context. Well, too complicated = impossible. Also, omapdrm never implemented the mode_set_base_atomic hook, so I kinda wonder why this was ever added. Drop the hooks. Reviewed-by:
-
Daniel Vetter authored
Read the docs, komeda is not an old enough driver for this :-) Reviewed-by:
-
Daniel Vetter authored
Split out to make the functional changes stick out more. All places where DRIVER_PRIME was used have been removed in previous patches already. v2: amdgpu gained DRIVER_SYNCOBJ_TIMELINE. v3: amdgpu lost DRIVER_SYNCOBJ_TIMELINE. v4: Don't add a space in i915_drv.c (Sam) v5: Add note that previous patches removed all the DRIVER_PRIME users already (Emil). v6: Fixupe ingenic (new driver) while applying. Cc: Sam Ravnborg <sam@ravnborg.org> Reviewed-by:
-
Daniel Vetter authored
Drivers must fill out the handle_to_fd and fd_to_handle hooks to enable export/import prime functionality already. The additional DRIVER_PRIME flag doesn't serve any real purpose, since the overall flag doesn't even tell you whether import or export or maybe even both is supported. Ditch it. This patch just makes it defunct, subsequent patches will remove it from all the drivers. Note this changes the userspace visible errno in some situations from EOPNOTSUPP to ENOSYS. Userspace already needs to treat both as "no prime support", so this should break anything. v2: Improve commit message as suggested by Emil Reviewed-by:
-
Daniel Vetter authored
It's tiny, already embedded, and setup/teardown cost is trivial. Reviewed-by:
-
Daniel Vetter authored
Yes this is a bit a big patch, but since it's essentially a complete rewrite of all the prime docs I didn't see how to better split it up. Changes: - Consistently point to drm_gem_object_funcs as the preferred hooks, where applicable. - Document all the hooks in &drm_driver that lacked kerneldoc. - Completely new overview section, which now also includes the cleaned up lifetime/reference counting subchapter. I also mentioned the weak references in there due to the lookup caches. - Completely rewritten helper intro section, highlight the import/export related functionality. - Polish for all the functions and more cross references. I also sprinkled a bunch of todos all over. Most important: 0 code changes in here. The cleanup motivated by reading and improving all this will follow later on. v2: Actually update the prime helper docs. Plus add a few FIXMEs that I won't address right away in subsequent cleanup patches. v3: - Split out the function moving. This patch is now exclusively documentation changes. - Typos and nits (Sam). v4: Polish suggestions from Noralf. Acked-by:
Gerd Hoffmann <kraxel@redhat.com> Acked-by:
Noralf Trønnes <noralf@tronnes.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Noralf Trønnes <noralf@tronnes.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Eric Anholt <eric@anholt.net> Cc: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by:
-
Daniel Vetter authored
Reorder all the functions in drm_prime.[hc] into three groups: core, export helpers, import helpers. Not other changes beyond moving the functions and their unchanged kerneldoc around in here. Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Eric Anholt <eric@anholt.net> Cc: Emil Velikov <emil.l.velikov@gmail.com> Acked-by:
-
YueHaibing authored
Remove duplicated include. Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
Benjamin Gaignard <benjamin.gaignard@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190620150306.124839-1-yuehaibing@huawei.com
-
- 20 Jun, 2019 3 commits
-
-
Daniel Vetter authored
I rushed merging this a bit too much, and Noralf pointed out that we're a lot better already and have made great progress. Let's try again. v2: Fix typo spotted by Eric Engestrom. Fixes: 8db420ac ("drm/todo: Improve drm_gem_object funcs todo") Reviewed-by:
-
Yannick Fertré authored
Without this fix, the system can not go in "suspend" mode due to an error in drv_suspend function. Fixes: 35ab6cfb ("drm/stm: support runtime power management") Signed-off-by:
Yannick Fertré <yannick.fertre@st.com> Acked-by:
Philippe Cornu <philippe.cornu@st.com> Signed-off-by:
-
Sean Paul authored
If state allocation fails, we still try to give back the reference on it. Also initialize ret in case the crtc is not enabled and we hit the eject button. Fixes: 1452c25b ("drm: Add helpers to kick off self refresh mode in drivers") Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Jose Souza <jose.souza@intel.com> Cc: Zain Wang <wzz@rock-chips.com> Cc: Tomasz Figa <tfiga@chromium.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Sean Paul <seanpaul@chromium.org> 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: dri-devel@lists.freedesktop.org Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190619181951.192305-1-sean@poorly.run
-
- 19 Jun, 2019 12 commits
-
-
Dan Carpenter authored
This test is flipped around so it either leads to a memory leak or a NULL dereference. Fixes: 1452c25b ("drm: Add helpers to kick off self refresh mode in drivers") Signed-off-by:
-
Paul Cercueil authored
Add a KMS driver for the Ingenic JZ47xx family of SoCs. This driver is meant to replace the aging jz4740-fb driver. This driver does not make use of the simple pipe helper, for the reason that it will soon be updated to support more advanced features like multiple planes, IPU integration for colorspace conversion and up/down scaling, support for DSI displays, and TV-out and HDMI outputs. Notes: v2: - Remove custom handling of panel. The panel is now discovered using the standard API. - Lots of small tweaks suggested by upstream v3: - Use devm_drm_dev_init() - Update compatible strings to -lcd instead of -drm - Add destroy() callbacks to plane and crtc - The ingenic,lcd-mode is now read from the bridge's DT node v4: Remove ingenic,lcd-mode property completely. The various modes are now deduced from the connector type, the pixel format or the bus flags. v5: - Fix framebuffer size incorrectly calculated for 24bpp framebuffers - Use 32bpp framebuffer instead of 16bpp, as it'll work with both 16-bit and 24-bit panel - Get rid of drm_format_plane_cpp() which has been dropped upstream - Avoid using drm_format_info->depth, which is deprecated. Signed-off-by:Paul Cercueil <paul@crapouillou.net> Tested-by:
Artur Rojek <contact@artur-rojek.eu> Reviewed-by:
-
Paul Cercueil authored
Add documentation for the devicetree bindings of the LCD controller present in the JZ47xx family of SoCs from Ingenic. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Maarten Lankhorst authored
topic/remove-fbcon-notifiers: - remove fbdev notifier usage for fbcon, as prep work to clean up the fbcon locking - assorted locking checks in vt/console code - assorted notifier and cleanups in fbdev and backlight code This is the pull request that was sent out, plus the compile fix for sh4 reported by kbuild. Acked-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Maarten Lankhorst authored
remove-fbcon-notifiers topic branch is based on rc4, so we need a fresh backmerge of drm-next to pull it in. Signed-off-by: -
Maxime Ripard authored
Now that the TV margins are properly parsed and filled into drm_cmdline_mode, we just need to initialise the first state at reset to get those values and start using them. Acked-by:
Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/44e24172e300be6a41578517021ef6a6e90ed682.1560783090.git-series.maxime.ripard@bootlin.com
-
Maxime Ripard authored
The command line parser is pretty tough to get right and very error prone, so let's add a selftest to try to catch any regression. Reviewed-by:
-
Maxime Ripard authored
During the connector reset, if that connector has a TV property, it needs to be reset to the value provided on the command line. Provide a helper to do that. Reviewed-by:
-
Maxime Ripard authored
Properly configuring the overscan properties might be needed for the initial setup of the framebuffer for display that still have overscan. Let's allow for more properties on the kernel command line to setup each margin. Reviewed-by:
-
Maxime Ripard authored
The TV margins has been defined as a structure inside the drm_connector_state structure so far. However, we will need it in other structures as well, so let's move that structure definition so that it can be reused. Reviewed-by:
-
Maxime Ripard authored
Rotations and reflections setup are needed in some scenarios to initialise properly the initial framebuffer. Some drivers already had a bunch of quirks to deal with this, such as either a private kernel command line parameter (omapdss) or on the device tree (various panels). In order to accomodate this, let's create a video mode parameter to deal with the rotation and reflexion. Reviewed-by:
-
Maxime Ripard authored
The drm subsystem also uses the video= kernel parameter, and in the documentation refers to the fbdev documentation for that parameter. However, that documentation also says that instead of giving the mode using its resolution we can also give a name. However, DRM doesn't handle that case at the moment. Even though in most case it shouldn't make any difference, it might be useful for analog modes, where different standards might have the same resolution, but still have a few different parameters that are not encoded in the modes (NTSC vs NTSC-J vs PAL-M for example). Reviewed-by:
-
