linux-toradex.git/include/sound/soc-dai.h, branch v3.7.2

ASoC: add definations for compressed operations

2012-08-20T19:50:37+00:00

Here we update the asoc structures to add compress stream definations
First the struct snd_soc_dai_driver adds a new member to indicate if the dai is
compressed or pcm. Next we add a new structre the struct snd_soc_compr_ops in
the struct snd_soc_dai_link. This is to be used for machine driver to perform
any opertaions required for setting up compressed audio streams

next is the compressed data operations, they are added using struct
snd_compr_ops in the struct snd_soc_platform_driver.

Signed-off-by: Namarta Kohli 
Signed-off-by: Ramesh Babu K V 
Signed-off-by: Vinod Koul 
Signed-off-by: Mark Brown

ASoC: core: Allow DAIs to specify a base address

2012-05-02T14:42:27+00:00

Devices with many DAIs are becoming more and more common, and generally
the more modern devices have consistent register layouts between DAIs.
Rather than have drivers open code lookups based on the DAI ID or cause
uglification in UI by having register addresses for IDs provide a base
address field they can use.

Signed-off-by: Mark Brown 
Acked-by: Liam Girdwood

ASoC: dpcm: Add bespoke trigger()

2012-04-26T16:48:42+00:00

Some on SoC DSP HW is very tightly coupled with DMA and DAI drivers. It's
necessary to allow some flexability wrt to PCM operations here so that we
can define a bespoke DPCM trigger() PCM operation for such HW.

A bespoke DPCM trigger() allows exact ordering and timing of component
triggering by allowing a component driver to manage the final enable
and disable configurations without adding extra complexity to other
component drivers. e.g. The McPDM DAI and ABE are tightly coupled on
OMAP4 so we have a bespoke trigger to manage the trigger to improve
performance and reduce complexity when triggering new McPDM BEs.

Signed-off-by: Liam Girdwood 
Signed-off-by: Mark Brown

ASoC: core: Add platform DAI widget mapping

2012-04-01T10:28:21+00:00

Add platform driver support for CPU DAI DAPM widgets.

Signed-off-by: Liam Girdwood 
Signed-off-by: Mark Brown

ASoC: core: Split the union for CODEC/platform in the DAI

2012-03-04T13:44:01+00:00

There's now core code which falls back to global CODEC operations for
DAI calls that needs to be able to tell if it's dealing with a CPU or
CODEC DAI and given the small number of DAIs in a typical system and
overall memory usage pattern saving a pointer per DAI is really not
worth the effort.

Reported-by: Ian Lartey 
Signed-off-by: Mark Brown 
Acked-by: Liam Girdwood

ASoC: dapm: Implement and instantiate DAI widgets

2012-02-17T16:10:10+00:00

In order to allow us to do smarter things with DAI links create DAPM
widgets which directly represent the DAIs in the DAPM graph. These are
automatically created from the DAIs as we probe the card with references
held in both directions between the widget and the DAI.

The widgets are not made available for direct instantiation by drivers,
they are created automatically from the DAIs.  Drivers should be updated
to create stream routes using DAPM maps rather than by annotating AIF
and DAC widgets with streams.

In order to ease transition to this model from existing drivers we
automatically create DAPM routes between the DAI widgets and the existing
stream widgets which are started and stopped by the DAI widgets, though
the old stream handling mechanism is still in place.  This also has the
nice effect of removing non-DAPM devices as any device with a DAI
acquires a widget automatically which will allow future simplifications
to the core DAPM logic.

The intention is that in future the AIF and DAI widgets will gain the
ability to interact such that we are able to manage activity on
individual channels independantly rather than powering up and down the
entire AIF as we do currently.

Currently we only generate these for CODECs, mostly as I have no systems
with non-CODEC DAPM to integrate with. It should be a simple matter of
programming to add the additional hookup for these.

Signed-off-by: Mark Brown 
Acked-by: Liam Girdwood

ASoC: Allow DAI formats to be specified in the dai_link

2011-09-28T12:22:28+00:00

For almost all machines the DAI format is a constant, always set to the
same thing. This means that not only should we normally set it on init
rather than in hw_params() (where it has been for historical reasons) we
should also allow users to configure this by setting a variable in the
dai_link structure. The combination of these two will make many machine
drivers even more data driven.

Implement a new dai_fmt field in the dai_link doing just that. Since 0 is
a valid value for many format flags and we need to be able to tell if the
field is actually set also add one to all the values used to configure
formats.

Signed-off-by: Mark Brown

ASoC: soc-core: symmetry checking for each DAIs separately

2011-09-21T14:59:46+00:00

The orginal code does not cover the case that one DAI such as codec
may be shared between other two DAIs(CPU).
When do symmetry checking, altough the codec DAI requires symmetry,
the two CPU DAIs may still be configured to run on different rates.

We change to check each DAI's state separately instead of only checking
the dai link to prevent this issue.

Signed-off-by: Dong Aisheng 
Tested-by: Wolfram Sang 
Acked-by: Liam Girdwood 
Signed-off-by: Mark Brown

ASoC: core - Allow components to probe/remove in sequence.

2011-06-07T17:38:27+00:00

Some ASoC components depend on other ASoC components to provide clocks and
power resources in order to probe() and vice versa for remove().

Allow components to be ordered so that components can be probed() and removed()
in sequences that conform to their dependencies.

Signed-off-by: Liam Girdwood 
Signed-off-by: Mark Brown

ASoC: Make the DAI ops constant in the DAI structure

2010-12-03T12:17:43+00:00

Neither drivers nor the core should be fiddling with the actual ops
structure at runtime.

Signed-off-by: Mark Brown 
Acked-by: Liam Girdwood