From: Arnd Bergmann <arnd@arndb.de>
To: devicetree-discuss@lists.ozlabs.org
Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>,
linux-sh@vger.kernel.org, Vinod Koul <vinod.koul@intel.com>,
Guennadi Liakhovetski <g.liakhovetski+renesas@gmail.com>,
Magnus Damm <magnus.damm@gmail.com>,
Rob Herring <rob.herring@calxeda.com>,
Simon Horman <horms@verge.net.au>
Subject: Re: [PATCH v2 3/3] DMA: shdma: add DT support
Date: Mon, 17 Jun 2013 15:48:11 +0000 [thread overview]
Message-ID: <201306171748.11836.arnd@arndb.de> (raw)
In-Reply-To: <1370533645-23690-4-git-send-email-g.liakhovetski@gmx.de>
On Thursday 06 June 2013, Guennadi Liakhovetski wrote:
> +Required properties:
> +- dmas: a list of <[DMA controller phandle] [MID/RID value]> pairs
> +- dma-names: a list of DMA channel names, one per "dmas" entry
Looks ok to me, although it might be helpful to clarify what MID/RID means,
by expanding the acronym and describing whether one needs to pass both
or just one of them. If both, what is the bit pattern?
> * services would have to provide their own filters, which first would check
> * the device driver, similar to how other DMAC drivers, e.g., sa11x0-dma.c, do
> * this, and only then, in case of a match, call this common filter.
> + * NOTE 2: This filter function is also used in the DT case by shdma_xlate().
> + * In that case the MID-RID value is used for slave channel filtering and is
> + * passed to this function in the "arg" parameter.
> */
> bool shdma_chan_filter(struct dma_chan *chan, void *arg)
> {
> struct shdma_chan *schan = to_shdma_chan(chan);
> struct shdma_dev *sdev = to_shdma_dev(schan->dma_chan.device);
> const struct shdma_ops *ops = sdev->ops;
> - int slave_id = (int)arg;
> + int match = (int)arg;
> int ret;
>
> - if (slave_id < 0)
> + if (match < 0)
> /* No slave requested - arbitrary channel */
> return true;
>
> - if (slave_id >= slave_num)
> + if (!schan->dev->of_node && match >= slave_num)
> return false;
>
> - ret = ops->set_slave(schan, slave_id, true);
> + ret = ops->set_slave(schan, match, true);
> if (ret < 0)
> return false;
This is complicated by the fact that you are using the same function for
two entirely different purposes. It would be easier to have a separate
filter for the DT case, rather than reusing the one that uses the slave_id
as an argument.
> @@ -867,6 +883,29 @@ void shdma_chan_remove(struct shdma_chan *schan)
> }
> EXPORT_SYMBOL(shdma_chan_remove);
>
> +struct dma_chan *shdma_xlate(struct of_phandle_args *dma_spec,
> + struct of_dma *ofdma)
> +{
> + struct shdma_dev *sdev = ofdma->of_dma_data;
> + u32 id = dma_spec->args[0];
> + dma_cap_mask_t mask;
> + struct dma_chan *chan;
> +
> + if (dma_spec->args_count != 1 || !sdev)
> + return NULL;
> +
> + dma_cap_zero(mask);
> + /* Only slave DMA channels can be allocated via DT */
> + dma_cap_set(DMA_SLAVE, mask);
> +
> + chan = dma_request_channel(mask, shdma_chan_filter, (void *)id);
> + if (chan)
> + to_shdma_chan(chan)->hw_req = id;
> +
> + return chan;
> +}
> +EXPORT_SYMBOL(shdma_xlate);
I would suggest keeping this to the drivers/dma/sh/shdma.c file
and not exporting it. The sudma would use a different binding anyway.
> +/*
> + * Find a slave channel configuration from the contoller list by either a slave
> + * ID in the non-DT case, or by a MID/RID value in the DT case
> + */
> static const struct sh_dmae_slave_config *dmae_find_slave(
> - struct sh_dmae_chan *sh_chan, int slave_id)
> + struct sh_dmae_chan *sh_chan, int match)
> {
> struct sh_dmae_device *shdev = to_sh_dev(sh_chan);
> struct sh_dmae_pdata *pdata = shdev->pdata;
> const struct sh_dmae_slave_config *cfg;
> int i;
>
> - if (slave_id >= SH_DMA_SLAVE_NUMBER)
> - return NULL;
> + if (!sh_chan->shdma_chan.dev->of_node) {
> + if (match >= SH_DMA_SLAVE_NUMBER)
> + return NULL;
>
> - for (i = 0, cfg = pdata->slave; i < pdata->slave_num; i++, cfg++)
> - if (cfg->slave_id = slave_id)
> - return cfg;
> + for (i = 0, cfg = pdata->slave; i < pdata->slave_num; i++, cfg++)
> + if (cfg->slave_id = match)
> + return cfg;
> + } else {
> + for (i = 0, cfg = pdata->slave; i < pdata->slave_num; i++, cfg++)
> + if (cfg->mid_rid = match) {
> + sh_chan->shdma_chan.slave_id = cfg->slave_id;
> + return cfg;
> + }
> + }
The pdata and slave_id should really not be needed here for the lookup in the DT
case. Is this just temporary until all slave drivers use dmaenging_slave_config
to pass the address? That should be clarified in a comment.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: devicetree-discuss@lists.ozlabs.org
Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>,
linux-sh@vger.kernel.org, Vinod Koul <vinod.koul@intel.com>,
Guennadi Liakhovetski <g.liakhovetski+renesas@gmail.com>,
Magnus Damm <magnus.damm@gmail.com>,
Rob Herring <rob.herring@calxeda.com>,
Simon Horman <horms@verge.net.au>
Subject: Re: [PATCH v2 3/3] DMA: shdma: add DT support
Date: Mon, 17 Jun 2013 17:48:11 +0200 [thread overview]
Message-ID: <201306171748.11836.arnd@arndb.de> (raw)
In-Reply-To: <1370533645-23690-4-git-send-email-g.liakhovetski@gmx.de>
On Thursday 06 June 2013, Guennadi Liakhovetski wrote:
> +Required properties:
> +- dmas: a list of <[DMA controller phandle] [MID/RID value]> pairs
> +- dma-names: a list of DMA channel names, one per "dmas" entry
Looks ok to me, although it might be helpful to clarify what MID/RID means,
by expanding the acronym and describing whether one needs to pass both
or just one of them. If both, what is the bit pattern?
> * services would have to provide their own filters, which first would check
> * the device driver, similar to how other DMAC drivers, e.g., sa11x0-dma.c, do
> * this, and only then, in case of a match, call this common filter.
> + * NOTE 2: This filter function is also used in the DT case by shdma_xlate().
> + * In that case the MID-RID value is used for slave channel filtering and is
> + * passed to this function in the "arg" parameter.
> */
> bool shdma_chan_filter(struct dma_chan *chan, void *arg)
> {
> struct shdma_chan *schan = to_shdma_chan(chan);
> struct shdma_dev *sdev = to_shdma_dev(schan->dma_chan.device);
> const struct shdma_ops *ops = sdev->ops;
> - int slave_id = (int)arg;
> + int match = (int)arg;
> int ret;
>
> - if (slave_id < 0)
> + if (match < 0)
> /* No slave requested - arbitrary channel */
> return true;
>
> - if (slave_id >= slave_num)
> + if (!schan->dev->of_node && match >= slave_num)
> return false;
>
> - ret = ops->set_slave(schan, slave_id, true);
> + ret = ops->set_slave(schan, match, true);
> if (ret < 0)
> return false;
This is complicated by the fact that you are using the same function for
two entirely different purposes. It would be easier to have a separate
filter for the DT case, rather than reusing the one that uses the slave_id
as an argument.
> @@ -867,6 +883,29 @@ void shdma_chan_remove(struct shdma_chan *schan)
> }
> EXPORT_SYMBOL(shdma_chan_remove);
>
> +struct dma_chan *shdma_xlate(struct of_phandle_args *dma_spec,
> + struct of_dma *ofdma)
> +{
> + struct shdma_dev *sdev = ofdma->of_dma_data;
> + u32 id = dma_spec->args[0];
> + dma_cap_mask_t mask;
> + struct dma_chan *chan;
> +
> + if (dma_spec->args_count != 1 || !sdev)
> + return NULL;
> +
> + dma_cap_zero(mask);
> + /* Only slave DMA channels can be allocated via DT */
> + dma_cap_set(DMA_SLAVE, mask);
> +
> + chan = dma_request_channel(mask, shdma_chan_filter, (void *)id);
> + if (chan)
> + to_shdma_chan(chan)->hw_req = id;
> +
> + return chan;
> +}
> +EXPORT_SYMBOL(shdma_xlate);
I would suggest keeping this to the drivers/dma/sh/shdma.c file
and not exporting it. The sudma would use a different binding anyway.
> +/*
> + * Find a slave channel configuration from the contoller list by either a slave
> + * ID in the non-DT case, or by a MID/RID value in the DT case
> + */
> static const struct sh_dmae_slave_config *dmae_find_slave(
> - struct sh_dmae_chan *sh_chan, int slave_id)
> + struct sh_dmae_chan *sh_chan, int match)
> {
> struct sh_dmae_device *shdev = to_sh_dev(sh_chan);
> struct sh_dmae_pdata *pdata = shdev->pdata;
> const struct sh_dmae_slave_config *cfg;
> int i;
>
> - if (slave_id >= SH_DMA_SLAVE_NUMBER)
> - return NULL;
> + if (!sh_chan->shdma_chan.dev->of_node) {
> + if (match >= SH_DMA_SLAVE_NUMBER)
> + return NULL;
>
> - for (i = 0, cfg = pdata->slave; i < pdata->slave_num; i++, cfg++)
> - if (cfg->slave_id == slave_id)
> - return cfg;
> + for (i = 0, cfg = pdata->slave; i < pdata->slave_num; i++, cfg++)
> + if (cfg->slave_id == match)
> + return cfg;
> + } else {
> + for (i = 0, cfg = pdata->slave; i < pdata->slave_num; i++, cfg++)
> + if (cfg->mid_rid == match) {
> + sh_chan->shdma_chan.slave_id = cfg->slave_id;
> + return cfg;
> + }
> + }
The pdata and slave_id should really not be needed here for the lookup in the DT
case. Is this just temporary until all slave drivers use dmaenging_slave_config
to pass the address? That should be clarified in a comment.
Arnd
next prev parent reply other threads:[~2013-06-17 15:48 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-06 15:47 [PATCH 0/3] dma: add support for DMA multiplexer DT nodes Guennadi Liakhovetski
2013-06-06 15:47 ` Guennadi Liakhovetski
2013-06-06 15:47 ` [PATCH 1/3] OF: add a new phandle parsing function for grouped nodes Guennadi Liakhovetski
2013-06-06 15:47 ` Guennadi Liakhovetski
[not found] ` <1370533645-23690-1-git-send-email-g.liakhovetski-Mmb7MZpHnFY@public.gmane.org>
2013-06-06 15:47 ` [PATCH 2/3] dmaengine: add support for DMA multiplexer DT nodes Guennadi Liakhovetski
2013-06-06 15:47 ` Guennadi Liakhovetski
2013-06-17 16:16 ` Arnd Bergmann
2013-06-17 16:16 ` Arnd Bergmann
2013-06-18 8:59 ` Guennadi Liakhovetski
2013-06-18 8:59 ` Guennadi Liakhovetski
2013-06-18 13:23 ` Arnd Bergmann
2013-06-18 13:23 ` Arnd Bergmann
2013-06-06 15:47 ` [PATCH v2 3/3] DMA: shdma: add DT support Guennadi Liakhovetski
2013-06-06 15:47 ` Guennadi Liakhovetski
2013-06-17 15:48 ` Arnd Bergmann [this message]
2013-06-17 15:48 ` Arnd Bergmann
2013-06-18 8:16 ` Guennadi Liakhovetski
2013-06-18 8:16 ` Guennadi Liakhovetski
2013-06-18 13:30 ` Arnd Bergmann
2013-06-18 13:30 ` Arnd Bergmann
2013-06-12 9:23 ` [PATCH 0/3] dma: add support for DMA multiplexer DT nodes Vinod Koul
2013-06-12 9:35 ` Vinod Koul
2013-06-12 9:25 ` Vinod Koul
2013-06-12 9:37 ` Vinod Koul
2013-06-12 10:38 ` Guennadi Liakhovetski
2013-06-12 10:38 ` Guennadi Liakhovetski
2013-06-17 13:40 ` Vinod Koul
2013-06-17 13:52 ` Vinod Koul
[not found] ` <20130612092349.GR4107-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2013-06-17 15:51 ` Arnd Bergmann
2013-06-17 15:51 ` Arnd Bergmann
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=201306171748.11836.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=g.liakhovetski+renesas@gmail.com \
--cc=g.liakhovetski@gmx.de \
--cc=horms@verge.net.au \
--cc=linux-sh@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=rob.herring@calxeda.com \
--cc=vinod.koul@intel.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 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.