kernel/linux.git/drivers/gpu/drm/omapdrm, branch linux-6.9.y

drm/omapdrm: Fix console with deferred ops

2024-05-30T07:44:42+00:00

[ Upstream commit 01c0cce88c5480cc2505b79330246ef12eda938f ] Commit 95da53d63dcf ("drm/omapdrm: Use regular fbdev I/O helpers") stopped console from updating for command mode displays because there is no damage handling in fb_sys_write() unlike we had earlier in drm_fb_helper_sys_write(). Let's fix the issue by adding FB_GEN_DEFAULT_DEFERRED_DMAMEM_OPS and FB_DMAMEM_HELPERS_DEFERRED as suggested by Thomas. We cannot use the FB_DEFAULT_DEFERRED_OPS as fb_deferred_io_mmap() won't work properly for write-combine. Fixes: 95da53d63dcf ("drm/omapdrm: Use regular fbdev I/O helpers") Suggested-by: Thomas Zimmermann Reviewed-by: Thomas Zimmermann Signed-off-by: Tony Lindgren Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20240228063540.4444-3-tony@atomide.com Signed-off-by: Sasha Levin

drm/omapdrm: Fix console by implementing fb_dirty

2024-05-30T07:44:42+00:00

[ Upstream commit 632bac50544c0929ced9eed41e7d04c08adecbb0 ] The framebuffer console stopped updating with commit f231af498c29 ("drm/fb-helper: Disconnect damage worker from update logic"). Let's fix the issue by implementing fb_dirty similar to what was done with commit 039a72ce7e57 ("drm/i915/fbdev: Implement fb_dirty for intel custom fb helper"). Fixes: f231af498c29 ("drm/fb-helper: Disconnect damage worker from update logic") Reviewed-by: Thomas Zimmermann Signed-off-by: Tony Lindgren Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20240228063540.4444-2-tony@atomide.com Signed-off-by: Sasha Levin

drm/omap/hdmi5: switch to ->edid_read callback

2024-02-09T08:16:01+00:00

Prefer using the struct drm_edid based callback and functions. Signed-off-by: Jani Nikula Reviewed-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/da96653c111a7f989c7c804923968fa5f47c6b5a.1706038510.git.jani.nikula@intel.com

drm/omap/hdmi4: switch to ->edid_read callback

2024-02-09T08:15:59+00:00

Prefer using the struct drm_edid based callback and functions. Signed-off-by: Jani Nikula Reviewed-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/4c9b24a399e8f305698f8fe5ebd687bfd6ce2e59.1706038510.git.jani.nikula@intel.com

drm/omapdrm: Improve check for contiguous buffers

2023-12-01T10:04:28+00:00

While a scatter-gather table having only 1 entry does imply it is contiguous, it is a logic error to assume the inverse. Tables can have more than 1 entry and still be contiguous. Use a proper check here. Signed-off-by: Andrew Davis Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20231113205501.616927-1-afd@ti.com

drm: Use device_get_match_data()

2023-11-27T19:56:32+00:00

Use preferred device_get_match_data() instead of of_match_device() to get the driver match data in a single step. With this, adjust the includes to explicitly include the correct headers. That also serves as preparation to remove implicit includes within the DT headers (of_device.h in particular). Reviewed-by: Tomi Valkeinen Reviewed-by: Andrew Jeffery Link: https://lore.kernel.org/r/20231020125214.2930329-1-robh@kernel.org Signed-off-by: Rob Herring

Revert "drm/omapdrm: Annotate dma-fence critical section in commit path"

2023-10-31T13:32:20+00:00

