[RFC net-next 0/3] net: airoha: npu: keep NPU-shared DMA buffers in the NPU window

[Chris Scott <gilroyscott1970@gmail.com>]

The EN7581 NPU can only address host DRAM at 0x80000000-0xbfffffff;
higher addresses alias the lower 1 GiB, as confirmed by Airoha [1].
On boards with 2 GiB of RAM nothing keeps the buffers the NPU reads
and writes inside that window:

- the mailbox buffers are streaming-mapped kzalloc() memory, which on
  arm64 bounces through swiotlb; on W1700K the swiotlb pool is at
  0xff6cf000, so the NPU version query reads back 0.0 and mt76 does not
  bind NPU offload (this is the issue behind the earlier "use coherent
  DMA for mailbox messages" / cacheline-buffer postings [2]);

- the coherent buffers mt76 allocates on the NPU device (NPU TX/RX
  rings, HW-RRO and TXD buffers) currently land in the window only
  because of early-boot allocation order; reserving low DRAM away makes
  the SoC hang right after mt7996 firmware load.

Patch 1 adds an optional "dma" shared-dma-pool region to the NPU
binding. Patch 2 attaches it as the NPU device coherent pool, so every
coherent allocation on the NPU device comes from the window. Patch 3
moves the mailbox to per-core coherent buffers, which then come from
that pool.

Streaming mappings are deliberately left alone. Packet buffers are only
passed through to the WiFi DMA engine; restricting them with a
restricted-dma-pool or a bus DMA limit forces swiotlb bouncing and cost
~22% of host-path WiFi TX in testing, and the default swiotlb pool is
itself outside the window on these boards.

Sent as RFC while net-next is closed; I will repost as v1 once it
reopens. Feedback on the approach is welcome, in particular whether a
reserved coherent pool is the preferred way to express the NPU window
rather than a dma-ranges based limit.

Testing: Daniel tested this series, backported to OpenWrt kernel
6.18.57, on a Gemtek W1700K (EN7581 + MT7996, 2 GiB) with a 16 MiB
pool: the pool is assigned at 0xbf000000-0xbfffffff, the NPU version
query is correct, all three bands and MLO come up and there are no
warnings. I tested the equivalent of patches 2 and 3 on the same board
with 6.18.55 and 7.3-rc6: all mt76 NPU rings/RRO/TXD buffers come from
the pool (~10.7 MiB used), host-path and offloaded WiFi throughput are
unchanged versus no pool, and boot still succeeds with low DRAM
reserved away. On net-next the series was build-tested with W=1
(airoha and mt76 incl. MT7996_NPU, at each patch), checkpatch --strict
and dt_binding_check.

mainline en7581.dtsi does not have an NPU node yet, so there is no DTS
change here; boards using the WLAN offload need a 16 MiB pool, others
only need the mailbox (1 MiB is plenty).

Tools: patch 1 was originally written with Codex and patch 3 with
Cursor; patch 2 was written with Claude (Anthropic), which was also
used to rebase patches 1 and 3 onto net-next and rewrite their commit
messages.

[1] https://lore.kernel.org/r/atCRsquzA1UxSpCc@mediatek.com
[2] https://lore.kernel.org/r/20260809152813.585797-1-pawlik.dan@gmail.com

Chris Scott (1):
  net: airoha: npu: attach a coherent pool in the NPU window

Daniel Pawlik (2):
  dt-bindings: net: airoha: npu: add DMA pool memory region
  net: airoha: npu: use coherent memory for mailbox messages

 .../bindings/net/airoha,en7581-npu.yaml       | 40 +++++----
 drivers/net/ethernet/airoha/airoha_npu.c      | 83 +++++++++++++++----
 include/linux/soc/airoha/airoha_offload.h     |  3 +
 3 files changed, 95 insertions(+), 31 deletions(-)


base-commit: 734bef548a96e8774d6eef5dfa2026c6edc4e80b
-- 
2.53.0