Re: [PATCH 0/6] drm/bridge: Add a BPF-based MIPI-DSI panel driver

[Benjamin Tissoires <bentiss@kernel.org>]

On Sep 28 2026, Neil Armstrong wrote:
> Hi,
> 
> On 9/28/26 18:22, Maxime Ripard wrote:
> > 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 is kind of late for serious applications except if we manage to
> solve the bootloader to Linux display engine transition.
> 
> > 
> > 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.
> 
> This adds a dependency on user-space behavior and if somehow the
> initramfs doesn't load for a reason we won't have a way to display
> an error.
> 
> > 
> >    * 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.
> 
> Both options are not really great...
> 
> > 
> > - 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.
> 
> On this point, DDIC _are_ bridges, but in the current panel API we blur the line between
> the panel and the DDIC. So being a bridge is fine, but in a general way we lack
> a proper way to describe the display/panel/monitor independently of the DDIC.
> 
> At first glance it's a nice driver, but moving the timings into a blob moves something
> into possible proprietary binaries with possible closed licence and distribution
> restriction so it's a downgrade for the same of bringing up a panel faster.

Quick answer on this, because I had the very same questions regarding
HID-BPF:
- in BPF, you can require (and by default it does) that only GPL
	compatible BPF programs are loaded, closing the argument of "closed
	licence and distribution restriction"
- also, a BPF program can be disassembled much easier than a binary
	blob, and I remember Alexei showing me an example where you get almost
	the source code from the BPF object in just one pass.

Cheers,
Benjamin