public inbox for linux-mediatek@lists.infradead.org
 help / color / mirror / Atom feed
From: "Nícolas F. R. A. Prado" <nfraprado@collabora.com>
To: Louis Chauvet <louis.chauvet@bootlin.com>,
	Maarten Lankhorst	 <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	 Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
	 Chun-Kuang Hu <chunkuang.hu@kernel.org>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Matthias Brugger	 <matthias.bgg@gmail.com>,
	AngeloGioacchino Del Regno	
	<angelogioacchino.delregno@collabora.com>
Cc: Alex Hung <alex.hung@amd.com>,
	wayland-devel@lists.freedesktop.org,  harry.wentland@amd.com,
	leo.liu@amd.com, ville.syrjala@linux.intel.com,
	 pekka.paalanen@collabora.com, contact@emersion.fr,
	mwen@igalia.com,  jadahl@redhat.com, sebastian.wick@redhat.com,
	shashank.sharma@amd.com,  agoins@nvidia.com, joshua@froggi.es,
	mdaenzer@redhat.com, aleixpol@kde.org, xaver.hugl@gmail.com,
	victoria@system76.com, uma.shankar@intel.com,
	 quic_naseer@quicinc.com, quic_cbraga@quicinc.com,
	quic_abhinavk@quicinc.com, 	marcan@marcan.st,
	Liviu.Dudau@arm.com, sashamcintosh@google.com,
		chaitanya.kumar.borah@intel.com, mcanal@igalia.com,
	kernel@collabora.com, 	daniels@collabora.com,
	dri-devel@lists.freedesktop.org, 	linux-kernel@vger.kernel.org,
	linux-mediatek@lists.infradead.org,
		linux-arm-kernel@lists.infradead.org,
	Simona Vetter <simona.vetter@ffwll.ch>
Subject: Re: [PATCH RFC 1/5] drm: Support post-blend color pipeline API
Date: Tue, 09 Sep 2025 15:31:17 -0400	[thread overview]
Message-ID: <eab7182d8b25d87c11f2541db910c6ea3d9434e9.camel@collabora.com> (raw)
In-Reply-To: <4d63e90a-794f-4108-9219-19b0c0dab267@bootlin.com>

