From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 55F083191D6; Fri, 7 Aug 2026 14:24:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786112679; cv=none; b=AKTtXtSzcQjf8lA7y0TXeHimPsul8h11Ox7b5qucNWcKCvrDW0DQlxglbzsqHiHz+Hn1sBrVEORO116H1i66c+ZPt+dfezeYz0urp8sdPKcFd8W196Xi28OGanvBu2ZpSXyXkkGNJSjSwZLd9MMtwsqMWo9P/fDa/T0mloRTEnU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786112679; c=relaxed/simple; bh=bjWAifFxgtUCdE82wAQsbJm5us80D5W3SDsxqOZvTLk=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=MVvQKSYknYrDFBLV7jcsqZ805TiInkt2iWKKfV2RNuDX3PXUC5+I1dH+SH8wURSDgCunJdT0pj37QDdJsf7k6aSpT6e0tgZfhmbXGwI8+3eywy0+cXDe3Sk+K23zQ28YsxVKB5XId7PMMmoSv7qSANs+3LsgoTRkz5NZKaOgrX0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=fqv7xemQ; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="fqv7xemQ" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 8E5681BCA; Fri, 7 Aug 2026 07:24:33 -0700 (PDT) Received: from [10.2.212.23] (e121345-lin.cambridge.arm.com [10.2.212.23]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 968CD3F9A2; Fri, 7 Aug 2026 07:24:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1786112677; bh=bjWAifFxgtUCdE82wAQsbJm5us80D5W3SDsxqOZvTLk=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=fqv7xemQXZNRzwDmanQKRIX//hiRV55JHD/WtmdOucJL18W+Ow6vQUW2O/z5m3ITW zD+IcEt+Oc71EROtAEMUNkOegbtod7cvwWo/Ir3jKcoybAd3wyDANa7bMhUxrUN0dg qBLDpY4RMr/RODVycbR4HtbqXI1pe2UJguxWQS28= Message-ID: Date: Fri, 7 Aug 2026 15:24:33 +0100 Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v6 7/9] accel/rocket: add RK3576 NPU (RKNN) support To: Diederik de Haas , Jiaxing Hu , tomeu@tomeuvizoso.net, heiko@sntech.de, robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org, joro@8bytes.org, will@kernel.org, ulfh@kernel.org, p.zabel@pengutronix.de, ogabbay@kernel.org, zhangqing@rock-chips.com Cc: royalnet026@gmail.com, alchark@flipper.net, chaoyi.chen@rock-chips.com, dri-devel@lists.freedesktop.org, linux-rockchip@lists.infradead.org, iommu@lists.linux.dev, linux-pm@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <20260806063413.350184-1-gahing@gahingwoo.com> <20260806063413.350184-8-gahing@gahingwoo.com> From: Robin Murphy Content-Language: en-GB In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 07/08/2026 2:32 pm, Diederik de Haas wrote: > 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 Ah, that list is effectively describing the *maximum* capabilities of the v8 cores' respective GIC-CPU interface implementations. It's really just saying that cores which predate GICv4 don't implement the additional system registers relevant to direct injection (and of course the v7 cores which predate GICv3 don't have a system register interface at all). > 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." Oh wow, indeed perhaps I should have just looked at the upstream DT :) Going back to GICv2 seems like a mildly surprising choice at this point in time, but fair enough, sometimes power/area costs beat performance. My point still remains valid that the GIC implementation itself should have no impact on the behaviour of SPIs that are correctly described in the DT. Cheers, Robin. > 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.