From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Maxime Ripard <mripard@kernel.org>
Cc: Neil Armstrong <neil.armstrong@linaro.org>,
Jessica Zhang <jesszhan0024@gmail.com>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Thomas Zimmermann <tzimmermann@suse.de>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Nathan Chancellor <nathan@kernel.org>,
Nick Desaulniers <ndesaulniers@google.com>,
Bill Wendling <morbo@google.com>,
Justin Stitt <justinstitt@google.com>,
Florian Fainelli <florian.fainelli@broadcom.com>,
Broadcom internal kernel review list
<bcm-kernel-feedback-list@broadcom.com>,
Andrzej Hajda <andrzej.hajda@intel.com>,
Robert Foss <rfoss@kernel.org>, Jonas Karlman <jonas@kwiboo.se>,
Jernej Skrabec <jernej.skrabec@gmail.com>,
Luca Ceresoli <luca.ceresoli@bootlin.com>,
Albert Esteve <aesteve@redhat.com>,
Dave Stevenson <dave.stevenson@raspberrypi.com>,
Javier Martinez Canillas <javierm@redhat.com>,
dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, bpf@vger.kernel.org,
llvm@lists.linux.dev, linux-rpi-kernel@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
Benjamin Tissoires <bentiss@kernel.org>
Subject: Re: [PATCH 0/6] drm/bridge: Add a BPF-based MIPI-DSI panel driver
Date: Mon, 28 Sep 2026 19:37:11 +0300 [thread overview]
Message-ID: <20260928163711.GA210522@killaraus.ideasonboard.com> (raw)
In-Reply-To: <20260928-drm-mipi-dsi-panel-ebpf-v1-0-5244926aace4@kernel.org>
Hi Maxime,
On Mon, Sep 28, 2026 at 06:22:00PM +0200, 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.
Interesting idea.
How would that work for devices that want early display support ? In
particular, how does it interact with your recent work on "fastboot"
support (with the kernel drivers taking over a running display
configured by the boot loader) ?
I'm also wondering about the incentives for vendors to upstream the
code. How will we avoid having a proliferation of out-of-tree drivers ?
> 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.
>
> * 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.
>
> - 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.
>
> Let me know what you think,
> Maxime
>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> Maxime Ripard (6):
> dt-bindings: display: Add panel-mipi-dsi-bpf generic panel binding
> drm/panel: Add generic MIPI-DSI panel driver with BPF init sequences
> drm/panel: dsi-bpf: Add BPF program build infrastructure and helper header
> drm/panel: dsi-bpf: Add Raspberry Pi 7-inch panel BPF program
> drm/panel: dsi-bpf: Add Raspberry Pi 5-inch panel BPF program
> [DO NOT MERGE] arm64: dts: broadcom: Add Raspberry Pi ILI9881C DSI panel overlays
>
> .../bindings/display/panel/panel-mipi-dsi-bpf.yaml | 184 +++++++++
> arch/arm64/boot/dts/broadcom/Makefile | 8 +
> .../bcm2711-rpi-4-b-dsi-ili9881-5inch.dtso | 22 +
> .../bcm2711-rpi-4-b-dsi-ili9881-7inch.dtso | 22 +
> .../dts/broadcom/bcm2711-rpi-4-b-dsi-ili9881.dtsi | 65 +++
> drivers/gpu/drm/panel/Kconfig | 3 +
> drivers/gpu/drm/panel/Makefile | 1 +
> drivers/gpu/drm/panel/bpf/Kconfig | 28 ++
> drivers/gpu/drm/panel/bpf/Makefile | 10 +
> .../gpu/drm/panel/bpf/panel-bpf-mipi-dsi-core.c | 452 +++++++++++++++++++++
> .../gpu/drm/panel/bpf/panel-bpf-mipi-dsi-kfuncs.c | 278 +++++++++++++
> drivers/gpu/drm/panel/bpf/panel-bpf-mipi-dsi-ops.c | 242 +++++++++++
> .../gpu/drm/panel/bpf/panel-bpf-mipi-dsi-trace.c | 4 +
> .../gpu/drm/panel/bpf/panel-bpf-mipi-dsi-trace.h | 246 +++++++++++
> drivers/gpu/drm/panel/bpf/panel-bpf-mipi-dsi.h | 264 ++++++++++++
> drivers/gpu/drm/panel/bpf/progs/Makefile | 93 +++++
> .../panel/bpf/progs/Raspberrypi__dsi-5inch.bpf.c | 266 ++++++++++++
> .../panel/bpf/progs/Raspberrypi__dsi-7inch.bpf.c | 271 ++++++++++++
> .../gpu/drm/panel/bpf/progs/panel-bpf-mipi-dsi.h | 95 +++++
> 19 files changed, 2554 insertions(+)
> ---
> base-commit: 6e375de99d0c420169481fcd36064177ab55b09d
> change-id: 20260928-drm-mipi-dsi-panel-ebpf-d78b72a9c47f
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2026-09-28 16:37 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-28 16:22 [PATCH 0/6] drm/bridge: Add a BPF-based MIPI-DSI panel driver Maxime Ripard
2026-09-28 16:22 ` [PATCH 1/6] dt-bindings: display: Add panel-mipi-dsi-bpf generic panel binding Maxime Ripard
2026-09-28 16:35 ` sashiko-bot
2026-09-28 19:16 ` Neil Armstrong
2026-09-28 20:40 ` Rob Herring
2026-09-29 8:39 ` Maxime Ripard
2026-09-29 22:28 ` Rob Herring
2026-09-30 8:04 ` Maxime Ripard
2026-09-30 19:07 ` Rob Herring
2026-10-01 7:22 ` Maxime Ripard
2026-10-01 16:03 ` Rob Herring
2026-09-30 13:32 ` Neil Armstrong
2026-10-01 7:09 ` Maxime Ripard
2026-10-02 7:28 ` Neil Armstrong
2026-09-28 20:43 ` Rob Herring (Arm)
2026-09-29 23:44 ` bot+bpf-ci
2026-09-29 23:44 ` bot+bpf-ci
2026-09-28 16:22 ` [PATCH 2/6] drm/panel: Add generic MIPI-DSI panel driver with BPF init sequences Maxime Ripard
2026-09-28 16:34 ` sashiko-bot
2026-09-28 16:22 ` [PATCH 3/6] drm/panel: dsi-bpf: Add BPF program build infrastructure and helper header Maxime Ripard
2026-09-28 16:31 ` sashiko-bot
2026-09-29 23:44 ` bot+bpf-ci
2026-09-29 23:44 ` bot+bpf-ci
2026-09-28 16:22 ` [PATCH 4/6] drm/panel: dsi-bpf: Add Raspberry Pi 7-inch panel BPF program Maxime Ripard
2026-09-28 16:34 ` sashiko-bot
2026-09-28 16:22 ` [PATCH 5/6] drm/panel: dsi-bpf: Add Raspberry Pi 5-inch " Maxime Ripard
2026-09-28 16:33 ` sashiko-bot
2026-09-28 16:22 ` [PATCH DO NOT MERGE 6/6] arm64: dts: broadcom: Add Raspberry Pi ILI9881C DSI panel overlays Maxime Ripard
2026-09-28 16:31 ` sashiko-bot
2026-09-28 16:37 ` Laurent Pinchart [this message]
2026-09-28 17:31 ` [PATCH 0/6] drm/bridge: Add a BPF-based MIPI-DSI panel driver Benjamin Tissoires
2026-09-28 18:12 ` Laurent Pinchart
2026-09-29 6:54 ` Maxime Ripard
2026-09-28 16:39 ` Neil Armstrong
2026-09-28 17:24 ` Benjamin Tissoires
2026-09-28 19:20 ` Neil Armstrong
2026-09-28 19:48 ` Benjamin Tissoires
2026-09-28 20:36 ` Neil Armstrong
2026-09-29 7:41 ` Maxime Ripard
2026-09-29 7:55 ` Javier Martinez Canillas
2026-09-30 13:37 ` Neil Armstrong
2026-10-01 6:50 ` Maxime Ripard
2026-10-02 7:30 ` Neil Armstrong
2026-10-02 7:37 ` Javier Martinez Canillas
2026-10-02 7:53 ` Neil Armstrong
2026-10-02 9:04 ` Javier Martinez Canillas
2026-09-30 13:36 ` Neil Armstrong
2026-09-30 20:59 ` Kumar Kartikeya Dwivedi
2026-10-01 6:38 ` Maxime Ripard
2026-10-01 17:03 ` Maxime Ripard
2026-09-29 7:27 ` Maxime Ripard
2026-09-30 13:49 ` Neil Armstrong
2026-10-01 7:01 ` Maxime Ripard
2026-10-02 7:39 ` Neil Armstrong
2026-09-29 7:13 ` Maxime Ripard
2026-09-29 7:46 ` Benjamin Tissoires
2026-09-30 13:46 ` Neil Armstrong
2026-10-01 6:48 ` Maxime Ripard
2026-10-02 8:11 ` Neil Armstrong
2026-09-29 9:03 ` Jani Nikula
2026-09-29 9:32 ` Benjamin Tissoires
2026-09-29 10:16 ` Jani Nikula
2026-09-29 12:28 ` Maxime Ripard
2026-09-30 14:01 ` Neil Armstrong
2026-09-30 19:18 ` Jani Nikula
2026-10-01 7:05 ` Maxime Ripard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260928163711.GA210522@killaraus.ideasonboard.com \
--to=laurent.pinchart@ideasonboard.com \
--cc=aesteve@redhat.com \
--cc=airlied@gmail.com \
--cc=andrzej.hajda@intel.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=bentiss@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=conor+dt@kernel.org \
--cc=dave.stevenson@raspberrypi.com \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=florian.fainelli@broadcom.com \
--cc=javierm@redhat.com \
--cc=jernej.skrabec@gmail.com \
--cc=jesszhan0024@gmail.com \
--cc=jonas@kwiboo.se \
--cc=justinstitt@google.com \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rpi-kernel@lists.infradead.org \
--cc=llvm@lists.linux.dev \
--cc=luca.ceresoli@bootlin.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=morbo@google.com \
--cc=mripard@kernel.org \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=neil.armstrong@linaro.org \
--cc=rfoss@kernel.org \
--cc=robh@kernel.org \
--cc=simona@ffwll.ch \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.