[alsa-devel] [PATCH] ASoC: OMAP: Add checking to detect bufferless pcms
Add checking in hw_params and prepare to detect bufferless pcms(i.e. BT <--> codec).
Signed-off-by: Joonyoung Shim jy0922.shim@samsung.com --- sound/soc/omap/omap-pcm.c | 9 ++++++++- 1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c index 07cf7f4..6454e15 100644 --- a/sound/soc/omap/omap-pcm.c +++ b/sound/soc/omap/omap-pcm.c @@ -87,8 +87,10 @@ static int omap_pcm_hw_params(struct snd_pcm_substream *substream, struct omap_pcm_dma_data *dma_data = rtd->dai->cpu_dai->dma_data; int err = 0;
+ /* return if this is a bufferless transfer e.g. + * codec <--> BT codec or GSM modem -- lg FIXME */ if (!dma_data) - return -ENODEV; + return 0;
snd_pcm_set_runtime_buffer(substream, &substream->dma_buffer); runtime->dma_bytes = params_buffer_bytes(params); @@ -134,6 +136,11 @@ static int omap_pcm_prepare(struct snd_pcm_substream *substream) struct omap_pcm_dma_data *dma_data = prtd->dma_data; struct omap_dma_channel_params dma_params;
+ /* return if this is a bufferless transfer e.g. + * codec <--> BT codec or GSM modem -- lg FIXME */ + if (!prtd->dma_data) + return 0; + memset(&dma_params, 0, sizeof(dma_params)); /* * Note: Regardless of interface data formats supported by OMAP McBSP
On Wed, Apr 22, 2009 at 4:56 AM, Joonyoung Shim jy0922.shim@samsung.comwrote:
Add checking in hw_params and prepare to detect bufferless pcms(i.e. BT <--> codec).
Signed-off-by: Joonyoung Shim jy0922.shim@samsung.com
sound/soc/omap/omap-pcm.c | 9 ++++++++- 1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c index 07cf7f4..6454e15 100644 --- a/sound/soc/omap/omap-pcm.c +++ b/sound/soc/omap/omap-pcm.c @@ -87,8 +87,10 @@ static int omap_pcm_hw_params(struct snd_pcm_substream *substream, struct omap_pcm_dma_data *dma_data = rtd->dai->cpu_dai->dma_data; int err = 0;
/* return if this is a bufferless transfer e.g.* codec <--> BT codec or GSM modem -- lg FIXME */ if (!dma_data)
return -ENODEV;
return 0;
I see exactly similar lines in s3c24xx-pcm.c but don't point now the use case where this is used and I don't have idea what is this all about.
Is this something where DAI driver or another end of connection is used to provide clocking and the whole setup is then controlled with ALSA PCM API? Somehow I have the feeling that would there be a better way to achieve it than with dummy bufferless transfer?
On Wed, Apr 22, 2009 at 11:30:32AM +0300, Jarkko Nikula wrote:
On Wed, Apr 22, 2009 at 4:56 AM, Joonyoung Shim jy0922.shim@samsung.comwrote:
/* return if this is a bufferless transfer e.g.* codec <--> BT codec or GSM modem -- lg FIXME */ if (!dma_data)
return -ENODEV;
return 0;
I see exactly similar lines in s3c24xx-pcm.c but don't point now the use case where this is used and I don't have idea what is this all about.
The use case is for dummy DAIs used to represent bluetooth and similar - they aren't going to do any DMA so don't pass anything to the platform.
Is this something where DAI driver or another end of connection is used to provide clocking and the whole setup is then controlled with ALSA PCM API? Somehow I have the feeling that would there be a better way to achieve it than with dummy bufferless transfer?
The host isn't transferring any data at all in these cases. Ideally we'd support multiple platforms and there'd be a dummy platform driver to go with the dummy DAI driver.
On Wed, Apr 22, 2009 at 11:43 AM, Mark Brown broonie@sirena.org.uk wrote:
On Wed, Apr 22, 2009 at 11:30:32AM +0300, Jarkko Nikula wrote:
Is this something where DAI driver or another end of connection is used
to
provide clocking and the whole setup is then controlled with ALSA PCM
API?
Somehow I have the feeling that would there be a better way to achieve it than with dummy bufferless transfer?
The host isn't transferring any data at all in these cases. Ideally we'd support multiple platforms and there'd be a dummy platform driver to go with the dummy DAI driver.
Probably it's better to extend this patch to other architectures as well (at least DaVinci) where possible in order to be more consistent. I just noticed that also PXA is having the same feature.
On Wed, Apr 22, 2009 at 12:01:28PM +0300, Jarkko Nikula wrote:
On Wed, Apr 22, 2009 at 11:43 AM, Mark Brown broonie@sirena.org.uk wrote:
The host isn't transferring any data at all in these cases. Ideally we'd support multiple platforms and there'd be a dummy platform driver to go with the dummy DAI driver.
Probably it's better to extend this patch to other architectures as well (at least DaVinci) where possible in order to be more consistent. I just noticed that also PXA is having the same feature.
Yes, though given that it's a bodge at the moment it'd need someone to go through per architecture and check that the right thing is being done.
When I've thought about doing it I've always decided it'd probably be less hassle to fix the core not to need the bodge :/
On Wednesday 22 April 2009 11:30:32 ext Jarkko Nikula wrote:
On Wed, Apr 22, 2009 at 4:56 AM, Joonyoung Shim <jy0922.shim@samsung.commailto:jy0922.shim@samsung.com> wrote: Add checking in hw_params and prepare to detect bufferless pcms(i.e. BT <--> codec).
I see exactly similar lines in s3c24xx-pcm.c but don't point now the use case where this is used and I don't have idea what is this all about.
Is this something where DAI driver or another end of connection is used to provide clocking and the whole setup is then controlled with ALSA PCM API? Somehow I have the feeling that would there be a better way to achieve it than with dummy bufferless transfer?
In the twl codec, the BT interface does not have dedicated clock line, but it is (re)using the clock lines for the voice PCM interface. So in order to get BT data going between the BT and the codec, the voice PCM interface has to generate the clocks.
But I think this could be done even without the need for the alsa PCM interface, probably well placed DAPM switches would also can take care of this?
-- Jarkko
On 4/22/2009 5:30 PM, Jarkko Nikula wrote:
On Wed, Apr 22, 2009 at 4:56 AM, Joonyoung Shim <jy0922.shim@samsung.com mailto:jy0922.shim@samsung.com> wrote:
Add checking in hw_params and prepare to detect bufferless pcms(i.e. BT <--> codec). Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com <mailto:jy0922.shim@samsung.com>> --- 쟳ound/soc/omap/omap-pcm.c | 9 ++++++++- 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c index 07cf7f4..6454e15 100644 --- a/sound/soc/omap/omap-pcm.c +++ b/sound/soc/omap/omap-pcm.c @@ -87,8 +87,10 @@ static int omap_pcm_hw_params(struct snd_pcm_substream *substream, 쟳truct omap_pcm_dma_data *dma_data = rtd->dai->cpu_dai->dma_data; 쟧nt err = 0; + /* return if this is a bufferless transfer e.g. + * codec <--> BT codec or GSM modem -- lg FIXME */ 쟧f (!dma_data) - return -ENODEV; + return 0;I see exactly similar lines in s3c24xx-pcm.c but don't point now the use case where this is used and I don't have idea what is this all about.
Is this something where DAI driver or another end of connection is used to provide clocking and the whole setup is then controlled with ALSA PCM API? Somehow I have the feeling that would there be a better way to achieve it than with dummy bufferless transfer?
I tested this patch with the omap3 target having the twl4030 codec. The twl4030 codec driver supports the voice DAI to transfer pcm data between modem and codec, and i added for test the dummy voice DAI in machine driver. To transfer pcm data at modem <--> codec doesn't need DMA.
-- Jarkko
participants (4)
-
Jarkko Nikula -
Joonyoung Shim -
Mark Brown -
Peter Ujfalusi