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

[Neil Armstrong <neil.armstrong@linaro.org>]

On 9/29/26 09:41, Maxime Ripard wrote:
> 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.
>>>>>>
>>>>>>>
>>>>>>> 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".
>>>>
>>>> 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...
>>>>
>>>
>>> That's exactly where BPF shines. The simple rule of thumb is: there is
>>> no API stability guaranteed. Basically, thanks to the verifier and CORE
>>> (Compile Once Run Everywhere), you don't need to keep the API stable and
>>> available forever. There are multiple ways of dealing with it, but the
>>> gist is that if a BPF is trying to load an "old" API, it will be
>>> rejected by the verifier.
>>>
>>> Then it's a matter of being nice enough in the kernel and provide ways
>>> to deal with those.
>>>
>>> To give you a few examples:
>>>
>>> - in HID-BPF, in userspace, we keep old versions of APIs in separate
>>> 	compiled objects. Each is incremented (by 10 so we have a little bit
>>> 	of room in the middle). Then the loader tries first
>>> 	0020-device-with-new-api.bpf.o, and if it fails, it tries
>>> 	0010-device-with-old-api.bpf.o
>>>
>>> 	I'm not saying we should do the same here, but that's one idea
>>>
>>> - recently, a BPF commit broke the ABI of a function while removing
>>> 	implicits: bpf_wq_set_callback_impl() was replaced by
>>> 	bpf_wq_set_callback() with a different number of arguments. I simply
>>> 	had to add a new function in my header which basically does:
>>>
>>> 	static inline int
>>> 	hid_bpf_wq_set_callback(struct bpf_wq *wq,
>>> 	                        int (*callback_fn)(void *, int *, void *),
>>> 	                        unsigned int flags)
>>> 	{
>>>         if (bpf_ksym_exists(bpf_wq_set_callback))
>>>                 return bpf_wq_set_callback(wq, callback_fn, flags);
>>>         if (bpf_ksym_exists(bpf_wq_set_callback_impl))
>>>                 return bpf_wq_set_callback_impl(wq, callback_fn, flags, NULL);
>>>     }
>>>
>>>     And then I changed the bpf.c to use hid_bpf_wq_set_callback() and the
>>>     bpf is compatible with both APIs
>>>
>>> - with CORE, struct fields are relocated on the fly when you load the BPF
>>>     So for instance, if my BPF only accesses fields .name, .phys and .id
>>>     in the BPF, I can define:
>>>     struct hid_device {
>>>       char                       name[128];
>>>       char                       phys[64];
>>>       unsigned int               id;
>>>     }
>>>
>>>     Then when loading the bpf, the verifier replaces all offset to the
>>>     ones actually used by the running kernel, and the program loads
>>>     transparently, even if you add fields before/after or change the
>>>     fields order in the kernel.
>>>
>>> Changing the mindset is the hardest part of it. But once you are making
>>> the shift, it's actually much better to work with. It doesn't mean you
>>> can go yolo. You still need to be careful in your choices knowing the
>>> impact on your users. But the API at version 0 is not frozen and you
>>> don't need to maintain it forever, especially if you control the loader
>>> and the headers used to compile the BPFs.
>>
>> It's really impressive, but there's no way this would become the de-facto
>> way to program the panels
> 
> Nobody said it would? And like I said in my previous mail, I actually
> expect us to keep merging panel drivers. Do I think it should become the
> go-to solution for simple panels? yes. But we can always make
> exceptions, and for more complex panels we should totally do a more
> complex driver. Like HID has been doing.
> 
>> and if the motivation is to make it simpler this implementation
>> requires adding bindings and bpf programs which that are the same as
>> native panel drivers, but won't be able to work until user-space
>> starts and will require to be in initramfs or rootfs to have
>> functional display.
>>
>> Not sure to understand what are the positive features here except
>> isolating the panel code in a safe bpf program (is this really needed
>> ?).
> 
>  From the cover letter:
> 
> """
> 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.
> """
> 
> You can disagree with the solution, that's fair, we can also discuss on
> how to solve this problem, but I'd appreciate it if you weren't claiming
> it's all useless.

I did read the cover-letter and I got the arguments from Benjamin, and
while in theory it could indeed solve the issue described, in reality
it won't for the reasons I exposed.

And since it's basically allowing to accept out-of-tree downstream
driver instead of upstreaming, I'm kind against TBH.

But I'm open to discussion, and I'll talk about display Panel in
XDC today, Plumbers and ELC next week so I hope we'll find time to
discuss about this in person!

Neil

> 
> Maxime