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

Takashi Iwai tiwai at suse.de
Wed Aug 8 09:22:53 CEST 2012

At Tue, 7 Aug 2012 17:27:59 -0700,
Ian Minett wrote:
> >Looks good, but I think start and stop can be a single trigger like
> >PCM op, something like:
> >
> >  int (*load_dsp_trigger)(struct hda_bus *bus, bool start);
> >
> >The second argument could be a generic int like PCM op, but I don't
> >think we'd need pause or suspend/resume command for DSP loader :)
> Hi Takashi,
> The proposed method for handling the DSP load process looks fine to
> us, and we can make a start on adding this to the CA0132 driver now.
> We can update patch_ca0132.c, but would you be able to assist us with
> the modifications to the hda_intel.c side at all? We think it might
> result in a smoother process (and involving fewer submissions :) )
> given your familiarity with the low-level architecture in that area.

Sure, just send me a draft version of your patch, so that I can work
on it.

> If not, we'd appreciate any info or pointers you can provide on how
> and where the necessary modifications need to be made to hda_intel.c.

You had already some working code but it was calling PCM ops.
When you see hda_intel.c, the necessary streaming operations can be
much easier implemented there instead of indirect call of PCM ops, if
you have a dedicated load_dsp_prepare and load_dsp_trigger. 
The current azx_pcm_trigger(), for example, looks fairly complex, but
it's simply because of the support for linked PCM streams.  If you can
assume a single stream, it's just a call of azx_stream_start() and

BTW, what would be the license of the firmware?
For upstreaming the firmware, you'd need to clarify its license.
You can see the license texts in kernel-firmware tree / package about
what other vendors give.



More information about the Alsa-devel mailing list