On Tue, 11 Aug 2009 16:05:27 +0300 Eduardo Valentin <[email protected]> wrote:
> From: Eduardo Valentin <[email protected]> > > Signed-off-by: Eduardo Valentin <[email protected]> > --- > sound/soc/omap/omap-mcbsp.c | 8 ++++++-- > sound/soc/omap/omap-pcm.c | 13 +++++++++++-- > sound/soc/omap/omap-pcm.h | 1 + > 3 files changed, 18 insertions(+), 4 deletions(-) > ... > diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c > index 0c1ba0f..d8f52e8 100644 > --- a/sound/soc/omap/omap-pcm.c > +++ b/sound/soc/omap/omap-pcm.c > @@ -144,7 +144,9 @@ static int omap_pcm_prepare(struct snd_pcm_substream > *substream) > > memset(&dma_params, 0, sizeof(dma_params)); > > - if (cpu_is_omap34xx()) > + /* TODO: Currently, MODE_ELEMENT == MODE_FRAME */ > + if (cpu_is_omap34xx() && > + (dma_data->dma_op_mode == MCBSP_DMA_MODE_THRESHOLD)) > sync_mode = OMAP_DMA_SYNC_FRAME; > else > sync_mode = OMAP_DMA_SYNC_ELEMENT; Note, you could avoid the compile error if you move this into omap-mcbsp.c and pass only sync_mode here. Probably as easy as dma_data->sync_mode since OMAP_DMA_SYNC_ELEMENT is zero. The McBSP DAI must and can know the DMA parameters (like sync_mode) but otherwise (like MCBSP_DMA_MODE_xxx) it sounds unnecessary glue between the drivers. > @@ -193,9 +195,16 @@ static int omap_pcm_trigger(struct snd_pcm_substream > *substream, int cmd) > struct omap_pcm_dma_data *dma_data = prtd->dma_data; > unsigned long flags; > int ret = 0; > - int samples = snd_pcm_lib_period_bytes(substream) >> 1; > + int samples; > > spin_lock_irqsave(&prtd->lock, flags); > + > + /* TODO: Currently, MODE_ELEMENT == MODE_FRAME */ > + if (dma_data->dma_op_mode == MCBSP_DMA_MODE_THRESHOLD) > + samples = snd_pcm_lib_period_bytes(substream) >> 1; > + else > + samples = 1; > + Can these lines in this patch and in patch 15 to be moved into omap_mcbsp_trigger? For me it looks it would simplify and remove the glue between the drivers. -- Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
