dmaengine.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vinod Koul <vkoul@kernel.org>
To: Green Wan <green.wan@sifive.com>
Cc: linux-hackers@sifive.com, Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Palmer Dabbelt <palmer@sifive.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Dan Williams <dan.j.williams@intel.com>,
	Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jonathan Cameron <Jonathan.Cameron@huawei.com>,
	"Paul E. McKenney" <paulmck@linux.ibm.com>,
	Bin Meng <bmeng.cn@gmail.com>, Yash Shah <yash.shah@sifive.com>,
	Sagar Kadam <sagar.kadam@sifive.com>,
	dmaengine@vger.kernel.org, devicetree@vger.kernel.org,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 3/4] dmaengine: sf-pdma: add platform DMA support for HiFive Unleashed A00
Date: Sun, 20 Oct 2019 19:29:52 +0530	[thread overview]
Message-ID: <20191020135952.GU2654@vkoul-mobl> (raw)
In-Reply-To: <20191003090945.29210-4-green.wan@sifive.com>

On 03-10-19, 17:09, Green Wan wrote:

> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> index 7af874b69ffb..03dc82094857 100644
> --- a/drivers/dma/Kconfig
> +++ b/drivers/dma/Kconfig
> @@ -661,6 +661,8 @@ source "drivers/dma/qcom/Kconfig"
>  
>  source "drivers/dma/dw/Kconfig"
>  
> +source "drivers/dma/sf-pdma/Kconfig"

Please keep this in sorted order

> +
>  source "drivers/dma/dw-edma/Kconfig"
>  
>  source "drivers/dma/hsu/Kconfig"
> diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
> index f5ce8665e944..4bbd90563ede 100644
> --- a/drivers/dma/Makefile
> +++ b/drivers/dma/Makefile
> @@ -28,6 +28,7 @@ obj-$(CONFIG_DMA_SUN4I) += sun4i-dma.o
>  obj-$(CONFIG_DMA_SUN6I) += sun6i-dma.o
>  obj-$(CONFIG_DW_AXI_DMAC) += dw-axi-dmac/
>  obj-$(CONFIG_DW_DMAC_CORE) += dw/
> +obj-$(CONFIG_SF_PDMA) += sf-pdma/

here as well!

>  obj-$(CONFIG_DW_EDMA) += dw-edma/
>  obj-$(CONFIG_EP93XX_DMA) += ep93xx_dma.o
>  obj-$(CONFIG_FSL_DMA) += fsldma.o
> diff --git a/drivers/dma/sf-pdma/Kconfig b/drivers/dma/sf-pdma/Kconfig
> new file mode 100644
> index 000000000000..0e01a5728a79
> --- /dev/null
> +++ b/drivers/dma/sf-pdma/Kconfig
> @@ -0,0 +1,6 @@
> +config SF_PDMA
> +	bool "Sifive PDMA controller driver"

why not a module?

> +#include <linux/module.h>
> +#include <linux/device.h>
> +#include <linux/kernel.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/dmaengine.h>
> +#include <linux/err.h>
> +#include <linux/interrupt.h>
> +#include <linux/dma-mapping.h>
> +#include <linux/irq.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_dma.h>

do you need all the headers?

> +#include <linux/time64.h>

why is this required?

> +
> +#include "sf-pdma.h"
> +#include "../dmaengine.h"
> +#include "../virt-dma.h"
> +
> +#define SIFIVE_PDMA_NAME "sf-pdma"

this is used only once! can you use it directly to help readability!

