From: Arnd Bergmann <arnd@arndb.de>
To: Jon Hunter <jon-hunter@ti.com>
Cc: device-tree <devicetree-discuss@lists.ozlabs.org>,
linux-omap <linux-omap@vger.kernel.org>,
linux-arm <linux-arm-kernel@lists.infradead.org>,
Nicolas Ferre <nicolas.ferre@atmel.com>,
Benoit Cousson <b-cousson@ti.com>,
Stephen Warren <swarren@nvidia.com>,
Grant Likely <grant.likely@secretlab.ca>,
Russell King <linux@arm.linux.org.uk>,
Rob Herring <rob.herring@calxeda.com>,
Vinod Koul <vinod.koul@intel.com>, Dan Williams <djbw@fb.com>
Subject: Re: [PATCH V4 1/2] of: Add generic device tree DMA helpers
Date: Fri, 14 Sep 2012 09:43:49 +0000 [thread overview]
Message-ID: <201209140943.49904.arnd@arndb.de> (raw)
In-Reply-To: <1347573629-21299-2-git-send-email-jon-hunter@ti.com>
On Thursday 13 September 2012, Jon Hunter wrote:
> This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2]
> to add some basic helpers to retrieve a DMA controller device_node and the
> DMA request/channel information.
I think we're getting very close now, I only have a few small comments left
that should all be uncontroversial.
> +
> +Client drivers should specify the DMA property using a phandle to the controller
> +followed by DMA controller specific data.
> +
> +Required property:
> +- dmas: List of one or more DMA specifiers, each consisting of
> + - A phandle pointing to DMA controller node
> + - A single integer cell containing DMA controller
> + specific information. This typically contains a dma
> + request line number or a channel number, but can
> + contain any data that is used required for configuring
> + a channel.
> +- dma-names: Contains one identifier string for each dma specifier in
> + the dmas property. The specific strings that can be used
> + are defined in the binding of the DMA client device.
I think here we need to clarify that listing the same name multiple times implies
having multiple alternatives for the same channel.
> +Example:
> +
> +- One DMA write channel, one DMA read/write channel:
> +
> + i2c1: i2c@1 {
> + ...
> + dmas = <&sdma 2 /* read channel */
> + &sdma 3>; /* write channel */
> + dma-names = "rx", "tx"
> + ...
> + };
And please add an example documenting this case.
> +/**
> + * of_dma_find_channel - Find a DMA channel by name
> + * @np: device node to look for DMA channels
> + * @name: name of desired channel
> + * @dma_spec: pointer to DMA specifier as found in the device tree
> + *
> + * Find a DMA channel by the name. Returns 0 on success or appropriate
> + * errno value on error.
> + */
> +static int of_dma_find_channel(struct device_node *np, char *name,
> + struct of_phandle_args *dma_spec)
> +{
> + int count, i;
> + const char *s;
> +
> + count = of_property_count_strings(np, "dma-names");
> + if (count < 0)
> + return count;
> +
> + for (i = 0; i < count; i++) {
> + of_property_read_string_index(np, "dma-names", i, &s);
> +
> + if (strcmp(name, s))
> + continue;
> +
> + return of_parse_phandle_with_args(np, "dmas", "#dma-cells",
> + i, dma_spec);
> + }
> +
> + return -ENODEV;
> +}
I think we should at least keep trying the other channels with the same name when
of_parse_phandle_with_args fails. We might want to do something smarter in
the long run, e.g. to spread channel allocations across the avaialable controllers.
> +/**
> + * of_dma_request_slave_channel - Get the DMA slave channel
> + * @np: device node to get DMA request from
> + * @name: name of desired channel
> + *
> + * Returns pointer to appropriate dma channel on success or NULL on error.
> + */
> +struct dma_chan *of_dma_request_slave_channel(struct device_node *np,
> + char *name)
> +{
> ...
> +}
> +EXPORT_SYMBOL_GPL(of_dma_request_slave_channel);
I think this no longer needs to be exported, with patch 2 on top.
> +/**
> + * of_dma_simple_xlate - Simple DMA engine translation function
> + * @dma_spec: pointer to DMA specifier as found in the device tree
> + * @of_dma: pointer to DMA controller data
> + *
> + * A simple translation function for devices that use a 32-bit value for the
> + * filter_param when calling the DMA engine dma_request_channel() function.
> + * Note that this translation function requires that #dma-cells is equal to 1
> + * and the argument of the dma specifier is the 32-bit filter_param. Returns
> + * pointer to appropriate dma channel on success or NULL on error.
> + */
> +struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_spec,
> + struct of_dma *ofdma)
> +{
> + int count = dma_spec->args_count;
> + struct of_dma_filter_info *info = ofdma->of_dma_data;
> +
> + if (!info || !info->filter_fn)
> + return NULL;
> +
> + if (count != 1)
> + return NULL;
> +
> + return dma_request_channel(info->dma_cap, info->filter_fn,
> + &dma_spec->args[0]);
> +}
But this one does.
Arnd
next prev parent reply other threads:[~2012-09-14 9:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-13 22:00 [PATCH V4 0/2] of: Add generic device tree DMA helpers Jon Hunter
2012-09-13 22:00 ` [PATCH V4 1/2] " Jon Hunter
2012-09-14 9:43 ` Arnd Bergmann [this message]
2012-09-14 13:27 ` Jon Hunter
2012-09-14 13:32 ` Arnd Bergmann
2012-09-14 14:03 ` Jon Hunter
2012-09-14 16:28 ` Stephen Warren
2012-09-14 17:19 ` Jon Hunter
2012-09-13 22:00 ` [PATCH V4 2/2] dmaengine: add helper function to request a slave DMA channel Jon Hunter
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=201209140943.49904.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=b-cousson@ti.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=djbw@fb.com \
--cc=grant.likely@secretlab.ca \
--cc=jon-hunter@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=nicolas.ferre@atmel.com \
--cc=rob.herring@calxeda.com \
--cc=swarren@nvidia.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 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).