[PATCH v10 2/2] net: airoha: npu: use cacheline-sized buffers for mailbox DMA

[Daniel Pawlik]

Hi Zhengping, Kuba,

Thanks for confirming the NPU address window.

Please consider v10 2/2 withdrawn. It avoids the observed SWIOTLB bounce
path but does not ensure that DMA addresses stay within the NPU window.

I tested W1700K with all 2 GiB of RAM and the upstream DMA_BIDIRECTIONAL
mailbox path, using a restricted DMA pool at 0xbc000000-0xbfffffff,
without either the cacheline patch or the coherent-mailbox workaround.
Both the NPU and MT7996 drivers report version 0.1111, and all three
Wi-Fi APs are enabled.

The OpenWrt change is posted for review [1]

[1] https://github.com/openwrt/openwrt/pull/25928


Thanks,
Dan

czw., 15 paź 2026, 10:41 użytkownik Zhengping Zhang
<zhengping.zhang at airoha.com> napisał:
>
> Hi Daniel,
>
> We investigated the NPU V2 address handling and confirmed that the NPU
> exposes only a 1 GiB DRAM address window.
>
> The relevant vendor definitions are:
>
>     #define DRAM_RANGE_1GB 0xbfffffff
>
>     #define DRAM_CAC_TO_UNC(x) \
>             ((x & 0x3fffffff) | 0x40000000)
>
>     #define DRAM_UNC_TO_CAC(x) \
>             ((x & 0x3fffffff) | 0x80000000)
>
> Therefore, the supported host cached DRAM range is:
>
>     0x80000000 - 0xbfffffff
>
> The corresponding NPU uncached address range is:
>
>     0x40000000 - 0x7fffffff
>
> As a result, the upper 1 GiB of a 2 GiB DRAM configuration aliases the
> lower 1 GiB from the NPU's point of view.
>
> The WLAN NPU firmware also checks the address range for packet buffers
> and TX ring addresses:
>
>     if (addr > DRAM_RANGE_1GB)
>             printf("out of available range");
>
> NPU debug output is disabled by default. To enable it for debugging,
> change the value written to REG_CR_NPU_MIB(21) from 1 to 0 in
> airoha_npu.c:
>
> -    regmap_write(npu->regmap, REG_CR_NPU_MIB(21), 1);
> +    regmap_write(npu->regmap, REG_CR_NPU_MIB(21), 0);
>
> The recommended platform integration is to reserve all NPU-owned WLAN
> buffers inside the supported DRAM window. For example:
>
>     reserved-memory {
>             #address-cells = <2>;
>             #size-cells = <2>;
>             ranges;
>
>             npu_pkt: npu-pkt at 8a000000 {
>                     no-map;
>                     reg = <0x0 0x8a000000 0x0 0x2c00000>;
>             };
>
>             npu_txpkt: npu-txpkt at 8cc00000 {
>                     no-map;
>                     reg = <0x0 0x8cc00000 0x0 0x4000000>;
>             };
>
>             npu_txbufid: npu-txbufid at 90c00000 {
>                     no-map;
>                     reg = <0x0 0x90c00000 0x0 0x6800>;
>             };
>
>             npu_ba: npu-ba at 90c06800 {
>                     no-map;
>                     reg = <0x0 0x90c06800 0x0 0x200000>;
>             };
>     };
>
> The regions should then be referenced by name from the NPU device node:
>
>     npu {
>             memory-region = <&npu_pkt>,
>                             <&npu_txpkt>,
>                             <&npu_txbufid>,
>                             <&npu_ba>;
>             memory-region-names = "pkt", "tx-pkt", "tx-bufid", "ba";
>     };
>
> This reserved-memory configuration covers the NPU WLAN packet buffers,
> TX packet buffers, buffer IDs, and BA memory.
>
> It does not automatically constrain the temporary mailbox buffers
> allocated with kzalloc(). If the same NPU address-window restriction
> also applies to mailbox DMA, those buffers must be allocated from a
> low-address DMA pool or otherwise guaranteed to map to an address
> within the supported window.
>
> Best regards,
> Zhengping
>
> Wed, Sep 30, 2026 at 06:19:31PM +0200, Daniel Pawlik wrote:
> > Hi Kuba, Lorenzo, Airoha team,
> >
> > I found a concrete lead for the unresolved cacheline patch in the vendor
> > firmware. The installed en7581_MT7996_npu_rv32.bin matches the blob in
> > linux-firmware commit 1043c0303910 by SHA-256.
> >
> > At file offset 0x3a9c, the Wi-Fi mailbox handler converts the supplied
> > buffer address before reading the command:
> >
> >   lui   a5,0x40000
> >   addi  a4,a5,-1
> >   and   a4,a4,a0
> >   or    a4,a4,a5
> >   lw    a1,0(a4)
> >
> > This implements (address & 0x3fffffff) | 0x40000000. Both 0xbf6cf000
> > and 0xff6cf000 produce 0x7f6cf000. W1700K has 2 GiB of RAM starting
> > at 0x80000000; its current SWIOTLB pool starts at 0xff6cf000.
> >
> > The handler also returns 1 (success) for an unsupported operation type
> > at file offset 0x3b4a. My earlier claim that mailbox success proved a
> > correct command read was therefore unjustified. The traces do not
> > establish a read-succeeds/write-fails limitation.
> >
> > This suggests an address-window problem, but the NPU-side bus mapping
> > still needs confirmation. The cacheline patch avoids the observed bounce
> > path without constraining the address of future direct allocations.
> >
> > Can Airoha confirm which host DRAM range this alias covers, and whether
> > mailbox buffers above 0xbfffffff are supported?
> >
> > I have prepared, but not yet run, a test retaining all 2 GiB of RAM and
> > the 12-byte DMA_BIDIRECTIONAL mapping, with the SWIOTLB boot pool below
> > 0xc0000000. A successful version response through a verified bounced
> > mapping there would help distinguish the address limitation from a
> > SWIOTLB copy/cache issue.
> >
> > Thanks,
> > Dan
> >