pm24.git/drivers/gpu/drm/omapdrm, branch v6.7

drm: Call drm_atomic_helper_shutdown() at shutdown time for misc drivers

2023-09-21T17:41:04Z

Based on grepping through the source code these drivers appear to be missing a call to drm_atomic_helper_shutdown() at system shutdown time. Among other things, this means that if a panel is in use that it won't be cleanly powered off at system shutdown time. The fact that we should call drm_atomic_helper_shutdown() in the case of OS shutdown/restart comes straight out of the kernel doc "driver instance overview" in drm_drv.c. All of the drivers in this patch were fairly straightforward to fix since they already had a call to drm_atomic_helper_shutdown() at remove/unbind time but were just lacking one at system shutdown. The only hitch is that some of these drivers use the component model to register/unregister their DRM devices. The shutdown callback is part of the original device. The typical solution here, based on how other DRM drivers do this, is to keep track of whether the device is bound based on drvdata. In most cases the drvdata is the drm_device, so we can just make sure it is NULL when the device is not bound. In some drivers, this required minor code changes. To make things simpler, drm_atomic_helper_shutdown() has been modified to consider a NULL drm_device as a noop in the patch ("drm/atomic-helper: drm_atomic_helper_shutdown(NULL) should be a noop"). Suggested-by: Maxime Ripard Reviewed-by: Tomi Valkeinen Tested-by: Tomi Valkeinen Acked-by: Maxime Ripard Tested-by: Jernej Skrabec Reviewed-by: Jernej Skrabec Reviewed-by: Sui Jingfeng Tested-by: Sui Jingfeng Signed-off-by: Douglas Anderson Link: https://patchwork.freedesktop.org/patch/msgid/20230901163944.RFT.2.I9115e5d094a43e687978b0699cc1fe9f2a3452ea@changeid

fbdev: Use _DMAMEM_ infix for DMA-memory helpers

2023-07-31T18:07:18Z

Change the infix for fbdev's DMA-memory helpers from _DMA_ to _DMAMEM_. The helpers perform operations within DMA-able memory, but they don't perform DMA operations. Naming should make this clear. Adapt all users. No functional changes. Signed-off-by: Thomas Zimmermann Reviewed-by: Sam Ravnborg Acked-by: Helge Deller Link: https://patchwork.freedesktop.org/patch/msgid/20230729193157.15446-4-tzimmermann@suse.de

drm/omapdrm: Set fbdev FBINFO_VIRTFB flag

2023-07-24T18:14:43Z

Mark the framebuffer with FBINFO_VIRTFB. The framebuffer range is in DMA-able memory and should be accessed with the CPU's regular memory ops. v2: * drop FBINFO_DEFAULT Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Acked-by: Maxime Ripard Cc: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20230707083422.18691-11-tzimmermann@suse.de

drm/omapdrm: Use GEM mmap for fbdev emulation

2023-07-24T18:14:43Z

The fbdev emulation currently uses fbdev's default mmap code, which has been written for I/O memory. Provide an mmap that uses GEM's mmap infrastructure. Utilize fine-grained fbdev macros to initialize struct fb_ops. The macros set the read/write and the draw callbacks for DMA memory. Set the fb_mmap callback to omapdrm's new mmap helper. Also select the correct Kconfig token for fbdev's DMA helpers. Note that the DMA helpers are the same as for system memory. Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Acked-by: Maxime Ripard Cc: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20230707083422.18691-10-tzimmermann@suse.de

drm/omapdrm: Set VM flags in GEM-object mmap function

2023-07-24T18:14:43Z

Use the mmap callback in struct drm_gem_object_funcs to set the VM flags. Replace a number of mmap helpers in omapdrm with their GEM helper counterparts. Generate DRM's file-operations instance with GEM's DEFINE_DRM_GEM_FOPS. The omapdrm driver uses DRM's drm_gem_mmap() helper to prepare the VMA structure. It then modifies the resulting VMA state in its own helper omap_gem_mmap_obj(). The patch improves this by setting up the VMA in the mmap callback in drm_gem_object_funcs, which is called from within drm_gem_mmap(). Omapdrm's omap_gem_mmap() and omap_gem_mmap() can then be removed from the driver. A call to drm_gem_mmap() is sufficient for the mmap operation. Finally, with the omap functions gone, the drivers file_ops in omapdriver_fops can be generated with DEFINE_DRM_GEM_FOPS, which sets DRM's default helpers. v2: * detailed commit message (Javier) * do not set VM_PFNMAP Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Acked-by: Maxime Ripard Cc: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20230707083422.18691-9-tzimmermann@suse.de

