Re: [PATCH 0/6] drm/bridge: Add a BPF-based MIPI-DSI panel driver
From: Neil Armstrong
Date: Fri Oct 02 2026 - 04:12:08 EST
On 10/1/26 08:48, Maxime Ripard wrote:
On Wed, Sep 30, 2026 at 03:46:04PM +0200, Neil Armstrong wrote:
On 9/29/26 09:13, Maxime Ripard wrote:
Hi Neil,
On Mon, Sep 28, 2026 at 06:39:58PM +0200, Neil Armstrong wrote:
On 9/28/26 18:22, 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.
This is kind of late for serious applications except if we manage to
solve the bootloader to Linux display engine transition.
Virtually all "generic" distributions are shipping the panel as modules
today anyway, because anything else is nothing but impractical. But
maybe you don't consider them serious enough. Also, applications live in
userspace already, so can be ran after this driver would be initialized
anyway.
So what would this exactly solve ? keeping out-of-tree BPF driver + bindings
driver forever and never upstreaming then ? Is this what we really want ?
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.
Yes, if an error happens before the DRM driver loads, it won't be shown
on the screen. This is already the case for any panel driver today on
any major !embedded distribution. And with built-in drivers, this can
also happen before or while the DRM driver loads.
The solution is always the same though: load simpledrm first, move to
the proper DRM device once it's functional. It still works with this
solution.
Module != bpf programs, maybe one day it will change.
I have exactly zero idea what your point is here. You were saying that
it's bad because panels get to probe later now and you wouldn't see an
error. I'm saying it's already what happens today with a significant
part of the install base and doesn't seem to bother you.
I'm not talking about BPF programs themselves, I'm talking about your
double standard.
I just expressed that you're trying to compare modules which are already
hard to handle since they can be loaded anytime with BPF. Adding an additional
complexity on top of modules won't simplify things at all.
* 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...
Feel free to make any suggestions
- 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,
I have no idea what a DDIC mean.
The DDIC is the Display Driver Interface Controller, basically the
IC which received DSI packets and physically drives the display.
It's basically a bridge to the panel, and this is mainly what we program.
I've been writing panel drivers longer than you did, there's no need to
be patronizing.
Sorry I never meant to patronize you in any way, I just explained my position
on why DDIC are bridges. So perhaps I didn't understand your question.
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
Let's not kid ourselves, it's *already* a blob. We just sugar-coated it
enough that we can be happy and call it GPL.
It's the case for most drivers, but since we don't get proper
documentation we're stuck using registers list and can't
implement advanced features. And moving this to a bpf won't solve
but enhance the problem by a large factor.
How? You keep saying those broad, alarmist statements. Look at the BPF
examples I provided. *How* is it "making the problem worse by a large
factor" exactly?
Just like I said to Rob, I don't mind changing that driver to accomodate
your fear or anxiety. But "this is shit" isn't a review, it's abusive
behaviour. If you plan on continuing that trend, don't.
I'm sorry if you felt like this, I expressed multiple times this patchset
is great and very well written, I only expressed some legitimate questions
about BPF because I'm ignorant on the subject and the impact it will have
on my volunteer DRM panel maintenance activity.
I'm sorry if this felt as fear, anxiety or abusive behaviour.
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.
We can already make a proprietary, out-of-tree, panel driver today. That
being said, the only license we allow for BPF programs here is GPL, so
if anything it would be less of a concern for this than it would be for
regular panels.
So you're on to facilitate keeping panel driver out-of-tree and never
upstream them ? this is awkward TBH.
Hahahaha, yeah, sure. I don't care about upstreaming anymore and just
want to scorch-earth the entire kernel to have an excuse to retire and
do goat farming. You got me.
However, given the current state of this discussion and the intention
you're giving me, it does sound appealing.
So this remark comes from directly from the cover letter arguments, which
are mainly helping to facilitate OEMs and distros to ship panels drivers
faster and would help "ship the programs separately from the
kernel, and with a different lifecycle".
Since I still don't understand how it will help OEM and distros, because I'm
no more an OEM for while and I don't run a distro and since I maintain the
subsystem I feel legitimate to understand exactly how it would solve
the *real* issue you expressed.
Let me be clear, I want people to upstream panel drivers, and since I took
over the panel maintainership I have a constant driver review and merge
rate, so perhaps it means I need to improve how I handle the susbsystem ?
Or is writing a panel driver too hard ? Am I to strict on the review ?
TBH I'll handle the BPF driver the same way, so again it makes me feel
this solution is not the right way to solve this, or I should just do
something else ?
I think we should stop arguing here, since my words were badly interpreted,
and we should leverage the Plumbers and OSS/ELC next week to discuss this
in-person.
Thanks,
Neil
Maxime