From: "José Expósito" <jose.exposito89@gmail.com>
To: Louis Chauvet <louis.chauvet@bootlin.com>
Cc: hamohammed.sa@gmail.com, simona@ffwll.ch, melissa.srw@gmail.com,
maarten.lankhorst@linux.intel.com, mripard@kernel.org,
tzimmermann@suse.de, airlied@gmail.com,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 09/13] drm/vkms: Allow to attach planes and CRTCs
Date: Thu, 13 Feb 2025 16:32:54 +0100 [thread overview]
Message-ID: <Z64QpktpcVjtelKY@fedora> (raw)
In-Reply-To: <b05831de-c67b-4ba9-8808-f049d97b3654@bootlin.com>
On Wed, Feb 12, 2025 at 03:10:49PM +0100, Louis Chauvet wrote:
>
>
> Le 11/02/2025 à 11:47, José Expósito a écrit :
> > On Thu, Jan 30, 2025 at 02:48:21PM +0100, Louis Chauvet wrote:
> > > On 29/01/25 - 12:00, José Expósito wrote:
> > > > Add a list of possible CRTCs to the plane configuration and helpers to
> > > > attach, detach and get the primary and cursor planes attached to a CRTC.
> > > >
> > > > Now that the default configuration has its planes and CRTC correctly
> > > > attached, configure the output following the configuration.
> > > >
> > > > Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
> > > > Signed-off-by: José Expósito <jose.exposito89@gmail.com>
> > >
> > > Co-developped-by: Louis Chauvet <louis.chauvet@bootlin.com>
> > > Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
> > > Signed-off-by: José Expósito <jose.exposito89@gmail.com>
> > >
> > > [...]
> > >
> > > > +int __must_check vkms_config_plane_attach_crtc(struct vkms_config_plane *plane_cfg,
> > > > + struct vkms_config_crtc *crtc_cfg)
> > > > +{
> > > > + struct vkms_config_crtc *possible_crtc;
> > > > + unsigned long idx = 0;
> > > > + u32 crtc_idx = 0;
> > > > +
> > > > + xa_for_each(&plane_cfg->possible_crtcs, idx, possible_crtc) {
> > > > + if (possible_crtc == crtc_cfg)
> > > > + return -EINVAL;
> > >
> > > Is it really an error? After this call, we expect plane and crtc to be
> > > attached, so if the plane is already attached, I don't see any issue.
> >
> > In my opinion, this could be either handled as an error or not. I think that
> > there are arguments for both approaches but, for our use case, I think that it
> > is better to return an error.
> >
> > Since the main (and for the moment only) user of this function will be configfs,
> > it is very convenient to return an error to avoid creating 2 links between
> > plane <-> crtc.
> >
> > If we allow to create multiple links, and the user deletes one of them, the
> > items would be still linked, which is a bit unexpected.
> >
> > The same applies to the other vkms_config_*_attach_* functions.
>
> I see your reasoning, I did not think about this issue.
> We can keep the error, but can we use `EEXIST` to reflect better the status?
Very good point, I'll change it to EEXIST in v3.
> And I just think about it, maybe we can add here the check "is the crtc part
> of the same config as the plane" (and return EINVAL if not)? It will remove
> the need to do the check in configFS + avoid errors for future users of
> vkms_config.
Another excellent point. Since we can not use the vkms_config_plane.plane and
vkms_config_crtc.crtc pointers to check if they belong to the same device, the
only solution I see is adding a pointer to the parent vkms_config to every
structure (vkms_config_plane, vkms_config_crtc, etc).
In this way we can do something like:
if (plane_cfg->config != crtc_cfg->config)
return -EINVAL;
I tried with container_of(), but I don't think it'll work with the current data
structure.
Unless you can think of a better solution, I'll implement this in v3.
Thanks for the great comments,
Jose
> > For these reasons, I didn't change it in v2, let me know your opinion.
> > Jose
> >
> > > > + }
> > > > +
> > > > + return xa_alloc(&plane_cfg->possible_crtcs, &crtc_idx, crtc_cfg,
> > > > + xa_limit_32b, GFP_KERNEL);
> > > > +}
> > > > +
> > >
> > > [...]
> > >
> > > > +struct vkms_config_crtc **vkms_config_plane_get_possible_crtcs(struct vkms_config_plane *plane_cfg,
> > > > + size_t *out_length)
> > > > +{
> > > > + struct vkms_config_crtc **array;
> > > > + struct vkms_config_crtc *possible_crtc;
> > > > + unsigned long idx;
> > > > + size_t length = 0;
> > > > + int n = 0;
> > > > +
> > > > + xa_for_each(&plane_cfg->possible_crtcs, idx, possible_crtc)
> > > > + length++;
> > > > +
> > > > + if (length == 0) {
> > > > + *out_length = length;
> > > > + return NULL;
> > > > + }
> > > > +
> > > > + array = kmalloc_array(length, sizeof(*array), GFP_KERNEL);
> > > > + if (!array)
> > > > + return ERR_PTR(-ENOMEM);
> > > > +
> > > > + xa_for_each(&plane_cfg->possible_crtcs, idx, possible_crtc) {
> > > > + array[n] = possible_crtc;
> > > > + n++;
> > > > + }
> > > > +
> > > > + *out_length = length;
> > > > + return array;
> > > > +}
> > >
> > > Same as before, can we use an iterator?
> > >
> > > > +static struct vkms_config_plane *vkms_config_crtc_get_plane(const struct vkms_config *config,
> > > > + struct vkms_config_crtc *crtc_cfg,
> > > > + enum drm_plane_type type)
> > >
> > > Even if this is a private function, can we add a comment explaning that
> > > the returned value is only one of the available planes of this type?
> > >
> > > /**
> > > * vkms_config_crtc_get_plane() - Get the first attached plane
> > > * found of a specific type
> > > * @config: configuration containing the crtc and the planes
> > > * @crtc_cfg: Only find planes attached to this CRTC
> > > * @type: Plane type to search
> > > *
> > > * Returns:
> > > * The first plane found attached to @crtc_cfg with the type
> > > * @type.
> > > */
> > >
> > > > +{
> > > > + struct vkms_config_plane *plane_cfg;
> > > > + struct vkms_config_crtc *possible_crtc;
> > > > + enum drm_plane_type current_type;
> > > > + unsigned long idx;
> > > > +
> > > > + list_for_each_entry(plane_cfg, &config->planes, link) {
> > > > + current_type = vkms_config_plane_get_type(plane_cfg);
> > > > +
> > > > + xa_for_each(&plane_cfg->possible_crtcs, idx, possible_crtc) {
> > > > + if (possible_crtc == crtc_cfg && current_type == type)
> > > > + return plane_cfg;
> > > > + }
> > > > + }
> > > > +
> > > > + return NULL;
> > > > +}
> > >
> > > [...]
> > >
> > > > diff --git a/drivers/gpu/drm/vkms/vkms_config.h b/drivers/gpu/drm/vkms/vkms_config.h
> > >
> > > [...]
> > >
> > > > +/**
> > > > + * vkms_config_crtc_primary_plane() - Return the primary plane for a CRTC
> > > > + * @config: Configuration containing the CRTC
> > > > + * @crtc_config: Target CRTC
> > > > + *
> > > > + * Returns:
> > > > + * The primary plane or NULL if none is assigned yet.
> > > > + */
> > >
> > > Same as above, can you speficy that it is one of the primary plane?
> > >
> > > > +struct vkms_config_plane *vkms_config_crtc_primary_plane(const struct vkms_config *config,
> > > > + struct vkms_config_crtc *crtc_cfg);
> > > > +
> > > > +/**
> > > > + * vkms_config_crtc_cursor_plane() - Return the cursor plane for a CRTC
> > >
> > > Ditto
> > >
> > > [...]
> > >
> > > > diff --git a/drivers/gpu/drm/vkms/vkms_output.c b/drivers/gpu/drm/vkms/vkms_output.c
> > >
> > > [...]
> > >
> > > > @@ -35,19 +41,54 @@ int vkms_output_init(struct vkms_device *vkmsdev)
> > > > ret = PTR_ERR(plane_cfg->plane);
> > > > goto err_free;
> > > > }
> > > > + }
> > > > +
> > > > + for (n = 0; n < n_crtcs; n++) {
> > > > + struct vkms_config_crtc *crtc_cfg;
> > > > + struct vkms_config_plane *primary, *cursor;
> > > > +
> > > > + crtc_cfg = crtc_cfgs[n];
> > > > + primary = vkms_config_crtc_primary_plane(vkmsdev->config, crtc_cfg);
> > > > + cursor = vkms_config_crtc_cursor_plane(vkmsdev->config, crtc_cfg);
> > >
> > > Linked with a previous comment: here we have no garantee that primary is a
> > > valid pointer, can we check it or call vkms_config_is_valid to ensure it?
> > >
> > > > + crtc_cfg->crtc = vkms_crtc_init(dev, &primary->plane->base,
> > > > + cursor ? &cursor->plane->base : NULL);
> > > > + if (IS_ERR(crtc_cfg->crtc)) {
> > > > + DRM_ERROR("Failed to allocate CRTC\n");
> > > > + ret = PTR_ERR(crtc_cfg->crtc);
> > > > + goto err_free;
> > > > + }
> > >
> > > [...]
>
> --
> Louis Chauvet, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>
next prev parent reply other threads:[~2025-02-13 15:33 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-29 11:00 [PATCH 00/13] drm/vkms: Allow to configure device José Expósito
2025-01-29 11:00 ` [PATCH 01/13] drm/vkms: Extract vkms_connector header José Expósito
2025-01-30 13:48 ` Louis Chauvet
2025-02-11 10:37 ` José Expósito
2025-01-29 11:00 ` [PATCH 02/13] drm/vkms: Add KUnit test scaffolding José Expósito
2025-01-30 13:48 ` Louis Chauvet
2025-01-29 11:00 ` [PATCH 03/13] drm/vkms: Extract vkms_config header José Expósito
2025-01-30 13:48 ` Louis Chauvet
2025-02-11 10:39 ` José Expósito
2025-01-29 11:00 ` [PATCH 04/13] drm/vkms: Move default_config creation to its own function José Expósito
2025-01-30 13:48 ` Louis Chauvet
2025-01-29 11:00 ` [PATCH 05/13] drm/vkms: Set device name from vkms_config José Expósito
2025-01-30 13:48 ` Louis Chauvet
2025-01-29 11:00 ` [PATCH 06/13] drm/vkms: Add a validation function for VKMS configuration José Expósito
2025-01-30 13:48 ` Louis Chauvet
2025-01-29 11:00 ` [PATCH 07/13] drm/vkms: Allow to configure multiple planes José Expósito
2025-01-30 13:48 ` Louis Chauvet
2025-02-11 10:43 ` José Expósito
2025-02-12 14:10 ` Louis Chauvet
2025-01-29 11:00 ` [PATCH 08/13] drm/vkms: Allow to configure multiple CRTCs José Expósito
2025-01-30 13:48 ` Louis Chauvet
2025-02-11 10:44 ` José Expósito
2025-02-12 14:12 ` Louis Chauvet
2025-02-13 15:26 ` José Expósito
2025-01-29 11:00 ` [PATCH 09/13] drm/vkms: Allow to attach planes and CRTCs José Expósito
2025-01-30 13:48 ` Louis Chauvet
2025-02-11 10:47 ` José Expósito
2025-02-12 14:10 ` Louis Chauvet
2025-02-13 15:32 ` José Expósito [this message]
2025-01-29 11:00 ` [PATCH 10/13] drm/vkms: Allow to configure multiple encoders José Expósito
2025-01-30 13:48 ` Louis Chauvet
2025-01-29 11:00 ` [PATCH 11/13] drm/vkms: Allow to attach encoders and CRTCs José Expósito
2025-01-30 13:48 ` Louis Chauvet
2025-01-29 11:00 ` [PATCH 12/13] drm/vkms: Allow to configure multiple connectors José Expósito
2025-01-30 13:48 ` Louis Chauvet
2025-01-29 11:00 ` [PATCH 13/13] drm/vkms: Allow to attach connectors and encoders José Expósito
2025-01-30 13:48 ` Louis Chauvet
2025-01-30 13:48 ` [PATCH 00/13] drm/vkms: Allow to configure device Louis Chauvet
2025-01-31 9:31 ` José Expósito
2025-01-31 13:02 ` Louis Chauvet
2025-01-31 17:13 ` José Expósito
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=Z64QpktpcVjtelKY@fedora \
--to=jose.exposito89@gmail.com \
--cc=airlied@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=hamohammed.sa@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=louis.chauvet@bootlin.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=melissa.srw@gmail.com \
--cc=mripard@kernel.org \
--cc=simona@ffwll.ch \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.