Merge tag 'drm-misc-next-2023-07-13' of git://anongit.freedesktop.org/drm/drm-misc into drm-next

2023-07-17T13:37:57Z

drm-misc-next for v6.6: UAPI Changes: * fbdev: * Make fbdev userspace interfaces optional; only leaves the framebuffer console active * prime: * Support dma-buf self-import for all drivers automatically: improves support for many userspace compositors Cross-subsystem Changes: * backlight: * Fix interaction with fbdev in several drivers * base: Convert struct platform.remove to return void; part of a larger, tree-wide effort * dma-buf: Acquire reservation lock for mmap() in exporters; part of an on-going effort to simplify locking around dma-bufs * fbdev: * Use Linux device instead of fbdev device in many places * Use deferred-I/O helper macros in various drivers * i2c: Convert struct i2c from .probe_new to .probe; part of a larger, tree-wide effort * video: * Avoid including Core Changes: * atomic: * Improve logging * prime: * Remove struct drm_driver.gem_prime_mmap plus driver updates: all drivers now implement this callback with drm_gem_prime_mmap() * gem: * Support execution contexts: provides locking over multiple GEM objects * ttm: * Support init_on_free * Swapout fixes Driver Changes: * accel: * ivpu: MMU updates; Support debugfs * ast: * Improve device-model detection * Cleanups * bridge: * dw-hdmi: Improve support for YUV420 bus format * dw-mipi-dsi: Fix enable/disable of DSI controller * lt9611uxc: Use MODULE_FIRMWARE() * ps8640: Remove broken EDID code * samsung-dsim: Fix command transfer * tc358764: Handle HS/VS polarity; Use BIT() macro; Various cleanups * Cleanups * ingenic: * Kconfig REGMAP fixes * loongson: * Support display controller * mgag200: * Minor fixes * mxsfb: * Support disabling overlay planes * nouveau: * Improve VRAM detection * Various fixes and cleanups * panel: * panel-edp: Support AUO B116XAB01.4 * Support Visionox R66451 plus DT bindings * Cleanups * ssd130x: * Support per-controller default resolution plus DT bindings * Reduce memory-allocation overhead * Cleanups * tidss: * Support TI AM625 plus DT bindings * Implement new connector model plus driver updates * vkms * Improve write-back support * Documentation fixes Signed-off-by: Daniel Vetter From: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20230713090830.GA23281@linux-uq9g

drm/client: Send hotplug event after registering a client

2023-07-11T12:02:01Z

