[PATCH 0/3 v3][RFC] dmaengine: rcar-audmapp: calculate chcr via src/dst addr

[PATCH 0/3 v3][RFC] dmaengine: rcar-audmapp: calculate chcr via src/dst addr

[Kuninori Morimoto]

Hi all

These are v3 of rcar-audmapp driver as [RFC].
We can reduce Audio DMAC peri peri DT entry 220 -> 22 node by these patches.

Actually, sound driver side needs update for this rcar-audmapp update,
but it doesn't include these patches at this point.
These are focuing about rcar-audmapp only at this point.

Main change on this version is that audmapp driver assumes DTS has reg-names

Kuninori Morimoto (3):
      dmaengine: rcar-audmapp: calculate chcr via src/dst addr
      ARM: shmobile: r8a7790: add SSIU/DTCP/MLM/SCU reg for Audio DMAC peri peri
      ARM: shmobile: r8a7790: enables Audio DMAC peri peri entry on DTSI

 arch/arm/boot/dts/r8a7790.dtsi |   26 ++++++-
 drivers/dma/sh/rcar-audmapp.c  |  164 +++++++++++++++++++++++++++++++++++++---
 2 files changed, 175 insertions(+), 15 deletions(-)

Best regards
---
Kuninori Morimoto
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3 v3][RFC] dmaengine: rcar-audmapp: calculate chcr via src/dst addr

[Kuninori Morimoto]

Hi Vinod, Arnd

Can I have feedback from you about below mail, and this patch ?

http://thread.gmane.org/gmane.linux.ports.sh.devel/41063/focusC372

> Hi all
> 
> These are v3 of rcar-audmapp driver as [RFC].
> We can reduce Audio DMAC peri peri DT entry 220 -> 22 node by these patches.
> 
> Actually, sound driver side needs update for this rcar-audmapp update,
> but it doesn't include these patches at this point.
> These are focuing about rcar-audmapp only at this point.
> 
> Main change on this version is that audmapp driver assumes DTS has reg-names
> 
> Kuninori Morimoto (3):
>       dmaengine: rcar-audmapp: calculate chcr via src/dst addr
>       ARM: shmobile: r8a7790: add SSIU/DTCP/MLM/SCU reg for Audio DMAC peri peri
>       ARM: shmobile: r8a7790: enables Audio DMAC peri peri entry on DTSI
> 
>  arch/arm/boot/dts/r8a7790.dtsi |   26 ++++++-
>  drivers/dma/sh/rcar-audmapp.c  |  164 +++++++++++++++++++++++++++++++++++++---
>  2 files changed, 175 insertions(+), 15 deletions(-)
> 
> Best regards
> ---
> Kuninori Morimoto
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Best regards
---
Kuninori Morimoto

Re: [PATCH 0/3 v3][RFC] dmaengine: rcar-audmapp: calculate chcr via src/dst addr

[Arnd Bergmann]

On Monday 09 February 2015 01:37:41 Kuninori Morimoto wrote:
> 
> Hi Vinod, Arnd
> 
> Can I have feedback from you about below mail, and this patch ?
> 
> http://thread.gmane.org/gmane.linux.ports.sh.devel/41063/focusC372

I had the chance to discuss this in more depth with Laurent last
week. What it basically comes down to is that you try to do something
that the existing DT binding and slave API does not support: we
only really do DMA_DEV_TO_MEM or DMA_MEM_TO_DEV, but not DMA_DEV_TO_DEV.

To properly support this with the dmaengine API, we would likely first
need to extend the generic DT binding, and then implement the driver
to use that extended binding.

The easiest way out however seems to be to move the audmapp
implementation into the rcar audio driver itself. As Laurent pointed
out, it is not really a general-purpose dmaengine anyway and it
only ever gets used by one driver, so we could not find any downsides.

	Arnd

Re: [PATCH 0/3 v3][RFC] dmaengine: rcar-audmapp: calculate chcr via src/dst addr

[Kuninori Morimoto]

Hi Arnd
Cc Mark Brown

