All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolin Chen <nicolinc@nvidia.com>
To: Will Deacon <will@kernel.org>
Cc: Ashish Mhetre <amhetre@nvidia.com>, <robin.murphy@arm.com>,
	<joro@8bytes.org>, <jgg@ziepe.ca>,
	<linux-arm-kernel@lists.infradead.org>, <iommu@lists.linux.dev>,
	<linux-kernel@vger.kernel.org>, <linux-tegra@vger.kernel.org>
Subject: Re: [PATCH v3 1/3] iommu/arm-smmu-v3: Factor out CMDQ batch force-sync conditions
Date: Tue, 2 Jun 2026 13:08:26 -0700	[thread overview]
Message-ID: <ah84OmisAm8805FT@Asurada-Nvidia> (raw)
In-Reply-To: <ah81HhVW7_h9xyDM@willie-the-truck>

On Tue, Jun 02, 2026 at 08:55:10PM +0100, Will Deacon wrote:
> On Mon, Jun 01, 2026 at 10:48:43AM +0000, Ashish Mhetre wrote:
> > From: Nicolin Chen <nicolinc@nvidia.com>
> > 
> > arm_smmu_cmdq_batch_add_cmd_p() carries two distinct reasons for
> > flushing the current batch with a CMD_SYNC before appending the
> > new command:
> > 
> >   - The batch's pre-assigned cmdq does not support the new command.
> >   - The Arm erratum 2812531 workaround (ARM_SMMU_OPT_CMDQ_FORCE_SYNC)
> >     forces a SYNC at one entry before the batch is full.
> > 
> > Lift those checks into a new arm_smmu_cmdq_batch_force_sync() helper
> > so that adding another force-sync condition becomes a one-line
> > addition. No functional change.
> > 
> > Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
> > Signed-off-by: Ashish Mhetre <amhetre@nvidia.com>
> > ---
> >  drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 26 ++++++++++++++++-----
> >  1 file changed, 20 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> > index 9be589d14a3b..4d29bd343460 100644
> > --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> > +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> > @@ -847,16 +847,30 @@ static void arm_smmu_cmdq_batch_init_cmd(struct arm_smmu_device *smmu,
> >  	cmds->cmdq = arm_smmu_get_cmdq(smmu, cmd);
> >  }
> >  
> > +static bool arm_smmu_cmdq_batch_force_sync(struct arm_smmu_device *smmu,
> > +					   struct arm_smmu_cmdq_batch *cmds,
> > +					   struct arm_smmu_cmd *cmd)
> > +{
> > +	if (!cmds->num)
> > +		return false;
> 
> This check seems new?

You are right. Maybe the commit message should have mentioned that
there is a slight behavior change to the unsupported_cmd path:

 - Before: if cmds->num = 0 && unsupported_cmd, it would issue an
           empty batch (one CMD_SYNC)
 - After : if cmds->num = 0, no issue on the empty batch

With that, I think it's good to have?

Thanks
Nicolin


  reply	other threads:[~2026-06-02 20:09 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-01 10:48 [PATCH v3 0/3] iommu/arm-smmu-v3: Tegra264 invalidation workaround Ashish Mhetre
2026-06-01 10:48 ` [PATCH v3 1/3] iommu/arm-smmu-v3: Factor out CMDQ batch force-sync conditions Ashish Mhetre
2026-06-02 19:55   ` Will Deacon
2026-06-02 20:08     ` Nicolin Chen [this message]
2026-06-02 20:23       ` Will Deacon
2026-06-01 10:48 ` [PATCH v3 2/3] iommu/arm-smmu-v3: Detect Tegra264 erratum Ashish Mhetre
2026-06-02 20:13   ` Will Deacon
2026-06-02 20:31     ` Nicolin Chen
2026-06-02 20:59       ` Will Deacon
2026-06-02 21:06         ` Nicolin Chen
2026-06-05 14:05     ` Ashish Mhetre
2026-06-05 14:10       ` Jason Gunthorpe
2026-06-01 10:48 ` [PATCH v3 3/3] iommu/arm-smmu-v3: Issue CFGI/TLBI twice on Tegra264 Ashish Mhetre
2026-06-01 18:37   ` Nicolin Chen
2026-06-02 20:22   ` Will Deacon
2026-06-02 20:35     ` Nicolin Chen
2026-06-03  0:59     ` Jason Gunthorpe
2026-06-03  1:01     ` Jason Gunthorpe
2026-06-03 11:33       ` Will Deacon
2026-06-05 14:41         ` Ashish Mhetre
2026-06-05 14:12     ` Ashish Mhetre
2026-06-02 16:31 ` [PATCH v3 0/3] iommu/arm-smmu-v3: Tegra264 invalidation workaround Mostafa Saleh
2026-06-02 18:23   ` Jason Gunthorpe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ah84OmisAm8805FT@Asurada-Nvidia \
    --to=nicolinc@nvidia.com \
    --cc=amhetre@nvidia.com \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@ziepe.ca \
    --cc=joro@8bytes.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.