From: Pranjal Shrivastava <praan@google.com>
To: iommu@lists.linux.dev
Cc: Will Deacon <will@kernel.org>, Joerg Roedel <joro@8bytes.org>,
Robin Murphy <robin.murphy@arm.com>,
Jason Gunthorpe <jgg@ziepe.ca>,
Mostafa Saleh <smostafa@google.com>,
Nicolin Chen <nicolinc@nvidia.com>,
Daniel Mentz <danielmentz@google.com>,
Ashish Mhetre <amhetre@nvidia.com>,
linux-arm-kernel@lists.infradead.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
rafael@kernel.org, Danilo Krummrich <dakr@kernel.org>,
Thomas Gleixner <tglx@kernel.org>,
driver-core@lists.linux.dev,
Pranjal Shrivastava <praan@google.com>
Subject: [PATCH v10 03/15] iommu/arm-smmu-v3: Add arm_smmu_drain_queue() helper
Date: Tue, 8 Sep 2026 17:16:59 +0000 [thread overview]
Message-ID: <20260908171712.356645-4-praan@google.com> (raw)
In-Reply-To: <20260908171712.356645-1-praan@google.com>
From: Nicolin Chen <nicolinc@nvidia.com>
Add a counting-based arm_smmu_drain_queue() helper, to replace queue
specific polling loops. Its until_empty mode serves the suspend and
runtime PM routines that would drain the CMDQ. Any timed-out drain fires
a WARN_ON as well, since reaching the timeout would take some stuck
consumer in any realistic case.
The existing queue_poll() API is not reusable for such a drain: it is the
atomic busy-wait for the command issuing paths, and it assumes a hardware
consumer making progress. A drain caller is sleepable, in contrast, while
the EVTQ/PRIQ consumer is a threaded IRQ handler that needs the CPU: such
a busy wait would starve the handler throughout an entire timeout, whenever
the waiter and the handler shared one CPU on a non-preemptible kernel. So,
this new sleeping helper is marked with a might_sleep() as well, given that
an atomic-context misuse would otherwise hide behind an empty queue.
Note that a drained event is dequeued, but not necessarily handled, since
queue_remove_raw() moves the MMIO CONS before the threaded IRQ handler gets
to push the event onto the IOPF workqueue. A subsequent change will invoke
synchronize_irq() and iopf_queue_flush_dev() to close that gap, and it will
act on the errno of a timed-out drain too.
Assisted-by: Claude:claude-fable-5
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
Signed-off-by: Pranjal Shrivastava <praan@google.com>
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 81 +++++++++++++++++++++
1 file changed, 81 insertions(+)
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 06b7de2e6e4b..84b56849f6dc 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -948,6 +948,87 @@ static int arm_smmu_cmdq_batch_submit(struct arm_smmu_device *smmu,
cmds->num, true);
}
+/**
+ * arm_smmu_drain_queue - Drain an SMMU queue
+ * @smmu: the SMMU device
+ * @q: the queue to drain
+ * @until_empty: target selection
+ *
+ * With @until_empty == true (for CMDQ), exit once the queue is observed empty:
+ *
+ * cons0 cons prod
+ * | | |
+ * ---+###################+=====================+=============+--->
+ * |<--------- undrained==0? --------->|
+ *
+ * With @until_empty == false (for EVTQ/PRIQ), exit once "drained" reaches its
+ * target: "pending" (i.e. prod0 - cons0, frozen at the entry time):
+ *
+ * cons0 cons prod0 (prod)
+ * |<---- drained ---->| | |
+ * ---+###################+=====================+=============+--->
+ * |<--------------- pending --------------->|
+ *
+ * Note that a drained entry is dequeued, but not necessarily handled: the
+ * EVTQ/PRIQ callers must follow up with a synchronize_irq() to wait for the
+ * threaded IRQ handler to finish handling the dequeued entries.
+ *
+ * Context: Process context; may sleep.
+ * Return: 0 on success or a negative errno on timeout.
+ */
+static int __maybe_unused arm_smmu_drain_queue(struct arm_smmu_device *smmu,
+ struct arm_smmu_queue *q,
+ bool until_empty)
+{
+ ktime_t timeout = ktime_add_us(ktime_get(), ARM_SMMU_POLL_TIMEOUT_US);
+ u32 cons, prod, prev, undrained;
+ u32 drained = 0, pending;
+
+ might_sleep();
+
+ cons = readl_relaxed(q->cons_reg);
+ prod = readl_relaxed(q->prod_reg);
+ /* The exit target: the number of entries in the queue at entry */
+ pending = Q_POS(&q->llq, prod - cons);
+
+ while (true) {
+ /* Accumulate the entries consumed since the last poll */
+ prev = cons;
+ cons = readl_relaxed(q->cons_reg);
+ drained += Q_POS(&q->llq, cons - prev);
+
+ prod = readl_relaxed(q->prod_reg);
+ undrained = Q_POS(&q->llq, prod - cons);
+
+ /* Exit on an empty queue, regardless of until_empty */
+ if (!undrained)
+ return 0;
+
+ /* Snapshot mode: exit once the pending entries are drained */
+ if (!until_empty && drained >= pending)
+ return 0;
+
+ /*
+ * A timeout means the consumer might be stuck. In theory, if it
+ * moves 2 * qsize entries or more within a single poll interval
+ * Q_POS() would wrap and undercount drained: that could trigger
+ * a spurious warning too, if the queue was never once observed
+ * empty. Yet, that much consumption in such a short interval is
+ * unrealistic. WARN it only, as a stuck consumer is a real bug.
+ */
+ if (WARN_ON(ktime_compare(ktime_get(), timeout) > 0))
+ break;
+
+ /* The consumer might be a threaded IRQ handler. Yield to it */
+ usleep_range(100, 200);
+ }
+
+ dev_warn_ratelimited(smmu->dev,
+ "queue drain timed out at prod=0x%x cons=0x%x\n",
+ prod, cons);
+ return -ETIMEDOUT;
+}
+
static void arm_smmu_page_response(struct device *dev, struct iopf_fault *unused,
struct iommu_page_response *resp)
{
--
2.55.0.979.g7e5102b832-goog
next prev parent reply other threads:[~2026-09-08 17:17 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-08 17:16 [PATCH v10 00/15] iommu/arm-smmu-v3: Implement Runtime/System Sleep ops Pranjal Shrivastava
2026-09-08 17:16 ` [PATCH v10 01/15] iommu/arm-smmu-v3: Refactor arm_smmu_setup_irqs Pranjal Shrivastava
2026-09-08 17:16 ` [PATCH v10 02/15] iommu/arm-smmu-v3: Add Q_POS() macro Pranjal Shrivastava
2026-09-08 17:16 ` Pranjal Shrivastava [this message]
2026-09-08 17:17 ` [PATCH v10 04/15] iommu/tegra241-cmdqv: Add a helper to drain VCMDQs Pranjal Shrivastava
2026-09-08 17:17 ` [PATCH v10 05/15] iommu/arm-smmu-v3: Add a helper to drain cmd queues Pranjal Shrivastava
2026-09-08 17:17 ` [PATCH v10 06/15] iommu/tegra241-cmdqv: Restore PROD and CONS after resume Pranjal Shrivastava
2026-09-08 17:17 ` [PATCH v10 07/15] platform-msi: Introduce platform_device_msi_rewrite() Pranjal Shrivastava
2026-09-08 19:40 ` Thomas Gleixner
2026-09-08 20:15 ` Pranjal Shrivastava
2026-09-08 20:16 ` Pranjal Shrivastava
2026-09-09 9:20 ` Thomas Gleixner
2026-09-08 22:55 ` Jason Gunthorpe
2026-09-08 17:17 ` [PATCH v10 08/15] iommu/arm-smmu-v3: Cache and restore MSI config Pranjal Shrivastava
2026-09-08 19:56 ` Thomas Gleixner
2026-09-08 20:23 ` Pranjal Shrivastava
2026-09-08 17:17 ` [PATCH v10 09/15] iommu/arm-smmu-v3: Factor out arm_smmu_handle_gerror() Pranjal Shrivastava
2026-09-08 17:17 ` [PATCH v10 10/15] iommu/arm-smmu-v3: Add CMDQ_PROD_STOP_FLAG to gate CMDQ submissions Pranjal Shrivastava
2026-09-08 17:17 ` [PATCH v10 11/15] iommu/tegra241-cmdqv: Add a helper to quiesce VCMDQs Pranjal Shrivastava
2026-09-08 17:17 ` [PATCH v10 12/15] iommu/arm-smmu-v3: Implement pm_runtime & system sleep ops Pranjal Shrivastava
2026-09-08 17:17 ` [PATCH v10 13/15] iommu/arm-smmu-v3: Enable pm_runtime and setup devlinks Pranjal Shrivastava
2026-09-08 17:17 ` [PATCH v10 14/15] iommu/arm-smmu-v3: Invoke pm_runtime before hw access Pranjal Shrivastava
2026-09-08 17:17 ` [PATCH v10 15/15] iommu/arm-smmu-v3: Add KUnit unit tests for Runtime PM Pranjal Shrivastava
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=20260908171712.356645-4-praan@google.com \
--to=praan@google.com \
--cc=amhetre@nvidia.com \
--cc=dakr@kernel.org \
--cc=danielmentz@google.com \
--cc=driver-core@lists.linux.dev \
--cc=gregkh@linuxfoundation.org \
--cc=iommu@lists.linux.dev \
--cc=jgg@ziepe.ca \
--cc=joro@8bytes.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=nicolinc@nvidia.com \
--cc=rafael@kernel.org \
--cc=robin.murphy@arm.com \
--cc=smostafa@google.com \
--cc=tglx@kernel.org \
--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.