Hi, I'll merge the two discussions in that thread.
On Mon, Sep 28, 2026 at 03:40:59PM -0500, Rob Herring wrote: > On Mon, Sep 28, 2026 at 06:22:01PM +0200, Maxime Ripard wrote: > > Most MIPI-DSI panel drivers follow an identical pattern: acquire > > regulators and GPIOs, perform a reset pulse with specific timing, > > send a vendor-supplied sequence of DSI commands, then enable the > > display. The only truly panel-specific part is the init sequence > > and power-on/off timing. > > > > The panel-mipi-dsi-bpf driver replaces per-panel kernel modules > > with a single generic driver whose panel-specific behavior is > > provided by BPF programs loaded from userspace at runtime, > > following the HID-BPF model. This enables new panel support > > without kernel patches. > > > > Panel DT nodes use a two-entry compatible with the panel-specific > > string first and "panel-mipi-dsi-bpf" as fallback. The generic > > driver matches on the fallback, while the first compatible is used > > to identify which BPF program to load. > > If you need the 1st compatible anyways, what is the point of the > second one? The whole point of this driver is that you don't need to modify the kernel when you add support for a new panel. > Also, I assume there is at least some panel supported in the kernel > you might want to convert to this. That panel would not have the > fallback (and the DT is fixed). Yeah, that's true. I'd still need to identify the parts though. I guess using a generic compatible but a specific model would work? > And I agree with Neil's comment. At least until we start embedding BPF > into DT directly. ;) And from Neil: > I don't see how this can be a valid hardware description, bfp is a > software implementation and has nothing to do in the bindings. I'm quite a bit surprised by that argument though. We have in the main dt-schema repos bindings like: https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/options/u-boot.yaml https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/bootph.yaml https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/post-init-providers.yaml Or, in Linux: https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/misc/google,android-pipe.yaml https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/sound/simple-card.yaml All of them have been reviewed or acked by you, and yet none of them relate to any hardware description. panel-mipi-dsi-spi is a generic panel that will load a firmware, and quite similar to this one. google,android-pipe and qcom,fastrpc don't attach to anything and will just open a tunnel to userspace, which is somewhat equivalent but more dramatic than what this driver is doing. simple-card or its variations will just instantiate a kernel driver from the DT and is used pretty much everywhere. I reused the binding from panel-mipi-dsi-spi for this. It was reviewed by rob, and acked by a panel maintainer, and 4 years ago, so we're way past the "oh but we didn't know what we were doing back then" argument. So, let's phrase this differently: what's different about the description than panel-mipi-dsi-spi, or any other binding already in tree? If it's the BPF part, BPF is not Linux-only, and there's hardware with direct BPF support these days, so it can be considered OS-agnostic and not an implementation detail. Maxime
signature.asc
Description: PGP signature
