[PATCH v9 09/12] iommu/arm-smmu-v3: Implement pm_runtime & system sleep ops
Pranjal Shrivastava
praan at google.com
Wed Aug 26 07:17:42 PDT 2026
On Wed, Aug 26, 2026 at 10:47:57AM -0300, Jason Gunthorpe wrote:
> 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?
>
Yes, we can add a comment and a small dev_warn when ATS is enabled with
rpm clearly mentioning the reason for any unwanted aliasing (if observed)
> IIRC there is a PCI spec thing that says the ATC is cleared on certain
> config cycles?
>
Yes, IRC, D3Cold would clear everything anyway, and D3Hot -> D0 with
soft-reset also lands in uninitialized. I'd have to check for D3Hot ->
D0 without soft-reset. However, for this discussion I think we agree
hhat it's not the IOMMU's responsibility to handle the PCIe ATC state.
Thanks,
Praan
More information about the linux-arm-kernel
mailing list