All of lore.kernel.org
 help / color / mirror / Atom feed
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 1/2] dma: at_xdmac: creation of the atmel eXtended DMA Controller driver
Date: Mon, 15 Sep 2014 18:47:22 +0200	[thread overview]
Message-ID: <201409151847.22686.arnd@arndb.de> (raw)
In-Reply-To: <1410792622-22621-2-git-send-email-ludovic.desroches@atmel.com>

On Monday 15 September 2014, Ludovic Desroches wrote:
>  
> +config AT_XDMAC
> +	tristate "Atmel XDMA support"
> +	depends on ARCH_AT91
> +	select DMA_ENGINE
> +	help
> +	  Support the Atmel XDMA controller.

This should depend on (ARCH_AT91 || COMPILE_TEST) and built on x86 to
get into the usual automated build checkers.

> +static struct dma_chan *at_xdmac_xlate(struct of_phandle_args *dma_spec,
> +				       struct of_dma *of_dma)
> +{
> +	struct at_xdmac		*atxdmac = of_dma->of_dma_data;
> +	struct at_xdmac_chan	*atchan;
> +	struct dma_chan		*chan;
> +	struct device		*dev = atxdmac->dma.dev;
> +	dma_cap_mask_t 		mask;
> +
> +	if (dma_spec->args_count != 2) {
> +		dev_err(dev, "dma phandler args: bad number of args\n");
> +		return NULL;
> +	}
> +
> +	dma_cap_zero(mask);
> +	dma_cap_set(DMA_SLAVE, mask);

The mask is unused, just remove it.

> +	chan = dma_get_any_slave_channel(&atxdmac->dma);
> +	if (!chan) {
> +		dev_err(dev, "can't get a dma channel\n");
> +		return NULL;
> +	}
> +
> +	atchan = to_at_xdmac_chan(chan);
> +	atchan->memif = AT91_XDMAC_DT_GET_MEM_IF(dma_spec->args[0]);
> +	atchan->perif = AT91_XDMAC_DT_GET_PER_IF(dma_spec->args[0]);
> +	atchan->perid = AT91_XDMAC_DT_GET_PERID(dma_spec->args[1]);
> +	dev_info(dev, "chan dt cfg: memif=%u perif=%u perid=%u\n",
> +		 atchan->memif, atchan->perif, atchan->perid);

Maybe dev_dbg instead of dev_info?

I think having three cells would be nicer here, so you can get rid of the
macros.
> diff --git a/drivers/dma/at_xdmac.h b/drivers/dma/at_xdmac.h
> new file mode 100644
> index 0000000..5f4d898
> --- /dev/null
> +++ b/drivers/dma/at_xdmac.h

The header is only used in one file, so just move the contents into that file.

> +
> +static inline void __iomem *at_xdmac_chan_reg_base(struct at_xdmac *atxdmac, unsigned int chan_nb)
> +{
> +	return (void __iomem *)(atxdmac->regs + (AT_XDMAC_CHAN_REG_BASE + chan_nb * 0x40));
> +}

That type cast should not be needed. Is atxdmac->regs not already a void __iomem *

> +#define at_xdmac_read(atxdmac, reg) readl_relaxed((atxdmac)->regs + (reg))
> +#define at_xdmac_write(atxdmac, reg, value) \
> +	writel_relaxed((value), (atxdmac)->regs + (reg))
> +
> +#define at_xdmac_chan_read(atchan, reg) readl_relaxed((atchan)->ch_regs + (reg))
> +#define at_xdmac_chan_write(atchan, reg, value) writel_relaxed((value), (atchan)->ch_regs + (reg))

Is writel_relaxed the right accessor here? I haven't reviewed all uses of this,
but you have to ensure that every use that needs synchronization against the
actual DMA has explicit barriers here.
(0x2 << AT91_DMA_CFG_FIFOCFG_OFFSET)	/* single AHB access */
>  
> +
> +/* ---------- XDMAC ---------- */
> +#define AT91_XDMAC_DT_MEM_IF_MASK	(0x1)
> +#define AT91_XDMAC_DT_MEM_IF_OFFSET	(16)
> +#define AT91_XDMAC_DT_MEM_IF(mem_if)	(((mem_if) & AT91_XDMAC_DT_MEM_IF_MASK) \
> +					<< AT91_XDMAC_DT_MEM_IF_OFFSET)
> +#define AT91_XDMAC_DT_GET_MEM_IF(cfg)	(((cfg) >> AT91_XDMAC_DT_MEM_IF_OFFSET) \
> +					& AT91_XDMAC_DT_MEM_IF_MASK)
> +
> +#define AT91_XDMAC_DT_PER_IF_MASK	(0x1)
> +#define AT91_XDMAC_DT_PER_IF_OFFSET	(0)
> +#define AT91_XDMAC_DT_PER_IF(per_if)	(((per_if) & AT91_XDMAC_DT_PER_IF_MASK) \
> +					<< AT91_XDMAC_DT_PER_IF_OFFSET)
> +#define AT91_XDMAC_DT_GET_PER_IF(cfg)	(((cfg) >> AT91_XDMAC_DT_PER_IF_OFFSET) \
> +					& AT91_XDMAC_DT_PER_IF_MASK)
> +
> +#define AT91_XDMAC_DT_PERID_MASK	(0x7f)
> +#define AT91_XDMAC_DT_PERID_OFFSET	(24)
> +#define AT91_XDMAC_DT_PERID(perid)	(((perid) & AT91_XDMAC_DT_PERID_MASK) \
> +					<< AT91_XDMAC_DT_PERID_OFFSET)
> +#define AT91_XDMAC_DT_GET_PERID(cfg)	(((cfg) >> AT91_XDMAC_DT_PERID_OFFSET) \
> +					& AT91_XDMAC_DT_PERID_MASK)

