From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 839A1C77B7C for ; Tue, 9 May 2023 21:20:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235866AbjEIVUY (ORCPT ); Tue, 9 May 2023 17:20:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37532 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235684AbjEIVTs (ORCPT ); Tue, 9 May 2023 17:19:48 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 93F6F3C0C; Tue, 9 May 2023 14:19:46 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 6DA10634CE; Tue, 9 May 2023 21:19:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5E650C4339E; Tue, 9 May 2023 21:19:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1683667185; bh=0RTxEfn9EcxVsSBor3zTW2+GS+h8rLAjauKZ+Wi9+qA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BgdDK5gy1PfQ6KbsGPnKSWenStceIWMF9aLq58KaHR4Wx0WRxXZqm1YlXASFO47Hd FlOma3IUAOxz6A3fA9elHEuScrPA4Vi6t1a3wX2K0PIyBxzsKet9vfXRCaL8McUpnP HmrWdj0KAPybsjMRvm/NyCpxXE5oPwYQZyxBg/4z0ftqkZ7baJwutFVE3F2Yon8e/y t9I6a9XjVo/I9jyiSAHKBxnDdp+8jEXgcjLc9T+aW03M/y9tfya7FfZEbHsy1fbh5C OMnNZA65KvBzN9BOKlz4o59ak+IZpYdI/t3iuF4cpAcxzAbdlnHxJtvyXstFcCroMp hyNsf2V0wY+Ag== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Tomas Krcka , Will Deacon , Sasha Levin , joro@8bytes.org, baolu.lu@linux.intel.com, robin.murphy@arm.com, jean-philippe@linaro.org, shameerali.kolothum.thodi@huawei.com, yangyicong@hisilicon.com, nicolinc@nvidia.com, linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev Subject: [PATCH AUTOSEL 6.3 11/18] iommu/arm-smmu-v3: Acknowledge pri/event queue overflow if any Date: Tue, 9 May 2023 17:19:19 -0400 Message-Id: <20230509211928.21010-11-sashal@kernel.org> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20230509211928.21010-1-sashal@kernel.org> References: <20230509211928.21010-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Tomas Krcka [ Upstream commit 67ea0b7ce41844eae7c10bb04dfe66a23318c224 ] When an overflow occurs in the PRI queue, the SMMU toggles the overflow flag in the PROD register. To exit the overflow condition, the PRI thread is supposed to acknowledge it by toggling this flag in the CONS register. Unacknowledged overflow causes the queue to stop adding anything new. Currently, the priq thread always writes the CONS register back to the SMMU after clearing the queue. The writeback is not necessary if the OVFLG in the PROD register has not been changed, no overflow has occured. This commit checks the difference of the overflow flag between CONS and PROD register. If it's different, toggles the OVACKFLG flag in the CONS register and write it to the SMMU. The situation is similar for the event queue. The acknowledge register is also toggled after clearing the event queue but never propagated to the hardware. This would only be done the next time when executing evtq thread. Unacknowledged event queue overflow doesn't affect the event queue, because the SMMU still adds elements to that queue when the overflow condition is active. But it feel nicer to keep SMMU in sync when possible, so use the same way here as well. Signed-off-by: Tomas Krcka Link: https://lore.kernel.org/r/20230329123420.34641-1-tomas.krcka@gmail.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin --- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 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 f2425b0f0cd62..7614739ea2c1b 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c @@ -152,6 +152,18 @@ static void queue_inc_cons(struct arm_smmu_ll_queue *q) q->cons = Q_OVF(q->cons) | Q_WRP(q, cons) | Q_IDX(q, cons); } +static void queue_sync_cons_ovf(struct arm_smmu_queue *q) +{ + struct arm_smmu_ll_queue *llq = &q->llq; + + if (likely(Q_OVF(llq->prod) == Q_OVF(llq->cons))) + return; + + llq->cons = Q_OVF(llq->prod) | Q_WRP(llq, llq->cons) | + Q_IDX(llq, llq->cons); + queue_sync_cons_out(q); +} + static int queue_sync_prod_in(struct arm_smmu_queue *q) { u32 prod; @@ -1577,8 +1589,7 @@ static irqreturn_t arm_smmu_evtq_thread(int irq, void *dev) } while (!queue_empty(llq)); /* Sync our overflow flag, as we believe we're up to speed */ - llq->cons = Q_OVF(llq->prod) | Q_WRP(llq, llq->cons) | - Q_IDX(llq, llq->cons); + queue_sync_cons_ovf(q); return IRQ_HANDLED; } @@ -1636,9 +1647,7 @@ static irqreturn_t arm_smmu_priq_thread(int irq, void *dev) } while (!queue_empty(llq)); /* Sync our overflow flag, as we believe we're up to speed */ - llq->cons = Q_OVF(llq->prod) | Q_WRP(llq, llq->cons) | - Q_IDX(llq, llq->cons); - queue_sync_cons_out(q); + queue_sync_cons_ovf(q); return IRQ_HANDLED; } -- 2.39.2