[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20251206-vop2-atomic-fixups-v2-0-7fb45bbfbebd@collabora.com>
Date: Sat, 06 Dec 2025 21:45:10 +0100
From: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
To: Sandy Huang <hjc@...k-chips.com>,
Heiko Stübner <heiko@...ech.de>,
Andy Yan <andy.yan@...k-chips.com>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>
Cc: kernel@...labora.com, dri-devel@...ts.freedesktop.org,
linux-arm-kernel@...ts.infradead.org, linux-rockchip@...ts.infradead.org,
linux-kernel@...r.kernel.org, Daniel Stone <daniels@...labora.com>,
Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
Subject: [PATCH v2 0/8] drm/rockchip: No more post-atomic_check fixups
I'm taking over this series to get it across the finish line. Original
cover letter from Daniel Stone on v1:
> Hi,
> This series is a pretty small and consistent one for VOP2. The atomic
> uAPI very clearly specifies that drivers should either do what userspace
> requested (on a successful commit), or fail atomic_check if it is not
> for any reason possible to do what userspace requested.
>
> VOP2 is unfortunately littered with a bunch of cases where it will apply
> fixups after atomic_check - doing something different to what userspace
> requested, e.g. clipping or aligning regions - or throw error messages
> into the log when userspace does request a condition which can't be met.
>
> Doing something different to what was requested is bad because it
> results in unexpected visual output which can look like artifacts.
> Throwing errors into the log is bad because generic userspace will
> reasonably attempt to try any configuration it can. For example,
> throwing an error message on a plane not being aligned to a 16 pixel
> boundary can result in 15 frames' worth of error output in the log when
> a window is being animated across a screen.
>
> This series removes all post-check fixups - failing the check if the
> configuration cannot be applied - and also demotes all messages about
> unsupported configurations to DEBUG_KMS.
>
> Cheers,
> Daniel
Changes in v2:
- Dropped patches [1, 5] as they were already applied.
- Changed the patch subject to use prefix "drm/rockchip: vop2:" for the
remaining ones.
- Fixed a checkpatch nag about commenting style in "Switch impossible
pos conditional to WARN_ON".
- Reworded "eSmart" to "Esmart" for consistency, and to avoid drawing
Tim Apple's ire.
- Make the hopefully impossible WARN_ON format conditional in
vop2_plane_atomic_check still bubble the error up to userspace,
instead of continuing on.
- Use dest_w instead of dsp_w in patch "Enforce scaling workaround
in plane_check", to avoid a compiler error.
- Only reject non-multiple-of-4-pixel-wide framebuffers on
RK3566/RK3568, as the other SoCs have no such limitation. (Thank you
to Andy Yan for doing the research to confirm this!)
- Consequently also only WARN_ON if this condition is violated in
atomic_update on those SoCs.
- Link to v1: https://lore.kernel.org/dri-devel/20251015110042.41273-1-daniels@collabora.com/
Signed-off-by: Daniel Stone <daniels@...labora.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
---
Daniel Stone (8):
drm/rockchip: vop2: Switch impossible format conditional to WARN_ON
drm/rockchip: vop2: Switch impossible pos conditional to WARN_ON
drm/rockchip: vop2: Fix Esmart test condition
drm/rockchip: vop2: Enforce scaling workaround in plane_check
drm/rockchip: vop2: Enforce AFBC source alignment in plane_check
drm/rockchip: vop2: Enforce AFBC transform stride align in plane_check
drm/rockchip: vop2: Use drm_is_afbc helper function
drm/rockchip: vop2: Simplify format_mod_supported
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 137 ++++++++++++---------------
1 file changed, 62 insertions(+), 75 deletions(-)
---
base-commit: 4e5a9b630580faea139e9837b4fba666db6bd728
change-id: 20251206-vop2-atomic-fixups-0c30e0980f85
Best regards,
--
Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
Powered by blists - more mailing lists