This reverts commit 250aa22920cd5d956a5d3e9c6a43d671c2bae217. The DMA-fence annotations cause a lockdep warning (see below). As per https://patchwork.freedesktop.org/patch/462170/ it sounds like the annotations don't work correctly. ====================================================== WARNING: possible circular locking dependency detected 6.5.0-rc2+ #2 Not tainted ------------------------------------------------------ kmstest/219 is trying to acquire lock: c4705838 (&hdmi->lock){+.+.}-{3:3}, at: hdmi5_bridge_mode_set+0x1c/0x50 but task is already holding lock: c11e1128 (dma_fence_map){++++}-{0:0}, at: omap_atomic_commit_tail+0x14/0xbc which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (dma_fence_map){++++}-{0:0}: __dma_fence_might_wait+0x48/0xb4 dma_resv_lockdep+0x1b8/0x2bc do_one_initcall+0x68/0x3b0 kernel_init_freeable+0x260/0x34c kernel_init+0x14/0x140 ret_from_fork+0x14/0x28 -> #1 (fs_reclaim){+.+.}-{0:0}: fs_reclaim_acquire+0x70/0xa8 __kmem_cache_alloc_node+0x3c/0x368 kmalloc_trace+0x28/0x58 _drm_do_get_edid+0x7c/0x35c hdmi5_bridge_get_edid+0xc8/0x1ac drm_bridge_connector_get_modes+0x64/0xc0 drm_helper_probe_single_connector_modes+0x170/0x528 drm_client_modeset_probe+0x208/0x1334 __drm_fb_helper_initial_config_and_unlock+0x30/0x548 omap_fbdev_client_hotplug+0x3c/0x6c drm_client_register+0x58/0x94 pdev_probe+0x544/0x6b0 platform_probe+0x58/0xbc really_probe+0xd8/0x3fc __driver_probe_device+0x94/0x1f4 driver_probe_device+0x2c/0xc4 __device_attach_driver+0xa4/0x11c bus_for_each_drv+0x84/0xdc __device_attach+0xac/0x20c bus_probe_device+0x8c/0x90 device_add+0x588/0x7e0 platform_device_add+0x110/0x24c platform_device_register_full+0x108/0x15c dss_bind+0x90/0xc0 try_to_bring_up_aggregate_device+0x1e0/0x2c8 __component_add+0xa4/0x174 hdmi5_probe+0x1c8/0x270 platform_probe+0x58/0xbc really_probe+0xd8/0x3fc __driver_probe_device+0x94/0x1f4 driver_probe_device+0x2c/0xc4 __device_attach_driver+0xa4/0x11c bus_for_each_drv+0x84/0xdc __device_attach+0xac/0x20c bus_probe_device+0x8c/0x90 deferred_probe_work_func+0x8c/0xd8 process_one_work+0x2ac/0x6e4 worker_thread+0x30/0x4ec kthread+0x100/0x124 ret_from_fork+0x14/0x28 -> #0 (&hdmi->lock){+.+.}-{3:3}: __lock_acquire+0x145c/0x29cc lock_acquire.part.0+0xb4/0x258 __mutex_lock+0x90/0x950 mutex_lock_nested+0x1c/0x24 hdmi5_bridge_mode_set+0x1c/0x50 drm_bridge_chain_mode_set+0x48/0x5c crtc_set_mode+0x188/0x1d0 omap_atomic_commit_tail+0x2c/0xbc commit_tail+0x9c/0x188 drm_atomic_helper_commit+0x158/0x18c drm_atomic_commit+0xa4/0xe8 drm_mode_atomic_ioctl+0x9a4/0xc38 drm_ioctl+0x210/0x4a8 sys_ioctl+0x138/0xf00 ret_fast_syscall+0x0/0x1c other info that might help us debug this: Chain exists of: &hdmi->lock --> fs_reclaim --> dma_fence_map Possible unsafe locking scenario: CPU0 CPU1 ---- ---- rlock(dma_fence_map); lock(fs_reclaim); lock(dma_fence_map); lock(&hdmi->lock); *** DEADLOCK *** 3 locks held by kmstest/219: #0: f1011de4 (crtc_ww_class_acquire){+.+.}-{0:0}, at: drm_mode_atomic_ioctl+0xf0/0xc38 #1: c47059c8 (crtc_ww_class_mutex){+.+.}-{3:3}, at: modeset_lock+0xf8/0x230 #2: c11e1128 (dma_fence_map){++++}-{0:0}, at: omap_atomic_commit_tail+0x14/0xbc stack backtrace: CPU: 1 PID: 219 Comm: kmstest Not tainted 6.5.0-rc2+ #2 Hardware name: Generic DRA74X (Flattened Device Tree) unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x58/0x70 dump_stack_lvl from check_noncircular+0x164/0x198 check_noncircular from __lock_acquire+0x145c/0x29cc __lock_acquire from lock_acquire.part.0+0xb4/0x258 lock_acquire.part.0 from __mutex_lock+0x90/0x950 __mutex_lock from mutex_lock_nested+0x1c/0x24 mutex_lock_nested from hdmi5_bridge_mode_set+0x1c/0x50 hdmi5_bridge_mode_set from drm_bridge_chain_mode_set+0x48/0x5c drm_bridge_chain_mode_set from crtc_set_mode+0x188/0x1d0 crtc_set_mode from omap_atomic_commit_tail+0x2c/0xbc omap_atomic_commit_tail from commit_tail+0x9c/0x188 commit_tail from drm_atomic_helper_commit+0x158/0x18c drm_atomic_helper_commit from drm_atomic_commit+0xa4/0xe8 drm_atomic_commit from drm_mode_atomic_ioctl+0x9a4/0xc38 drm_mode_atomic_ioctl from drm_ioctl+0x210/0x4a8 drm_ioctl from sys_ioctl+0x138/0xf00 sys_ioctl from ret_fast_syscall+0x0/0x1c Exception stack(0xf1011fa8 to 0xf1011ff0) 1fa0: 00466d58 be9ab510 00000003 c03864bc be9ab510 be9ab4e0 1fc0: 00466d58 be9ab510 c03864bc 00000036 00466ef0 00466fc0 00467020 00466f20 1fe0: b6bc7ef4 be9ab4d0 b6bbbb00 b6cb2cc0 Fixes: 250aa22920cd ("drm/omapdrm: Annotate dma-fence critical section in commit path") Reviewed-by: Aradhya Bhatia Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20230920-dma-fence-annotation-revert-v1-2-7ebf6f7f5bf6@ideasonboard.com

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

2023-09-21T17:41:04+00:00

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:18+00:00

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:43+00:00

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