Received-SPF: pass (google.com: domain of linux-kernel+bounces-162976-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Message-ID: <3cdd429f0c4c1e87cb68977199564af4848d0587.camel@redhat.com>
Subject: Re: [PATCH 2/4] WIP: drm: Introduce rvkms
From: Lyude Paul <lyude@redhat.com>
To: Benno Lossin <benno.lossin@proton.me>, dri-devel@lists.freedesktop.org
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>, Maxime Ripard
 <mripard@kernel.org>, Thomas Zimmermann <tzimmermann@suse.de>, David Airlie
 <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>, Miguel Ojeda
 <ojeda@kernel.org>, Alex Gaynor <alex.gaynor@gmail.com>, Wedson Almeida
 Filho <wedsonaf@gmail.com>, Boqun Feng <boqun.feng@gmail.com>, Gary Guo
 <gary@garyguo.net>, =?ISO-8859-1?Q?Bj=F6rn?= Roy Baron
 <bjorn3_gh@protonmail.com>, Andreas Hindborg <a.hindborg@samsung.com>,
 Alice Ryhl <aliceryhl@google.com>, linux-kernel@vger.kernel.org,
 rust-for-linux@vger.kernel.org
Date: Mon, 29 Apr 2024 15:54:16 -0400
In-Reply-To: <c04294b3-a08a-44af-b74a-27f6b873c6b8@proton.me>
References: <20240322221305.1403600-1-lyude@redhat.com>
	 <20240322221305.1403600-3-lyude@redhat.com>
	 <b41f707d-7e06-4c1a-93f0-d74ee242b650@proton.me>
	 <6a16f0023b62beba4658677bebcc4786da1ea4be.camel@redhat.com>
	 <c04294b3-a08a-44af-b74a-27f6b873c6b8@proton.me>
Organization: Red Hat Inc.
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.52.1 (3.52.1-1.fc40) 
Precedence: bulk
MIME-Version: 1.0

On Thu, 2024-04-25 at 15:46 +0000, Benno Lossin wrote:
> On 22.04.24 03:54, Lyude Paul wrote:
> > On Wed, 2024-03-27 at 21:06 +0000, Benno Lossin wrote:
> > > On 22.03.24 23:03, Lyude Paul wrote:
> > > > +
> > > > +pub(crate) type Connector =3D
> > > > connector::Connector<DriverConnector>;
> > > > +
> > > > +impl connector::DriverConnector for DriverConnector {
> > > > +=C2=A0=C2=A0=C2=A0 type Initializer =3D impl PinInit<Self, Error>;
> > > > +
> > > > +=C2=A0=C2=A0=C2=A0 type State =3D ConnectorState;
> > > > +
> > > > +=C2=A0=C2=A0=C2=A0 type Driver =3D RvkmsDriver;
> > > > +
> > > > +=C2=A0=C2=A0=C2=A0 type Args =3D ();
> > > > +
> > > > +=C2=A0=C2=A0=C2=A0 fn new(dev: &Device<Self::Driver>, args: Self::=
Args) ->
> > > > Self::Initializer {
> > >=20
> > > And then here just return `Self`.
> > >=20
> > > This works, since there is a blanket impl `PinInit<T, E> for T`.
> > >=20
> > > Looking at how you use this API, I am not sure if you actually
> > > need
> > > pin-init for the type that implements `DriverConnector`.
> > > Do you need to store eg `Mutex<T>` or something else that needs
> > > pin-init in here in a more complex driver?
> >=20
> > Most likely yes - a lot of drivers have various private locks
> > contained
> > within their subclassed mode objects. I'm not sure we will in
> > rvkms's
> > connector since vkms doesn't really do much with connectors - but
> > we at
> > a minimum be using pinned types (spinlocks and hrtimers) in our
> > DriverCrtc implementation once I've started implementing support
> > for
> > vblanks[1]
> >=20
> > [1]
> > https://www.kernel.org/doc/html/v6.9-rc5/gpu/drm-kms.html?highlight=3Dv=
blank#vertical-blanking
> >=20
> > In nova (the main reason I'm working on rvkms in the first place),
> > we'll definitely have locks in our connectors and possibly other
> > types.
>=20
> I see, in that case it would be a good idea to either have an RFC of
> the nova driver (or something else that needs pinned types) as
> motivation for why it needs to be pin-initialized.

I mean - I'll happily include this with the RFC of nova if nova is
ready at that point, but the purpose of rvkms is to exercise enough of
this API to justify merging it :P - and I think it's a lot likely rvkm
is probably going to be ready well before nova gets to the point of
modesetting. And we will definitely have some uses of pinned types in
rvkms once the driver's ready for submission.

>=20

--=20
Cheers,
 Lyude Paul (she/her)
 Software Engineer at Red Hat