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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 94DA9CD1284 for ; Thu, 28 Mar 2024 15:01:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=3Gyq2qRoP118/YBpwABae71Oj+ET2y3QUYGMCKbYwaA=; b=qq8nc0xPn0+X2H e6smbm5M9jJkG3P4j7oRpYRuv28N5ZIqaaQREs4BJXlJtyomf4p7RfMprvevC5BJSt1gLuTsLqOHA nAoqxerlgBK192O54fF5poWXw1rd6en7SMRqzKGcYBkMMabO10ihBgKpgtnBlzncMv+xU5jwR5uSG 9IBcU2gENZjRUVC5b5gRBiqESlbM91dP+33A3PKFQW6+ukW9khL9+LxkwpFPhe6E/iZYCKFx+u6uR 7wQ20cf1gBJtJDXUvPjv5j4UX9/eKRKNTJQoEWF5u4f43vlYfF/BXSnSYSADT7ADWfbqj8ZEenLED YHmYLO5jtY1ywdBUzFNg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rprFE-0000000EQum-46l4; Thu, 28 Mar 2024 15:00:44 +0000 Received: from out-188.mta1.migadu.com ([2001:41d0:203:375::bc]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rprF7-0000000EQnW-0jNo for linux-arm-kernel@lists.infradead.org; Thu, 28 Mar 2024 15:00:39 +0000 Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1711638028; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vnqQ84/rMjC+/rcGQR2+/HXsL+AxeYk9jECNf55kBHU=; b=pSI293ziwMZM/xh2IUz27+6/EZ2rERRrKJz2IlDn3Ql42kY6xoKt0zIee6GNFz3GAUN66I vh1yg2NdG+pSoEk3BktZGUQE+cNSoB2L5EsSOV5xH6Tz4jIXj1Cby7JYJHB+6R+G0cJaHh wk2zMItRX3y+JW8JpXDmSxILAzEWIIk= Date: Thu, 28 Mar 2024 11:00:24 -0400 MIME-Version: 1.0 Subject: Re: [PATCH 2/3] dma: xilinx_dpdma: Remove unnecessary use of irqsave/restore Content-Language: en-US To: Tomi Valkeinen Cc: Michal Simek , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Laurent Pinchart , Vinod Koul , dmaengine@vger.kernel.org References: <20240308210034.3634938-1-sean.anderson@linux.dev> <20240308210034.3634938-3-sean.anderson@linux.dev> <0652c82f-b0a2-4881-ac51-38399b180ad4@ideasonboard.com> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Sean Anderson In-Reply-To: <0652c82f-b0a2-4881-ac51-38399b180ad4@ideasonboard.com> X-Migadu-Flow: FLOW_OUT X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240328_080038_038782_F2683D5C X-CRM114-Status: GOOD ( 18.51 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 3/27/24 08:27, Tomi Valkeinen wrote: > Hi, > > On 08/03/2024 23:00, Sean Anderson wrote: >> xilinx_dpdma_chan_done_irq and xilinx_dpdma_chan_vsync_irq are always >> called with IRQs disabled from xilinx_dpdma_irq_handler. Therefore we >> don't need to save/restore the IRQ flags. > > I think this is fine, but a few thoughts: > > - Is spin_lock clearly faster than the irqsave variant, or is this a pointless optimization? It's safer to just use irqsave variant, instead of making sure the code is always called from the expected contexts. It's not an optimization. Technically this will save a few instructions, but... > - Is this style documented/recommended anywhere? Going through docs, I only found docs telling to use irqsave when mixing irq and non-irq contexts. The purpose is mainly to make it clear that this is meant to be called in IRQ context. With irqsave, there's an implication that this could be called in non-IRQ context, which it never is. > - Does this cause issues on PREEMPT_RT? Why would it? --Sean > > Tomi > >> Signed-off-by: Sean Anderson >> --- >> >> drivers/dma/xilinx/xilinx_dpdma.c | 10 ++++------ >> 1 file changed, 4 insertions(+), 6 deletions(-) >> >> diff --git a/drivers/dma/xilinx/xilinx_dpdma.c b/drivers/dma/xilinx/xilinx_dpdma.c >> index eb0637d90342..36bd4825d389 100644 >> --- a/drivers/dma/xilinx/xilinx_dpdma.c >> +++ b/drivers/dma/xilinx/xilinx_dpdma.c >> @@ -1043,9 +1043,8 @@ static int xilinx_dpdma_chan_stop(struct xilinx_dpdma_chan *chan) >> static void xilinx_dpdma_chan_done_irq(struct xilinx_dpdma_chan *chan) >> { >> struct xilinx_dpdma_tx_desc *active; >> - unsigned long flags; >> - spin_lock_irqsave(&chan->lock, flags); >> + spin_lock(&chan->lock); >> xilinx_dpdma_debugfs_desc_done_irq(chan); >> @@ -1057,7 +1056,7 @@ static void xilinx_dpdma_chan_done_irq(struct xilinx_dpdma_chan *chan) >> "chan%u: DONE IRQ with no active descriptor!\n", >> chan->id); >> - spin_unlock_irqrestore(&chan->lock, flags); >> + spin_unlock(&chan->lock); >> } >> /** >> @@ -1072,10 +1071,9 @@ static void xilinx_dpdma_chan_vsync_irq(struct xilinx_dpdma_chan *chan) >> { >> struct xilinx_dpdma_tx_desc *pending; >> struct xilinx_dpdma_sw_desc *sw_desc; >> - unsigned long flags; >> u32 desc_id; >> - spin_lock_irqsave(&chan->lock, flags); >> + spin_lock(&chan->lock); >> pending = chan->desc.pending; >> if (!chan->running || !pending) >> @@ -1108,7 +1106,7 @@ static void xilinx_dpdma_chan_vsync_irq(struct xilinx_dpdma_chan *chan) >> spin_unlock(&chan->vchan.lock); >> out: >> - spin_unlock_irqrestore(&chan->lock, flags); >> + spin_unlock(&chan->lock); >> } >> /** > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel