All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vinod Koul <vinod.koul@intel.com>
To: linux-sh@vger.kernel.org
Subject: Re: [PATCH 2/2 v2] dmaengine: rcar-audmapp: independent from SH_DMAE_BASE v2
Date: Tue, 16 Dec 2014 16:51:04 +0000	[thread overview]
Message-ID: <20141216163903.GB16827@intel.com> (raw)
In-Reply-To: <87vblknmw3.wl%kuninori.morimoto.gx@renesas.com>

On Tue, Dec 16, 2014 at 09:03:38AM +0000, Kuninori Morimoto wrote:
> 
> Hi Vinod
> 
> > > This rcar-audmapp driver is very limited usage, and user is only sound device/driver.
> > > Sound driver configures both 1st/2nd DMAC if needed (it depends on platform).
> > > Sound driver knows all reg address / mem address which are needed for 1st/2nd DMAC settings.
> > > 1st/2nd DMAC needs general DMAEngine settings method, not special. 
> > > Now, sound driver + 1st/2nd DMAC works well on my local environment.
> > Are you not using the sound dmaengine library then, right?
> 
> At this point, yes.
> But, I got request from Mark to use it
Yes that is the subsytem recommendation

> # current dmaengine "method" on my driver is same as library.
> # but I need to fix non-dmaengine area
> 
> > One more question, audio data will be in system memory and then it needs to
> > be transfered to periphral FIFO, how will data travel thru these two DMAs?
> 
> like this
> 
>     1st DMA            2nd DMA
> [mem] -> [periphral IP-A] -> [periphral IP-B] -> speaker
Okay and by current implementation you wont be able to use the generic
dmaengine sound layer. That layer assumes you will have only one dmaengine
channel to configure and will configure only one DMA and which is 1st DMA
here.

So what do we do we 2nd one here. The point that 2nd DMA is behind the 1st
DMA, should the users know about it and configure? I am not sure...
If not, then who should configure this. Another candidate is 1st DMA, but
then from the point of 1st DMA should it configure 2nd DMA as well, treat it
as its salve... sounds plausible but am not too sure... comments?

-- 
~Vinod

  parent reply	other threads:[~2014-12-16 16:51 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-10  4:34 [PATCH 2/2 v2] dmaengine: rcar-audmapp: independent from SH_DMAE_BASE v2 Kuninori Morimoto
2014-12-10  5:58 ` Vinod Koul
2014-12-10  7:05 ` Kuninori Morimoto
2014-12-11  5:17 ` Vinod Koul
2014-12-11  5:31 ` Kuninori Morimoto
2014-12-15 10:31 ` Kuninori Morimoto
2014-12-15 14:54 ` Vinod Koul
2014-12-16  0:08 ` Kuninori Morimoto
2014-12-16  6:58 ` Vinod Koul
2014-12-16  9:03 ` Kuninori Morimoto
2014-12-16  9:11 ` Kuninori Morimoto
2014-12-16 16:45 ` Vinod Koul
2014-12-16 16:51 ` Vinod Koul [this message]
2014-12-16 19:41 ` Laurent Pinchart
2014-12-17  0:27 ` Kuninori Morimoto
2014-12-18 20:49 ` Laurent Pinchart
2014-12-19  0:27 ` Kuninori Morimoto
2014-12-22 15:26 ` Vinod Koul
2014-12-24  1:39 ` Kuninori Morimoto
2014-12-24  5:35 ` 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=20141216163903.GB16827@intel.com \
    --to=vinod.koul@intel.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.