[alsa-devel] [RFC 1/3] ASoC: dmaengine: Don't use runtime private data for dmaengine data

[Russell King - ARM Linux]

On Tue, Sep 04, 2012 at 04:26:28PM +0300, Peter Ujfalusi wrote:
> Hi Takashi,
> 
> On 09/04/2012 04:14 PM, Takashi Iwai wrote:
> >> Ok, it might have been helpful in the conversion process, but for the final
> >> patch it would be nice if you could replace
> >>
> >> struct snd_pcm_runtime *runtime = substream->runtime;
> >> struct omap_runtime_data *prtd = runtime->private_data;
> >> struct omap_pcm_dma_data *dma_data = prtd->dma_data;
> >> with
> >> struct omap_pcm_dma_data *dma_data = snd_dmaengine_pcm_get_data(substream);
> >>
> >> and in the hwparams callback use
> >>
> >> snd_dmaengine_pcm_set_data(substream, dma_data);
> >>
> >> and then drop patch 1 and 2 from the series.
> > 
> > We discussed with Liam about the addition of new field in ALSA core,
> > and concluded that a bit different approach, at least, more generic
> > name is preferred, even if a new field is inevitably needed.
> > 
> > So, eventually some change may happen in near future in ALSA core
> > side, but still it'd be really helpful if the callers have been
> > standardized beforehand with a helper function like above.
> 
> If the omap-pcm dmaengine conversion works on all OMAP versions (from OMAP1 to
> OMAP5) it is possible to avoid the additional field.
> My main concern at the moment is if we will need two sets of drivers to
> support OMAP1 and OMAP2/3/4/5.
> In all case we use the same omap-mcbsp driver which would need deal with two
> different type of ASoC platform driver (dmaengine and non-dmaengine).
> I hope we get confirmation from Janusz soon regarding to OMAP1 with dmaengine
> so we can plan on how to move forward.

As the target for the DMA engine work is to kill off the OMAP private DMA
APIs, then if OMAP1 doesn't work with the OMAP DMA engine driver, that's
what needs fixing, rather than having two ASoC platform drivers.

Note that time is ticking for the removal of the OMAP private DMA APIs (see
feature-removal-schedule.txt) and it has to happen so that the next stage
of the OMAP DMA engine conversion can happen - that is, to make the OMAP
DMA engine support be a proper driver rather than just a DMA Engine to OMAP
private DMA API conversion shim.