[RFC PATCH 0/5] rust: drm: minimal KMS bindings, EDID read, rotation, HDCP defs

[Mike Lothian]

This RFC series exposes enough of the C KMS API to Rust for a driver to
bring up an atomic mode-setting pipeline with the drm_simple_display_pipe
helper (one CRTC + primary plane + encoder) and install a real EDID read
off its own transport:

  1/4  KMS headers + Driver::FEAT_MODESET/FEAT_ATOMIC
  2/4  <drm/drm_edid.h>: drm_edid_alloc/_connector_update/_add_modes
  3/4  pub drm::Device::as_raw() escape hatch (separate, contentious bit)
  4/4  <drm/drm_blend.h> (atomic plane rotation property) + a rust_helper
       for drm_atomic_get_new_crtc_state() (inspect proposed CRTC state
       from a mode_config atomic_check)

It is deliberately an RFC and interim: it does NOT add safe Rust KMS
abstractions (CRTC/plane/connector wrappers - an active upstream effort),
only the raw binding surface plus the trait/visibility tweaks a driver
needs to call the C helpers itself.

FEAT_MODESET / FEAT_ATOMIC follow the existing FEAT_RENDER idiom exactly
(per-feature bool associated consts folded into compute_features()), so
GEM-only drivers are unaffected.

drm::Device::as_raw() is made pub as a documented temporary escape hatch
for calling the C KMS helpers until safe wrappers exist. That is the part
most likely to draw objections, so it is split into its own patch (3/3):
the feature flags and header bindings in 1/3 and 2/3 are useful on their
own and can land even if the escape hatch is reworked or dropped (e.g.
replaced by narrow per-helper safe wrappers).

drm_blend.h (4/4) exposes drm_plane_create_rotation_property() so a
driver can offer the standard atomic rotation property, and adds a
rust_helper for the static-inline drm_atomic_get_new_crtc_state() so a
driver can read a CRTC's proposed state during atomic_check() (the vino
driver uses it to reject a multi-head modeset that would exceed the USB
bandwidth). Like the rest of the series it is interim raw-binding surface.

drm_hdcp.h (5/5) exposes <drm/display/drm_hdcp.h> so a Rust HDCP driver
can use the canonical HDCP 2.2 message IDs, length constants and hdcp2_*
message structs instead of redefining them (the vino driver runs HDCP 2.2
over a vendor USB transport and reuses only the message definitions, not
the drm_hdcp_helper state machine). It only pulls in <linux/types.h>.

Note: a related but independent fix - using drm_dev_unplug() instead of
drm_dev_unregister() in Registration::drop, which closes a real
use-after-free for Rust DRM drivers on a hot-removable bus - is sent as a
standalone, non-RFC patch ("rust: drm: unplug the device on Registration
drop") rather than buried in this RFC, since it stands alone and should
not be gated on the KMS-surface discussion.

Factored out of an out-of-tree in-kernel Rust DisplayLink DL3 dock driver
that drives a virtual connector and reads the dock's downstream EDID; but
the bindings are generic (the same path simpledrm/gud/udl use).
Compile-tested in-tree against drm-next.

Mike Lothian (3):
  rust: drm: add minimal KMS bindings for simple-display-pipe drivers
  rust: drm: expose drm_edid.h for reading connector EDID
  rust: drm: expose drm::Device::as_raw()
  rust: drm: expose drm_blend.h and the atomic new-CRTC-state helper
  rust: drm: expose <drm/display/drm_hdcp.h> HDCP 2.2 message definitions

 rust/bindings/bindings_helper.h | 10 ++++++++++
 rust/kernel/drm/device.rs       | 18 +++++++++++++++++-
 rust/kernel/drm/driver.rs       | 17 +++++++++++++++++
 3 files changed, 44 insertions(+), 1 deletion(-)

--
2.54.0