From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Vinod Koul <vinod.koul@linux.intel.com>
Cc: linux-kernel@vger.kernel.org, Dan Williams <djbw@fb.com>,
Arnd Bergmann <arnd@arndb.de>,
linus.walleij@linaro.org, Jon Hunter <jon-hunter@ti.com>,
Stephen Warren <swarren@nvidia.com>,
Benoit Cousson <b-cousson@ti.com>,
Shawn Guo <shawn.guo@linaro.org>,
Guennadi Liakhovetski <g.liakhovetski@gmx.de>,
Sascha Hauer <kernel@pengutronix.de>,
Kukjin Kim <kgene.kim@samsung.com>,
viresh kumar <viresh.kumar@linaro.org>,
Paul Mundt <lethal@linux-sh.org>
Subject: Re: [PATCH] dmaengine: add dmanegine slave map api's
Date: Fri, 14 Sep 2012 10:41:55 +0100 [thread overview]
Message-ID: <20120914094155.GC12245@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <1347615189-27052-1-git-send-email-vinod.koul@linux.intel.com>
On Fri, Sep 14, 2012 at 03:03:09PM +0530, Vinod Koul wrote:
> +/*called under lock held */
> +static struct dma_chan *dmaengine_get_slave_channel(char *requestor, dma_cap_mask_t *mask)
> +{
> +
> + struct dma_device *device, *_d;
> + struct dma_chan *chan = NULL;
> + int err;
> +
> + list_for_each_entry_safe(device, _d, &dma_device_list, global_node) {
> + if (strcmp(requestor, dev_name(device->dev)))
> + continue;
So, this finds a DMA device where the struct device's name corresponds
with the name passed in as 'requestor' (note that requestor should be
const.)
> +
> + chan = private_candidate(mask, device, NULL, NULL);
> + if (chan) {
And this finds _any_ channel on the device.
> + /* Found a suitable channel, try to grab, prep, and
> + * return it. We first set DMA_PRIVATE to disable
> + * balance_ref_count as this channel will not be
> + * published in the general-purpose allocator
> + */
> + dma_cap_set(DMA_PRIVATE, device->cap_mask);
> + device->privatecnt++;
> + err = dma_chan_get(chan);
> +
> + if (err == -ENODEV) {
> + pr_debug("%s: %s module removed\n",
> + __func__, dma_chan_name(chan));
> + list_del_rcu(&device->global_node);
> + } else if (err)
> + pr_debug("%s: failed to get %s: (%d)\n",
> + __func__, dma_chan_name(chan), err);
> + else
> + break;
> + if (--device->privatecnt == 0)
> + dma_cap_clear(DMA_PRIVATE, device->cap_mask);
> + chan = NULL;
> + }
> + }
> + return chan;
and returns it...
> +struct dma_chan *dmaengine_request_slave_channel(
> + char *requestor, struct dma_slave_config *config,
> + dma_cap_mask_t *mask, dma_filter_fn fn, void *fn_param)
> +{
> + struct dma_chan *slave = NULL;
> + struct dmaengine_slave_map_entries *entry, *_e;
> +
> + /* perhpas we dont need mask arg, it should be slave anyway */
> + if (!__dma_has_cap(DMA_SLAVE, mask))
> + return NULL;
> +
> + mutex_lock(&dma_list_mutex);
> + /* find a channel which maps to this request */
> + list_for_each_entry_safe(entry, _e, &dma_slave_map, node) {
> + if (strcmp(requestor, entry->map->client))
> + continue;
> +
> + /* have we already allocated this mapping */
> + if (entry->used == true)
> + continue;
> +
> + /* now we hit an entry in map,
> + * see if we can get a channel in controller */
> + slave = dmaengine_get_slave_channel(requestor, mask);
> + if (!slave)
> + continue;
Ok, so here we've got a channel - any old channel what so ever on the
device described by 'requestor'. And we're holding a reference to it.
> +
> + /* check if client is requesting some specfic slave channel */
> + if ((entry->map->ch != -1) && (entry->map->ch != slave->chan_id))
> + continue;
If the channel number isn't what we wanted, where do we drop this
reference? Also note that this 'continue' causes us to move to the
next entry in the map list - whereas what may have happened is that
the channel on the DMA engine is free, but it simply wasn't the first
free channel. I don't see how this can work sanely.
> + /* now call filter fn but it should not be used anyway */
> + if (fn && !fn(slave, fn_param))
> + continue;
> +
> + entry->used = true;
> + mutex_unlock(&dma_list_mutex);
> +
> + /* pick slave id from map if not set */
> + if (!config->slave_id)
> + config->slave_id = entry->map->slave_id;
So, with this level, we're talking about tying DMA channels to slave IDs.
What about the case where you may have a DMA engine with just two channels
but 16 request signals? (as is the case with PL081).
We're still into having 'virtual' DMA channels in DMA engines, this just
adds an additional layer of complexity on top.
Maybe a better idea would be to pass the map entry down to the DMA engine
driver itself, and let it return the appropriate struct dma_chan?
next prev parent reply other threads:[~2012-09-14 9:42 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-14 9:33 Vinod Koul
2012-09-14 9:39 ` [RFC] " Vinod Koul
2012-09-14 9:41 ` Russell King - ARM Linux [this message]
2012-09-14 10:51 ` [PATCH] " Vinod Koul
2012-09-14 11:18 ` Russell King - ARM Linux
2012-09-17 3:40 ` Vinod Koul
2012-09-17 8:36 ` Russell King - ARM Linux
2012-09-17 9:50 ` Vinod Koul
2012-09-17 21:57 ` Russell King - ARM Linux
2012-09-18 3:18 ` Vinod Koul
2012-09-18 12:20 ` Linus Walleij
2012-09-18 20:52 ` Russell King - ARM Linux
2012-09-18 21:04 ` Linus Walleij
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=20120914094155.GC12245@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=arnd@arndb.de \
--cc=b-cousson@ti.com \
--cc=djbw@fb.com \
--cc=g.liakhovetski@gmx.de \
--cc=jon-hunter@ti.com \
--cc=kernel@pengutronix.de \
--cc=kgene.kim@samsung.com \
--cc=lethal@linux-sh.org \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=shawn.guo@linaro.org \
--cc=swarren@nvidia.com \
--cc=vinod.koul@linux.intel.com \
--cc=viresh.kumar@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®