- 23 Jun, 2019 4 commits
-
-
Krzysztof Kozlowski authored
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. 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-4-krzk@kernel.org
-
Krzysztof Kozlowski authored
Store the PTR_ERR() result in local variable in clock init error path. This makes the code consistent with similar section in regulator init code. Signed-off-by:
-
Krzysztof Kozlowski authored
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. Fixes: a1d2a633 ("drm/lima: driver for ARM Mali4xx GPUs") Signed-off-by: -
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:
-
- 21 Jun, 2019 36 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:
-
