kernel/include/drm/drm_mode_config.h, branch linux-rolling-lts

drm: Pass the format info to .fb_create()

2025-07-16T17:03:14Z

Pass along the format information from the top to .fb_create() so that we can avoid redundant (and somewhat expensive) lookups in the drivers. Done with cocci (with some manual fixups): @@ identifier func =~ ".*create.*"; identifier dev, file, mode_cmd; @@ struct drm_framebuffer *func( struct drm_device *dev, struct drm_file *file, + const struct drm_format_info *info, const struct drm_mode_fb_cmd2 *mode_cmd) { ... ( - const struct drm_format_info *info = drm_get_format_info(...); | - const struct drm_format_info *info; ... - info = drm_get_format_info(...); ) <... - if (!info) - return ...; ...> } @@ identifier func =~ ".*create.*"; identifier dev, file, mode_cmd; @@ struct drm_framebuffer *func( struct drm_device *dev, struct drm_file *file, + const struct drm_format_info *info, const struct drm_mode_fb_cmd2 *mode_cmd) { ... } @find@ identifier fb_create_func =~ ".*create.*"; identifier dev, file, mode_cmd; @@ struct drm_framebuffer *fb_create_func( struct drm_device *dev, struct drm_file *file, + const struct drm_format_info *info, const struct drm_mode_fb_cmd2 *mode_cmd); @@ identifier find.fb_create_func; expression dev, file, mode_cmd; @@ fb_create_func(dev, file + ,info ,mode_cmd) @@ expression dev, file, mode_cmd; @@ drm_gem_fb_create(dev, file + ,info ,mode_cmd) @@ expression dev, file, mode_cmd; @@ drm_gem_fb_create_with_dirty(dev, file + ,info ,mode_cmd) @@ expression dev, file_priv, mode_cmd; identifier info, fb; @@ info = drm_get_format_info(...); ... fb = dev->mode_config.funcs->fb_create(dev, file_priv + ,info ,mode_cmd); @@ identifier dev, file_priv, mode_cmd; @@ struct drm_mode_config_funcs { ... struct drm_framebuffer *(*fb_create)(struct drm_device *dev, struct drm_file *file_priv, + const struct drm_format_info *info, const struct drm_mode_fb_cmd2 *mode_cmd); ... }; v2: Fix kernel docs (Laurent) Fix commit msg (Geert) Cc: Alex Deucher Cc: Liviu Dudau Cc: Maxime Ripard Cc: Russell King Cc: Inki Dae Cc: Seung-Woo Kim Cc: Kyungmin Park Cc: Patrik Jakobsson Cc: Chun-Kuang Hu Cc: Philipp Zabel Cc: Rob Clark Cc: Abhinav Kumar Cc: Dmitry Baryshkov Cc: Sean Paul Cc: Marijn Suijten Cc: Marek Vasut Cc: Stefan Agner Cc: Lyude Paul Cc: Danilo Krummrich Cc: Tomi Valkeinen Cc: Dave Airlie Cc: Gerd Hoffmann Cc: Kieran Bingham Cc: Biju Das Cc: Sandy Huang Cc: "Heiko Stübner" Cc: Andy Yan Cc: Thierry Reding Cc: Mikko Perttunen Cc: Dave Stevenson Cc: "Maíra Canal" Cc: Raspberry Pi Kernel Maintenance Cc: Dmitry Osipenko Cc: Gurchetan Singh Cc: Chia-I Wu Cc: Zack Rusin Cc: Broadcom internal kernel review list Cc: Oleksandr Andrushchenko Cc: amd-gfx@lists.freedesktop.org Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Cc: virtualization@lists.linux.dev Cc: spice-devel@lists.freedesktop.org Cc: linux-renesas-soc@vger.kernel.org Cc: linux-tegra@vger.kernel.org Cc: Laurent Pinchart Reviewed-by: Geert Uytterhoeven Reviewed-by: Thomas Zimmermann Reviewed-by: Dmitry Baryshkov Acked-by: Liviu Dudau Reviewed-by: Laurent Pinchart Acked-by: Alex Deucher Acked-by: Rodrigo Vivi Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20250701090722.13645-5-ville.syrjala@linux.intel.com

drm: Pass pixel_format+modifier to .get_format_info()

