public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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 00/13] drm/vkms: Allow to configure device
Date: Fri, 31 Jan 2025 10:31:02 +0100	[thread overview]
Message-ID: <Z5yYVov9_z6CDU46@fedora> (raw)
In-Reply-To: <Z5uDGr445jEfdt5L@louis-chauvet-laptop>

On Thu, Jan 30, 2025 at 02:48:10PM +0100, Louis Chauvet wrote:
> On 29/01/25 - 12:00, José Expósito wrote:
> > Hi everyone,
> > 
> > In preparation for ConfigFS support, a flexible way to configure VKMS device(s)
> > is required.
> > This series adds the required APIs to create a configuration, the code changes
> > required to apply it and KUnit test validating the changes.
> 
> Hi José,

Hi Louis,

Thanks a lot for the quick review!

> Thanks a lot!
> 
> This series is amazing and better than mine on many points. I have few 
> comments:
> - a "strange" naming pair: add/destroy (I expect add/remove or 
>   create/destroy like other function in DRM)

I used "add" because the function creates and adds a display pipeline
items and "destroy" because the opposite function removes it and frees
its memory, so I wanted to emphasize that the action was destructive.

However, I don't have a strong preference about the naming. If you
prefer another pair of verbs, I'll be happy to change the function
names.

> - usage of "complex" list accessors, can't we just create iterators?

Yes, on the first iteration, I used the underlying structure: list
iterators for planes/CRTCs/encoders/connectors and xa_for_each for
the possible_* items.

However, I found 2 main issues that made me rewrite this code:

The first one is that, if in the future, we change the internal data
type, we'll have to change all the code using it. On this way, like
I did with all the other vkms_config_*_get_*() functions, the data is
encapsulated.

The second one is vkms_config_get_connectors(). Unlike the other
functions, this one filters by connector enabled status. If we let the
caller do the filtering, we'll duplicate that logic.

Because of these two reasons, I decided to add a getter for lists.

> - should we use pr_err in vkms_config_valid?

I think it is great to show to the user a reason why their device couldn't
be enabled in dmesg... But I'm not sure if there is a better way to do it.

> > Louis Chauvet and I are working on ConfigFS support. In this series I tried to
> > merge his changes [1] with mine [2].
> > I kept his Signed-off-by to reflect that, even if I show up as the author of
> > some/most of the patches, this was a joint effort.
> 
> To avoid confusion, you should add the Co-developped-by tag, so it will be 
> clear that we worked together on this.

Good point, I'll change it.

> > I'm still polishing the ConfigFS code [3] and its IGT tests [4] (connector
> > hot-add/remove bugs) but the IGT tests also exercise this series and can be used
> > for additional test coverage.
> 
> I will take a look at those series. For the connector hot-add/remove, do 
> you have any example of usage in the kernel? I did not found anything in 
> the documentation explaining they are hot-addable.

I pushed a couple of WIP commits to the kernel and IGT so you can see/test
the crashes and hopefully share some ideas.

About the documentation: I didn't find much information other than a few
mentions to hot-add/remove. However, in one of my rebases, two new functions, 
drm_connector_dynamic_init() and drm_connector_dynamic_register(), were added:
https://patchwork.freedesktop.org/patch/628418/

I'm still trying to make them work, but I think they are what we need.

Part of the crashes happen on the cleanup of drm_client_setup(). Adding a
connector adds modes in the DRM client, but removing the connector doesn't
remove them and, on cleanup, I get a NULL pointer.

I'm a bit stuck, so help or tips are very welcome :)

> Thanks again for this series,
> Louis Chauvet

I'll look with more time into your comments in the other patches next week.

Thanks,
Jose

> > Best wishes,
> > José Expósito
> > 
> > [1] https://patchwork.kernel.org/project/dri-devel/cover/20250121-google-remove-crtc-index-from-parameter-v3-0-cac00a3c3544@bootlin.com/
> > [2] https://patchwork.kernel.org/project/dri-devel/cover/20240813105134.17439-1-jose.exposito89@gmail.com/
> > [3] https://github.com/JoseExposito/linux/commits/patch-vkms-configfs/
> > [4] https://gitlab.freedesktop.org/jexposit/igt-gpu-tools/-/commits/vkms-configfs
> > 
> > José Expósito (12):
> >   drm/vkms: Extract vkms_connector header
> >   drm/vkms: Add KUnit test scaffolding
> >   drm/vkms: Extract vkms_config header
> >   drm/vkms: Move default_config creation to its own function
> >   drm/vkms: Set device name from vkms_config
> >   drm/vkms: Allow to configure multiple planes
> >   drm/vkms: Allow to configure multiple CRTCs
> >   drm/vkms: Allow to attach planes and CRTCs
> >   drm/vkms: Allow to configure multiple encoders
> >   drm/vkms: Allow to attach encoders and CRTCs
> >   drm/vkms: Allow to configure multiple connectors
> >   drm/vkms: Allow to attach connectors and encoders
> > 
> > Louis Chauvet (1):
> >   drm/vkms: Add a validation function for VKMS configuration
> > 
> >  drivers/gpu/drm/vkms/Kconfig                  |  15 +
> >  drivers/gpu/drm/vkms/Makefile                 |   5 +-
> >  drivers/gpu/drm/vkms/tests/.kunitconfig       |   4 +
> >  drivers/gpu/drm/vkms/tests/Makefile           |   3 +
> >  drivers/gpu/drm/vkms/tests/vkms_config_test.c | 782 +++++++++++++++++
> >  drivers/gpu/drm/vkms/vkms_config.c            | 784 ++++++++++++++++++
> >  drivers/gpu/drm/vkms/vkms_config.h            | 479 +++++++++++
> >  drivers/gpu/drm/vkms/vkms_connector.c         |  61 ++
> >  drivers/gpu/drm/vkms/vkms_connector.h         |  26 +
> >  drivers/gpu/drm/vkms/vkms_drv.c               |  45 +-
> >  drivers/gpu/drm/vkms/vkms_drv.h               |  17 +-
> >  drivers/gpu/drm/vkms/vkms_output.c            | 255 ++++--
> >  12 files changed, 2337 insertions(+), 139 deletions(-)
> >  create mode 100644 drivers/gpu/drm/vkms/tests/.kunitconfig
> >  create mode 100644 drivers/gpu/drm/vkms/tests/Makefile
> >  create mode 100644 drivers/gpu/drm/vkms/tests/vkms_config_test.c
> >  create mode 100644 drivers/gpu/drm/vkms/vkms_config.c
> >  create mode 100644 drivers/gpu/drm/vkms/vkms_config.h
> >  create mode 100644 drivers/gpu/drm/vkms/vkms_connector.c
> >  create mode 100644 drivers/gpu/drm/vkms/vkms_connector.h
> > 
> > -- 
> > 2.48.1
> > 

  reply	other threads:[~2025-01-31  9:31 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
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 [this message]
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=Z5yYVov9_z6CDU46@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox