Hi,
Panels in general, and MIPI-DSI panels in particular, are pretty
difficult to support and require pretty much a panel driver for each
panel produced. Most of them are pretty simple, and require an opaque
initialization sequence that is usually poorly documented.
This creates a tension between OEMs and distros because OEMs will
typically get a new panel to react to a sourcing issue during
production, and thus need some swift turnaround between getting their
new panel and it being operational in the OS. Distributions on the other
hand can take years to ship a kernel with that new panel driver.
To solve this, I followed the example of HID-BPF and wrote a panel
driver that will rely on BPF programs to perform the panel
initialization. That way, we can ship the programs separately from the
kernel, and with a different lifecycle. If this driver is accepted, the
plan is to have a userspace component started by udev to identify and
load the right BPF program for the panels found on the device.
This driver is fully functional and works with both 5" and 7" Touch
Display 2 panels for the RaspberryPi. However, it breaks away from the
typical panel driver in multiple ways:
- BPF programs can only be loaded by userspace. This leaves us with two
choices:
* We prevent the driver from loading until the script itself is
loaded. This has the side effect of preventing any other output to
be used until the initramfs is ran at the earliest, and possibly
ever if the loader isn't installed for example.
* Or we probe the driver all the time, but only report it as connected
once a program has been registered. This is somewhat unconventional,
but allows the other outputs to be functional, *and* allows the user
to force the output if their panel doesn't require any
initialization or during debugging. I chose this solution.
- It's not a panel driver, but a bridge one, which is also pretty
unconventional. This is required because panel drivers don't have
access to a detect callback that is required for the above, but I also
think that the recent work from Luca blurs the line from panels and
bridges and we'll end up going that road anyway.
Let me know what you think,
Maxime
Signed-off-by: Maxime Ripard <[email protected]>
---
Maxime Ripard (6):
dt-bindings: display: Add panel-mipi-dsi-bpf generic panel binding
drm/panel: Add generic MIPI-DSI panel driver with BPF init sequences
drm/panel: dsi-bpf: Add BPF program build infrastructure and helper header
drm/panel: dsi-bpf: Add Raspberry Pi 7-inch panel BPF program
drm/panel: dsi-bpf: Add Raspberry Pi 5-inch panel BPF program
[DO NOT MERGE] arm64: dts: broadcom: Add Raspberry Pi ILI9881C DSI panel
overlays
.../bindings/display/panel/panel-mipi-dsi-bpf.yaml | 184 +++++++++
arch/arm64/boot/dts/broadcom/Makefile | 8 +
.../bcm2711-rpi-4-b-dsi-ili9881-5inch.dtso | 22 +
.../bcm2711-rpi-4-b-dsi-ili9881-7inch.dtso | 22 +
.../dts/broadcom/bcm2711-rpi-4-b-dsi-ili9881.dtsi | 65 +++
drivers/gpu/drm/panel/Kconfig | 3 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/bpf/Kconfig | 28 ++
drivers/gpu/drm/panel/bpf/Makefile | 10 +
.../gpu/drm/panel/bpf/panel-bpf-mipi-dsi-core.c | 452 +++++++++++++++++++++
.../gpu/drm/panel/bpf/panel-bpf-mipi-dsi-kfuncs.c | 278 +++++++++++++
drivers/gpu/drm/panel/bpf/panel-bpf-mipi-dsi-ops.c | 242 +++++++++++
.../gpu/drm/panel/bpf/panel-bpf-mipi-dsi-trace.c | 4 +
.../gpu/drm/panel/bpf/panel-bpf-mipi-dsi-trace.h | 246 +++++++++++
drivers/gpu/drm/panel/bpf/panel-bpf-mipi-dsi.h | 264 ++++++++++++
drivers/gpu/drm/panel/bpf/progs/Makefile | 93 +++++
.../panel/bpf/progs/Raspberrypi__dsi-5inch.bpf.c | 266 ++++++++++++
.../panel/bpf/progs/Raspberrypi__dsi-7inch.bpf.c | 271 ++++++++++++
.../gpu/drm/panel/bpf/progs/panel-bpf-mipi-dsi.h | 95 +++++
19 files changed, 2554 insertions(+)
---
base-commit: 6e375de99d0c420169481fcd36064177ab55b09d
change-id: 20260928-drm-mipi-dsi-panel-ebpf-d78b72a9c47f
Best regards,
--
Maxime Ripard <[email protected]>