2025-07-16T16:59:59Z

Decouple .get_format_info() from struct drm_mode_fb_cmd2 and just pass the pixel format+modifier combo in by hand. We may want to use .get_format_info() outside of the normal addfb paths where we won't have a struct drm_mode_fb_cmd2, and creating a temporary one just for this seems silly. v2: Fix intel_fb_get_format_info() docs (Laurent) Cc: Harry Wentland Cc: Leo Li Cc: Rodrigo Siqueira Cc: Alex Deucher Cc: amd-gfx@lists.freedesktop.org Cc: Laurent Pinchart Reviewed-by: Thomas Zimmermann Reviewed-by: Laurent Pinchart Acked-by: Alex Deucher Acked-by: Rodrigo Vivi Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20250701090722.13645-2-ville.syrjala@linux.intel.com

drm/plane: Add new plane property IN_FORMATS_ASYNC

2025-05-09T09:59:40Z

There exists a property IN_FORMATS which exposes the plane supported modifiers/formats to the user. In some platforms when asynchronous flip are used all of modifiers/formats mentioned in IN_FORMATS are not supported. This patch adds a new plane property IN_FORMATS_ASYNC to expose the async flip supported modifiers/formats so that user can use this information ahead and do flip with unsupported formats/modifiers. This will save flip failures. Add a new function pointer similar to format_mod_supported specifically for asynchronous flip. v2: Remove async variable from drm_plane (Ville) v3: Add new function pointer for async (Ville) v5: Typo corrected in commit message & some correction in the kernel documentation. (Chaitanya) v7: Place IN_FORMATS_ASYNC next to IN_FORMATS (Ville) v8: replace uint32_t with u32 and uint64_t with u64 (Chaitanya) Signed-off-by: Arun R Murthy Acked-by: Xaver Hugl Acked-by: Harry Wentland Reviewed-by: Chaitanya Kumar Borah Reviewed-by: Ville Syrjälä Tested-by: Naveen Kumar Signed-off-by: Suraj Kandpal Link: https://lore.kernel.org/r/20250407-asyn-v13-1-b93ef83076c5@intel.com

drm/mode_config: Make drm_mode_config.(max|min)_(width|height) unsigned

2025-04-02T21:20:01Z

It doesn't make much sense to allow devices to specify their min/max resolution as signed integers, and in Rust with CONFIG_RUST_OVERFLOW_CHECKS enabled this provides us actual over/underflow checks. Similarly, it doesn't really make much sense for us to allow devices to specify their minimum/maximum resolution as signed. Signed-off-by: Lyude Paul Reviewed-by: Maxime Ripard Reviewed-by: Thomas Zimmermann Cc: Greg Kroah-Hartman Cc: Thomas Zimmermann Link: https://lore.kernel.org/r/20250331222556.454334-3-lyude@redhat.com

drm: Remove struct drm_mode_config_funcs.output_poll_changed

2024-08-13T14:21:13Z

The output_poll_changed hook in struct drm_mode_config_funcs is unused. Remove it. The helper drm_client_dev_hotplug() implements the callback's functionality. Signed-off-by: Thomas Zimmermann Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20240812083000.337744-10-tzimmermann@suse.de

Revert "drm: Introduce 'power saving policy' drm property"

2024-08-02T15:28:53Z

This reverts commit 76299a557f36d624ca32500173ad7856e1ad93c0. It was merged without meeting userspace requirements. Signed-off-by: Hamza Mahfooz Reviewed-by: Harry Wentland Link: https://patchwork.freedesktop.org/patch/msgid/20240802145946.48073-1-hamza.mahfooz@amd.com

drm: Introduce 'power saving policy' drm property

2024-07-10T20:58:19Z

The `power saving policy` DRM property is an optional property that can be added to a connector by a driver. This property is for compositors to indicate intent of policy of whether a driver can use power saving features that may compromise the experience intended by the compositor. Acked-by: Leo Li Signed-off-by: Mario Limonciello Signed-off-by: Hamza Mahfooz Link: https://patchwork.freedesktop.org/patch/msgid/20240703051722.328-2-mario.limonciello@amd.com

drm/fbdev: Clean up fbdev documentation

2024-05-02T09:33:34Z

