<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/include/sound/soc.h, branch linux-3.5.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>ASoC: dpcm: Add bespoke trigger()</title>
<updated>2012-04-26T16:48:42+00:00</updated>
<author>
<name>Liam Girdwood</name>
<email>lrg@ti.com</email>
</author>
<published>2012-04-25T11:12:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=07bf84aaf736781a283b1bd36eaa911453b14574'/>
<id>07bf84aaf736781a283b1bd36eaa911453b14574</id>
<content type='text'>
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 &lt;lrg@ti.com&gt;
Signed-off-by: Mark Brown &lt;broonie@opensource.wolfsonmicro.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;lrg@ti.com&gt;
Signed-off-by: Mark Brown &lt;broonie@opensource.wolfsonmicro.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ASoC: dpcm: Add API for DAI link substream and runtime lookup</title>
<updated>2012-04-26T16:48:19+00:00</updated>
<author>
<name>Liam Girdwood</name>
<email>lrg@ti.com</email>
</author>
<published>2012-04-25T11:12:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=47c88ffff73d27425be59b34a6d5a91518b5ebed'/>
<id>47c88ffff73d27425be59b34a6d5a91518b5ebed</id>
<content type='text'>
Some component drivers will need to be able to look up their
DAI link substream and RTD data. Provide a mechanism for this.

Signed-off-by: Liam Girdwood &lt;lrg@ti.com&gt;
Signed-off-by: Mark Brown &lt;broonie@opensource.wolfsonmicro.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Some component drivers will need to be able to look up their
DAI link substream and RTD data. Provide a mechanism for this.

Signed-off-by: Liam Girdwood &lt;lrg@ti.com&gt;
Signed-off-by: Mark Brown &lt;broonie@opensource.wolfsonmicro.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ASoC: dpcm: Add debugFS support for DPCM</title>
<updated>2012-04-26T16:48:19+00:00</updated>
<author>
<name>Liam Girdwood</name>
<email>lrg@ti.com</email>
</author>
<published>2012-04-25T11:12:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f86dcef87b771935c223334324a93c1d71f7a84c'/>
<id>f86dcef87b771935c223334324a93c1d71f7a84c</id>
<content type='text'>
Add debugFS files for DPCM link management information.

Signed-off-by: Liam Girdwood &lt;lrg@ti.com&gt;
Signed-off-by: Mark Brown &lt;broonie@opensource.wolfsonmicro.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add debugFS files for DPCM link management information.

Signed-off-by: Liam Girdwood &lt;lrg@ti.com&gt;
Signed-off-by: Mark Brown &lt;broonie@opensource.wolfsonmicro.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ASoC: dpcm: Add Dynamic PCM core operations.</title>
<updated>2012-04-26T16:48:19+00:00</updated>
<author>
<name>Liam Girdwood</name>
<email>lrg@ti.com</email>
</author>
<published>2012-04-25T11:12:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=01d7584cd2e5a93a2b959c9dddaa0d93ec205404'/>
<id>01d7584cd2e5a93a2b959c9dddaa0d93ec205404</id>
<content type='text'>
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.

Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.

e.g. pcm:0,0 routing digital data to 2 external codecs.

FE pcm:0,0  ----&gt; BE (McBSP.0) ----&gt; CODEC 0
             +--&gt; BE (McPDM.0) ----&gt; CODEC 1

e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.

FE pcm:0,0 ---
             +--&gt; BE (McBSP.0) ----&gt; CODEC
FE pcm:0,1 ---

The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.

DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.

Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.

This patch adds the core DPCM code and contains :-

 o The FE and BE PCM operations.
 o FE and BE DAI link support.
 o FE and BE PCM creation.
 o BE support API.
 o BE and FE link management.

Signed-off-by: Liam Girdwood &lt;lrg@ti.com&gt;
Signed-off-by: Mark Brown &lt;broonie@opensource.wolfsonmicro.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.

Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.

e.g. pcm:0,0 routing digital data to 2 external codecs.

FE pcm:0,0  ----&gt; BE (McBSP.0) ----&gt; CODEC 0
             +--&gt; BE (McPDM.0) ----&gt; CODEC 1

e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.

FE pcm:0,0 ---
             +--&gt; BE (McBSP.0) ----&gt; CODEC
FE pcm:0,1 ---

The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.

DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.

Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.