As mentioned, I think it would be much better to keep the macros inside of the
driver and not visible to the binding, so you can use simple numbers in DT.

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
To: Ludovic Desroches
	<ludovic.desroches-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
Cc: dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org,
	plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org,
	vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
	dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
	josh.wu-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org,
	maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org,
	sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org,
	mark.rutland-5wv7dgnIgG8@public.gmane.org
Subject: Re: [PATCH v4 1/2] dma: at_xdmac: creation of the atmel eXtended DMA Controller driver
Date: Mon, 15 Sep 2014 18:47:22 +0200	[thread overview]
Message-ID: <201409151847.22686.arnd@arndb.de> (raw)
In-Reply-To: <1410792622-22621-2-git-send-email-ludovic.desroches-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>

On Monday 15 September 2014, Ludovic Desroches wrote:
>  
> +config AT_XDMAC
> +	tristate "Atmel XDMA support"
> +	depends on ARCH_AT91
> +	select DMA_ENGINE
> +	help
> +	  Support the Atmel XDMA controller.

This should depend on (ARCH_AT91 || COMPILE_TEST) and built on x86 to
get into the usual automated build checkers.

> +static struct dma_chan *at_xdmac_xlate(struct of_phandle_args *dma_spec,
> +				       struct of_dma *of_dma)
> +{
> +	struct at_xdmac		*atxdmac = of_dma->of_dma_data;
> +	struct at_xdmac_chan	*atchan;
> +	struct dma_chan		*chan;
> +	struct device		*dev = atxdmac->dma.dev;
> +	dma_cap_mask_t 		mask;
> +
> +	if (dma_spec->args_count != 2) {
> +		dev_err(dev, "dma phandler args: bad number of args\n");
> +		return NULL;
> +	}
> +
> +	dma_cap_zero(mask);
> +	dma_cap_set(DMA_SLAVE, mask);

The mask is unused, just remove it.

> +	chan = dma_get_any_slave_channel(&atxdmac->dma);
> +	if (!chan) {
> +		dev_err(dev, "can't get a dma channel\n");
> +		return NULL;
> +	}
> +
> +	atchan = to_at_xdmac_chan(chan);
> +	atchan->memif = AT91_XDMAC_DT_GET_MEM_IF(dma_spec->args[0]);
> +	atchan->perif = AT91_XDMAC_DT_GET_PER_IF(dma_spec->args[0]);
> +	atchan->perid = AT91_XDMAC_DT_GET_PERID(dma_spec->args[1]);
> +	dev_info(dev, "chan dt cfg: memif=%u perif=%u perid=%u\n",
> +		 atchan->memif, atchan->perif, atchan->perid);

Maybe dev_dbg instead of dev_info?

I think having three cells would be nicer here, so you can get rid of the
macros.
> diff --git a/drivers/dma/at_xdmac.h b/drivers/dma/at_xdmac.h
> new file mode 100644
> index 0000000..5f4d898
> --- /dev/null
> +++ b/drivers/dma/at_xdmac.h

The header is only used in one file, so just move the contents into that file.

> +
> +static inline void __iomem *at_xdmac_chan_reg_base(struct at_xdmac *atxdmac, unsigned int chan_nb)
> +{
> +	return (void __iomem *)(atxdmac->regs + (AT_XDMAC_CHAN_REG_BASE + chan_nb * 0x40));
> +}

That type cast should not be needed. Is atxdmac->regs not already a void __iomem *

> +#define at_xdmac_read(atxdmac, reg) readl_relaxed((atxdmac)->regs + (reg))
> +#define at_xdmac_write(atxdmac, reg, value) \
> +	writel_relaxed((value), (atxdmac)->regs + (reg))
> +
> +#define at_xdmac_chan_read(atchan, reg) readl_relaxed((atchan)->ch_regs + (reg))
> +#define at_xdmac_chan_write(atchan, reg, value) writel_relaxed((value), (atchan)->ch_regs + (reg))

Is writel_relaxed the right accessor here? I haven't reviewed all uses of this,
but you have to ensure that every use that needs synchronization against the
actual DMA has explicit barriers here.
(0x2 << AT91_DMA_CFG_FIFOCFG_OFFSET)	/* single AHB access */
>  
> +
> +/* ---------- XDMAC ---------- */
> +#define AT91_XDMAC_DT_MEM_IF_MASK	(0x1)
> +#define AT91_XDMAC_DT_MEM_IF_OFFSET	(16)
> +#define AT91_XDMAC_DT_MEM_IF(mem_if)	(((mem_if) & AT91_XDMAC_DT_MEM_IF_MASK) \
> +					<< AT91_XDMAC_DT_MEM_IF_OFFSET)
> +#define AT91_XDMAC_DT_GET_MEM_IF(cfg)	(((cfg) >> AT91_XDMAC_DT_MEM_IF_OFFSET) \
> +					& AT91_XDMAC_DT_MEM_IF_MASK)
> +
> +#define AT91_XDMAC_DT_PER_IF_MASK	(0x1)
> +#define AT91_XDMAC_DT_PER_IF_OFFSET	(0)
> +#define AT91_XDMAC_DT_PER_IF(per_if)	(((per_if) & AT91_XDMAC_DT_PER_IF_MASK) \
> +					<< AT91_XDMAC_DT_PER_IF_OFFSET)
> +#define AT91_XDMAC_DT_GET_PER_IF(cfg)	(((cfg) >> AT91_XDMAC_DT_PER_IF_OFFSET) \
> +					& AT91_XDMAC_DT_PER_IF_MASK)
> +
> +#define AT91_XDMAC_DT_PERID_MASK	(0x7f)
> +#define AT91_XDMAC_DT_PERID_OFFSET	(24)
> +#define AT91_XDMAC_DT_PERID(perid)	(((perid) & AT91_XDMAC_DT_PERID_MASK) \
> +					<< AT91_XDMAC_DT_PERID_OFFSET)
> +#define AT91_XDMAC_DT_GET_PERID(cfg)	(((cfg) >> AT91_XDMAC_DT_PERID_OFFSET) \
> +					& AT91_XDMAC_DT_PERID_MASK)

As mentioned, I think it would be much better to keep the macros inside of the
driver and not visible to the binding, so you can use simple numbers in DT.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2014-09-15 16:47 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-15 14:50 [PATCH v4 0/2] new Atmel DMA controller Ludovic Desroches
2014-09-15 14:50 ` Ludovic Desroches
2014-09-15 14:50 ` [PATCH v4 1/2] dma: at_xdmac: creation of the atmel eXtended DMA Controller driver Ludovic Desroches
2014-09-15 14:50   ` Ludovic Desroches
2014-09-15 16:47   ` Arnd Bergmann [this message]
2014-09-15 16:47     ` Arnd Bergmann
2014-09-16  9:34     ` Ludovic Desroches
2014-09-16  9:34       ` Ludovic Desroches
2014-09-17 12:10   ` Nicolas Ferre
2014-09-17 12:10     ` Nicolas Ferre
2014-09-15 14:50 ` [PATCH v4 2/2] ARM: dts: at_xdmac: add bindings documentation Ludovic Desroches
2014-09-15 14:50   ` Ludovic Desroches
2014-09-17  8:30   ` Nicolas Ferre
2014-09-17  8:30     ` Nicolas Ferre

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=201409151847.22686.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.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.