[alsa-devel] [PATCHv2 - CA0132 HDA Codec 1/2] ALSA: Update Creative CA0132 codec to add DSP features.

[Takashi Iwai]

At Mon, 30 Jul 2012 15:49:00 -0700,
Ian Minett wrote:
> 
> >> One thought we have is to handle the spin_lock_irqxxx() as a special
> >> case or quirk for the CA0132 codec. Using an approach similar to
> >> 'needs_damn_long_delay' in the CA0110 patch, we could define another
> >> flag e.g. 'needs_trigger_irqsave' in hda_codec.h struct hda_bus{}. In
> >> the CA0132 patch, we would set this flag, which would then be read in
> >> hda_intel.c,azx_pcm_trigger(). Either spin_lock_irqxxx() or the current
> >> spin_lock() would then be called depending on the flag condition.
> >> What is your opinion on an approach like this? Would this be acceptable?
> 
> >No.  The fact that you are calling the PCM functions is already
> >wrong.  The irqsave() is just a side-effect by that, and we can forget
> >about it completely now.
> 
> >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.


thanks,

Takashi