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

[Jason Gunthorpe <jgg@nvidia.com>]

On Wed, Aug 26, 2026 at 11:51:47AM +0000, Pranjal Shrivastava wrote:
> 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 

So maybe everything is OK and it just need some commenting to define
this split up?

IIRC there is a PCI spec thing that says the ATC is cleared on certain
config cycles?

Jason