- 23 Jun, 2019 1 commit
-
-
Krzysztof Kozlowski authored
Mark long numbers with ULL to silence the Smatch warning: drivers/gpu/drm/lima/lima_device.c:314:32: warning: constant 0x100000000 is so big it is long long Fixes: a1d2a633 ("drm/lima: driver for ARM Mali4xx GPUs") Signed-off-by:Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
Qiang Yu <yuq825@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190621162117.22533-1-krzk@kernel.org
-
- 21 Jun, 2019 39 commits
-
-
Daniel Vetter authored
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. Fixes: 5eab9987 ("drm/vgem: Drop drm_gem_prime_export") Reviewed-by:
Emil Velikov <emil.velikov@collabora.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190614203615.12639-49-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
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:
Eric Anholt <eric@anholt.net> 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:
Gerd Hoffmann <kraxel@redhat.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:
Shawn Guo <shawnguo@kernel.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:
Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.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
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:
-
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:
-
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. Acked-by:
Philippe Cornu <philippe.cornu@st.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:
Benjamin Gaignard <benjamin.gaignard@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:
Laurent Pinchart <laurent.pinchart@ideasonboard.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:
Heiko Stuebner <heiko@sntech.de> 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:
-
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:
-
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:
-
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:
-