This patch adds the core DPCM code and contains :-

 o The FE and BE PCM operations.
 o FE and BE DAI link support.
 o FE and BE PCM creation.
 o BE support API.
 o BE and FE link management.

Signed-off-by: Liam Girdwood &lt;lrg@ti.com&gt;
Signed-off-by: Mark Brown &lt;broonie@opensource.wolfsonmicro.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ASoC: core: Add strobe control</title>
<updated>2012-04-23T19:05:06+00:00</updated>
<author>
<name>Kristoffer KARLSSON</name>
<email>kristoffer.karlsson@stericsson.com</email>
</author>
<published>2012-04-20T09:32:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=dd7b10b30c40dddb9750926d78cfe89c0cd8434d'/>
<id>dd7b10b30c40dddb9750926d78cfe89c0cd8434d</id>
<content type='text'>
Added support for a control that strobes a bit in
a register to high then back to low (or the inverse).

This is typically useful for hardware that requires
strobing a singe bit to trigger some functionality
and where exposing the bit in a normal single control
would require the user to first manually set then
again unset the bit again for the strobe to trigger.

Added convenience macro.

SOC_SINGLE_STROBE

Added accessor implementations.

snd_soc_get_strobe
snd_soc_put_strobe

Signed-off-by: Kristoffer KARLSSON &lt;kristoffer.karlsson@stericsson.com&gt;
Signed-off-by: Mark Brown &lt;broonie@opensource.wolfsonmicro.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Added support for a control that strobes a bit in
a register to high then back to low (or the inverse).

This is typically useful for hardware that requires
strobing a singe bit to trigger some functionality
and where exposing the bit in a normal single control
would require the user to first manually set then
again unset the bit again for the strobe to trigger.

Added convenience macro.

SOC_SINGLE_STROBE

Added accessor implementations.

snd_soc_get_strobe
snd_soc_put_strobe

Signed-off-by: Kristoffer KARLSSON &lt;kristoffer.karlsson@stericsson.com&gt;
Signed-off-by: Mark Brown &lt;broonie@opensource.wolfsonmicro.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ASoC: core: Add signed multi register control</title>
<updated>2012-04-23T19:05:06+00:00</updated>
<author>
<name>Kristoffer KARLSSON</name>
<email>kristoffer.karlsson@stericsson.com</email>
</author>
<published>2012-04-20T09:32:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4183eed288f31c3b9142476915e842f879f36b8e'/>
<id>4183eed288f31c3b9142476915e842f879f36b8e</id>
<content type='text'>
Added control type that can span multiple consecutive codec registers
forming a single signed value in a MSB/LSB manner.
The control dynamically adjusts to the register word size configured
in driver.

Added convenience macro.

SOC_SINGLE_XR_SX

Added accessor implementations.

snd_soc_info_xr_sx
snd_soc_get_xr_sx
snd_soc_put_xr_sx

Signed-off-by: Kristoffer KARLSSON &lt;kristoffer.karlsson@stericsson.com&gt;
Signed-off-by: Mark Brown &lt;broonie@opensource.wolfsonmicro.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Added control type that can span multiple consecutive codec registers
forming a single signed value in a MSB/LSB manner.
The control dynamically adjusts to the register word size configured
in driver.

Added convenience macro.

SOC_SINGLE_XR_SX

Added accessor implementations.

snd_soc_info_xr_sx
snd_soc_get_xr_sx
snd_soc_put_xr_sx

Signed-off-by: Kristoffer KARLSSON &lt;kristoffer.karlsson@stericsson.com&gt;
Signed-off-by: Mark Brown &lt;broonie@opensource.wolfsonmicro.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ASoC: core: Support transparent CODEC&lt;-&gt;CODEC DAI links</title>
<updated>2012-04-16T18:36:29+00:00</updated>
<author>
<name>Mark Brown</name>
<email>broonie@opensource.wolfsonmicro.com</email>
</author>
<published>2012-04-04T21:12:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c74184ed30ecce2a5e9ae9aa22cb5e3942e0c7c7'/>
<id>c74184ed30ecce2a5e9ae9aa22cb5e3942e0c7c7</id>
<content type='text'>
Rather than having the user half start a stream but avoid any DMA to
trigger data flow on links which don't pass through the CPU create a
DAPM route between the two DAI widgets using a hw_params configuration
provided by the machine driver with the new 'params' member of the
dai_link struct.  If no configuration is provided in the dai_link then
use the old style even for CODEC&lt;-&gt;CODEC links to avoid breaking
systems.

