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

[Maxime Ripard <mripard@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 3178 bytes --]

Hi Laurent,

On Mon, Sep 28, 2026 at 07:37:11PM +0300, Laurent Pinchart wrote:
> On Mon, Sep 28, 2026 at 06:22:00PM +0200, Maxime Ripard 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.
> 
> Interesting idea.
> 
> How would that work for devices that want early display support ? In
> particular, how does it interact with your recent work on "fastboot"
> support (with the kernel drivers taking over a running display
> configured by the boot loader) ?

That's a very good question, and I haven't really thought about it tbh.
I don't think it would be super hard to implement though. For panels
itself, we don't typically track anything in the state. panel_bridge
however would still need to fill its own bridge state but that only
contains the bus formats and flags which can be infered from the DT.

Another thing we might need for the connector is whether it's active or
not, but panel ICs typically don't tell you that anyway, and you can
always infer it from the encoder / previous bridge state.

And then, for the first kernel modeset, we end up in the same situation
than a regular driver I suppose.

> I'm also wondering about the incentives for vendors to upstream the
> code. How will we avoid having a proliferation of out-of-tree drivers ?

I'm not really concerned about that part, because:

* You can *already* support a panel with a proprietary out-of-tree
  module, and it hasn't really affected us so far

* In fact, it's easier to decompile an hypothetical proprietary BPF
  program than an compiled .ko file (that we wouldn't be able to load
  anyway), so if we really end up there, it would be easy for us to get
  to the source code again.

* And panels are so trivial that I don't really see the importance of
  having support for them in the kernel anyway. It's constant tedious
  work that is barely documented, fragile, and provides very little
  value. And the vast majority of the panels are not supported anyway
  except for some willing OEMs (that are using panel-edp anyway) and
  willing hobbyists/consultants. So we probably wouldn't miss much.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]