Message ID | 20221108074938.48853-1-andriy.shevchenko@linux.intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp2554619wru; Tue, 8 Nov 2022 00:08:00 -0800 (PST) X-Google-Smtp-Source: AMsMyM7SPTqtWUkSXP3h1SQGyRm7+mzxjU3sslPOUqs/BkNT+0hRvF0LVa+iio/tZO+ywmhI6/T6 X-Received: by 2002:a05:6402:4d9:b0:462:e787:3bf8 with SMTP id n25-20020a05640204d900b00462e7873bf8mr54400534edw.195.1667894880570; Tue, 08 Nov 2022 00:08:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1667894880; cv=none; d=google.com; s=arc-20160816; b=MAqKB1JwEImi6dNh+sQVM7sgj/IOZrkY+8G6Oj3k4Aj0PFoP83OY3Ph9zjU5OxoqxA yiy85RO2j4KvwfEQ49diGGxdApGQaSOUAXsAHdo3FYblr39t+bsBLm6jFvWEvu+QK+SZ dVP6bCPXw7pIvfUnQ32xvqaggoYRdoAjMb0PprY0mg4xoGfQ4PDtmPWztIj/9NB3wp4+ m8O7mIvK8geUFXP2pGBFO90eOU6vlzRBAOqhDu/xYQZLLs4QLFKf3tL2WXEkPk6piG60 3kj4iBOQD61dI1LqK2zwTnjLnKIsL7DYE8uhsckTCL29S2m6rhFIfVaqfrhysYt2Ex75 LRDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=YflkZhwKYCrnTSr9NNBORMBmxzajY8AMnsGOgMqhBAc=; b=ETnfBpXbNmBuEFS3TsKHLb2/0ov/CZLKcaGI8aEkBWHApHDg8YanTqC9RZEvMWEudL uCbTgV8njnuwUP6rUnMLMIN8roN2ID2uXqSfoWkLNcaFh9igCaNZpr1AbesuYUAXq2Fs Yqj5pxFIxx/TPdQ47pjQnImQ2PfWfdYTSZ1LPbzxsZzjAiyjMYodElSTm4/vNtP+Ygb9 KVyPCzY2ugmQWPYVLp7XHs77ujlmTmWzwX8k9NDCd1QdonSuhOzo4vPwfl90iiTtIG0r zgGm7CjlW0VtvT456CYENNvbLbDNaR9qXg3Y+fE7z+ouJt+rK3VJT5dDQGseHjoCIoQm 4fEA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Imdug1vo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g16-20020a1709065d1000b00790058488dcsi5637079ejt.48.2022.11.08.00.07.37; Tue, 08 Nov 2022 00:08:00 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Imdug1vo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233663AbiKHHtY (ORCPT <rfc822;hjfbswb@gmail.com> + 99 others); Tue, 8 Nov 2022 02:49:24 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53384 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233301AbiKHHtW (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 8 Nov 2022 02:49:22 -0500 Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DD6BB13D2E; Mon, 7 Nov 2022 23:49:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1667893761; x=1699429761; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=4dh3IRHYQd4HH6cn+7mT19zqVvTBD88fHDivkBet2uM=; b=Imdug1vo9Jjmv1Jp2a+lwGzXlQsPKsQ4ulmFIUl4YtJaLrZcFiTMkUx+ LX9ZU7eJ7cLI2g7MSSMFeDLqoscts3Puow/zUu90tWYSVgvjD1h8rcfdl fMJXAZovkg3e+MNuvH7AtufU3gbzCDIC7ipVs4uLLHFONgajjhljrAb12 0XQRQJfCu05oDHZ8nr0FlW9ItKccxiGbDMQRlrhTxrsEjO2zykbqas6RO E5QO2nug5eNGWZ25WHU/jUCcmhZP480vAlzBIsBk1JBokjKJMfEAoTyYj mogEUHURaoBijKkmoN294LR2iLR2kORfoKPWNoXsDbryR/tvPDiMd1acE A==; X-IronPort-AV: E=McAfee;i="6500,9779,10524"; a="310630781" X-IronPort-AV: E=Sophos;i="5.96,147,1665471600"; d="scan'208";a="310630781" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Nov 2022 23:49:21 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10524"; a="881423689" X-IronPort-AV: E=Sophos;i="5.96,147,1665471600"; d="scan'208";a="881423689" Received: from black.fi.intel.com ([10.237.72.28]) by fmsmga006.fm.intel.com with ESMTP; 07 Nov 2022 23:49:19 -0800 Received: by black.fi.intel.com (Postfix, from userid 1003) id 4E12DF7; Tue, 8 Nov 2022 09:49:43 +0200 (EET) From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> To: Vinod Koul <vkoul@kernel.org>, Tudor Ambarus <tudor.ambarus@microchip.com>, Nicolas Ferre <nicolas.ferre@microchip.com>, linux-arm-kernel@lists.infradead.org, dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Ludovic Desroches <ludovic.desroches@microchip.com>, Andy Shevchenko <andriy.shevchenko@linux.intel.com> Subject: [PATCH v1 1/2] at_hdmac: check and return DMA_PAUSED status when suitable Date: Tue, 8 Nov 2022 09:49:37 +0200 Message-Id: <20221108074938.48853-1-andriy.shevchenko@linux.intel.com> X-Mailer: git-send-email 2.35.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_HI,SPF_HELO_NONE, SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1748914542055966781?= X-GMAIL-MSGID: =?utf-8?q?1748914542055966781?= |
Series |
[v1,1/2] at_hdmac: check and return DMA_PAUSED status when suitable
|
|
Commit Message
Andy Shevchenko
Nov. 8, 2022, 7:49 a.m. UTC
device_tx_status() may return DMA_PAUSED status when driver supports it.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/dma/at_hdmac.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
Comments
Hi, Andy, On 11/8/22 09:49, Andy Shevchenko wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > device_tx_status() may return DMA_PAUSED status when driver supports it. Yeah, but you haven't described the why. And that's because dma_cookie_status() currently considers just DMA_COMPLETE and DMA_IN_PROGRESS for the status of the cookie, so the controller drivers are forced to query the DMA_PAUSED state themselves. Also, I noticed that Vinod prefers that you use the full paragraph in the commit message, and not a continuation of the patch title, so you may want to reword the commit message. > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > --- > drivers/dma/at_hdmac.c | 15 ++++++++++++++- > 1 file changed, 14 insertions(+), 1 deletion(-) > > diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c > index 8858470246e1..a9d8dd990d6e 100644 > --- a/drivers/dma/at_hdmac.c > +++ b/drivers/dma/at_hdmac.c > @@ -1669,9 +1669,19 @@ atc_tx_status(struct dma_chan *chan, > int ret; > > dma_status = dma_cookie_status(chan, cookie, txstate); > - if (dma_status == DMA_COMPLETE || !txstate) > + if (dma_status == DMA_COMPLETE) > return dma_status; > > + /* > + * There's no point in calculating the residue if there's > + * no txstate to store the value. > + */ > + if (!txstate) { > + if (test_bit(ATC_IS_PAUSED, &atchan->status)) there's a helper function that you can use instead: atc_chan_is_paused() > + return DMA_PAUSED; > + return DMA_ERROR; return dma_status please > + } > + > spin_lock_irqsave(&atchan->vc.lock, flags); > /* Get number of bytes left in the active transactions */ > ret = atc_get_residue(chan, cookie, &residue); > @@ -1684,6 +1694,9 @@ atc_tx_status(struct dma_chan *chan, > dma_set_residue(txstate, residue); > } > > + if (test_bit(ATC_IS_PAUSED, &atchan->status)) The status may change after spin_unlock_irqrestore(). Should the residue be in sync with the dma status? If yes, you should check the status while holding the lock. > + dma_status = DMA_PAUSED; > + > dev_vdbg(chan2dev(chan), "tx_status %d: cookie = %d residue = %u\n", > dma_status, cookie, residue); > > -- > 2.35.1 > -- Cheers, ta
On Tue, Nov 08, 2022 at 11:50:19AM +0000, Tudor.Ambarus@microchip.com wrote: > On 11/8/22 09:49, Andy Shevchenko wrote: > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > > > device_tx_status() may return DMA_PAUSED status when driver supports it. > > Yeah, but you haven't described the why. And that's because dma_cookie_status() > currently considers just DMA_COMPLETE and DMA_IN_PROGRESS for the status of the > cookie, so the controller drivers are forced to query the DMA_PAUSED state > themselves. At last without this change it's inconvenient and requires a lot of additional (unneeded) code to be written by the caller. Moreover, it's racy. If you query status twice in a raw, it may be well changed (for example from PAUSED to IN_PROGRESS or COMPETE). I will add a word summarizing this. > Also, I noticed that Vinod prefers that you use the full paragraph in the commit > message, and not a continuation of the patch title, so you may want to reword > the commit message. Yes, I will fix that. ... > > + if (!txstate) { > > + if (test_bit(ATC_IS_PAUSED, &atchan->status)) > > there's a helper function that you can use instead: atc_chan_is_paused() Will use it. > > + return DMA_PAUSED; > > + return DMA_ERROR; > > return dma_status please Will squash the patch. > > + } ... > > + if (test_bit(ATC_IS_PAUSED, &atchan->status)) > > The status may change after spin_unlock_irqrestore(). Should the residue > be in sync with the dma status? If yes, you should check the status while > holding the lock. You should tell me actually. Because I'm a bit puzzled why we need a spin lock _and_ atomic bit operations together. > > + dma_status = DMA_PAUSED; ... Thank you for the review.
diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c index 8858470246e1..a9d8dd990d6e 100644 --- a/drivers/dma/at_hdmac.c +++ b/drivers/dma/at_hdmac.c @@ -1669,9 +1669,19 @@ atc_tx_status(struct dma_chan *chan, int ret; dma_status = dma_cookie_status(chan, cookie, txstate); - if (dma_status == DMA_COMPLETE || !txstate) + if (dma_status == DMA_COMPLETE) return dma_status; + /* + * There's no point in calculating the residue if there's + * no txstate to store the value. + */ + if (!txstate) { + if (test_bit(ATC_IS_PAUSED, &atchan->status)) + return DMA_PAUSED; + return DMA_ERROR; + } + spin_lock_irqsave(&atchan->vc.lock, flags); /* Get number of bytes left in the active transactions */ ret = atc_get_residue(chan, cookie, &residue); @@ -1684,6 +1694,9 @@ atc_tx_status(struct dma_chan *chan, dma_set_residue(txstate, residue); } + if (test_bit(ATC_IS_PAUSED, &atchan->status)) + dma_status = DMA_PAUSED; + dev_vdbg(chan2dev(chan), "tx_status %d: cookie = %d residue = %u\n", dma_status, cookie, residue);