Heterogeneous embedded SoCs increasingly require display hardware sharing between Linux and real-time firmware cores. For e.g., In automotive instrument clusters, safety-critical telltales must be rendered by an RTOS on a real-time core (e.g., R5F) while Linux drives the GPU-composited UI on the same display. No generic upstream solution exists to cleanly bridge these worlds within the DRM/KMS subsystem.

We present rpmsg-kms, a vendor-agnostic DRM helper framework that unifies display sharing across heterogeneous cores. The design leverages the kernel's remoteproc/virtio/rpmsg transport chain for automatic driver binding, eliminating manual integration. The framework and firmware communicate through the firmware's resource table and rpmsg name-service announcement, enabling independent development and deployment.

The session will be addressing two distinct models:
Model 1: Universal Framebuffer Handoff targets platforms where firmware owns the display pipeline. Linux communicates per-frame plane updates (address, geometry, format, Z-order) over rpmsg to firmware, which programs hardware registers. Vsync can be delivered via rpmsg. This suits any processor and display controller where firmware needs complete control and Linux is in charge of passing GPU-rendered framebuffers for firmware-side for post-processing, composition and display.

Model 2: Hardware-Assisted Display Partitioning targets SoCs like TI's K3 family with hardware support for partitioning display resources across cores. The hardware enforces isolation, for e.g. one scenario could be where firmware owns specific planes (e.g., overlay1-3) while Linux owns others (e.g., overlay4-7), with hardware Z-ordering ensuring firmware planes appear on top. Here, rpmsg is used at probe time for resource negotiation where Linux requests partition assignments then writes display registers directly using it's own alloted register-space for all runtime updates, achieving zero IPC overhead per frame. rpmsg remains active for system events: suspend/shutdown notifications and fatal error handling ensure display integrity across core transitions.

Following DRM's atomic helper pattern, rpmsg-kms provides a reusable core with vendor-specific callbacks, enabling platform choice between rpmsg-based updates or direct register access.
This talk covers the architecture, protocol, device tree bindings, and vendor-ops interface along with open-challenges such as passing framebuffer addresses over rpmsg.