ARM PL330 DMA controller

Identity

Status — ◐ partial

Both PL330 instances should attach as of 2026-04-30: the FreeBSD xDMA-framework PL330 driver lives at sys/dev/xdma/controller/pl330.c and matches compatible = "arm,pl330" exactly; the RK3399 device tree that ships in sys/contrib/device-tree/src/arm64/rockchip/rk3399-base.dtsi already declares both dmac_bus@ff6d0000 and dmac_peri@ff6e0000 with that compatible string, two GIC SPIs each, and #dma-cells = <1>. The only missing piece was the kernel config — neither device pl330 nor device xdma was in PINEPHONE_PRO, so the driver was being built into GENERIC kernels but not ours. Adding both lines is enough to bring up the controllers; consumer drivers are still TODO.

Driver

• Our tree: sys/dev/xdma/controller/pl330.c (FreeBSD upstream, unchanged) — registered via EARLY_DRIVER_MODULE(pl330, simplebus, ...). The DTS nodes are inherited from sys/contrib/device-tree/...rk3399-base.dtsi — also unchanged. The fix is in src/sys/arm64/conf/PINEPHONE_PRO which now declares device xdma + device pl330.
• Linux mainline: drivers/dma/pl330.c — reference, fully working with the same dma-cells = <1> shape.
• FreeBSD upstream: sys/dev/xdma/controller/pl330.c — note that FreeBSD’s pl330 lives under the xDMA framework rather than sys/dev/pl330/, which is why earlier reads of the source tree at sys/dev/pl330/pl330.c came up empty.

The FreeBSD probe does not currently call clk_get_by_ofw_name(dev, "apb_pclk", ...) to enable the AMBA PCLK that the upstream Linux binding documents under clock-names. On RK3399 the ACLK_DMAC0_PERILP and ACLK_DMAC1_PERILP gates default to enabled by U-Boot, so attach should still succeed; if a future U-Boot ever leaves them gated the controller will probe but transfers will hang silently. That gap is upstream’s, not ours, but worth noting before any I2S DMA work lands.

Open work

• Wire I2S0 as the first DMA consumer; the audio TX zero-buffer issue from essay 13 is partly downstream of this. RK3399 dts has dmas = <&dmac_bus 0>, <&dmac_bus 1> for I2S0 already, but our rk_i2s.c is PIO-only — adding xDMA channel allocation + descriptor submission to it is its own refactor.
• Cover SPI flash next — mx25l would benefit from DMA too once the GD25LQ128 ID is added.
• Upstream the missing clk_get for apb_pclk so future bring-ups don’t depend on U-Boot leaving the AMBA gate enabled.

Parity verification

Bench predicate is the dmesg attach line. After a kernel built with device xdma + device pl330 boots:

pl330_0: <ARM PrimeCell DMA Controller (PL330)> mem 0xff6d0000-0xff6d3fff irq 0,1 on simplebus0
pl330_1: <ARM PrimeCell DMA Controller (PL330)> mem 0xff6e0000-0xff6e3fff irq 0,1 on simplebus0

Falsifiers:

• No attach lines at all — device pl330 (or device xdma) is missing from the kernel config, or the linked-set glue isn’t being emitted (gcc14+bfd ld vs. clang+lld; build with the project’s stock clang toolchain, never honeyguide/cross-build.sh).
• Only one of the two attaches — almost certainly a DTS regression where one of the two dma-controller@ff6d0000 / @ff6e0000 nodes lost its compatible or got a status = "disabled" somewhere. Diff sys/contrib/device-tree/src/arm64/rockchip/rk3399-base.dtsi against upstream Linux.
• Attach with later channel-alloc EBUSY — clock gate left off by U-Boot. Manifests as pl330_channel_alloc succeeding but transfers never completing; cure is to teach pl330_attach to grab apb_pclk and clk_enable() it (upstream patch territory).
• No consumer ever requests a channel — expected today; the controller will sit idle until rk_i2s.c (or another driver) calls xdma_ofw_get().

Related

• Audio on device — the I2S/PIO buffer pipeline that DMA would fix.
• Cross-driver audit 2026-04-30 — driver gap audit.