On Fri, 2025-09-05 at 19:55 +0200, Louis Chauvet wrote:
> 
> 
> Le 22/08/2025 à 20:36, Nícolas F. R. A. Prado a écrit :
> > Introduce support for a post-blend color pipeline API analogous to
> > the
> > pre-blend color pipeline API. While the pre-blend color pipeline
> > was
> > configured through a COLOR_PIPELINE property attached to a
> > drm_plane,
> > the post-blend color pipeline is configured through a
> > COLOR_PIPELINE
> > property on the drm_crtc.
> > 
> > Since colorops can now be attached to either a drm_plane or a
> > drm_crtc,
> > rework the helpers to account for both cases.
> > 
> > Also introduce a new cap, DRM_CLIENT_CAP_POST_BLEND_COLOR_PIPELINE,
> > to
> > enable support for post-blend color pipelines, and prevent the now
> > legacy GAMMA_LUT, DEGAMMA_LUT, GAMMA_LUT_SIZE and CTM properties
> > from
> > being exposed.
> > 
> > Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
> > ---
> >   drivers/gpu/drm/drm_atomic.c        |  32 ++++++--
> >   drivers/gpu/drm/drm_atomic_uapi.c   |  50 ++++++++++++-
> >   drivers/gpu/drm/drm_colorop.c       | 144
> > +++++++++++++++++++++++++++++-------
> >   drivers/gpu/drm/drm_connector.c     |   1 +
> >   drivers/gpu/drm/drm_crtc.c          |  77 +++++++++++++++++++
> >   drivers/gpu/drm/drm_crtc_internal.h |   6 ++
> >   drivers/gpu/drm/drm_ioctl.c         |   7 ++
> >   drivers/gpu/drm/drm_mode_object.c   |  20 +++++
> >   drivers/gpu/drm/drm_plane.c         |  36 ++-------
> >   include/drm/drm_atomic.h            |  20 +++++
> >   include/drm/drm_atomic_uapi.h       |   2 +
> >   include/drm/drm_colorop.h           |  16 +++-
> >   include/drm/drm_crtc.h              |  19 +++++
> >   include/drm/drm_file.h              |   7 ++
> >   include/uapi/drm/drm.h              |  16 ++++
> >   15 files changed, 383 insertions(+), 70 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic.c
> > b/drivers/gpu/drm/drm_atomic.c
> > index
> > 3ab32fe7fe1cbf9057c3763d979638dce013d82b..558d389d59d9a44d3cd1048ed
> > 365848f62b4d62d 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -472,6 +472,8 @@ static void drm_atomic_crtc_print_state(struct
> > drm_printer *p,
> >   	drm_printf(p, "\tplane_mask=%x\n", state->plane_mask);
> >   	drm_printf(p, "\tconnector_mask=%x\n", state-
> > >connector_mask);
> >   	drm_printf(p, "\tencoder_mask=%x\n", state->encoder_mask);
> > +	drm_printf(p, "\tcolor-pipeline=%d\n",
> > +		   state->color_pipeline ? state->color_pipeline-
> > >base.id : 0);
> 
> This could be in a separate patch / suggested to the initial series.

Right, I'll make sure to split the changes in this commit further for
v2.

> 
> >   	drm_printf(p, "\tmode: " DRM_MODE_FMT "\n",
> > DRM_MODE_ARG(&state->mode));
> >   
> >   	if (crtc->funcs->atomic_print_state)
> > @@ -617,9 +619,15 @@ drm_atomic_get_colorop_state(struct
> > drm_atomic_state *state,
> >   	if (colorop_state)
> >   		return colorop_state;
> >   
> > -	ret = drm_modeset_lock(&colorop->plane->mutex, state-
> > >acquire_ctx);
> > -	if (ret)
> > -		return ERR_PTR(ret);
> > +	if (colorop->plane) {
> > +		ret = drm_modeset_lock(&colorop->plane->mutex,
> > state->acquire_ctx);
> > +		if (ret)
> > +			return ERR_PTR(ret);
> > +	} else {
> > +		ret = drm_modeset_lock(&colorop->crtc->mutex,
> > state->acquire_ctx);
> > +		if (ret)
> > +			return ERR_PTR(ret);
> > +	}
> 
> Two suggestions here:
> 
> Maybe you can create `colorop_modeset_lock/unlock` helpers to avoid
> code 
> repetition.
> 
> Can you also change it to
> 
> 	if (colorop->plane)
> 		...
> 	else if (colorop->crtc)
> 		...
> 	else
> 		drm_err("Dangling colorop, it must be attached to a
> plane or a CRTC")
> 		return ERR_PTR
> 
> ?
> 
> This way it will avoid issues if someone add support to attach
> colorop 
> to other drm parts and forgot to update locking in some places.

Yes, both suggestions sound good, I'll apply them for v2.

> > diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> > index
> > 27cc159c1d275c7a7fe057840ef792f30a582bb7..1191b142ebaa5478376308f16
> > 9f9ce8591580d9d 100644
> > --- a/include/uapi/drm/drm.h
> > +++ b/include/uapi/drm/drm.h
> > @@ -921,6 +921,22 @@ struct drm_get_cap {
> >    */
> >   #define DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE	7
> >   
> > +/**
> > + * DRM_CLIENT_CAP_POST_BLEND_COLOR_PIPELINE
> > + *
> > + * If set to 1 the DRM core will allow setting the COLOR_PIPELINE
> > + * property on a &drm_crtc, as well as drm_colorop properties.
> > + *
> > + * Setting of these crtc properties will be rejected when this
> > client
> > + * cap is set:
> 
> I don't know enough the uAPI of DRM, but if I understand your patch 
> correctly, it will not reject GAMMA_LUT/DEGAMMA_LUT/CTM, only unlist 
> them from the get_properties syscall. Did I overlooked something?

You're right. This was originally based on v10 of the pre-blend series
(https://lore.kernel.org/dri-devel/20250617041746.2884343-12-alex.hung@amd.com/
), which did in fact return an error when the properties were set with
the cap enabled, but v11
(https://lore.kernel.org/all/20250815035047.3319284-12-alex.hung@amd.com/
) switched to just unlisting the properties, so I also updated the code
here accordingly for this RFC, but forgot to update this text, and
apparently so did the original series.

From the discussion in another thread
(https://lore.kernel.org/dri-devel/20250822-mtk-post-blend-color-pipeline-v1-0-a9446d4aca82@collabora.com/T/#m1e8ba77ef54453b26ae70e1f1699ed17afec91e3
) we might make these properties read-only, and in which case we'll
have to make them listed but error when set again, so I'll wait for
that discussion to be resolved before updating this and forwarding that
feedback to the pre-blend series. But thanks for pointing out the
inconsistency anyway.

> 
> > + * - GAMMA_LUT
> > + * - DEGAMMA_LUT
> > + * - CTM
> > + *
> > + * The client must enable &DRM_CLIENT_CAP_ATOMIC first.
> > + */
> > +#define DRM_CLIENT_CAP_POST_BLEND_COLOR_PIPELINE	8
> > +
> >   /* DRM_IOCTL_SET_CLIENT_CAP ioctl argument type */
> >   struct drm_set_client_cap {
> >   	__u64 capability;
> > 

-- 
Thanks,

Nícolas


  reply	other threads:[~2025-09-09 19:32 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-22 18:36 [PATCH RFC 0/5] Introduce support for post-blend color pipeline Nícolas F. R. A. Prado
2025-08-22 18:36 ` [PATCH RFC 1/5] drm: Support post-blend color pipeline API Nícolas F. R. A. Prado
2025-08-25 13:34   ` Daniel Stone
2025-08-25 18:45     ` Xaver Hugl
2025-08-26 12:25       ` Daniel Stone
2025-09-03 18:42         ` Nícolas F. R. A. Prado
2025-09-15 12:31           ` Daniel Stone
2025-09-26 13:51             ` Sebastian Wick
2025-09-29 10:33               ` Harry Wentland
     [not found]             ` <2a985767-0fe1-40fc-b45e-921bbf201e07@app.fastmail.com>
2025-09-30 12:20               ` Daniel Stone
2025-10-02  8:00                 ` Pekka Paalanen
2025-08-27 11:17   ` Sebastian Wick
2025-08-27 11:32     ` Daniel Stone
2025-09-05 17:55   ` Louis Chauvet
2025-09-09 19:31     ` Nícolas F. R. A. Prado [this message]
2025-08-22 18:36 ` [PATCH RFC 2/5] drm/colorop: Export drm_colorop_cleanup() so drivers can extend it Nícolas F. R. A. Prado
2025-09-05 17:55   ` Louis Chauvet
2025-08-22 18:36 ` [PATCH RFC 3/5] drm/mediatek: Support post-blend colorops for gamma and ctm Nícolas F. R. A. Prado
2025-09-05 17:55   ` Louis Chauvet
2025-08-22 18:36 ` [PATCH RFC 4/5] drm/mediatek: ccorr: Support post-blend color pipeline API Nícolas F. R. A. Prado
2025-08-22 18:36 ` [PATCH RFC 5/5] drm/mediatek: gamma: " Nícolas F. R. A. Prado

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=eab7182d8b25d87c11f2541db910c6ea3d9434e9.camel@collabora.com \
    --to=nfraprado@collabora.com \
    --cc=Liviu.Dudau@arm.com \
    --cc=agoins@nvidia.com \
    --cc=airlied@gmail.com \
    --cc=aleixpol@kde.org \
    --cc=alex.hung@amd.com \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=chaitanya.kumar.borah@intel.com \
    --cc=chunkuang.hu@kernel.org \
    --cc=contact@emersion.fr \
    --cc=daniels@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=harry.wentland@amd.com \
    --cc=jadahl@redhat.com \
    --cc=joshua@froggi.es \
    --cc=kernel@collabora.com \
    --cc=leo.liu@amd.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=louis.chauvet@bootlin.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=marcan@marcan.st \
    --cc=matthias.bgg@gmail.com \
    --cc=mcanal@igalia.com \
    --cc=mdaenzer@redhat.com \
    --cc=mripard@kernel.org \
    --cc=mwen@igalia.com \
    --cc=p.zabel@pengutronix.de \
    --cc=pekka.paalanen@collabora.com \
    --cc=quic_abhinavk@quicinc.com \
    --cc=quic_cbraga@quicinc.com \
    --cc=quic_naseer@quicinc.com \
    --cc=sashamcintosh@google.com \
    --cc=sebastian.wick@redhat.com \
    --cc=shashank.sharma@amd.com \
    --cc=simona.vetter@ffwll.ch \
    --cc=simona@ffwll.ch \
    --cc=tzimmermann@suse.de \
    --cc=uma.shankar@intel.com \
    --cc=victoria@system76.com \
    --cc=ville.syrjala@linux.intel.com \
    --cc=wayland-devel@lists.freedesktop.org \
    --cc=xaver.hugl@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox