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: 3645 bytes --]

On Wed, Sep 30, 2026 at 04:01:52PM +0200, Neil Armstrong wrote:
> On 9/29/26 11:03, 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.
> 
> Yes we could have a similar panel-simple but with init tables, but
> in reality those panels offers much more features we don't handle because
> the DDIC vendors and panel integrators just don't care exposing those
> features, but they get handled by vendor implementation like for Phones.

It's kind of what we already do. It somewhat works, but doesn't address
my problem.

> > 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.
> 
> I don't think we want this, downstream vendors does that and we don't want
> to go there.
> 
> > 
> > Where that falls short, you could always have a dedicated driver, or
> > extend the declarative stuff.
> > 
> > Now, the question is, how much more BPF solves over that, without
> > requiring a dedicated driver, and is the added complexity worth it?
> 
> This is my global question, and this is what I'm evaluating here, and so
> far is created more problem that solutions.

Great, more judgmental stuff. It's a v1 that hasn't been merged yet.
What problems did it create exactly, and for who?

> > 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.
> 
> For _some_ panels, here, as a general solution no because we really
> want to have full support for panel features.

The only one who claimed it was a generic solution was you. I've been
pretty clear from the very beginning that I wasn't expecting it to be a
one-size-fits-all solution.

So if you want to review your idea of what this driver is, fine, but
keep me out of the recipient list.

Maxime

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