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

[Maxime Ripard]

On Wed, Sep 30, 2026 at 03:37:58PM +0200, Neil Armstrong wrote:
> On 9/29/26 09:55, Javier Martinez Canillas wrote:
> > Maxime Ripard <mripard at kernel.org> writes:
> > 
> > > On Mon, Sep 28, 2026 at 10:36:18PM +0200, Neil Armstrong wrote:
> > > > On 9/28/26 21:48, Benjamin Tissoires wrote:
> > > > > On Sep 28 2026, Neil Armstrong wrote:
> > > > > > On 9/28/26 19:24, Benjamin Tissoires wrote:
> > > > > > > On Sep 28 2026, Neil Armstrong wrote:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > On 9/28/26 18:22, Maxime Ripard wrote:
> > > > > > > > > Hi,
> > > > > > > > > 
> > > > > > > > > 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.
> > > > > > > > 
> > 
> > Besides what Maxime already mentioned (that most general purpose Linux distributions
> > built the drivers as modules anyways), it doesn't have to be mutually exclusive.
> > 
> > A simple panel could be supported using this BPF-based driver and then a panel driver
> > added to the kernel, if is found that some applications need to have it built-in and
> > earlier in the boot path.
> > 
> > I don't see why this would be any different than HDI-BPF or other BPF-based infra,
> > such as sched_ext.
>
> I don't want to add a supplementary maintenance burden for the sake of using a cool
> technology which has serious drawbacks and dependencies on user-space even if looks
> really cool.

Spoiler alert: v2 won't. I've got the in-kernel loader to work and thus
you can have a built-in panel driver that works without user-space
intervention. So this is not a topic of discussion anymore.

Maxime


will work
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20261001/e6adc6be/attachment.sig>