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 <[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'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
signature.asc
Description: PGP signature
