Re: [PATCH 00/18] edma/ASoC: dmaengine PCM for AM335x and AM447x

2014-03-14 Thread Peter Ujfalusi
On 03/13/2014 03:46 PM, Mark Brown wrote:
 On Thu, Mar 13, 2014 at 11:18:22AM +0200, Peter Ujfalusi wrote:
 
 With this series AM335x and AM447x will use the dmaengine PCM for audio. The
 daVinci devices will keep using the davinci-pcm for now since I do not have
 means to test them but the code is written in a way that they can be switched
 to use the edma-pcm easily (DA850/OMAP-L138 has been tested and audio was
 working fine).
 
 Can you please not resend the ASoC portions of this series until the
 EDMA portion is stable (and ideally committed)?  I'm not quite sure why
 but every EDMA patch series seems to go through lots of iterations which
 gets rather noisy - my initial reaction to seeing EDMA in a subject is
 to just delete the thread.

Sure, I'm not planning to spam alsa-devel however the switch to dmaengine PCM
for AM335x/AM447x needs the edma patches, otherwise it is not going to work.
AFAIK I have not sent patch to edma as of now so I have no idea how long it
takes to get stuff in (the good thing is that the edma part does not touch DT,
which is alone can reduce the number of iterations).
Anyway, what I can - and already did is:
Reorder the ASoC patches and I can leave out the switch to dmaengine PCM patch
for davinci-mcasp for now. The edma-pcm and the other patches for McASP can go
in right away (I will not add the edma-pcm to the Makefile/Kconfig to avoid
issues).

I will detach the edma stuff and follow it up outside of alsa-devel.

The only thing I'm afraid off is that it is going to take two release cycle to
get this in: first cycle edma part, next cycle for the ASoC to switch to use
the edma-pcm.

-- 
Péter
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 00/18] edma/ASoC: dmaengine PCM for AM335x and AM447x

2014-03-14 Thread Mark Brown
On Fri, Mar 14, 2014 at 11:38:58AM +0200, Peter Ujfalusi wrote:

 The only thing I'm afraid off is that it is going to take two release cycle to
 get this in: first cycle edma part, next cycle for the ASoC to switch to use
 the edma-pcm.

We can do a cross tree merge, or the EDMA code can be applied to ASoC
directly if that's what people want.


signature.asc
Description: Digital signature


[PATCH 00/18] edma/ASoC: dmaengine PCM for AM335x and AM447x

2014-03-13 Thread Peter Ujfalusi
Hi,

With this series AM335x and AM447x will use the dmaengine PCM for audio. The
daVinci devices will keep using the davinci-pcm for now since I do not have
means to test them but the code is written in a way that they can be switched
to use the edma-pcm easily (DA850/OMAP-L138 has been tested and audio was
working fine).

To be able to use the dmaengine PCM I needed to make changes to the edma code in
arch/arm/common/ and in drivers/dma/ :
Adding support for DMA pause/resume
Possibility to select non default event queue/TC for cyclic (audio) dma
channels: all devices using the eDMA via dmaengine was assigned to the default
EQ/TC (mmc, i2c, spi, etc, and audio). This is not optimal from system
performance point of view since sharing the same EQ/TC can cause latency spikes
for cyclic channels (long DMA transfers for MMC for example).

While debugging the edma to get things sorted out I noticed that the debug was
too verbose and the important information was hidden even when the we did not
asked for verbose dmaengine debug.
I have included some debug cleanups for the edma dmaengine driver also.

On the ASoC side: the series has been tested on AM335x and AM447x. I have report
that DA850/OMAP-L138 works with this series (which boots w/o DT).

Regards,
Peter
---
Peter Ujfalusi (18):
  platform_data: edma: Be precise with the paRAM struct
  dma: edma: Add support for DMA_PAUSE/RESUME operation
  dma: edma: Set DMA_CYCLIC capability flag
  arm: common: edma: Select event queue 1 as default when booted with DT
  arm: common: edma: Save the number of event queues/TCs
  arm: common: edma: API to request non default queue for a channel
  DMA: edma: Use different eventq for cyclic channels
  dma: edma: Implement device_slave_caps callback
  dma: edma: Simplify direction configuration in edma_config_pset()
  dma: edma: Reduce debug print verbosity for non verbose debugging
  dma: edma: Prefix debug prints where the text were identical in prep
callbacks
  dma: edma: Add channel number to debug prints
  dma: edma: Print the direction value as well when it is not supported
  ASoC: davinci: Add edma dmaengine platform driver
  ASoC: davinci-mcasp: Use dmaengine based platform driver for
AM335x/447x
  ASoC: davinci-mcasp: Provide correct filter_data for dmaengine for
non-DT boot
  ASoC: davinci-mcasp: Assign the dma_data earlier in dai_probe callback
  ASoC: davinci-mcasp: Place constraint on the period size based on FIFO
config

 arch/arm/common/edma.c |  34 -
 drivers/dma/edma.c |  92 ++
 include/linux/platform_data/edma.h |  20 
 sound/soc/davinci/Kconfig  |   1 +
 sound/soc/davinci/Makefile |   2 +-
 sound/soc/davinci/davinci-mcasp.c  | 100 ++---
 sound/soc/davinci/edma-pcm.c   |  77 
 sound/soc/davinci/edma-pcm.h   |  26 ++
 8 files changed, 303 insertions(+), 49 deletions(-)
 create mode 100644 sound/soc/davinci/edma-pcm.c
 create mode 100644 sound/soc/davinci/edma-pcm.h

-- 
1.9.0

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 00/18] edma/ASoC: dmaengine PCM for AM335x and AM447x

2014-03-13 Thread Mark Brown
On Thu, Mar 13, 2014 at 11:18:22AM +0200, Peter Ujfalusi wrote:

 With this series AM335x and AM447x will use the dmaengine PCM for audio. The
 daVinci devices will keep using the davinci-pcm for now since I do not have
 means to test them but the code is written in a way that they can be switched
 to use the edma-pcm easily (DA850/OMAP-L138 has been tested and audio was
 working fine).

Can you please not resend the ASoC portions of this series until the
EDMA portion is stable (and ideally committed)?  I'm not quite sure why
but every EDMA patch series seems to go through lots of iterations which
gets rather noisy - my initial reaction to seeing EDMA in a subject is
to just delete the thread.


signature.asc
Description: Digital signature