From: "José Expósito" <jose.exposito89@gmail.com>
To: Marius Vlad <marius.vlad@collabora.com>
Cc: Louis Chauvet <louis.chauvet@bootlin.com>,
Jim Shargo <jshargo@google.com>,
daniel@ffwll.ch, brpol@chromium.org, corbet@lwn.net,
dri-devel@lists.freedesktop.org, hamohammed.sa@gmail.com,
hirono@chromium.org, jshargo@chromium.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
mairacanal@riseup.net, mduggan@chromium.org,
melissa.srw@gmail.com, mripard@kernel.org,
rodrigosiqueiramelo@gmail.com, tzimmermann@suse.de
Subject: Re: [PATCH v6 0/7] Adds support for ConfigFS to VKMS!
Date: Mon, 13 May 2024 18:23:02 +0200 [thread overview]
Message-ID: <ZkI-ZjAYCJaMvmQD@fedora> (raw)
In-Reply-To: <ZkHXS6iBLgRoApNl@xpredator>
On Mon, May 13, 2024 at 12:03:07PM +0300, Marius Vlad wrote:
> Hi all,
> On Mon, May 13, 2024 at 10:08:38AM +0200, José Expósito wrote:
> > On Fri, May 10, 2024 at 06:19:45PM +0200, Louis Chauvet wrote:
> > > Le 09/05/24 - 18:18, Jim Shargo a écrit :
> > > > Sima--thanks SO MUCH for going through with everything leaving a
> > > > detailed review. I am excited to go through your feedback.
> > > >
> > > > It makes me extremely happy to see these patches get people excited.
> > > >
> > > > They've bounced between a few people, and I recently asked to take
> > > > them over again from the folks who were most recently looking at them
> > > > but haven't since had capacity to revisit them. I'd love to contribute
> > > > more but I am currently pretty swamped and I probably couldn't
> > > > realistically make too much headway before the middle of June.
> > > >
> > > > José--if you've got capacity and interest, I'd love to see this work
> > > > get in! Thanks!! Please let me know your timeline and if you want to
> > > > split anything up or have any questions, I'd love to help if possible.
> > > > But most important to me is seeing the community benefit from the
> > > > feature.
> > > >
> > > > And (in case it got lost in the shuffle of all these patches) the IGT
> > > > tests really make it much easier to develop this thing. Marius has
> > > > posted the most recent patches:
> > > > https://lore.kernel.org/igt-dev/?q=configfs
> > > >
> > > > Thanks!
> > > > -- Jim
> > > >
> > > >
> > > >
> > > > On Wed, May 8, 2024 at 2:17 PM José Expósito <jose.exposito89@gmail.com> wrote:
> > > > >
> > > > > Hi everyone,
> > > > >
> > > > > I wasn't aware of these patches, but I'm really glad they are getting
> > > > > some attention, thanks a lot for your review Sima.
> > > > >
> > > > > Given that it's been a while since the patches were emailed, I'm not
> > > > > sure if the original authors of the patches could implement your
> > > > > comments. If not, I can work on it. Please let me know.
> > > > >
> > > > > I'm working on a Mutter feature that'd greatly benefit from this uapi
> > > > > and I'm sure other compositors would find it useful.
> > > > >
> > > > > I'll start working on a new version in a few days if nobody else is
> > > > > already working on it.
> > > > >
> > > > > Best wishes,
> > > > > José Expósito
> > >
> > > Hi all!
> > >
> > > Very nice to see other people working on this subject. As the series
> > > seemed inactive, I started two weeks ago to rebase it on top of [1]. I
> > > also started some work to use drmm_* helpers instead of using lists in
> > > vkms. I currently struggle with a deadlock during rmmod.
> > >
> > > I need to clean my commits, but I can share a WIP version.
> >
> > Hi Louis,
> >
> > If you could share a RFC/WIP series it would be awesome!
> >
> > Since you are already working on the kernel patches (and I guess IGT?),
> > I'll start working on a libdrm high level API to interact with VKMS from
> > user-space on top of your patches. I'll share a link as soon as I have a
> > draft PR.
>
> Just out of curiosity what API would that be? These should fairly
> simple that they can be configured from a shell script
> (mount/mkdir/rm/echo/umount). Believe should be easy enough to test stuff with
> bunch scripts like that.
My plan is to add a very thin C API around mkdir/rmdir/etc.
It is true that VKMS can be configure easily using a bash script; however,
compositors with test suites written in C (or with bindings to libdrm) would
have to write similar wrappers around the mkdir/rmdir/etc calls.
I think that it could be beneficial for them to have a shared wrapper available
in libdrm.
> Perphas landing the I-G-T tests first (assuming we're settled
> on how exactly this would work) might be of greated help to get a green lit
> the kernel driver side? Skip if vkms/configfs/something else that tells
> us VKMS doesn't have ConfigFS eneabled, and run it when that is on.
>
> The lastest iteration was shared by Jim at
> https://lore.kernel.org/igt-dev/20230901092819.16924-1-marius.vlad@collabora.com/
>
> That way sub-sequent BAT CI would pick up issues, and can also used
> independently by Louis. Should also divide the work-load evenly with
> Louis focusing on the just the driver. Happy to review and test it.
>
> >
> > > Maybe we can discuss a bit the comment from Daniel (split init between
> > > default/configfs, use or not a real platform device...)
> > >
> > > For the split, I think the first solution (struct vkms_config) can be
> > > easier to understand and to implement, for two reasons:
> > > - No need to distinguish between the "default" and the "configfs" devices
> > > in the VKMS "core". All is managed with only one struct vkms_config.
> > > - Most of the lifetime issue should be gone. The only thing to
> > > synchronize is passing this vkms_config from ConfigFS to VKMS.
> >
> > I agree, this seems like the easiest solution.
> >
> > > The drawback of this is that it can become difficult to do the "runtime"
> > > configuration (today only hotplug, but I plan to add more complex stuff
> > > like DP emulation, EDID selection, MST support...). Those configuration
> > > must be done "at runtime" and will require a strong synchronization with
> > > the vkms "core".
> > >
> > > Maybe we can distinguish between the "creation" and the "runtime
> > > configuration", in two different configFS directory? Once a device is
> > > created, it is moved to the "enabled" directory and will have a different
> > > set of attribute (connection status, current EDID...)
> >
> > Once the device is enabled (i.e, `echo 1 > /config/vkms/my-device/enabled`),
> > would it make sense to use sysfs instead of another configfs directory?
> > The advantage is that with sysfs the kernel controls the lifetime of the
> > objects and I think it *might* simplify the code, but I'll need to write a
> > proof of concept to see if this works.
> Can indeed sysfs be used similar to ConfigFS? To me it sounds like sysfs is a
> view into a kernel objects, mostly for viewing and slight modifications
> but not manipulating, adding/removing, on the fly, various things. Sort
> of see it the other way around, device enabled with sysfs but
> configuration happens through ConfigFS. At least from a user-space pov.
> >
> > > For the platform driver part, it seems logic to me to use a "real"
> > > platform driver and a platform device for each pipeline, but I don't have
> > > the experience to tell if this is a good idea or not.
> >
> > I'm afraid I don't know which approach could work better. Trusting Sima and
> > Maíra on this one.
> >
> > Jose
> >
> > > [1]: https://lore.kernel.org/dri-devel/20240409-yuv-v6-0-de1c5728fd70@bootlin.com/
> > >
> > > Thanks,
> > > Louis Chauvet
> > >
> > > --
> > > Louis Chauvet, Bootlin
> > > Embedded Linux and Kernel engineering
> > > https://bootlin.com
next prev parent reply other threads:[~2024-05-13 16:23 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-29 5:30 [PATCH v6 0/7] Adds support for ConfigFS to VKMS! Brandon Pollack
2023-08-29 5:30 ` [PATCH v6 1/7] drm/vkms: Back VKMS with DRM memory management instead of static objects Brandon Pollack
2024-04-30 7:47 ` Daniel Vetter
2023-08-29 5:30 ` [PATCH v6 2/7] drm/vkms: Support multiple DRM objects (crtcs, etc.) per VKMS device Brandon Pollack
2023-09-01 9:33 ` Marius Vlad
2024-04-30 7:53 ` Daniel Vetter
2023-08-29 5:30 ` [PATCH v6 3/7] drm/vkms: Provide platform data when creating VKMS devices Brandon Pollack
2024-04-30 7:53 ` Daniel Vetter
2023-08-29 5:30 ` [PATCH v6 4/7] drm/vkms: Add ConfigFS scaffolding to VKMS Brandon Pollack
2024-04-30 8:14 ` Daniel Vetter
2023-08-29 5:30 ` [PATCH v6 5/7] drm/vkms: Support enabling ConfigFS devices Brandon Pollack
2024-04-30 8:22 ` Daniel Vetter
2024-04-30 8:32 ` Daniel Vetter
2023-08-29 5:30 ` [PATCH v6 6/7] drm/vkms: Add a module param to enable/disable the default device Brandon Pollack
2023-08-29 5:30 ` [PATCH v6 7/7] drm/vkms Add hotplug support via configfs to VKMS Brandon Pollack
2023-09-20 18:03 ` Helen Koike
2023-09-21 3:44 ` Brandon Ross Pollack
2024-04-30 8:27 ` Daniel Vetter
2023-09-01 9:32 ` [PATCH v6 0/7] Adds support for ConfigFS to VKMS! Marius Vlad
2024-04-30 8:36 ` Daniel Vetter
2024-05-08 18:17 ` José Expósito
2024-05-09 22:18 ` Jim Shargo
2024-05-10 16:19 ` Louis Chauvet
2024-05-13 8:08 ` José Expósito
2024-05-13 9:03 ` Marius Vlad
2024-05-13 16:23 ` José Expósito [this message]
2024-05-17 16:00 ` Louis Chauvet
2024-05-21 12:25 ` Daniel Vetter
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=ZkI-ZjAYCJaMvmQD@fedora \
--to=jose.exposito89@gmail.com \
--cc=brpol@chromium.org \
--cc=corbet@lwn.net \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=hamohammed.sa@gmail.com \
--cc=hirono@chromium.org \
--cc=jshargo@chromium.org \
--cc=jshargo@google.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=louis.chauvet@bootlin.com \
--cc=mairacanal@riseup.net \
--cc=marius.vlad@collabora.com \
--cc=mduggan@chromium.org \
--cc=melissa.srw@gmail.com \
--cc=mripard@kernel.org \
--cc=rodrigosiqueiramelo@gmail.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).