> > http://thread.gmane.org/gmane.linux.ports.sh.devel/41063/focusC372
> 
> I had the chance to discuss this in more depth with Laurent last
> week. What it basically comes down to is that you try to do something
> that the existing DT binding and slave API does not support: we
> only really do DMA_DEV_TO_MEM or DMA_MEM_TO_DEV, but not DMA_DEV_TO_DEV.
> 
> To properly support this with the dmaengine API, we would likely first
> need to extend the generic DT binding, and then implement the driver
> to use that extended binding.
> 
> The easiest way out however seems to be to move the audmapp
> implementation into the rcar audio driver itself. As Laurent pointed
> out, it is not really a general-purpose dmaengine anyway and it
> only ever gets used by one driver, so we could not find any downsides.

Hmm... OK I understand.

Mark

I try to move audmapp from current drivers/dma/sh/rcar-audmapp.c
to sound/soc/sh/rcar/


Best regards
---
Kuninori Morimoto

Re: [PATCH 0/3 v3][RFC] dmaengine: rcar-audmapp: calculate chcr via src/dst addr

[Arnd Bergmann]

On Tuesday 17 February 2015 00:10:10 Kuninori Morimoto wrote:
> Hi Arnd
> Cc Mark Brown
> 
> > > http://thread.gmane.org/gmane.linux.ports.sh.devel/41063/focusC372
> > 
> > I had the chance to discuss this in more depth with Laurent last
> > week. What it basically comes down to is that you try to do something
> > that the existing DT binding and slave API does not support: we
> > only really do DMA_DEV_TO_MEM or DMA_MEM_TO_DEV, but not DMA_DEV_TO_DEV.
> > 
> > To properly support this with the dmaengine API, we would likely first
> > need to extend the generic DT binding, and then implement the driver
> > to use that extended binding.
> > 
> > The easiest way out however seems to be to move the audmapp
> > implementation into the rcar audio driver itself. As Laurent pointed
> > out, it is not really a general-purpose dmaengine anyway and it
> > only ever gets used by one driver, so we could not find any downsides.
> 
> Hmm... OK I understand.
> 
> Mark
> 
> I try to move audmapp from current drivers/dma/sh/rcar-audmapp.c
> to sound/soc/sh/rcar/
> 

Sounds good.

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.

	Arnd

Re: [PATCH 0/3 v3][RFC] dmaengine: rcar-audmapp: calculate chcr via src/dst addr

[Nicolin Chen]

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

Re: [PATCH 0/3 v3][RFC] dmaengine: rcar-audmapp: calculate chcr via src/dst addr

[Kuninori Morimoto]

Hi Arnd

Thank you for your feedback

> 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.

Ahh... Actually I didn't 100% understand about your concern
of DT bindings. but, now I could.
Thank you for your explain


Best regards
---
Kuninori Morimoto

Re: [PATCH 0/3 v3][RFC] dmaengine: rcar-audmapp: calculate chcr via src/dst addr

[Vinod Koul]

On Mon, Feb 16, 2015 at 08:47:00PM +0100, Arnd Bergmann wrote:
> On Monday 09 February 2015 01:37:41 Kuninori Morimoto wrote:
> > 
> > Hi Vinod, Arnd
> > 
> > Can I have feedback from you about below mail, and this patch ?
> > 
> > http://thread.gmane.org/gmane.linux.ports.sh.devel/41063/focusC372
> 
> I had the chance to discuss this in more depth with Laurent last
> week. What it basically comes down to is that you try to do something
> that the existing DT binding and slave API does not support: we
> only really do DMA_DEV_TO_MEM or DMA_MEM_TO_DEV, but not DMA_DEV_TO_DEV.
For the record, device_prep_slave_sg() can do DMA_DEV_TO_DEV. That is the
sole reason why dma_slave_config has both the directions for every field.

HTH

-- 
~Vinod
 
> To properly support this with the dmaengine API, we would likely first
> need to extend the generic DT binding, and then implement the driver
> to use that extended binding.
> 
> The easiest way out however seems to be to move the audmapp
> implementation into the rcar audio driver itself. As Laurent pointed
> out, it is not really a general-purpose dmaengine anyway and it
> only ever gets used by one driver, so we could not find any downsides.
> 
> 	Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe dmaengine" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--