Rewrite some docs that are not up-to-date any longer. Remove the TODO item for fbdev-generic conversion, as the helper has been replaced. Make documentation for DMA, SHMEM and TTM emulation available. Signed-off-by: Thomas Zimmermann Cc: Jonathan Corbet Reviewed-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20240419083331.7761-44-tzimmermann@suse.de

drm: Fix plane SIZE_HINTS property docs

2024-04-22T08:42:32Z

Fix the typos in the plane SIZE_HINTS kernel docs. Reported-by: Stephen Rothwell Fixes: 9677547d8362 ("drm: Introduce plane SIZE_HINTS property") Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20240418114218.9162-1-ville.syrjala@linux.intel.com Reviewed-by: Dmitry Baryshkov

drm/panic: Add drm panic locking

2024-04-15T14:11:26Z

Rough sketch for the locking of drm panic printing code. The upshot of this approach is that we can pretty much entirely rely on the atomic commit flow, with the pair of raw_spin_lock/unlock providing any barriers we need, without having to create really big critical sections in code. This also avoids the need that drivers must explicitly update the panic handler state, which they might forget to do, or not do consistently, and then we blow up in the worst possible times. It is somewhat racy against a concurrent atomic update, and we might write into a buffer which the hardware will never display. But there's fundamentally no way to avoid that - if we do the panic state update explicitly after writing to the hardware, we might instead write to an old buffer that the user will barely ever see. Note that an rcu protected deference of plane->state would give us the the same guarantees, but it has the downside that we then need to protect the plane state freeing functions with call_rcu too. Which would very widely impact a lot of code and therefore doesn't seem worth the complexity compared to a raw spinlock with very tiny critical sections. Plus rcu cannot be used to protect access to peek/poke registers anyway, so we'd still need it for those cases. Peek/poke registers for vram access (or a gart pte reserved just for panic code) are also the reason I've gone with a per-device and not per-plane spinlock, since usually these things are global for the entire display. Going with per-plane locks would mean drivers for such hardware would need additional locks, which we don't want, since it deviates from the per-console takeoverlocks design. Longer term it might be useful if the panic notifiers grow a bit more structure than just the absolute bare EXPORT_SYMBOL(panic_notifier_list) - somewhat aside, why is that not EXPORT_SYMBOL_GPL ... If panic notifiers would be more like console drivers with proper register/unregister interfaces we could perhaps reuse the very fancy console lock with all it's check and takeover semantics that John Ogness is developing to fix the console_lock mess. But for the initial cut of a drm panic printing support I don't think we need that, because the critical sections are extremely small and only happen once per display refresh. So generally just 60 tiny locked sections per second, which is nothing compared to a serial console running a 115kbaud doing really slow mmio writes for each byte. So for now the raw spintrylock in drm panic notifier callback should be good enough. Another benefit of making panic notifiers more like full blown consoles (that are used in panics only) would be that we get the two stage design, where first all the safe outputs are used. And then the dangerous takeover tricks are deployed (where for display drivers we also might try to intercept any in-flight display buffer flips, which if we race and misprogram fifos and watermarks can hang the memory controller on some hw). For context the actual implementation on the drm side is by Jocelyn and this patch is meant to be combined with the overall approach in v7 (v8 is a bit less flexible, which I think is the wrong direction): https://lore.kernel.org/dri-devel/20240104160301.185915-1-jfalempe@redhat.com/ Note that the locking is very much not correct there, hence this separate rfc. Starting from v10, I (Jocelyn) have included this patch in the drm_panic series, and done the corresponding changes. v2: - fix authorship, this was all my typing - some typo oopsies - link to the drm panic work by Jocelyn for context v10: - Use spinlock_irqsave/restore (John Ogness) v11: - Use macro instead of inline functions for drm_panic_lock/unlock (John Ogness) Signed-off-by: Daniel Vetter Cc: Jocelyn Falempe Cc: Andrew Morton Cc: "Peter Zijlstra (Intel)" Cc: Lukas Wunner Cc: Petr Mladek Cc: Steven Rostedt Cc: John Ogness Cc: Sergey Senozhatsky Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter Signed-off-by: Jocelyn Falempe Link: https://patchwork.freedesktop.org/patch/msgid/20240409163432.352518-2-jfalempe@redhat.com Acked-by: Daniel Vetter