linux-toradex.git/drivers/gpu/drm/drm_plane.c, branch v6.12

drm: Export drm_plane_has_format()

2024-06-24T14:08:53+00:00

Export drm_plane_has_format() so that drivers can use it.

v2: add kerneldoc

Reviewed-by: Jani Nikula 
Reviewed-by: Daniel Vetter 
Signed-off-by: Ville Syrjälä 
Link: https://patchwork.freedesktop.org/patch/msgid/20240619113144.1616-1-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter 
Acked-by: Daniel Stone 
Acked-by: Thomas Zimmermann

drm: Rename drm_plane_check_pixel_format() to drm_plane_has_format()

2024-06-24T14:08:33+00:00

Rename drm_plane_check_pixel_format() to drm_plane_has_format()
and change the return type accordingly. Allows one to write
more natural code.

Also matches drm_any_plane_has_format() better.

Reviewed-by: Jani Nikula 
Signed-off-by: Ville Syrjälä 
Link: https://patchwork.freedesktop.org/patch/msgid/20240612204712.31404-2-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter 
Acked-by: Thomas Zimmermann

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: 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: Don't unref the same fb many times by mistake due to deadlock handling

2023-12-23T05:31:05+00:00

If we get a deadlock after the fb lookup in drm_mode_page_flip_ioctl()
we proceed to unref the fb and then retry the whole thing from the top.
But we forget to reset the fb pointer back to NULL, and so if we then
get another error during the retry, before the fb lookup, we proceed
the unref the same fb again without having gotten another reference.
The end result is that the fb will (eventually) end up being freed
while it's still in use.

Reset fb to NULL once we've unreffed it to avoid doing it again
until we've done another fb lookup.

This turned out to be pretty easy to hit on a DG2 when doing async
flips (and CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y). The first symptom I
saw that drm_closefb() simply got stuck in a busy loop while walking
the framebuffer list. Fortunately I was able to convince it to oops
instead, and from there it was easier to track down the culprit.

Cc: stable@vger.kernel.org
Signed-off-by: Ville Syrjälä 
Link: https://patchwork.freedesktop.org/patch/msgid/20231211081625.25704-1-ville.syrjala@linux.intel.com
Acked-by: Javier Martinez Canillas

Revert "drm: Introduce pixel_source DRM plane property"

2023-12-04T19:33:10+00:00

This reverts commit e50e5fed41c7eed2db4119645bf3480ec43fec11.

Although the Solid Fill planes patchset got all reviews and
acknowledgements, it doesn't fulfill requirements for the new uABI. It
has neither corresponding open-source userspace implementation nor the
IGT tests coverage. Reverting this patchset until userspace obligations
are fulfilled.

Acked-by: Simon Ser 
Acked-by: Maxime Ripard 
Signed-off-by: Dmitry Baryshkov 
Link: https://patchwork.freedesktop.org/patch/msgid/20231204131455.19023-8-dmitry.baryshkov@linaro.org

Revert "drm/atomic: Add solid fill data to plane state dump"

2023-12-04T19:33:07+00:00

This reverts commit e86413f5442ee094e66b3e75f2d3419ed0df9520.

Although the Solid Fill planes patchset got all reviews and
acknowledgements, it doesn't fulfill requirements for the new uABI. It
has neither corresponding open-source userspace implementation nor the
IGT tests coverage. Reverting this patchset until userspace obligations
are fulfilled.

Acked-by: Simon Ser 
Acked-by: Maxime Ripard 
Signed-off-by: Dmitry Baryshkov 
Link: https://patchwork.freedesktop.org/patch/msgid/20231204131455.19023-4-dmitry.baryshkov@linaro.org

drm/atomic: Add solid fill data to plane state dump

2023-12-01T23:56:53+00:00

Add solid_fill property data to the atomic plane state dump.

Reviewed-by: Dmitry Baryshkov 
Acked-by: Harry Wentland 
Acked-by: Sebastian Wick 
Signed-off-by: Jessica Zhang 
Signed-off-by: Dmitry Baryshkov 
Link: https://patchwork.freedesktop.org/patch/msgid/20231027-solid-fill-v7-5-780188bfa7b2@quicinc.com

drm: Introduce pixel_source DRM plane property

2023-12-01T23:56:46+00:00

Add support for pixel_source property to drm_plane and related
documentation. In addition, force pixel_source to
DRM_PLANE_PIXEL_SOURCE_FB in DRM_IOCTL_MODE_SETPLANE as to not break
legacy userspace.

This enum property will allow user to specify a pixel source for the
plane. Possible pixel sources will be defined in the
drm_plane_pixel_source enum.

Currently, the only pixel sources are DRM_PLANE_PIXEL_SOURCE_FB (the
default value) and DRM_PLANE_PIXEL_SOURCE_NONE.

Acked-by: Dmitry Baryshkov 
Acked-by: Pekka Paalanen 
Acked-by: Harry Wentland 
Acked-by: Sebastian Wick 
Acked-by: Simon Ser 
Signed-off-by: Jessica Zhang 
Signed-off-by: Dmitry Baryshkov 
Link: https://patchwork.freedesktop.org/patch/msgid/20231027-solid-fill-v7-1-780188bfa7b2@quicinc.com

drm/plane: Extend damage tracking kernel-doc

2023-11-24T14:15:29+00:00

The "Damage Tracking Properties" section in the documentation doesn't have
info about the two type of damage handling: frame damage vs buffer damage.

Add it to the section and mention that helpers only support frame damage,
and how drivers handling buffer damage can indicate that the damage clips
should be ignored.

Also add references to further documentation about the two damage types.

Suggested-by: Simon Ser 
Signed-off-by: Javier Martinez Canillas 
Reviewed-by: Simon Ser 
Reviewed-by: Thomas Zimmermann 
Reviewed-by: Zack Rusin 
Acked-by: Sima Vetter 
Link: https://patchwork.freedesktop.org/patch/msgid/20231123221315.3579454-5-javierm@redhat.com