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

[Pranjal Shrivastava <praan@google.com>]

On Sun, Jun 07, 2026 at 01:17:39PM -0700, Daniel Mentz wrote:
> On Thu, Jun 4, 2026 at 12:18 AM Pranjal Shrivastava <praan@google.com> wrote:
> >
> > On Wed, Jun 03, 2026 at 03:18:32PM -0700, Daniel Mentz wrote:
> > > On Thu, May 28, 2026 at 2:46 PM Pranjal Shrivastava <praan@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.
> > > > >
[..]
> > > 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().
> >
> > I saw some with DMA_FQ (fq_timer does batched async invalidations) but
> > the early ellision doesn't really help with perf which I agreed to in my
> > reply to Nicolin as well.
> >
> > The early checks were dropped in v8 (except for invs_array and for the
> > WARN_ON in inv_master).
> 
> Hi Pranjal,
> 
> Please correct me if I'm wrong, but in v8, I can see a call to
> arm_smmu_cmdq_can_elide() at the very beginning of
> arm_smmu_domain_inv_range(). Isn't this the path every iommu_unmap
> goes through?

That's correct. In v7 there were 4-5 callsites for these checks, most of
which were dropped. This one (for invs array) was retained in v8 based on
this discussion with Nicolin [1].

Thanks,
Praan

https://lore.kernel.org/all/ahjNYqe8hjPUQIQD@Asurada-Nvidia/