> +
> +#ifndef readq
> +static inline unsigned long long readq(void __iomem *addr)
> +{
> +	return readl(addr) | (((unsigned long long)readl(addr + 4)) << 32LL);
> +}
> +#endif
> +
> +#ifndef writeq
> +static inline void writeq(unsigned long long v, void __iomem *addr)
> +{
> +	writel(v & 0xffffffff, addr);
> +	writel(v >> 32, addr + 4);

why not use upper/lower_32_bits?

> +static void sf_pdma_fill_desc(struct sf_pdma_chan *chan,
> +			      u64 dst,
> +			      u64 src,
> +			      u64 size)

these can fit in a line!

> +struct dma_async_tx_descriptor *
> +	sf_pdma_prep_dma_memcpy(struct dma_chan *dchan,
> +				dma_addr_t dest,
> +				dma_addr_t src,
> +				size_t len,
> +				unsigned long flags)
> +{
> +	struct sf_pdma_chan *chan = to_sf_pdma_chan(dchan);
> +	struct sf_pdma_desc *desc;
> +
> +	if (!chan || !len || !dest || !src) {
> +		pr_debug("%s: Please check dma len, dest, src!\n", __func__);

why pr_debug() and not dev_debug(), bonus you get the device name in
each print!

and this should be an error print!

> +static void sf_pdma_unprep_slave_dma(struct sf_pdma_chan *chan)
> +{
> +	if (chan->dma_dir != DMA_NONE)
> +		dma_unmap_resource(chan->vchan.chan.device->dev,
> +				   chan->dma_dev_addr,
> +				   chan->dma_dev_size,
> +				   chan->dma_dir, 0);

this does not seem correct to me, in slave cases the client is supposed
to take care of mapping and unmapping, why is this being done here?

> +	chan->dma_dir = DMA_NONE;
> +}
> +
> +static int sf_pdma_slave_config(struct dma_chan *dchan,
> +				struct dma_slave_config *cfg)
> +{
> +	struct sf_pdma_chan *chan = to_sf_pdma_chan(dchan);
> +
> +	memcpy(&chan->cfg, cfg, sizeof(*cfg));
> +	sf_pdma_unprep_slave_dma(chan);

why unmap!

> +static enum dma_status
> +sf_pdma_tx_status(struct dma_chan *dchan,
> +		  dma_cookie_t cookie,
> +		  struct dma_tx_state *txstate)
> +{
> +	struct sf_pdma_chan *chan = to_sf_pdma_chan(dchan);
> +	enum dma_status status;
> +	unsigned long flags;
> +
> +	spin_lock_irqsave(&chan->lock, flags);
> +	if (chan->xfer_err) {
> +		chan->status = DMA_ERROR;
> +		spin_unlock_irqrestore(&chan->lock, flags);
> +		return chan->status;

well this is not correct! The status is queried for a descriptor and we
might have that succeeded so returning error of a channel for descriptor
does not make sense!

> +static irqreturn_t sf_pdma_done_isr(int irq, void *dev_id)
> +{
> +	struct sf_pdma_chan *chan = dev_id;
> +	struct pdma_regs *regs = &chan->regs;
> +	unsigned long flags;
> +
> +	spin_lock_irqsave(&chan->lock, flags);
> +	writel((readl(regs->ctrl)) & ~PDMA_DONE_STATUS_MASK, regs->ctrl);
> +	spin_unlock_irqrestore(&chan->lock, flags);

why not submit next transaction here? This is DMA so we do care about
utilizing it!

> +static int sf_pdma_irq_init(struct platform_device *pdev, struct sf_pdma *pdma)
> +{
> +	int irq, r, i;
> +	struct sf_pdma_chan *chan;
> +
> +	for (i = 0; i < pdma->n_chans; i++) {
> +		chan = &pdma->chans[i];
> +
> +		irq = platform_get_irq(pdev, i * 2);
> +		if (irq < 0) {
> +			dev_err(&pdev->dev, "Can't get pdma done irq.\n");
> +			return irq;
> +		}
> +
> +		r = devm_request_irq(&pdev->dev, irq, sf_pdma_done_isr, 0,
> +				     dev_name(&pdev->dev), (void *)chan);
> +		if (r) {
> +			dev_err(&pdev->dev, "Fail to attach done ISR: %d\n", r);
> +			return -1;

-1 :(

> +static int sf_pdma_probe(struct platform_device *pdev)
> +{
> +	struct sf_pdma *pdma;
> +	struct sf_pdma_chan *chan;
> +	struct resource *res;
> +	int len, chans;
> +	int ret;
> +
> +	chans = PDMA_NR_CH;
> +	len = sizeof(*pdma) + sizeof(*chan) * chans;
> +	pdma = devm_kzalloc(&pdev->dev, len, GFP_KERNEL);
> +	if (!pdma)
> +		return -ENOMEM;
> +
> +	pdma->n_chans = chans;
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	pdma->membase = devm_ioremap_resource(&pdev->dev, res);
> +	if (IS_ERR(pdma->membase))
> +		goto ERR_MEMBASE;
> +
> +	ret = sf_pdma_irq_init(pdev, pdma);
> +	if (ret)
> +		goto ERR_INITIRQ;
> +
> +	sf_pdma_setup_chans(pdma);
> +
> +	pdma->dma_dev.dev = &pdev->dev;
> +	dma_cap_set(DMA_MEMCPY, pdma->dma_dev.cap_mask);
> +
> +	ret = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
> +	if (ret)
> +		pr_warn("*** Failed to set DMA mask. Fall back to default.\n");
> +
> +	/* Setup DMA APIs */
> +	pdma->dma_dev.device_alloc_chan_resources =
> +		sf_pdma_alloc_chan_resources;
> +	pdma->dma_dev.device_free_chan_resources =
> +		sf_pdma_free_chan_resources;
> +	pdma->dma_dev.device_tx_status = sf_pdma_tx_status;
> +	pdma->dma_dev.device_prep_dma_memcpy = sf_pdma_prep_dma_memcpy;
> +	pdma->dma_dev.device_config = sf_pdma_slave_config;
> +	pdma->dma_dev.device_terminate_all = sf_pdma_terminate_all;
> +	pdma->dma_dev.device_issue_pending = sf_pdma_issue_pending;

please set the capabilities of the controller, width, direction,
granularity etc!

> +static int sf_pdma_remove(struct platform_device *pdev)
> +{
> +	struct sf_pdma *pdma = platform_get_drvdata(pdev);
> +
> +	dma_async_device_unregister(&pdma->dma_dev);

since you used devm_irq_() you have irq which is running, tasklets which
maybe schedule and can be scheduled again including the vchan one!
-- 
~Vinod

  parent reply	other threads:[~2019-10-20 14:00 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-03  9:09 [PATCH v4 0/4] dmaengine: sf-pdma: Add platform dma driver Green Wan
2019-10-03  9:09 ` [PATCH v4 1/4] dt-bindings: dmaengine: sf-pdma: add bindins for SiFive PDMA Green Wan
2019-10-09 23:34   ` Rob Herring
2019-10-03  9:09 ` [PATCH v4 2/4] riscv: dts: add support for PDMA device of HiFive Unleashed Rev A00 Green Wan
2019-10-03  9:09 ` [PATCH v4 3/4] dmaengine: sf-pdma: add platform DMA support for HiFive Unleashed A00 Green Wan
2019-10-13 13:04   ` [RFC PATCH] dmaengine: sf-pdma: sf_pdma_disclaim_chan() can be static kbuild test robot
2019-10-13 13:04   ` [PATCH v4 3/4] dmaengine: sf-pdma: add platform DMA support for HiFive Unleashed A00 kbuild test robot
2019-10-20 13:59   ` Vinod Koul [this message]
2019-10-03  9:09 ` [PATCH v4 4/4] MAINTAINERS: Add Green as SiFive PDMA driver maintainer Green Wan

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=20191020135952.GU2654@vkoul-mobl \
    --to=vkoul@kernel.org \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=bmeng.cn@gmail.com \
    --cc=dan.j.williams@intel.com \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=dmaengine@vger.kernel.org \
    --cc=green.wan@sifive.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-hackers@sifive.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=mchehab+samsung@kernel.org \
    --cc=palmer@sifive.com \
    --cc=paul.walmsley@sifive.com \
    --cc=paulmck@linux.ibm.com \
    --cc=robh+dt@kernel.org \
    --cc=sagar.kadam@sifive.com \
    --cc=yash.shah@sifive.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).