Add debugFS files for DPCM link management information.
Signed-off-by: NLiam Girdwood <lrg@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

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  ----> BE (McBSP.0) ----> CODEC 0
             +--> BE (McPDM.0) ----> CODEC 1

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

FE pcm:0,0 ---
             +--> BE (McBSP.0) ----> 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: NLiam Girdwood <lrg@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Currently stream events are only perfomed on codec stream widgets only.
There is now a need to be able to perform stream events on platform
widgets too.

e.g. we have the ABE platform driver with several DAI links
to dummy codecs. We need to be able to perform stream events on any
of the dummy codec DAI links.

This patch also removes the snd_soc_dai * parameter since it's already
contained within the rtd * parameter.

Finally makle stream event return void since no one checks it anyway.
Signed-off-by: NLiam Girdwood <lrg@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

In order to allow us to do something smarter than iterate through widgets
doing strcmp() to work out what to power up for stream events change the
interface used to generate them to be based on the combination of a DAI
and a stream direction rather than just a simple string identifying the
stream.

At some point we'll probably want a set of channels too.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NLiam Girdwood <lrg@ti.com>

Since we've already got logic to special case immediate teardown of the
stream we may as well use it if the pmdown_time has been set to zero by
the application layer instead of scheduling a work item with zero delay.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NLiam Girdwood <lrg@ti.com>

Use the standard logging macros and use dev_ variants where we can, also
reporting error codes whenever we report an error. These changes (the
error codes in particular) make it noticeably easier to figure out what
went wrong just from the basic dmesg output.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NLiam Girdwood <lrg@ti.com>

As per discussion we can safely ignore the 8 and 16 bit sample
sizes when applying the msbits constraint.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

On the off chance that an application both pays attention and gets
confused.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Most devices accept data in formats that don't correspond directly to
their internal format. ALSA allows us to set a msbits constraint which
tells userspace about this in case it finds it useful (for example, in
order to avoid wasting effort dithering bits that will be ignored when
raising the sample size of data) so provide a mechanism for drivers to
specify the number of bits that are actually significant on a DAI and
add the appropriate constraints along with all the others.

This is done slightly awkwardly as the constraint is specified per sample
size - we loop over every possible sample size, including ones that the
device doesn't support and including ones that have fewer bits than are
actually used, but this is harmless as the upper layers do the right thing
in these cases.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NLiam Girdwood <lrg@ti.com>

The original code does not cover the case that two DAIs(CPU) have different
ASoC core PCM operations(like mmap, pointer...). Currently we have only one
global soc_pcm_ops for ASoC core PCM operation. When two DAIs have different
pointer functions, second DAI's pointer function is set for both first DAI
and second DAI in case of original code.

This patch uses runtime's pcm_ops instead of global pcm_ops for each DAIs. So
each DAIs can have different ASoC core PCM operations. This is needed to
support multiple DAIs.
Signed-off-by: NSangsu Park <sangsu4u.park@samsung.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Every device that implements runtime power management for DAIs is doing
it in pretty much the same way: in the startup callback they take a
runtime PM reference and then in the shutdown callback they release that
reference, keeping the device active while the DAI is active. Given the
frequency with which this is done and the obviousness of the need to keep
the device active in this period factor the code out into the core, taking
references on the device for each CPU DAI, CODEC DAI and DMA device in the
core.

As runtime PM is reference counted this shouldn't interfere with any
other reference holding by the drivers, and since (in common with the
existing implementations) we don't check for errors on enabling it
shouldn't matter if the device actually has runtime PM enabled or not.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Tested-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>

There's no point in adding unlikely() annotations outside of hot paths
and on systems using these features the annotation will always be wrong
(as opposed to being something that only comes up once in a while) so
the annotation may even be harmful.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

With this flag, each dai_link in machine driver can choose
to ignore pmdown_time during DAPM shut down sequence.

If the ignore_pmdown_time is set, the DAPM for corresponding DAI
will be executed immediately.
Signed-off-by: NRamesh Babu K V <ramesh.babu@linux.intel.com>
Signed-off-by: NVinod Koul <vinod.koul@linux.intel.com>
Acked-by: NLiam Girdwood <lrg@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

With this flag codec drivers can indicate that it is desired
to ignore the pmdown_time for DAPM shutdown sequence when
playback stream is stopped.
The DAPM sequence will be executed without delay in this case.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

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: NDong Aisheng <b29396@freescale.com>
Tested-by: NWolfram Sang <w.sang@pengutronix.de>
Acked-by: NLiam Girdwood <lrg@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

The ASoC core tries to not enforce symmetric rates when
two streams open simultaneously. It does so by checking
rtd->rate being zero. This works exactly once after booting
because it is not set to zero again when the streams close.
Fix this by setting rtd->rate when no active stream is left.

[This leads to lots of warnings about not enforcing the symmetry in some
situations as there's a race in the userspace API where we know we've
got two applications but don't know what rates they want to set.
-- broonie ]
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Since commit b8c0dab9
"ASoC: core - PCM mutex per rtd",
the global pcm_mutex is not being used any more.
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Make sure we follow naming convention for all PCM ops.
Signed-off-by: NLiam Girdwood <lrg@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

In preparation for the new ASoC Dynamic PCM support (AKA DSP support).

The new ASoC Dynamic PCM core allows DAIs to be dynamically re-routed
at runtime between the PCM device end (or Frontend - FE) and the physical DAI
(Backend - BE) using regular kcontrols (just like a hardware CODEC routes
audio in the analog domain). The Dynamic PCM core therefore must be
able to call PCM operations for both the Frontend and Backend(s) DAIs at
the same time.

Currently we have a global pcm_mutex that is used to serialise
the ASoC PCM operations. This patch removes the global mutex
and adds a mutex per RTD allowing the PCM operations to be reentrant and
allow control of more than one DAI at at time. e.g. a frontend PCM hw_params()
could configure multiple backend DAI hw_params() with similar or different
hw parameters at the same time.
Signed-off-by: NLiam Girdwood <lrg@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

In preparation for Dynamic PCM support (AKA DSP support).

There will be future patches that add support to allow PCMs to be dynamically
routed to multiple DAIs at startup and also during stream runtime. This patch
moves the ASoC core PCM operaitions into a new file called soc-pcm.c.  This will
in simplify the ASoC core features into distinct files.
Signed-off-by: NLiam Girdwood <lrg@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>