linux-toradex.git/include/drm/drm_mode_config.h, branch v6.15-rc2

drm: Remove struct drm_mode_config_funcs.output_poll_changed

2024-08-13T14:21:13+00:00

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

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

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

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

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

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

drm: Introduce plane SIZE_HINTS property

2024-04-11T15:28:58+00:00

Add a new immutable plane property by which a plane can advertise
a handful of recommended plane sizes. This would be mostly exposed
by cursor planes as a slightly more capable replacement for
the DRM_CAP_CURSOR_WIDTH/HEIGHT caps, which can only declare
a one size fits all limit for the whole device.

Currently eg. amdgpu/i915/nouveau just advertize the max cursor
size via the cursor size caps. But always using the max sized
cursor can waste a surprising amount of power, so a better
strategy is desirable.

Most other drivers don't specify any cursor size at all, in
which case the ioctl code just claims that 64x64 is a great
choice. Whether that is actually true is debatable.

A poll of various compositor developers informs us that
blindly probing with setcursor/atomic ioctl to determine
suitable cursor sizes is not acceptable, thus the
introduction of the new property to supplant the cursor
size caps. The compositor will now be free to select a
more optimal cursor size from the short list of options.

Note that the reported sizes (either via the property or the
caps) make no claims about things such as plane scaling. So
these things should only really be consulted for simple
"cursor like" use cases.

Userspace consumer in the form of mutter seems ready:
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3165

v2: Try to add some docs
v3: Specify that value 0 is reserved for future use (basic idea from Jonas)
    Drop the note about typical hardware (Pekka)
v4: Update the docs to indicate the list is "in order of preference"
    Add a a link to the mutter MR
v5: Limit to cursors only for now (Simon)

Cc: Jonas Ådahl 
Cc: Sameer Lattannavar 
Reviewed-by: Sebastian Wick 
Reviewed-by: Simon Ser 
Acked-by: Daniel Stone 
Acked-by: Harry Wentland 
Acked-by: Pekka Paalanen 
Signed-off-by: Ville Syrjälä 
Link: https://patchwork.freedesktop.org/patch/msgid/20240318204408.9687-2-ville.syrjala@linux.intel.com

drm/fbdev-generic: Remove unused prefer_shadow_fbdev flag

2023-03-22T12:32:47+00:00

Remove the flag prefer_shadow_fbdev from struct drm_mode_config.
Drivers set this flag to enable shadow buffering in the generic
fbdev emulation. Such shadow buffering is now mandatory, so the
flag is unused.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
Reviewed-by: Zack Rusin 
Tested-by: Sui Jingfeng 
Link: https://patchwork.freedesktop.org/patch/msgid/20230320150751.20399-3-tzimmermann@suse.de

drm/connector: Add TV standard property

2022-11-24T11:42:39+00:00

The TV mode property has been around for a while now to select and get the
current TV mode output on an analog TV connector.

Despite that property name being generic, its content isn't and has been
driver-specific which makes it hard to build any generic behaviour on top
of it, both in kernel and user-space.

Let's create a new enum tv norm property, that can contain any of the
analog TV standards currently supported by kernel drivers. Each driver can
then pass in a bitmask of the modes it supports, and the property
creation function will filter out the modes not supported.

We'll then be able to phase out the older tv mode property.

Tested-by: Mateusz Kwiatkowski 
Acked-in-principle-or-something-like-that-by: Daniel Vetter 
Link: https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v10-5-256dad125326@cerno.tech
Signed-off-by: Maxime Ripard

drm/connector: Rename legacy TV property

2022-11-24T11:42:39+00:00

The current tv_mode has driver-specific values that don't allow to
easily share code using it, either at the userspace or kernel level.

Since we're going to introduce a new, generic, property that fit the
same purpose, let's rename this one to legacy_tv_mode to make it
obvious we should move away from it.

Acked-by: Thomas Zimmermann 
Reviewed-by: Lyude Paul  # nouveau
Reviewed-by: Noralf Trønnes 
Tested-by: Mateusz Kwiatkowski 
Acked-in-principle-or-something-like-that-by: Daniel Vetter 
Link: https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v10-2-256dad125326@cerno.tech
Signed-off-by: Maxime Ripard