Claude review: arm64: dts: rockchip: rk356x: Add NPU and its IOMMU

[Claude Code Review Bot <claude-review@example.com>]

Patch Review

**1. Node placement violates address ordering**

The NPU nodes are inserted between `qos_rga_wr` (0xfe158300) and `qos_npu` (0xfe180000):

```diff
 	qos_rga_wr: qos@fe158300 {
 		reg = <0x0 0xfe158300 0x0 0x20>;
 	};

+	rknn_core_0: npu@fde40000 {
```

But the NPU base address is `0xfde40000`, which is *lower* than `0xfe158300`. Rockchip DTS files sort nodes by unit address. These nodes should be placed earlier in the file, near other `0xfdeXXXXX` nodes.

**2. Shared interrupt between NPU and IOMMU**

```dts
rknn_core_0: npu@fde40000 {
	interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
	...
};

rknn_mmu_0: iommu@fde4b000 {
	interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
	...
};
```

Both the NPU core and its IOMMU use GIC_SPI 151. Verify this is correct per the TRM — on RK3588 the NPU cores and IOMMUs have distinct interrupts. Sharing an interrupt line between a device and its IOMMU can work if the driver handles it, but it's unusual and worth double-checking against the hardware documentation.

**3. `assigned-clock-rates` value**

```dts
assigned-clocks = <&scmi_clk SCMI_CLK_NPU>;
assigned-clock-rates = <200000000>;
```

The initial rate is set to 200 MHz here, but the driver's `rk3568_noc_init()` immediately ramps it to 600 MHz then 1 GHz. Consider whether 200 MHz is the right boot-time default, or whether the `assigned-clock-rates` should match the target operational frequency.

**4. Otherwise clean**

The node structure (reg regions, clocks, resets, power domain, IOMMU reference) mirrors the RK3588 pattern appropriately. The `rockchip,pmu = <&pmu>` phandle is present as required by the driver.

---

---
Generated by Claude Code Patch Reviewer