Hi Chaoyi, Thanks again for the AUTO_GATING fix and the MMU-v2 clarification — both are in v4.
The mainline `rocket` driver now probes, powers, and **submits** cleanly on the RK3568 NPU. The last blocker is purely functional: **a submitted conv never computes** — and I've now localized it precisely enough that I think it's a question only Rockchip can answer. ## The localization: the CNA weight-fetch DMA never fires I captured the **working vendor `rknpu`** running our exact conv (`conv2d`, 16→128, 5×5 s2) and diffed its pipeline against `rocket` running the same conv, both driven to the **identical engaged state**: - both units reach `S_STATUS=0x0c`, `S_POINTER=0x1000e` (executer bit16 set), `TASKST=0xf000`, `PC AMOUNTS=0x88`; - the CNA config registers are byte-identical (CONV_CON*, DATA_SIZE*, WEIGHT_SIZE*, CBUF). Yet the data-amount counters diverge completely: | counter | vendor `rknpu` (correct output) | mainline `rocket` (no output) | |---|---|---| | `wt_rd` (0x803c) | **0x1900** | **0** | | `dt_wr` (0x8034) | **0x6400** (= 204800 B, full) | **0** | | `dt_rd` (0x8038) | 0x32c9 | 0x8b (regcmd fetch only) | So on identical engaged HW with identical CNA config, the **vendor's CNA issues its weight-fetch DMA and the DPU writes the full output; `rocket`'s CNA never issues the weight read** — the MAC array starves and the DPU writes nothing. ## What I''ve already ruled out - **Command stream / weights / input:** byte-exact replay of the vendor's captured `conv2d` regcmd **+ weight BO + input BO** through the rocket UABI → still no compute. Content is not the gate. - **`state_init`:** RK3568's `rk356x_rknpu_config.state_init = NULL` (only RK3576 has one); we also tested the RK3576 `0x1024=0x80000000` / S_POINTER `0→1→0x1e` ritual on RK3568 anyway → no change. - **Reset / power / clocks / IOMMU:** rocket mirrors `rknpu_soft_reset` (srst assert/deassert, SCMI/PVTPLL two-step, NoC de-idle at PMU 0xfdd90000, IOMMU re-establish); clocks match the vendor (SCMI 1 GHz, CLK_NPU/aclk 200 MHz); AUTO_GATING = your bit-31 fix. - **Non-NPU-block writes (captured live, vendor + rocket same boot):** the only raw non-NPU writes the vendor `rknpu` makes are the NoC/PMU de-idle (`NOC_AUTO=0xfffb`, `BUS_IDLE_ST=0x1ea`, `PWR_STATUS=0x7f`) — rocket makes them **identically** (`0x1ea`/`0xfffb`). No `npu_grf` read-margin and no memory-repair on RK3568 (those exist only on RK3576/RK3588). So GRF/CRU/PMU/NoC are matched too. ## The question **With the executer engaged (`S_STATUS=0x0c`, `S_POINTER` bit16 set) and the CNA regcmd config landed, what triggers the CNA's weight-fetch DMA?** The vendor `rknpu` reaches `wt_rd=0x1900` from a clean submit; `rocket`, same SoC / engage / regcmd, stays `wt_rd=0`. I've now matched every software-visible surface I can find — NPU-block job writes (byte-exact), non-NPU writes (NoC/PMU/GRF, above), regcmd+weights+input (Method B replay), power/clocks/reset/ IOMMU — and the vendor still fetches weights while rocket doesn't. So my remaining hypotheses are all HW-internal, and I'd value your read on which: - an **ordering/timing** requirement between engage and the weight-fetch trigger that a byte-identical-but-differently-sequenced submit doesn't satisfy; - an internal CNA/CBUF **sequencer or credit/handshake** state that the vendor's power-on or first-job path leaves armed and that isn't a CPU-visible register; - or a genuinely undocumented CNA condition (a CBUF/DCOMP/weight-DMA enable) needed before the fetch will issue. Is any of these something the RK3568 NPU is known to require? Even a pointer to "the weight-fetch won't start unless X" would unblock the mainline driver. I would be happy to run any targeted register capture on the board. Thanks a lot, Midgy Le lun. 8 juin 2026 à 05:40, Chaoyi Chen <[email protected]> a écrit : > On 6/8/2026 9:45 AM, Chaoyi Chen wrote: > > Hi Midgy, > > > > On 6/8/2026 5:05 AM, Midgy Balon wrote: > >> Hi Chaoyi, > >> > >>> As I said, it is v2. Could you please try using the code below instead > and > >>> see if it works? > >>> [ auto_gate = read(RK_MMU_AUTO_GATING); auto_gate |= BIT(31); > write(...) ] > >> > >> Thanks -- that's clearly the right shape (read-modify-write, before > paging is > >> enabled, keeping the reset value instead of my clobbering 0x2). > >> > >> I rebuilt v7.1-rc6 (with the rocket RK3568 series + your per-device-ops > work) > >> using your bit-31 version and tested it on a ROCK 3B: the NPU IOMMU > comes up and > >> services the NPU's DMA cleanly -- the NPU probes, attaches its domain, > and runs > >> repeated conv submissions with no DMA_READ_ERROR and no page-walk > stall. No > >> regression from the write. > >> > >> To be precise about what I can and can't show: I tested both ways on > v7.1-rc6 -- > >> with your bit-31 write, and on the reset value (0x3) -- and the NPU > >> IOMMU services > >> the NPU's reads with zero faults in both cases (no DMA_READ_ERROR, no > page-walk > >> stall). So I don't have a failing baseline here that bit-31 visibly > >> fixes. Is the > >> AUTO_GATING write needed on current mainline, or only under conditions > I'm not > >> reproducing (a particular traffic pattern / silicon rev)? I'll keep the > patch in > >> your form unless you'd prefer to drop it. > >> > >> One question so I document it correctly: what does bit 31 of > RK_MMU_AUTO_GATING > >> control on the v2 block -- is it a master "disable internal auto > clock-gating" > >> for the page-table walker (i.e. so a TLB-miss walk's AXI master keeps > its clock > >> to completion)? The RK3568 TRM I have doesn't cover the IOMMU > registers, so a > >> one-line description would let me write an accurate comment. > >> > > > > Glad to hear this works. Please refer to the commit below. > > > > [0]: > https://github.com/rockchip-linux/kernel/commit/7f8158fb41b5cc8e738aaeebc3637c50ebd74cae > > [1]: > https://github.com/rockchip-linux/kernel/commit/6a355e5f9a2069a2309e240791bc3aad63b7324e > > > > It looks like RGA needs this patch too, and it has already been merged :). > > > https://lore.kernel.org/all/[email protected]/ > > -- > Best, > Chaoyi >
