On 9/29/26 11:03, Jani Nikula wrote:
On Mon, 28 Sep 2026, Maxime Ripard <[email protected]> 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 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.
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.
Neil
BR,
Jani.