Generate a hotplug event after registering a client to allow the client to configure its display. Remove the hotplug calls from the existing clients for fbdev emulation. This change fixes a concurrency bug between registering a client and receiving events from the DRM core. The bug is present in the fbdev emulation of all drivers. The fbdev emulation currently generates a hotplug event before registering the client to the device. For each new output, the DRM core sends an additional hotplug event to each registered client. If the DRM core detects first output between sending the artificial hotplug and registering the device, the output's hotplug event gets lost. If this is the first output, the fbdev console display remains dark. This has been observed with amdgpu and fbdev-generic. Fix this by adding hotplug generation directly to the client's register helper drm_client_register(). Registering the client and receiving events are serialized by struct drm_device.clientlist_mutex. So an output is either configured by the initial hotplug event, or the client has already been registered. The bug was originally added in commit 6e3f17ee73f7 ("drm/fb-helper: generic: Call drm_client_add() after setup is done"), in which adding a client and receiving a hotplug event switched order. It was hidden, as most hardware and drivers have at least on static output configured. Other drivers didn't use the internal DRM client or still had struct drm_mode_config_funcs.output_poll_changed set. That callback handled hotplug events as well. After not setting the callback in amdgpu in commit 0e3172bac3f4 ("drm/amdgpu: Don't set struct drm_driver.output_poll_changed"), amdgpu did not show a framebuffer console if output events got lost. The bug got copy-pasted from fbdev-generic into the other fbdev emulation. Reported-by: Moritz Duge Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/2649 Fixes: 6e3f17ee73f7 ("drm/fb-helper: generic: Call drm_client_add() after setup is done") Fixes: 8ab59da26bc0 ("drm/fb-helper: Move generic fbdev emulation into separate source file") Fixes: b79fe9abd58b ("drm/fbdev-dma: Implement fbdev emulation for GEM DMA helpers") Fixes: 63c381552f69 ("drm/armada: Implement fbdev emulation as in-kernel client") Fixes: 49953b70e7d3 ("drm/exynos: Implement fbdev emulation as in-kernel client") Fixes: 8f1aaccb04b7 ("drm/gma500: Implement client-based fbdev emulation") Fixes: 940b869c2f2f ("drm/msm: Implement fbdev emulation as in-kernel client") Fixes: 9e69bcd88e45 ("drm/omapdrm: Implement fbdev emulation as in-kernel client") Fixes: e317a69fe891 ("drm/radeon: Implement client-based fbdev emulation") Fixes: 71ec16f45ef8 ("drm/tegra: Implement fbdev emulation as in-kernel client") Fixes: 0e3172bac3f4 ("drm/amdgpu: Don't set struct drm_driver.output_poll_changed") Signed-off-by: Thomas Zimmermann Tested-by: Moritz Duge Tested-by: Torsten Krah Tested-by: Paul Schyska Cc: Daniel Vetter Cc: David Airlie Cc: Noralf Trønnes Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Javier Martinez Canillas Cc: Russell King Cc: Inki Dae Cc: Seung-Woo Kim Cc: Kyungmin Park Cc: Krzysztof Kozlowski Cc: Patrik Jakobsson Cc: Rob Clark Cc: Abhinav Kumar Cc: Dmitry Baryshkov Cc: Tomi Valkeinen Cc: Alex Deucher Cc: "Christian König" Cc: "Pan, Xinhui" Cc: Thierry Reding Cc: Mikko Perttunen Cc: dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: amd-gfx@lists.freedesktop.org Cc: linux-tegra@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: # v5.2+ Reviewed-by: Javier Martinez Canillas Reviewed-by: Dmitry Baryshkov # msm Link: https://patchwork.freedesktop.org/patch/msgid/20230710091029.27503-1-tzimmermann@suse.de

drm: Clear fd/handle callbacks in struct drm_driver

2023-06-26T09:08:41Z

Clear all assignments of struct drm_driver's fd/handle callbacks to drm_gem_prime_fd_to_handle() and drm_gem_prime_handle_to_fd(). These functions are called by default. Add a TODO item to convert vmwgfx to the defaults as well. v2: * remove TODO item (Zack) * also update amdgpu's amdgpu_partition_driver Signed-off-by: Thomas Zimmermann Reviewed-by: Simon Ser Acked-by: Alex Deucher Acked-by: Jeffrey Hugo # qaic Link: https://patchwork.freedesktop.org/patch/msgid/20230620080252.16368-3-tzimmermann@suse.de

drm: Don't assert held reservation lock for dma-buf mmapping

2023-06-21T17:22:20Z

Don't assert held dma-buf reservation lock on memory mapping of exported buffer. We're going to change dma-buf mmap() locking policy such that exporters will have to handle the lock. The previous locking policy caused deadlock problem for DRM drivers in a case of self-imported dma-bufs once these drivers are moved to use reservation lock universally. The problem is solved by moving the lock down to exporters. This patch prepares DRM drivers for the locking policy update. Reviewed-by: Emil Velikov Acked-by: Christian König Signed-off-by: Dmitry Osipenko Link: https://patchwork.freedesktop.org/patch/msgid/20230529223935.2672495-2-dmitry.osipenko@collabora.com Link: https://patchwork.freedesktop.org/patch/msgid/20230529223935.2672495-3-dmitry.osipenko@collabora.com Link: https://patchwork.freedesktop.org/patch/msgid/20230529223935.2672495-4-dmitry.osipenko@collabora.com Link: https://patchwork.freedesktop.org/patch/msgid/20230529223935.2672495-2-dmitry.osipenko@collabora.com Link: https://patchwork.freedesktop.org/patch/msgid/20230529223935.2672495-3-dmitry.osipenko@collabora.com Link: https://patchwork.freedesktop.org/patch/msgid/20230529223935.2672495-4-dmitry.osipenko@collabora.com

drm/omap: Convert to platform remove callback returning void

2023-06-08T17:35:17Z

The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert the omap drm driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König Reviewed-by: Laurent Pinchart Signed-off-by: Douglas Anderson Link: https://patchwork.freedesktop.org/patch/msgid/20230507162616.1368908-35-u.kleine-koenig@pengutronix.de