[PATCH v7 10/11] iommu/arm-smmu-v3: Invoke pm_runtime before hw access

[Daniel Mentz]

On Thu, May 28, 2026 at 2:46 PM Pranjal Shrivastava <praan at google.com> wrote:
>
> On Thu, May 28, 2026 at 01:28:15PM -0700, Nicolin Chen wrote:
> > On Wed, May 27, 2026 at 10:14:06PM +0000, Pranjal Shrivastava wrote:
> > > TLB and CFG invalidations are
> > > elided if the SMMU is suspended by observing the CMDQ_PROD_STOP_FLAG via
> > > the arm_smmu_can_elide() helper.
> >
> > All the arm_smmu_can_elide() call sites here would eventually elide
> > the commands in arm_smmu_cmdq_issue_cmdlist() that is already gated
> > by CMDQ_PROD_STOP_FLAG? It doesn't seem necessary to gate again?
>
> While issue_cmdlist() would eventually elide these commands, the
> can_elide() check is necessary to return early during suspension.
>
> This avoids unnecessary stack allocation, cmd building, and spinlock
> contention on the cmdq->lock for threads that are anyway about to be
> elided.
>
> By dropping these requests immediately, we significantly reduce cacheline
> bouncing and contention during unmap storms. Furthermore, the early check
> also allows us to specifically trigger the WARN_ON_ONCE() for broken
> devlinks.

Hi Pranjal,

Have you observed unmap storms in a real-world use case, or is this a
preemptive optimization? I would not expect a high rate of map/unmap
operations while the SMMU is suspended. If a client device calls
iommu_map/iommu_unmap (directly or indirectly), it suggests the client
device is RPM_ACTIVE, meaning the SMMU should be active as well.

I am in favor of removing arm_smmu_can_elide().