From: Nicolin Chen <nicoleotsuka@gmail.com>
To: linux-sh@vger.kernel.org
Subject: Re: [PATCH 0/3 v3][RFC] dmaengine: rcar-audmapp: calculate chcr via src/dst addr
Date: Tue, 17 Feb 2015 18:20:36 +0000 [thread overview]
Message-ID: <20150217182035.GA3888@Asurada> (raw)
In-Reply-To: <87mw4xey70.wl%kuninori.morimoto.gx@renesas.com>
On Tue, Feb 17, 2015 at 03:09:41PM +0100, Arnd Bergmann wrote:
> I've thought some more about what it would really mean to support
> DMA_DEV_TO_DEV with the existing framework and binding. I believe
> we can actually do this with the existing DT binding if we really
> wanted to, but the dmaengine code would have to change. At the
> moment, we have
>
> struct dma_chan *dma_request_slave_channel_reason(struct device *dev,
> const char *name);
>
> as the main interface. What I think we would need is a respective
> interface that takes two separate names for source and sink, like
>
> struct dma_chan *dma_request_dev_to_dev_channel(struct device *dev,
> const char *source,
> const char *sink);
>
> Then you'd list all available sources and all sinks separately
> in the device node for the audio device and combine the ones you
> need.
>
> Making this particular device specific to the audio driver is
> still much easier, I just wanted to ensure we document it here
> in case we need the same functionality later for something else.
>
> There seems to be some weird workaround for a related problem
> in sound/soc/fsl/fsl_asrc_dma.c, which tries to get two channels
> individually, and then puts them into a private datas structre
> and filter function to get a third channel that is actually being
> used.
The fsl_asrc_dma was implemented upon ASoC DPCM -- it's using ASRC
(it has 3 pairs) as the Front-end and one of possible Back-ends
(several I2S controllers or a SPDIF controller). So its DMA channel
of the Front-end is based on which ASRC pair the ASRC driver assigns
while the Back-end is totally according to which Back-end controller
the DAI link is using. It means the driver has to dynamically fetch
them at runtime and overwrite the configurations in order to request
corresponding DMA channels on the fly.
Generic DMA engine looks more perfect to deal with static channel
assignments: even the dma_request_dev_to_dev_channel() above is also
seemly a bit tough to apply to ASRC's case unless we list all the
possible Back-ends in the DT and select one of names of Back-ends
based on the controller being used at runtime, although listing all
the Back-ends doesn't sound too much unreasonable.
Best regards,
Nicolin
next prev parent reply other threads:[~2015-02-17 18:20 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-02 4:25 [PATCH 0/3 v3][RFC] dmaengine: rcar-audmapp: calculate chcr via src/dst addr Kuninori Morimoto
2015-02-09 1:37 ` Kuninori Morimoto
2015-02-16 19:47 ` Arnd Bergmann
2015-02-17 0:10 ` Kuninori Morimoto
2015-02-17 14:09 ` Arnd Bergmann
2015-02-17 18:20 ` Nicolin Chen [this message]
2015-02-18 0:41 ` Kuninori Morimoto
2015-02-18 13:43 ` Vinod Koul
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=20150217182035.GA3888@Asurada \
--to=nicoleotsuka@gmail.com \
--cc=linux-sh@vger.kernel.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.