BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//pretalx//cfp.embedded-recipes.org//er2026//speaker//F39ZBX
BEGIN:VTIMEZONE
TZID:CET
BEGIN:STANDARD
DTSTART:20001029T040000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20000326T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:pretalx-er2026-PCYPJP@cfp.embedded-recipes.org
DTSTART;TZID=CET:20260528T110000
DTEND;TZID=CET:20260528T114000
DESCRIPTION:Heterogeneous embedded SoCs increasingly require display hardwa
 re sharing between Linux and real-time firmware cores. For e.g.\, In autom
 otive instrument clusters\, safety-critical telltales must be rendered by 
 an RTOS on a real-time core (e.g.\, R5F) while Linux drives the GPU-compos
 ited UI on the same display. No generic upstream solution exists to cleanl
 y bridge these worlds within the DRM/KMS subsystem.\n\nWe present rpmsg-km
 s\, a vendor-agnostic DRM helper framework that unifies display sharing ac
 ross heterogeneous cores. The design leverages the kernel's remoteproc/vir
 tio/rpmsg transport chain for automatic driver binding\, eliminating manua
 l integration. The framework and firmware communicate through the firmware
 's resource table and rpmsg name-service announcement\, enabling independe
 nt development and  deployment.                             \n            
      \nThe session will be addressing two distinct models:\nModel 1: Unive
 rsal 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 regis
 ters. Vsync can be delivered via rpmsg. This suits any processor and displ
 ay controller where firmware needs complete control and Linux is in charge
  of passing GPU-rendered framebuffers for firmware-side for post-processin
 g\, composition and display.\n  \nModel 2: Hardware-Assisted Display Parti
 tioning targets SoCs like TI's K3 family with hardware support for partiti
 oning display resources across cores. The hardware enforces isolation\, fo
 r e.g. one scenario could be where firmware owns specific planes (e.g.\, o
 verlay1-3) while Linux owns others (e.g.\, overlay4-7)\, with hardware Z-o
 rdering ensuring firmware planes appear on top. Here\, rpmsg is used at pr
 obe time for resource negotiation where Linux requests partition assignmen
 ts then writes display registers directly using it's own alloted register-
 space for all runtime updates\, achieving zero IPC overhead per frame. rpm
 sg remains active for system events: suspend/shutdown notifications and fa
 tal error handling ensure display integrity across core transitions.\n\nFo
 llowing DRM's atomic helper pattern\, rpmsg-kms provides a reusable core w
 ith vendor-specific callbacks\, enabling platform choice between rpmsg-bas
 ed updates or direct register access.                          \nThis talk
  covers the architecture\, protocol\, device tree bindings\, and vendor-op
 s interface along with open-challenges such as passing framebuffer address
 es over rpmsg.
DTSTAMP:20260406T234753Z
LOCATION:Auditorium
SUMMARY:rpmsg-kms: A Unified DRM Framework for Display Sharing on Heterogen
 eous Embedded SoCs - Devarsh Thakkar\, Abhishek Chugh\, Beleswar Prasad Pa
 dhi
URL:https://cfp.embedded-recipes.org/er2026/talk/PCYPJP/
END:VEVENT
END:VCALENDAR