linux-kernel - Re: [RFC v3 31/33] rust: drm/kms: Add VblankSupport

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250314-archetypal-unnatural-rat-7108da@houat>
Date: Fri, 14 Mar 2025 13:37:09 +0100
From: Maxime Ripard <mripard@...nel.org>
To: Lyude Paul <lyude@...hat.com>
Cc: dri-devel@...ts.freedesktop.org, rust-for-linux@...r.kernel.org, 
	Danilo Krummrich <dakr@...nel.org>, mcanal@...lia.com, Alice Ryhl <aliceryhl@...gle.com>, 
	Simona Vetter <sima@...ll.ch>, Daniel Almeida <daniel.almeida@...labora.com>, 
	Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>, 
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>, 
	Björn Roy Baron <bjorn3_gh@...tonmail.com>, Benno Lossin <benno.lossin@...ton.me>, 
	Andreas Hindborg <a.hindborg@...nel.org>, Trevor Gross <tmgross@...ch.edu>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Asahi Lina <lina@...hilina.net>, 
	Wedson Almeida Filho <wedsonaf@...il.com>, open list <linux-kernel@...r.kernel.org>
Subject: Re: [RFC v3 31/33] rust: drm/kms: Add VblankSupport

On Wed, Mar 05, 2025 at 05:59:47PM -0500, Lyude Paul wrote:
> This commit adds bindings for implementing vblank support for a driver's
> CRTCs. These bindings are optional, to account for the fact that not all
> drivers have dedicated hardware vblanks.

Do we really have drivers not having a vblank implementation?

Not having dedicated hardware vblank, sure. vkms and any writeback
implementation are probably in this case. But they still provide some
vblank implementation.

> In order to accomplish this, we introduce the VblankSupport trait which can
> be implemented on DriverCrtc by drivers which support vblanks. This works
> in the same way as the main Kms trait - drivers which don't support
> hardware vblanks can simply pass PhantomData<Self> to the associated type
> on DriverCrtc. If a driver chooses to implement VblankSupport, VblankImpl
> will be implemented by DRM automatically - and can be passed to the
> VblankImpl associated type on DriverCrtc.
> 
> Additionally, we gate methods which only apply to vblank-supporting drivers
> by introducing a VblankDriverCrtc trait that is automatically implemented
> by DRM for CRTC drivers implementing VblankSupport. This works basically in
> the same way as Kms and KmsDriver, but for CRTCs.
> 
> Signed-off-by: Lyude Paul <lyude@...hat.com>
> 
> ---
> 
> Notes:
> 
> * One thing to keep in mind: this trait is implemented on the CRTC as
>   opposed to the KMS driver due to the possibility that a driver may have
>   multiple different types of CRTCs. As a result, it's not impossible that
>   there could potentially be differences in each type's vblank hardware
>   implementation.

It's not that it's not impossible, it's that it's pretty normal
actually. Any KMS driver supporting writeback for example is very likely
to have two different vblank implementation, depending on whether you're
using one of the actual CRTC, or the controller that provides writeback
support.

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (274 bytes)