This greatly simplifies the userspace usage of such links, making them
as simple as analogue connections with the stream configuration being
completely transparent to them.

This is achieved by defining a new dai_link widget type which is created
when CODECs are linked and triggering the configuration of the link via
the normal PCM operations from there.  It is expected that the bias
level callbacks will be used for clock configuration.

Currently only the DAI format, rate and channel count can be configured
and currently the only DAI operations which can be called are hw_params
and digital_mute().  This corresponds well to the majority of CODEC
drivers which only use other callbacks for constraint setting but there
is obviously much room for extension here.  We can't simply call
hw_params() on startup as things like the system clocking configuration
may change at runtime and in future it will be desirable to offer some
configurability of the link parameters.

At present we are also restricted to a single DAPM link for the entire
DAI.  Once we have better support for channel mapping it would also be
desirable to extend this feature so that we can propagate per-channel
power state over the link.

Signed-off-by: Mark Brown &lt;broonie@opensource.wolfsonmicro.com&gt;
Acked-by: Liam Girdwood &lt;lrg@ti.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Rather than having the user half start a stream but avoid any DMA to
trigger data flow on links which don't pass through the CPU create a
DAPM route between the two DAI widgets using a hw_params configuration
provided by the machine driver with the new 'params' member of the
dai_link struct.  If no configuration is provided in the dai_link then
use the old style even for CODEC&lt;-&gt;CODEC links to avoid breaking
systems.

This greatly simplifies the userspace usage of such links, making them
as simple as analogue connections with the stream configuration being
completely transparent to them.

This is achieved by defining a new dai_link widget type which is created
when CODECs are linked and triggering the configuration of the link via
the normal PCM operations from there.  It is expected that the bias
level callbacks will be used for clock configuration.

Currently only the DAI format, rate and channel count can be configured
and currently the only DAI operations which can be called are hw_params
and digital_mute().  This corresponds well to the majority of CODEC
drivers which only use other callbacks for constraint setting but there
is obviously much room for extension here.  We can't simply call
hw_params() on startup as things like the system clocking configuration
may change at runtime and in future it will be desirable to offer some
configurability of the link parameters.

At present we are also restricted to a single DAPM link for the entire
DAI.  Once we have better support for channel mapping it would also be
desirable to extend this feature so that we can propagate per-channel
power state over the link.

Signed-off-by: Mark Brown &lt;broonie@opensource.wolfsonmicro.com&gt;
Acked-by: Liam Girdwood &lt;lrg@ti.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ASoC: core: Rework SOC_DOUBLE_R_SX_TLV add SOC_SINGLE_SX_TLV</title>
<updated>2012-04-03T10:43:23+00:00</updated>
<author>
<name>Brian Austin</name>
<email>brian.austin@cirrus.com</email>
</author>
<published>2012-03-30T15:43:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1d99f2436d0d1c7741d6dfd9d27b5376cdbbca40'/>
<id>1d99f2436d0d1c7741d6dfd9d27b5376cdbbca40</id>
<content type='text'>
Some codecs namely Cirrus Logic Codecs have a way of wrapping the dB scale around 0dB without 0dB being in the middle.

Rework of SOC_DOUBLE_R_SX_TLV to be more consistent with other asoc tlv macros.
Add single register macro : SOC_SINGLE_SX_TLV.
Use snd_soc_info_volsw for .info
Use snd_soc_get_volsw_sx, snd_soc_put_volsw_sx for single and double.

kcontrols for CS42L51 and CS42L73 are adjusted to these new TLV Macros.

The max value is determined by: (number of steps) +1 for 0dB +max from codec datasheet.

Signed-off-by: Brian Austin &lt;brian.austin@cirrus.com&gt;
Acked-by: Liam Girdwood &lt;lrg@ti.com&gt;
Signed-off-by: Mark Brown &lt;broonie@opensource.wolfsonmicro.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Some codecs namely Cirrus Logic Codecs have a way of wrapping the dB scale around 0dB without 0dB being in the middle.

