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

[Diederik de Haas]

On Fri Aug 7, 2026 at 2:55 PM CEST, Robin Murphy wrote:
> On 07/08/2026 9:48 am, Diederik de Haas wrote:
>> On Thu Aug 6, 2026 at 8:34 AM CEST, Jiaxing Hu wrote:
>>> 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.