[PATCH v9 09/12] iommu/arm-smmu-v3: Implement pm_runtime & system sleep ops

[Pranjal Shrivastava]

On Tue, Aug 25, 2026 at 05:17:01PM -0300, Jason Gunthorpe wrote:
> On Tue, Aug 25, 2026 at 06:53:59PM +0000, Pranjal Shrivastava wrote:
> 
> > > I agree.. I think there are only two options?
> > >  1) After GBPA=Abort ATS requests are blocked, so you could full
> > >     invalidate all the device ATC's and now it is safe to ignore
> > >     ATC_INV
> > >  2) Just don't perform suspend once ATS is activated
> > 
> > This is a little tricky, I'm leaning towards 1) since edge devices can
> > have ATS enabled
> 
> Oh really? Surprising..
> 
> > However, the EP might've entered it's low power state by the time we 
> > reach smmu's suspend. I'm not sure if we should be waking up the EP for
> > ATC INV All (or if it would even wake up in such a case?)
> 
> Is its power down explicit? Could the PM stuff trigger wiping the ATC
> and blocking DMA for a single device before allowing it to power down?
> 

The power down is explicit, due to devlinks, the PCIe driver's suspend
op (runtime / system) is called before the SMMU's suspend. I'm relying
on PCIe driver's op to clear ATC and everything else before powering down 

Basically, what I mean is it should be the PCIe device's responsibility
to clear ATC in this case because by the time we come to IOMMU's
suspend, the PCIe device would be powered down anyway and I'm not sure
if issuing an ATS INV request TLP would wake up the endpoint.

IIUC, if the link is in L1 / L2 then TLP tranmission is disabled, and to
bring it back to L0 we might have to call into the PCIe subsystem
*somehow*.

One thing we can do is shout in the dmesg with a dev_warn if rpm & ATS
both are enabled saying the PCIe driver is responsible for clearing out
it's ATC during suspend since SMMU's suspend runs after the dev is down.

Thanks,
Praan