[alsa-devel] [PATCHv2 - CA0132 HDA Codec 1/2] ALSA: Update Creative CA0132 codec to add DSP features.
tiwai at suse.de
Wed Aug 1 07:48:02 CEST 2012
At Tue, 31 Jul 2012 19:38:05 -0700,
Ian Minett wrote:
> >>>The only question is where to implement the DSP loader stuff and how.
> >> Ok, we understand. Given that the codec cannot call into the controller's
> >> PCM interface to load the DSP image, is there an acceptable way you could
> >> recommend for us to add this functionality to the module, without breaking
> >> the architecture?
> >Well, as mentioned earlier, we need to push it up to the controller
> >layer, i.e. hda_intel.c. For example, add a new op for firmware DMA
> >transfer in hda_bus_ops.
> >Could you describe briefly the procedure for the DMA transfer of
> >CA0132? The code looks too complex to follow.
> Sure - the DSP code download procedure is:
> 1. The CA0132 driver extracts DSP data segments that need to download to
> the DSP chip.
> 2. Each of these data segments will be downloaded to the DSP chip via
> HDA-link, like audio data.
> 3. The HDA controller and CA0132 are programmed to transfer the DSP data
So, the data transfer here is just like the normal PCM streaming?
For example, if you have an op like
int (*load_dsp)(struct hda_bus *bus, void *buffer, int size);
and calling this for each segment would work?
(In addition, we'd need to give some way to determine the stop
condition in the codec side.)
> 4. The HDA controller FIFO must be flushed on every data segment to ensure
> that there is no previous residual data.
Actually FIFO flush might be needed for the audio transfer as well.
> These are the controller ops that the CA0132 driver used for the DMA transfer:
> #define azx_pcm_open(a) (a->ops->open(a))
> #define azx_pcm_close(a) (a->ops->close(a))
> #define azx_pcm_prepare(a) (a->ops->prepare(a))
> #define azx_pcm_trigger(a, b) (a->ops->trigger(a, b))
> #define azx_pcm_hw_free(a) (a->ops->hw_free(a))
More information about the Alsa-devel