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

[Zhengping Zhang <zhengping.zhang@airoha.com>]

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@8a000000 {
                    no-map;
                    reg = <0x0 0x8a000000 0x0 0x2c00000>;
            };

            npu_txpkt: npu-txpkt@8cc00000 {
                    no-map;
                    reg = <0x0 0x8cc00000 0x0 0x4000000>;
            };

            npu_txbufid: npu-txbufid@90c00000 {
                    no-map;
                    reg = <0x0 0x90c00000 0x0 0x6800>;
            };

            npu_ba: npu-ba@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
>