Rework of SOC_DOUBLE_R_SX_TLV to be more consistent with other asoc tlv macros.
Add single register macro : SOC_SINGLE_SX_TLV.
Use snd_soc_info_volsw for .info
Use snd_soc_get_volsw_sx, snd_soc_put_volsw_sx for single and double.

kcontrols for CS42L51 and CS42L73 are adjusted to these new TLV Macros.

The max value is determined by: (number of steps) +1 for 0dB +max from codec datasheet.

Signed-off-by: Brian Austin &lt;brian.austin@cirrus.com&gt;
Acked-by: Liam Girdwood &lt;lrg@ti.com&gt;
Signed-off-by: Mark Brown &lt;broonie@opensource.wolfsonmicro.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ASoC: core: Use driver core probe deferral</title>
<updated>2012-04-01T10:28:23+00:00</updated>
<author>
<name>Mark Brown</name>
<email>broonie@opensource.wolfsonmicro.com</email>
</author>
<published>2012-03-14T21:18:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b19e6e7b763c7144bfe2ceccf988b64d66d6dd0a'/>
<id>b19e6e7b763c7144bfe2ceccf988b64d66d6dd0a</id>
<content type='text'>
In version 3.4 the driver core acquired probe deferral which is a core way
of doing essentially the same thing as ASoC has been doing since forever
to make sure that all the devices needed to make up the card are present
without needing open coding in the subsystem.

Make basic use of this probe deferral mechanism for the cards, removing the
need to handle partially instantiated cards. We should be able to remove
even more code than this, though some of the checks we're currently doing
should stay since they're about things like suppressing unneeded DAPM runs
rather than deferring probes.

In order to avoid robustness issues with our teardown paths (which do need
quite a bit of TLC) add a check for aux_devs prior to attempting to set
things up, this means that we've got a reasonable idea that everything will
be there before we start. As with the removal of partial instantiation
support more work will be needed to make this work neatly.

Signed-off-by: Mark Brown &lt;broonie@opensource.wolfsonmicro.com&gt;
Acked-by: Liam Girdwood &lt;lrg@ti.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In version 3.4 the driver core acquired probe deferral which is a core way
of doing essentially the same thing as ASoC has been doing since forever
to make sure that all the devices needed to make up the card are present
without needing open coding in the subsystem.

Make basic use of this probe deferral mechanism for the cards, removing the
need to handle partially instantiated cards. We should be able to remove
even more code than this, though some of the checks we're currently doing
should stay since they're about things like suppressing unneeded DAPM runs
rather than deferring probes.

In order to avoid robustness issues with our teardown paths (which do need
quite a bit of TLC) add a check for aux_devs prior to attempting to set
things up, this means that we've got a reasonable idea that everything will
be there before we start. As with the removal of partial instantiation
support more work will be needed to make this work neatly.

Signed-off-by: Mark Brown &lt;broonie@opensource.wolfsonmicro.com&gt;
Acked-by: Liam Girdwood &lt;lrg@ti.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ASoC: jack: Push locking for jacks down to the jack</title>
<updated>2012-04-01T10:28:23+00:00</updated>
<author>
<name>Mark Brown</name>
<email>broonie@opensource.wolfsonmicro.com</email>
</author>
<published>2012-03-12T14:07:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2667b4b8bef8598917adb1b4af46ed2b7d4fa0d7'/>
<id>2667b4b8bef8598917adb1b4af46ed2b7d4fa0d7</id>
<content type='text'>
Currently operations on jack reporting take the CODEC mutex both to protect
the current jack status and also to protect the DAPM run which is triggered
on status updates. Since the addition of a DAPM-specific lock we no longer
need to worry about locking DAPM as it has its own finer grained lock so
create a per jack lock to take care of the jack status.

This is both cleaner where the jack isn't specifically associated with a
CODEC and clearer as it's much more obvious what the lock is protecting.

Signed-off-by: Mark Brown &lt;broonie@opensource.wolfsonmicro.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently operations on jack reporting take the CODEC mutex both to protect
the current jack status and also to protect the DAPM run which is triggered
on status updates. Since the addition of a DAPM-specific lock we no longer
need to worry about locking DAPM as it has its own finer grained lock so
create a per jack lock to take care of the jack status.

This is both cleaner where the jack isn't specifically associated with a
CODEC and clearer as it's much more obvious what the lock is protecting.

Signed-off-by: Mark Brown &lt;broonie@opensource.wolfsonmicro.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
