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

[Benjamin Tissoires <bentiss@kernel.org>]

On Sep 29 2026, Jani Nikula wrote:
> On Mon, 28 Sep 2026, Maxime Ripard <mripard@kernel.org> wrote:
> > 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.
> 
> I'd think for most panels it would suffice to have a declarative
> language describing what to do at what points in time. For example, at
> poweron, enable this GPIO, wait a little, write this set of DSI
> commands, etc. You rarely need actual programming, or even ability to
> read-modify-write something.

TBH, that's exactly how Maxime presented the idea to me before
submitting this.

> 
> It could be, say, YAML converted to some binary representation. Maybe
> that could be in the DT, or maybe you could override it with the
> firmware loader. And obviously any vendor "blob" could be trivially
> converted back to YAML and upstreamed.

Ouch. This immediately raises the "let's implement a parser in the
kernel" flag, or "let's create a new langage".

That's exactly what BPF is: ou have a source file (in C, rust, whatever)
that is converted to a binary blob that the kernel already knows how to
use and that is safe to load, and we can easily go back to the sources.

> 
> Where that falls short, you could always have a dedicated driver, or
> extend the declarative stuff.

See Maxime's answers: yes, falling back to dedicated driver is still
encouraged.

> 
> Now, the question is, how much more BPF solves over that, without
> requiring a dedicated driver, and is the added complexity worth it?

You'd still need a dedicated driver for your new blob parser, with far
fewer people who had had a look at it than BPF who has been working on
for several years.

The integration of BPF and the kernel is honestly transparent nowaday:
calling a struct_ops BPF function is just a function call away, and from
the bpf calling anything in the kernel is also just a call away.

> 
> FWIW, on the Intel platforms that support DSI, all of the
> initialization, poweron/poweroff, backlight on/off etc. sequences like
> that are stored in the BIOS, defined by the OEM. A plethora of DSI
> panels, one driver. Don't look at it for examples how to implement it,
> but I think the basic idea is workable.

Isn't that what Maxime wants to have? One driver for a plethora of DSI
panels, with the same ability the BIOS has to also do function calls to
set things up?

Cheers,
Benjamin