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

[Neil Armstrong]

On 10/1/26 09:01, Maxime Ripard wrote:
> On Wed, Sep 30, 2026 at 03:49:12PM +0200, Neil Armstrong wrote:
>> On 9/29/26 09:27, Maxime Ripard wrote:
>>> On Mon, Sep 28, 2026 at 09:20:12PM +0200, 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.
>>>>>>
>>>>>>>
>>>>>>> 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.
>>>>>>
>>>>>>>
>>>>>>>       * 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...
>>>>>>
>>>>>>>
>>>>>>> - 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, 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 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.
>>>>>
>>>>> Quick answer on this, because I had the very same questions regarding
>>>>> HID-BPF:
>>>>> - in BPF, you can require (and by default it does) that only GPL
>>>>> 	compatible BPF programs are loaded, closing the argument of "closed
>>>>> 	licence and distribution restriction"
>>>>> - also, a BPF program can be disassembled much easier than a binary
>>>>> 	blob, and I remember Alexei showing me an example where you get almost
>>>>> 	the source code from the BPF object in just one pass.
>>>>
>>>> Right, it "solve" one of my question, but doesn't really solve the issue
>>>> of vendors providing "GPL" bpf programs with source available "somewhere".
>>>
>>> Would you be ok if I was to make a tool to decompile a BPF program into its
>>> source file equivalent?
>>
>> Not really, I don't see the point TBH.
> 
> Cool, another moving goalpost then.
> 
>>>> Another big issue is the API, I don't want to keep the current API as-is,
>>>> we plan to support more advanced panel features and use try to use the
>>>> atomic states to support rate switching for example, and I'm not confident
>>>> it's a good idea since there's no "simple" and "forever valid" API
>>>> to initialize panels...
>>>
>>> So, a couple of things here. First, I really don't think we should
>>> extend the panel API, like at all. But let's discuss that at Plumbers, I
>>> don't think it's very relevant to this discussion anyway.
>>
>> It is, and I'll expose why we need to get out of this deprecated API
>> as soon as possible, we are seriously keeping the ability to provide
>> support for advanced panel features which are implemented in vendor
>> kernels.
> 
> I guess I'm not the one working on out-of-tree panel drivers then. But
> yeah, I don't dispute that statement.
> 
>> The API was ok when DSI was added and we didn't have generalized atomic
>> modesetting, why would you not want panels to embrace atomic ?
>>
>> I don't understand, please elaborate.
> 
> Again, you're putting words in my mouth. I never said I don't want
> panels to embrace atomic. I said we shouldn't extend the panel API, I
> told you twice what I meant exactly by that:
> 
> https://lore.kernel.org/ksummit/20260604-grinning-determined-falcon-0e8b01@houat/
> 
>> I acknowledge it might sound a bit like "let's burn the whole thing to
>> the ground", but what you just described sounds an awful lot like what
>> the bridge API already does.
>>
>> Let's acknowledge that drm_bridge isn't just about bridge anymore, make
>> panels bridges, and we're done.
> 
> https://lore.kernel.org/dri-devel/20260928-drm-mipi-dsi-panel-ebpf-v1-0-5244926aace4@kernel.org/
> 
>> 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.
> 
> So, yeah, my point is we already have an atomic API to support panels:
> it's the bridge one. If your plan is to make the panel API an equivalent
> to the bridge API, then it just makes no sense when all consumers are
> handling bridges anyway. Just write a bridge driver for your panel IC,
> and you're done. It works today, and you don't have to extend anything.
> And you can embrace your atomic panel.

I have no precise plan yet, but my idea is close. Since we basically program
the DDICs in panel drivers, which are bridges, just move them as bridges with
perhaps a set of panel DDIC helpers to reduce the burden to write a full
bridge driver and then declare the actual physical panel as connected to
the final bridge connector.

Having a proper "panel" described would be the key to the move, but the more
I dig the more it needs to be a generalized solution across DRM.
I had some feedback about how this would solve issues people struggle have
with advanced monitors arrangements and advanced features like Tiled Display, etc...

But yeah let's meet in Prague a discuss about this, I'll be pleasure to you
again in person, it has been a while !

Neil

> 
> Maxime