Re: [PATCH v3 2/3] iommu/arm-smmu-v3: Detect Tegra264 erratum

[Nicolin Chen <nicolinc@nvidia.com>]

On Tue, Jun 02, 2026 at 09:59:39PM +0100, Will Deacon wrote:
> On Tue, Jun 02, 2026 at 01:31:58PM -0700, Nicolin Chen wrote:
> > On Tue, Jun 02, 2026 at 09:13:39PM +0100, Will Deacon wrote:
> > > On Mon, Jun 01, 2026 at 10:48:44AM +0000, Ashish Mhetre wrote:
> > > > Tegra264 SMMU is affected by erratum where a TLB entry can survive an
> > > > invalidation that races with concurrent traffic targeting the same
> > > > entry. The hardware-recommended software workaround is to issue every
> > > > CFGI/TLBI command (each followed by CMD_SYNC) twice. The second issue
> > > > is guaranteed to evict the entry. ATC_INV is not affected and must not
> > > > be doubled.
> > > > 
> > > > The erratum is not flagged by any SMMUv3 IDR/IIDR register, so it
> > > > cannot be detected from hardware ID. Tegra264 boots from device tree
> > > > only and has no ACPI/IORT support, so detection is through device
> > > > tree only.
> > > 
> > > That seems odd to me -- whether the hardware has the erratum is
> > > completely unrelated to whether it probes using DT or ACPI, so I find it
> > > really weird to have the workaround enabled when booting with DT and not
> > > when booting with ACPI. We should have consistent behaviour between the
> > > two.
> > 
> > That's a good point. Yet, for ACPI to detect the erratum, we would
> > need a new IORT model or flag, right? That would need to go through
> > the entire ACPI protocol to update SMMU's IORT spec and the header
> > accordingly, which we don't have a use case to do so or to test it.
> > 
> > What would you like us to do here for the consistency?
> 
> Gah, I now realise I've mixed up Tegra264 and Tegra241 because
> tegra_cmdqv_dt_probe() is only called if the compatible string matches
> "nvidia,tegra264-smmu" yet all the cmdqv stuff talks only about
> Tegra241. So I was surprised that the ACPI probing code for Tegra241
> wasn't enabling the workaround.

I see. Numbers could be indeed confusing :)

> But if you're saying that:
> 
> 1. Tegra264 never uses ACPI
> 2. Tegra241 doesn't have the invalidation erratum

Yes.

> Then I'm less worried (even though it's a shame that we can't detect
> the erratum from the hardware itself).

Agreed, though I think the compatible string is already a life
saver as we wouldn't need to go through the whole ACPI route..

Nicolin