From: "José Expósito" <jose.exposito89@gmail.com>
To: Louis Chauvet <louis.chauvet@bootlin.com>
Cc: rodrigosiqueiramelo@gmail.com, melissa.srw@gmail.com,
mairacanal@riseup.net, hamohammed.sa@gmail.com, daniel@ffwll.ch,
maarten.lankhorst@linux.intel.com, mripard@kernel.org,
tzimmermann@suse.de, airlied@gmail.com,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
thomas@bootlin.com
Subject: Re: [RFC PATCH 00/17] VKMS: Add configfs support
Date: Tue, 20 Aug 2024 17:52:39 +0200 [thread overview]
Message-ID: <ZsS7x2y_HKgqGUFR@fedora> (raw)
In-Reply-To: <Zrue3980Z4S6P52z@louis-chauvet-laptop>
Hi Louis,
Thanks a lot for the review and for your comments!
On Tue, Aug 13, 2024 at 07:58:55PM +0200, Louis Chauvet wrote:
> Le 13/08/24 - 12:44, José Expósito a écrit :
> > Hi everyone,
>
> Hi José,
>
> > This RFC implements support to configure VKMS using configfs.
> > It allows to:
> >
> > - Create multiple devices
> > - Configure multiple overlay planes, CRTCs, encoders and
> > connectors
> > - Enable or disable cursor plane and writeback connector for
> > each CRTC
> > - Hot-plug/unplug connectors after device creation
> > - Disable the creation of the default VKMS instance to be
> > able to use only the configfs ones
> >
> > This work is based on a previous attempt to implement configfs
> > support by Jim Shargo and Brandon Pollack [1].
> > I tried to keep the changes as minimal and simple as possible
> > and addressed Sima's comments on [1].
> >
> > Currently, there is another RFC by Louis Chauvet [2]. As I
> > mentioned on his RFC, I'm not trying to push my implementation.
> > Instead, I think that having 2 implementations will make code
> > review way easier and I don't mind which implementation is used
> > as long as we get the feature implemented :)
>
> I will send few series tomorrow, don't panic, there will be 9 series and a
> total of ~50 commits (I have many conflict to rebase only the configFS
> part, and even if it was easy, I plan to submit all of my work, not
> everything will be RFC).
Nice work! I already reviewed "drm/vkms: Miscelanious clarifications",
"drm/vkms: Completly split headers" and "drm/vkms: Switch all vkms
object to DRM managed objects".
I'll have a look to the vkms_config and configfs as soon as possible,
but I think they'll have to wait until next week.
> > I'm looking forward to analyzing Louis's implementation, seeing
> > what the differences are and finding a common solution.
>
> There are four main differences:
> - I complelty splitted vkms_config and vkms_configfs structures
I considered this and I didn't do it because it duplicates a lot of
fields, but your implementation does the right think. I need to
split both structures.
> - I splitted my work in many different series
Which is really nice, I think that the 3 series I reviewed can be
easily rebased on drm-misc-next and get merged. I'd be able to drop
at least 4 patches if your code is merged.
> - I created a real platform device driver
> - I did not manage index by hand, I let drm core doing it
> - I used list to link crtc/planes/encoders and not bitfield (because of
> the previous point)
I need to look about your solution for the indices. It is the root
cause for the problems I'm having with vblanks not being referenced
by the correct index.
> - The primary and cursor planes are fully configurable
I think this is the right approach. However, there are some restrictions
on primary planes and a user will be able to create some invalid setups.
The DRM subsystem complains if you create a CRTC without a primary plane,
but I'm not sure if we want to do the validation in VKMS as well.
There are other restrictions handled by DRM (for example, only 32 encoders
and CRTCs are allowed) and I don't know if re-implement all validation
rules in VKMS is the best idea.
> The first two points are personnal preferences, so I am open to
> discussion.
>
> The third point was already discussed before, I don't know if it is a good
> solution or not. I think it should be easy to remove it.
>
> But for the index managment, I really think that for our usage
> in ConfigFS, bitfields are not a good solution and as shown in this
> series, very error-prone. If you have a better solution than what I did,
> let me know, I am not very happy with mine too.
>
> The last point is also important, we don't want to break uAPI once this
> series is merged, so having "default hidden planes" that can't be
> configured is annoying as we will have to manage them with a special case.
>
> > What's missing?
> >
> > - DebugFS only works for the default VKMS instance.
> > If we want to support it on instances created with configfs
> > I'll need to implement it.
>
> Same on my side, I forgot to reimplement this :-). It will not be in my
> RFC, but on the v1 for sure!
>
> > Known bugs:
> >
> > - When a CRTC is added and removed before device creation, there
> > is a vblank warning.
> > The issue is caused because vblanks are referenced using the
> > CRTC index but, because one of the CRTCs is removed, the
> > indices are not consecutives and drm_crtc_vblank_crtc() tries to
> > access and invalid index
> > I'm not sure if CRTC's indices *must* start at 0 and be
> > consecutives or if this is a bug in the drm_crtc_vblank_crtc()
> > implementation.
>
> Very nice work, but you hurted many issue I had too, and I attempted to
> solve them as nicely as I can. Overall there is one main issues for me:
> the crtc index managment is not correct and the configfs behavior is very
> easily broken because of this.
>
> This is an issue for two reason I think:
> - We are trying to implement a new index allocation mecanism, but it is
> not very difficult to let drm manage this part on device creation, so
> maybe just dont store indexes in config
> - The usage of a simple index++ is not suitable for configFS usecase,
> crating 32 crtcs and deleting 1 should be possible:
> mkdir {1..32};rmdir 1;mkdir 1
> but the index of 1 is now 33, which is forbidden by drm, so you have to
> do a "complex" algorithim "find_first_value_not_used_bellow_32".
>
> Thanks for all your work! You were right, while reviewing your work, I
> found issues in mine :-)
>
> Have a nice day,
> Louis Chauvet
I ran out of time this week to work on VKMS, but I'll try to solve the
issues you pointed out.
Thanks again for your review,
Jose
> >
> > Best wishes,
> > José Expósito
> >
> > [1] https://patchwork.kernel.org/project/dri-devel/list/?series=780110&archive=both
> > [2] https://lore.kernel.org/dri-devel/ZrZZFQW5RiG12ApN@louis-chauvet-laptop/T/#u
> >
> > José Expósito (17):
> > 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 CRTCs
> > drm/vkms: Use managed memory to create encoders
> > drm/vkms: Allow to configure multiple encoders
> > drm/vkms: Use managed memory to create connectors
> > drm/vkms: Allow to configure multiple connectors
> > drm/vkms: Allow to configure multiple overlay planes
> > drm/vkms: Allow to change connector status
> > drm/vkms: Add and remove VKMS instances via configfs
> > drm/vkms: Allow to configure multiple CRTCs via configfs
> > drm/vkms: Allow to configure multiple encoders via configfs
> > drm/vkms: Allow to configure multiple encoders
> > drm/vkms: Allow to configure multiple planes via configfs
> > drm/vkms: Allow to configure the default device creation
> > drm/vkms: Remove completed task from the TODO list
> >
> > Documentation/gpu/vkms.rst | 102 +++-
> > drivers/gpu/drm/vkms/Kconfig | 1 +
> > drivers/gpu/drm/vkms/Makefile | 4 +-
> > drivers/gpu/drm/vkms/vkms_composer.c | 30 +-
> > drivers/gpu/drm/vkms/vkms_config.c | 265 ++++++++++
> > drivers/gpu/drm/vkms/vkms_config.h | 101 ++++
> > drivers/gpu/drm/vkms/vkms_configfs.c | 721 ++++++++++++++++++++++++++
> > drivers/gpu/drm/vkms/vkms_configfs.h | 9 +
> > drivers/gpu/drm/vkms/vkms_crtc.c | 99 ++--
> > drivers/gpu/drm/vkms/vkms_drv.c | 75 ++-
> > drivers/gpu/drm/vkms/vkms_drv.h | 52 +-
> > drivers/gpu/drm/vkms/vkms_output.c | 187 ++++---
> > drivers/gpu/drm/vkms/vkms_plane.c | 6 +-
> > drivers/gpu/drm/vkms/vkms_writeback.c | 27 +-
> > 14 files changed, 1464 insertions(+), 215 deletions(-)
> > 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_configfs.c
> > create mode 100644 drivers/gpu/drm/vkms/vkms_configfs.h
> >
> > --
> > 2.46.0
> >
>
> --
> Louis Chauvet, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
next prev parent reply other threads:[~2024-08-20 15:52 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-13 10:44 [RFC PATCH 00/17] VKMS: Add configfs support José Expósito
2024-08-13 10:44 ` [RFC PATCH 01/17] drm/vkms: Extract vkms_config header José Expósito
2024-08-13 10:44 ` [RFC PATCH 02/17] drm/vkms: Move default_config creation to its own function José Expósito
2024-08-13 10:44 ` [RFC PATCH 03/17] drm/vkms: Set device name from vkms_config José Expósito
2024-08-13 17:58 ` Louis Chauvet
2024-08-13 10:44 ` [RFC PATCH 04/17] drm/vkms: Allow to configure multiple CRTCs José Expósito
2024-08-13 17:58 ` Louis Chauvet
2024-08-13 10:44 ` [RFC PATCH 05/17] drm/vkms: Use managed memory to create encoders José Expósito
2024-08-13 17:58 ` Louis Chauvet
2024-08-13 10:44 ` [RFC PATCH 06/17] drm/vkms: Allow to configure multiple encoders José Expósito
2024-08-13 17:58 ` Louis Chauvet
2024-08-13 10:44 ` [RFC PATCH 07/17] drm/vkms: Use managed memory to create connectors José Expósito
2024-08-13 17:58 ` Louis Chauvet
2024-08-13 10:44 ` [RFC PATCH 08/17] drm/vkms: Allow to configure multiple connectors José Expósito
2024-08-13 17:58 ` Louis Chauvet
2024-08-13 10:44 ` [RFC PATCH 09/17] drm/vkms: Allow to configure multiple overlay planes José Expósito
2024-08-13 17:58 ` Louis Chauvet
2024-08-13 10:44 ` [RFC PATCH 10/17] drm/vkms: Allow to change connector status José Expósito
2024-08-13 17:58 ` Louis Chauvet
2024-08-13 10:44 ` [RFC PATCH 11/17] drm/vkms: Add and remove VKMS instances via configfs José Expósito
2024-08-13 17:58 ` Louis Chauvet
2024-08-13 10:44 ` [RFC PATCH 12/17] drm/vkms: Allow to configure multiple CRTCs " José Expósito
2024-08-13 17:58 ` Louis Chauvet
2024-08-13 10:44 ` [RFC PATCH 13/17] drm/vkms: Allow to configure multiple encoders " José Expósito
2024-08-13 17:58 ` Louis Chauvet
2024-08-13 10:44 ` [RFC PATCH 14/17] drm/vkms: Allow to configure multiple encoders José Expósito
2024-08-13 17:59 ` Louis Chauvet
2024-08-13 10:44 ` [RFC PATCH 15/17] drm/vkms: Allow to configure multiple planes via configfs José Expósito
2024-08-13 17:59 ` Louis Chauvet
2024-08-13 10:44 ` [RFC PATCH 16/17] drm/vkms: Allow to configure the default device creation José Expósito
2024-08-13 10:44 ` [RFC PATCH 17/17] drm/vkms: Remove completed task from the TODO list José Expósito
2024-08-13 17:58 ` [RFC PATCH 00/17] VKMS: Add configfs support Louis Chauvet
2024-08-20 15:52 ` José Expósito [this message]
2024-08-14 9:10 ` Daniel Stone
2024-08-20 16:03 ` 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=ZsS7x2y_HKgqGUFR@fedora \
--to=jose.exposito89@gmail.com \
--cc=airlied@gmail.com \
--cc=daniel@ffwll.ch \
--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=mairacanal@riseup.net \
--cc=melissa.srw@gmail.com \
--cc=mripard@kernel.org \
--cc=rodrigosiqueiramelo@gmail.com \
--cc=thomas@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