From: Jani Nikula <jani.nikula@linux.intel.com>
To: Louis Chauvet <louis.chauvet@bootlin.com>,
Maxime Ripard <mripard@kernel.org>
Cc: "Rodrigo Siqueira" <rodrigosiqueiramelo@gmail.com>,
"Melissa Wen" <melissa.srw@gmail.com>,
"Maíra Canal" <mairacanal@riseup.net>,
"Haneen Mohammed" <hamohammed.sa@gmail.com>,
"Daniel Vetter" <daniel@ffwll.ch>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"David Airlie" <airlied@gmail.com>,
dri-devel@lists.freedesktop.org, arthurgrillo@riseup.net,
linux-kernel@vger.kernel.org, jeremie.dautheribes@bootlin.com,
miquel.raynal@bootlin.com, thomas.petazzoni@bootlin.com,
seanpaul@google.com, nicolejadeyee@google.com
Subject: Re: [PATCH RFC 11/15] drm: writeback: Add drm_writeback_connector cleanup
Date: Wed, 28 Aug 2024 11:35:43 +0300 [thread overview]
Message-ID: <87a5gxyrhc.fsf@intel.com> (raw)
In-Reply-To: <Zs3z7tx4dMBfY_DX@louis-chauvet-laptop>
On Tue, 27 Aug 2024, Louis Chauvet <louis.chauvet@bootlin.com> wrote:
> Le 27/08/24 - 16:33, Maxime Ripard a écrit :
>> Hi,
>>
>> On Wed, Aug 14, 2024 at 04:36:33PM GMT, Louis Chauvet wrote:
>> > Currently drm_writeback_connector are created by
>> > drm_writeback_connector_init or drm_writeback_connector_init_with_encoder.
>> > Both of the function uses drm_connector_init and drm_encoder_init, but
>> > there is no way to properly clean those structure from outside.
>> >
>> > This patch introduce the new function drm_writeback_connector_cleanup to
>> > allow a proper cleanup.
>> >
>> > Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
>> > ---
>> > drivers/gpu/drm/drm_writeback.c | 10 ++++++++++
>> > include/drm/drm_writeback.h | 11 +++++++++++
>> > 2 files changed, 21 insertions(+)
>> >
>> > diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
>> > index a031c335bdb9..505a4eb40f93 100644
>> > --- a/drivers/gpu/drm/drm_writeback.c
>> > +++ b/drivers/gpu/drm/drm_writeback.c
>> > @@ -184,6 +184,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
>> > drm_encoder_helper_add(&wb_connector->encoder, enc_helper_funcs);
>> >
>> > wb_connector->encoder.possible_crtcs = possible_crtcs;
>> > + wb_connector->managed_encoder = true;
>> >
>> > ret = drm_encoder_init(dev, &wb_connector->encoder,
>> > &drm_writeback_encoder_funcs,
>> > @@ -290,6 +291,15 @@ int drm_writeback_connector_init_with_encoder(struct drm_device *dev,
>> > }
>> > EXPORT_SYMBOL(drm_writeback_connector_init_with_encoder);
>> >
>> > +void drm_writeback_connector_cleanup(struct drm_writeback_connector *wb_connector)
>> > +{
>> > + drm_connector_cleanup(&wb_connector->base);
>> > + drm_property_blob_put(wb_connector->pixel_formats_blob_ptr);
>> > + if (wb_connector->managed_encoder)
>> > + drm_encoder_cleanup(&wb_connector->encoder);
>> > +}
>> > +EXPORT_SYMBOL(drm_writeback_connector_cleanup);
>> > +
>> > int drm_writeback_set_fb(struct drm_connector_state *conn_state,
>> > struct drm_framebuffer *fb)
>> > {
>> > diff --git a/include/drm/drm_writeback.h b/include/drm/drm_writeback.h
>> > index 17e576c80169..e651c0c0c84c 100644
>> > --- a/include/drm/drm_writeback.h
>> > +++ b/include/drm/drm_writeback.h
>> > @@ -35,6 +35,15 @@ struct drm_writeback_connector {
>> > */
>> > struct drm_encoder encoder;
>> >
>> > + /**
>> > + * @managed_encoder: Sets to true if @encoder was created by drm_writeback_connector_init()
>> > + *
>> > + * If the user used drm_writeback_connector_init_with_encoder() to create the connector,
>> > + * @encoder is not valid and not managed by drm_writeback_connector. This fields allows
>> > + * the drm_writeback_cleanup() function to properly destroy the encoder if needed.
>> > + */
>> > + bool managed_encoder;
>> > +
>>
>> I think we should rather create drmm_writeback_connector variants,
>> and make both deprecated in favor of these new functions.
>
> Hi,
>
> I can try to do it. If I understand correctly, you want to create two
> functions like this?
>
> int drmm_writeback_connector_init([...]) {
> /* drmm and alloc as we want to let drm core to manage this
> encoder, no need to store it in drm_writeback_connector
> */
> enc = drmm_plain_encoder_alloc(...);
>
> return drmm_writeback_connector_init_with_encoder([...], enc);
> }
>
> int drmm_writeback_connector_init_with_encoder([...], enc) {
> con = drmm_connector_init([...]);
>
> drm_connector_attach_encoder(enc, con);
>
> /* Needed for pixel_formats_blob_ptr, base is already
> managed by drmm_connector_init. Maybe cleaning
> job_queue is also needed? */
> drmm_add_action_or_reset([...], &drm_writeback_connector_cleanup)
> }
Why add two variants, when you can have one and pass NULL for encoder?
We have the _init_with_encoder variant only because nobody bothered to
clean up existing call sites.
Side note, I'd still like to be able to pass driver's own allocated
connector instead of having writeback midlayer force it on you.
BR,
Jani.
>
> Louis Chauvet
>
>> Maxime
>
>
--
Jani Nikula, Intel
next prev parent reply other threads:[~2024-08-28 8:36 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-14 14:36 [PATCH RFC 00/15] drm/vkms: Introduce detailed configuration Louis Chauvet
2024-08-14 14:36 ` [PATCH RFC 01/15] drm/vkms: Remove useles devres group Louis Chauvet
2024-08-19 14:23 ` Daniel Vetter
2024-08-14 14:36 ` [PATCH RFC 02/15] drm/vkms: remove possible crtc from parameters Louis Chauvet
2024-09-05 12:33 ` José Expósito
2024-08-14 14:36 ` [PATCH RFC 03/15] drm/vkms: Extract vkms_config header Louis Chauvet
2024-09-05 12:33 ` José Expósito
2024-08-14 14:36 ` [PATCH RFC 04/15] drm/vkms: Add a validation function for vkms configuration Louis Chauvet
2024-09-05 12:33 ` José Expósito
2024-08-14 14:36 ` [PATCH RFC 05/15] drm/vkms: Move default_config creation to its own function Louis Chauvet
2024-08-14 14:36 ` [PATCH RFC 06/15] drm/vkms: Introduce plane configuration Louis Chauvet
2024-09-05 12:33 ` José Expósito
2024-08-14 14:36 ` [PATCH RFC 07/15] drm/vkms: Introduce plane name configuration Louis Chauvet
2024-09-05 12:34 ` José Expósito
2024-08-14 14:36 ` [PATCH RFC 08/15] drm/vkms: Introduce plane rotation configuration Louis Chauvet
2024-08-14 14:36 ` [PATCH RFC 09/15] drm/vkms: Introduce configuration for plane color encoding Louis Chauvet
2024-08-14 14:36 ` [PATCH RFC 10/15] drm/vkms: Introduce configuration for plane color range Louis Chauvet
2024-08-14 14:36 ` [PATCH RFC 11/15] drm: writeback: Add drm_writeback_connector cleanup Louis Chauvet
2024-08-27 14:33 ` Maxime Ripard
2024-08-27 15:42 ` Louis Chauvet
2024-08-28 8:35 ` Jani Nikula [this message]
2024-08-28 9:07 ` Louis Chauvet
2024-08-28 15:17 ` Maxime Ripard
2024-08-14 14:36 ` [PATCH RFC 12/15] drm/vkms: Add configuration for CRTCs and encoders Louis Chauvet
2024-09-05 12:34 ` José Expósito
2024-08-14 14:36 ` [PATCH RFC 13/15] drm/vkms: Add name configuration for encoders Louis Chauvet
2024-08-14 14:36 ` [PATCH RFC 14/15] drm/vkms: Add name configuration for CRTCs Louis Chauvet
2024-08-14 14:36 ` [PATCH RFC 15/15] drm/vkms: Add test for config structure Louis Chauvet
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=87a5gxyrhc.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=airlied@gmail.com \
--cc=arthurgrillo@riseup.net \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=hamohammed.sa@gmail.com \
--cc=jeremie.dautheribes@bootlin.com \
--cc=linux-kernel@vger.kernel.org \
--cc=louis.chauvet@bootlin.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mairacanal@riseup.net \
--cc=melissa.srw@gmail.com \
--cc=miquel.raynal@bootlin.com \
--cc=mripard@kernel.org \
--cc=nicolejadeyee@google.com \
--cc=rodrigosiqueiramelo@gmail.com \
--cc=seanpaul@google.com \
--cc=thomas.petazzoni@bootlin.com \
--cc=tzimmermann@suse.de \
/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