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

On Tue, Sep 29, 2026 at 01:16:41PM +0300, Jani Nikula wrote:
> On Tue, 29 Sep 2026, Benjamin Tissoires <bentiss@kernel.org> wrote:
> > Ouch. This immediately raises the "let's implement a parser in the
> > kernel" flag, or "let's create a new langage".
> 
> Fair.
> 
> > You'd still need a dedicated driver for your new blob parser, with far
> > fewer people who had had a look at it than BPF who has been working on
> > for several years.
> 
> Fair.

Also, it's kind of what we had with panel-mipi-dbi:
https://github.com/notro/panel-mipi-dbi/wiki

It didn't really take off.

> > The integration of BPF and the kernel is honestly transparent nowaday:
> > calling a struct_ops BPF function is just a function call away, and from
> > the bpf calling anything in the kernel is also just a call away.
> 
> I don't know if I'm just being overly conservative here, but it seems to
> me BPF provides too much flexibility for the use case. But maybe the
> point is completely moot, and you should just ignore me. ;)
> 
> > See Maxime's answers: yes, falling back to dedicated driver is still
> > encouraged.
> 
> [Moved the above to go with below.]
> 
> > Isn't that what Maxime wants to have? One driver for a plethora of DSI
> > panels, with the same ability the BIOS has to also do function calls to
> > set things up?
> 
> I suppose this is something that could use some clarification. Is the
> idea that most (simple) dedicated panel drivers eventually get converted
> to BPF?

I don't think most of the existing panels will be converted, if only
because it would require a different DT binding for most of them. We
should totally fix the "what happens the panel is supported by a driver
and the bpf driver" situation Rob (I think?) pointed out though, because
I do think some will be converted still.

> Or is the idea that BPF is easy for prototyping and development
> using stable kernels and short time to market, and most of them would
> eventually get converted to dedicated panel drivers?

Even though it does make prototyping easier, I totally expect this to be
a production-grade driver, just like any other panel driver.

> The story wrt display before userspace is up and running also needs
> clarification.

Yeah, I'll work on an in-kernel loader for v2.

Maxime

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