Re: [RFC PATCH v6 7/9] accel/rocket: add RK3576 NPU (RKNN) support

On Fri Aug 7, 2026 at 2:55 PM CEST, Robin Murphy wrote:

On 07/08/2026 9:48 am, Diederik de Haas wrote:

quoted

On Thu Aug 6, 2026 at 8:34 AM CEST, Jiaxing Hu wrote:

quoted

The RK3576 has two cores of the same RKNN block and a few platform
differences:

  - the CBUF (convolution buffer) has its own clock domain, so the core
    needs six clocks rather than four;
  - the BIU reset moved into the power domain, leaving one reset here;
  - the NPU spans two power domains, and a device with more than one is
    skipped by the driver-core single-domain auto-attach, so the list has
    to be attached explicitly;
  - the DPU completion interrupt is armed exactly as on RK3588 but never
    reaches the GIC. The completion is visible in INTERRUPT_RAW_STATUS,

I don't know if it's relevant, so just a data point:
- RK3588 has Cortex A-76 + A-55, which have an External GICv4
- RK3576 has Cortex A-72 + A-53, which have an External GICv3

Nope, RK3588 has GIC-600, which is very much v3 still. I guess RK3576 
probably has GIC-500 like RK3399 given the CPUs, but that shouldn't make 
any meaningful difference here.

Unsurprisingly, you're (almost) correct :)
I looked at this document when I wrote that:
https://www.arm.com/-/media/Arm%20Developer%20Community/PDF/Cortex-A%20R%20M%20datasheets/Arm%20Cortex-A%20Comparison%20Table_v4.pdf

But the RK3588 TRM Part 1 Chapter 11 'GIC600' says:
"The GIC600 supports the GICv3 architecture ..."
"The version of GIC600 is r1p6-00rel0."

The RK3576 TRM Part 1 Chapter 13 'Generic Interrupt Controller (GIC)' says:
"There is a generic interrupt controller (GIC400) in RK3576 which generates
physical interrupts to Cortex-A53/Cortex-A72."

And RK3399 TRM Part 1 Chapter 11 'Generic Interrupt Controller (GIC)' says:
"The GIC-500 in RK3399 provides registers for managing interrupt sources,
interrupt behavior, and interrupt routing to one or more cores."

Cheers,
  Diederik

If the interrupt never fires at all then possibly the signal depends on 
some additional clock or power domain in order to propagate, or it's 
just described incorrectly; or if other interrupt sources within the 
NPU/IOMMU do still work then maybe there's some additional masking 
control that's been overlooked, or perhaps it it just terminally broken.

(And FWIW I'm also inclined to agree with the other comments that 
refactoring existing code to make room for new stuff, then actually 
adding the new stuff, should probably be two separate steps if it's not 
completely trivial)

Thanks,
Robin.