To support double channel shared controls split across 2 registers, one
for each channel, we must be able to update both registers together.
Add a second set of register fields to struct snd_soc_dapm_update, and
update the DAPM control writeback (put) callbacks to support this.
For codecs that use custom events which call into DAPM to do updates,
also clear struct snd_soc_dapm_update before using it, so the second
set of fields remains clean.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
This is useful outside the core, when one dapm element is added
at a time.
Signed-off-by: Subhransu S. Prusty <subhransu.s.prusty@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Certain situations may warrant examining DAPM paths only to a certain
arbitrary point, as opposed to always following them to the end. For
instance, when establishing a connection between a front-end DAI link
and a back-end DAI link in a DPCM path, it does not make sense to walk
the DAPM graph beyond the first widget associated with a back-end link.
This patch introduces a mechanism which lets a user of
dai_get_connected_widgets supply a function which will be called for
every node during the graph walk. When invoked, this function can
execute arbitrary logic to decide whether the walk, given a DAPM widget
and walk direction, should be terminated at that point or continued
as normal.
Signed-off-by: Piotr Stankiewicz <piotrs@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit 086d7f804e ("ASoC: Convert WM8962 MICBIAS to a supply widget",
2011-09-23) says:
A supply widget is generally clearer than a MICBIAS widget and a
mic bias is just a type of supply so use a supply widget for the
MICBIAS. This also avoids confusion with the routing when
connected to multiple inputs.
but this has never been documented as a policy. Add some comments to
make it clear.
Signed-off-by: John Keeping <john@metanate.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
DAPM models various widgets but lacks a sink widget.
DSPs can have modules which take audio data, process it and are
capable of generating events thus acting as a sink of data.
To make the dapm graph complete for such paths we need a dapm
sink widget for these modules, so add a SND_SOC_DAPM_SINK to
declare such a widget. This widget will be treated as
SND_SOC_DAPM_EP_SINK endpoint in the dapm graph
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
If there is anything in damp->path_source_cache or
damp->path_sink_cache, it can not be valid after the widgets have been
freed. Without this patch a repeated remove and load of a machine
driver may cause NULL pointer reference in dapm_wcache_lookup() when a
freed widget, not belonging to any list, is haunting in the wcache.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reported-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Given a kcontrol, we may want to access the parent widget
and it's associated data. So export function to return it.
Signed-off-by: Mythri P K <mythri.p.k@intel.com>
Signed-off-by: Jeeja KP <jeeja.kp@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
After the recent cleanups and generalizations of the DAPM algorithm the
handling of input and output paths is now fully symmetric. This means by
making some slight changes to the data structure and using arrays with one
entry for each direction, rather than separate fields, it is possible to
create a generic implementation that is capable of handling both input and
output paths.
Unfortunately this generalization significantly increases the code size on
the hot path of is_connected_{input,output}_ep() and
dapm_widget_invalidate_{input,output}_paths(), which has a negative impact
on the overall performance. The inner loops of those functions are quite
small and the generic implementation adds extra pointer arithmetic in a few
places.
Testing on ARM shows that the combined code size of the specialized
functions is about 50% larger than the generalized function in relative
numbers. But in absolute numbers its less than 200 bytes, which is still
quite small. On the other hand the generalized function increases the
execution time of dapm_power_one_widget() by 30%. Given that this function
is one of the most often called functions of the DAPM framework the
trade-off of getting better performance at expense of generating slightly
larger code at seems to be worth it.
To avoid this still keep two versions of these functions around, one for
input and one for output. But have a generic implementation of the
algorithm which gets inlined by those two versions. And then let the
compiler take care of optimizing it and removing he extra instructions.
This still reduces the source code size as well as the makes making changes
to the implementation more straight forward since the same change does no
longer need to be done in two separate places. Also on the slow paths we
can use a generic implementations that handle both input and output paths.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add helper iterator macros for iterating over the source and sink paths of
widget. This will make it easier to change the implementation later on.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
snd_soc_tplg_widget_remove_all() has a verbatim copy of an older version of
the widget freeing code from dapm_free_widgets(). Add a new helper function
that takes care of freeing a widget and use it in both places.
This removes the duplicated code and also makes sure that future changes to
the widget freeing code only have to be made in one location.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
The topology core parses the FW topology file for known block types and
instanciates any common ALSA/ASoC objects that it discovers. The core
also passes any block that is does not understand to client component
drivers for enumeration.
The core exports some APIs to client drivers in order to load and unload
firmware topology data as use case require.
Currently the core deals with the following object types :-
o kcontrols. This includes TLV, enumerated and bytes controls.
o DAPM widgets. All types with any associated kcontrol.
o DAPM graph.
o FE PCM. FE PCM capabilities and configuration can be defined.
o BE DAI Link. BE DAI link capabilities and configuration can be defined.
o Codec <-> codec style links capabilities and configuration.
Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The ASoC topology UAPI header defines the structures
required to define any DSP firmware audio topology and control objects from
userspace.
The following objects are supported :-
o kcontrols including TLV controls.
o DAPM widgets and graph elements
o Vendor bespoke objects.
o Coefficient data
o FE PCM capabilities and config.
o BE link capabilities and config.
o Codec <-> codec link capabilities and config.
o Topology object manifest.
The file format is simple and divided into blocks for each object type and
each block has a header that defines it's size and type. Blocks can be in
any order of type and can either all be in a single file or spread across
more than one file. Blocks also have a group identifier ID so that they can
be loaded and unloaded by ID.
Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Some CODECs have a significant number of DAPM routes and for each route,
when it is added to the card, the entire card widget list must be
searched. When adding routes it is very likely, however, that adjacent
routes will require adjacent widgets. For example all the routes for a
mux are likely added in a block and the sink widget will be the same
each time and it is also quite likely that the source widgets are
sequential located in the widget list.
This patch adds a cache to the DAPM context, this cache will hold the
source and sink widgets from the last call to snd_soc_dapm_add_route for
that context. A small search of the widget list will be made from those
points for both the sink and source. Currently this search only checks
both the last widget and the one adjacent to it.
On wm8280 which has approximately 500 widgets and 30000 routes (one of
the largest CODECs in mainline), the number of paths that hit the cache
is 24000, which significantly improves probe time.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
A demux is conceptually similar to a mux. Where a mux has multiple input
and one output and selects one of the inputs to be connected to the output,
the demux has one input and multiple outputs and selects one of the outputs
to which the input gets connected.
This similarity makes it straight forward to support them in DAPM using the
existing mux support, we only need to swap sinks and sources when initially
setting up the paths.
The only slightly tricky part is that there can only be one control per
path. Since mixers/muxes are at the sink of a path and a demux is at the
source and both types want a control it is not possible to directly connect
a demux output to a mixer/mux input. The patch adds some sanity checks to
make sure that this does not happen.
Drivers who want to model hardware which directly connects a demux output
to a mixer/mux input can do this by inserting a dummy widget between the
two. E.g.:
{ "Dummy", "Demux Control", "Demux" },
{ "Mixer", "Mixer Control", "Dummy" },
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently drivers are responsible for managing the bias_level field of
their DAPM context. The DAPM state itself is managed by the DAPM core
though and the core has certain expectations on how and when the bias_level
field should be updated. If drivers don't adhere to these undefined
behavior can occur.
This patch adds a few helper functions for manipulating the DAPM context
state, each function with a description on when it should be used and what
its effects are. This will also help us to move more of the bias_level
management from drivers to the DAPM core.
For convenience also add snd_soc_codec_* wrappers around these helpers.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Correct small copy and paste error where autodisable was not being
enabled for the SOC_DAPM_SINGLE_TLV_AUTODISABLE control.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
The delayed_work field in the snd_soc_dapm_context struct is now unused and
can be removed. Removing it reduces the size of the snd_soc_dapm_context
struct by ~50% from 100 bytes to 48 bytes.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The only two users of the suspend_bias_level field were two rather old
drivers which weren't exactly doing things by the book. Those drivers have
been updated and field is now unused and can be removed.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
dai-link params for codec-codec links were fixed. The fixed
link between codec and another chip which may be another codec,
baseband, bluetooth codec etc may require run time configuaration
changes. This change provides an optional alsa control to select
one of the params from a list of params.
Signed-off-by: Nikesh Oswal <nikesh@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
snd_soc_dapm_kcontrol_codec() is a extremely simple function and inlining it
typically results in less code than necessary for calling the non-inlined
version of the function.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Instead of calling device_create_file() manually, assign the static
attribute group entries at the device registration. This simplifies
the error handling and avoids the possible races.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
There are no more users of this field left so it can finally be removed.
New users should use snd_soc_dapm_to_codec(w->dapm);
The reason why it is removed is because it doesn't fit to well anymore in
the componentized ASoC hierarchy, where DAPM works on the snd_soc_component
level. And the alternative of snd_soc_dapm_to_codec(w->dapm) typically
generates the same amount of code, so there is really no reason to keep it.
For automatic conversion the following coccinelle semantic patch can be used:
// <smpl>
@@
struct snd_soc_dapm_widget *w;
@@
-w->codec
+snd_soc_dapm_to_codec(w->dapm)
// </smpl>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
For legacy reasons the ASoC framework assumes that a CODEC INPUT or OUTPUT
widget that is not explicitly connected to a external source or sink is
potentially connected to a source or a sink and hence the framework treats
the widget itself as source (for INPUT) or sink (for OUTPUT). For this
reason a INPUT or OUTPUT widget that is really not connected needs to be
explicitly marked as so.
Setting the card's fully_routed flag will cause the ASoC core, once that all
widgets and routes have been registered, to go through the list of all
widgets and mark all INPUT and OUTPUT that are not externally connected as
non-connected. This essentially negates the default behaviour of treating
INPUT or OUTPUT widgets without external routes as sources or sinks.
This patch takes a different approach while getting the same result. Instead
of first marking INPUT and OUTPUT widgets as sinks/sources and then later
marking them as non-connected, just never mark them as a sink or a source if
the fully_routed flag is set on a card.
This requires a lot less code and also results in a slightly faster card
initialization since there is no need to iterate over all widgets and check
whether the INPUT and OUTPUT widgets are connected or not.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently we cache the number of input and output paths going to/from a
widget only within a power update sequence. But not in between power update
sequences.
But we know how changes to the DAPM graph affect the number of input (form a
source) and output (to a sink) paths of a widget and only need to
recalculate them if a operation has been performed that might have changed
them.
* Adding/removing or connecting/disconnecting a path means that the for
the source of the path the number of output paths can change and for
the sink the number of input paths can change.
* Connecting/disconnecting a widget has the same effect has connecting/
disconnecting all paths of the widget. So for the widget itself the
number of inputs and outputs can change, for all sinks of the widget
the number of inputs can change and for all sources of the widget the
number of outputs can change.
* Activating/Deactivating a stream can either change the number of
outputs on the sources of the widget associated with the stream or the
number of inputs on the sinks.
Instead of always invalidating all cached numbers of input and output paths
for each power up or down sequence this patch restructures the code to only
invalidate the cached numbers when a operation that might change them has
been performed. This can greatly reduce the number of DAPM power checks for
some very common operations.
Since per DAPM operation typically only either change the number of inputs
or outputs the number of path checks is reduced by at least 50%. The number
of neighbor checks is also reduced about the same percentage, but since the
number of neighbors encountered when walking from sink to source is not the
same as when walking from source to sink the actual numbers will slightly
vary from card to card (e.g. for a mixer we see 1 neighbor when walking from
source to sink, but the number of inputs neighbors when walking from source
to sink).
Bigger improvements can be observed for widgets with multiple connected
inputs and output (e.g. mixers probably being the most widespread form of
this). Previously we had to re-calculate the number of inputs and outputs
on all input and output paths. With this change we only have to re-calculate
the number of outputs on the input path that got changed and the number of
inputs on the output paths.
E.g. imagine the following example:
A --> B ----.
v
M --> N --> Z <-- S <-- R
|
v
X
Widget Z has multiple input paths, if any change was made that cause Z to be
marked as dirty the power state of Z has to be re-computed. This requires to
know the number of inputs and outputs of Z, which requires to know the
number of inputs and outputs of all widgets on all paths from or to Z.
Previously this meant re-computing all inputs and outputs of all the path
going into or out of Z. With this patch in place only paths that actually
have changed need to be re-computed.
If the system is idle (or the part of the system affected by the changed
path) the number of path checks drops to either 0 or 1, regardless of how
large or complex the DAPM context is. 0 if there is no connected sink and no
connected source. 1 if there is either a connected source or sink, but not
both. The number of neighbor checks again will scale accordingly and will be
a constant number that is the number of inputs or outputs of the widget for
which we did the path check.
When loading a state file or switching between different profiles typically
multiple mixer and mux settings are changed, so we see the benefit of this
patch multiplied for these kinds of operations.
Testing with the ADAU1761 shows the following changes in DAPM stats for
changing a single Mixer switch for a Mixer with 5 inputs while the DAPM
context is idle.
Power Path Neighbour
Before: 2 12 30
After: 2 1 2
For the same switch, but with a active playback stream the stat changed are
as follows.
Power Path Neighbour
Before: 10 20 54
After: 10 7 21
Cumulative numbers for switching the audio profile which changes 7 controls
while the system is idle:
Power Path Neighbour
Before: 16 80 170
After: 16 7 23
Cumulative numbers for switching the audio profile which changes 7 controls
while playback is active:
Power Path Neighbour
Before: 51 123 273
After: 51 29 109
Starting (or stopping) the playback stream:
Power Path Neighbour
Before: 34 34 117
After: 34 17 69
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
The state of endpoint widgets is affected by that card's power state.
Endpoint widgets that do no have the ignore_suspend flag set will be
considered inactive during suspend. So they have to be re-checked and marked
dirty after the card's power state changes. Currently the input and output
widgets are marked dirty instead, this works most of the time since
typically a path from one endpoint to another will go via a input or output
widget. But marking the endpoints dirty is technically more correct and will
also work for odd corner cases.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Supply widgets do not count towards the input and output widgets of their
neighbors and for supply widgets themselves we do not care for the number
of input or output paths. This means that a path that connects to a supply
widget effectively behaves the same as a path that as the weak property set.
This patch adds a new path flag that gets set to true when the path is
connected to at least one supply widget. If a path with the flag set is
encountered in is_connected_{input,output}_ep() is is skipped in the same
way that weak paths are skipped. This slightly brings down the number of
path checks.
Since both the weak and the supply flag are implemented as bitfields which
are stored in the same word there is no runtime overhead due to checking
both rather than just one and also the size of the path struct is not
increased by this patch. Another advantage is that we do not have to handle
supply widgets in is_connected_{input,output}_ep() anymore since it will
never be called for supply widgets. The only exception is from
dapm_widget_power_read_file() where a check is added to special case supply
widgets.
Testing with the ADAU1761, which has a handful of supply widgets, shows the
following changes in the DAPM stats for a playback stream start.
Power Path Neighbour
Before: 34 78 117
After: 34 48 117
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
DAPM widgets can be classified into four categories:
* supply: Supply widgets do not affect the power state of their
non-supply widget neighbors and unlike other widgets a
supply widget is not powered up when it is on an active
path, but when at least on of its neighbors is powered up.
* source: A source is a widget that receives data from outside the
DAPM graph or generates data. This can for example be a
microphone, the playback DMA or a signal generator. A source
widget will be considered powered up if there is an active
path to a sink widget.
* sink: A sink is a widget that transmits data to somewhere outside
of the DAPM graph. This can e.g. be a speaker or the capture
DMA. A sink widget will be considered powered up if there is
an active path from a source widget.
* normal: Normal widgets are widgets not covered by the categories
above. A normal widget will be considered powered up if it
is on an active path between a source widget and a sink
widget.
The way the number of input and output paths for a widget is calculated
depends on its category. There are a bunch of factors which decide which
category a widget is. Currently there is no formal classification of these
categories and we calculate the category of the widget based on these
factors whenever we want to know it. This is at least once for every widget
during each power update sequence. The factors which determine the category
of the widgets are mostly static though and if at all change rather seldom.
This patch introduces three new per widget flags, one for each of non-normal
widgets categories. Instead of re-computing the category each time we want
to know them the flags will be checked. For the majority of widgets the
category is solely determined by the widget id, which means it never changes
and only has to be set once when the widget is created. The only widgets
with dynamic categories are:
snd_soc_dapm_dai_out: Is considered a sink iff the capture stream is
active, otherwise normal.
snd_soc_dapm_dai_in: Is considered a source iff the playback stream
is active, otherwise normal.
snd_soc_dapm_input: Is considered a sink iff it has no outgoing
paths, otherwise normal.
snd_soc_dapm_output: Is considered a source iff it has no incoming
paths, otherwise normal.
snd_soc_dapm_line: Is considered a sink iff it has no outgoing paths
and is considered a source iff it has no incoming paths,
otherwise normal.
For snd_soc_dapm_dai_out/snd_soc_dapm_dai_in widgets the category will be
updated when a stream is started or stopped. For the other dynamic widgets
the category will be updated when a path connecting to it is added or
removed.
Introducing those new widget categories allows to make
is_connected_{output,input}_ep, which are among the hottest paths of the
DAPM algorithm, more generic and significantly shorter.
The before and after sizes for is_connected_{output,input}_ep are:
On ARM (defconfig + CONFIG_SND_SOC):
function old new delta
is_connected_output_ep 480 340 -140
is_connected_input_ep 456 352 -104
On amd64 (defconfig + CONFIG_SND_SOC):
function old new delta
is_connected_output_ep 579 427 -152
is_connected_input_ep 563 427 -136
Which is about a 25%-30% decrease, other architectures are expected to have
similar numbers. At the same time the size of the snd_soc_dapm_widget struct
does not change since the new flags are stored in the same word as the
existing flags.
Note: that since the per widget 'ext' flag was only used to decide whether a
snd_soc_dapm_input or snd_soc_dapm_output widget was a source or a sink it
is now unused and can be removed.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
The 'walked' flag was used to avoid walking paths that have already been
walked. But since we started caching the number of inputs and outputs of a
path we never actually get into a situation where we try to walk a path that
has the 'walked' flag set.
There are two cases in which we can end up walking a path multiple times
within a single run of is_connected_output_ep() or is_connected_input_ep().
1) If a path splits up and rejoins later:
.--> C ---v
A -> B E --> F
'--> D ---^
When walking from A to F we'll end up at E twice, once via C and once via D.
But since we do a depth first search we'll fully discover the path and
initialize the number of outputs/inputs of the widget the first time we get
there. The second time we get there we'll use the cached value and not
bother to check any of the paths again. So we'll never see a path where
'walked' is set in this case.
2) If there is a circle:
A --> B <-- C <-.--> F
'--> D ---'
When walking from A to F we'll end up twice at B. But since there is a
circle the 'walking' flag will still be set on B once we get there the
second time. This means we won't look at any of it's outgoing paths. So in
this case we won't ever see a path where 'walked' is set either.
So it is safe to remove the flag. This on one hand means we remove some
always true checks from one of the hottest paths of the DAPM algorithm and
on the other hand means we do not have to do the tedious clearing of the
flag after checking the number inputs or outputs of a widget.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
The DSP driver needs to know widget control value in its event handler for
widgets like mixers. This is required in the subsequent patches
Signed-off-by: Subhransu S. Prusty <subhransu.s.prusty@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The only remaining user of the CODEC pointer in the DAPM struct is to
initialize the CODEC pointer in the widget struct. The later is scheduled
for removal, but has still a few users left. For now use
dapm->component->codec to initialize it.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
There is a substantial amount of drivers that in go to SND_SOC_BIAS_OFF on
suspend and go back to SND_SOC_BIAS_SUSPEND on resume (Often this is even
the only thing done in the suspend and resume handlers). This patch
introduces a new suspend_bias_off flag, which when set by a driver will let
the ASoC core automatically put the device's DAPM context at the
SND_SOC_BIAS_OFF level during suspend. Once the device is resumed the DAPM
context will go back to SND_SOC_BIAS_STANDBY (if the context is idle,
otherwise to SND_SOC_BIAS_ON).
This will allow us to remove a fair bit of duplicated code from the drivers.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
The platform field in the snd_soc_dapm_widget and snd_soc_dapm_context structs
is now unused can be removed. New code that wants to get the platform for a
widget or dapm context should use snd_soc_dapm_to_platform(w->dapm) or
snd_soc_dapm_to_platform(dapm).
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
This patch adds full DAPM support at the component level. Previously there was
only full DAPM support for CODECs and partial DAPM support (e.g. no Mixers nor
MUXs) for platforms. Having DAPM support at the component level will allow all
types of components to use DAPM and also help in consolidating the DAPM support
between CODECs and platforms.
Since the DAPM context is directly embedded into the snd_soc_codec and
snd_soc_platform struct and the 'dapm' field is directly referenced in a lot of
drivers moving the field just right now is not possible without causing code
churn. The approach this patch takes is to add two new fields to the component
struct. One field which is the pointer to the actual DAPM context used by the
component and one DAPM context that will be used as the default if no other
context was specified. For CODECs and platforms the pointer is initialized to
point to the CODEC or platform DAPM context. All generic code when referencing
a component's DAPM struct will go via the pointer. This will make it possible to
eventually seamlessly move the DAPM context from snd_soc_codec and
snd_soc_platform struct over once all direct references have been eliminated.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
Currently the DAPM code directly looks at the CODEC driver struct to get a
handle to the set_bias_level() callback. This patch adds a new set_bias_level()
callback to the DAPM context struct. The DAPM code will use this new callback
instead of the CODEC callback. For CODECs the new callback is set up to call the
CODEC specific set_bias_level callback(). Not looking directly at the CODEC
driver struct will allow non CODEC DAPM contexts to implement a set_bias_level()
callback.
This is also similar to how the seq_notifier() and stream_event() callbacks are
currently handled.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
Currently only pins in CODEC DAPM contexts are automatically marked as
non-connected if the card has the fully_routed flag set. This makes sense since
widgets which qualify for auto-disconnection are only found in CODEC DAPM
contexts. But with componentisation this is going to change, so consider all
widgets for auto-disconnection.
Also it is probably faster to walk the widgets list only once rather than once
for each CODEC.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
Commit commit de9ba98b6d ("ASoC: dapm: Make widget power register settings more
flexible") added generic support for on_val/off_val in the DAPM core. With this
in place there is no need anymore for having a special event callback for
SND_SOC_DAPM_REG() widgets.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
We currently have two very similar IO abstractions in ASoC, one for CODECs, the
other for platforms. Moving this to the component level will allow us to unify
those two. It will also enable us to move the standard kcontrol helpers as well
as DAPM support to the component level.
The new component level abstraction layer is primarily build around regmap.
There is a per component pointer for the regmap instance for the underlying
device. There are four new function snd_soc_component_read(),
snd_soc_component_write(), snd_soc_component_update_bits() and
snd_soc_component_update_bits_async(). They have the same signature as their
regmap counter-part and will internally forward the call one-to-one to regmap.
If the component it not using regmap it will fallback to using the custom IO
callbacks. This is done to be able to support drivers that haven't been
converted to regmap yet, but it is expected that this will eventually be removed
in the future once all component drivers have been converted to regmap.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
Since there are no users left, we can remove the deprecated ENUM and MUX macros
which are just alias for other macros.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
MUXs and virtual MUXs are almost identical, the only difference is that for
virtual MUX there is no hardware backing register in which setting is stored.
This patch adds code, which is similar to what we already do for DAPM mixer
controls to support virtual mixer controls, to DAPM enum controls. The new code
will check if the enum does a hardware backing register and skip over reading
and writing to the register if it has not. This allows us to use the same code
path for both MUXs and virtual MUXs and a lot of nearly identical code can be
removed.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
MUXs and value MUXs are almost identical, the only difference is that a value
MUX uses a look-up table to map from the selected control item to a register
value, while MUXs use a direct mapping. This patch uses
snd_soc_enum_item_to_val() and snd_soc_enum_val_to_item(), which where earlier
introduced during the consolidation of enum and value enum controls, to hide
this difference. This allows us to use the same code path for both MUXs and
value MUXs and a lot of nearly duplicated code can be removed.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
We will often call sync after several functions that require the DAPM
mutex to be held. Rather than release and immediately relock the mutex
provide an unlocked function for this situation.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
The snd_soc_dapm_xxxx_pin all require the dapm_mutex to be held when
they are called as they edit the dirty list, however very few of the
callers do so.
This patch adds unlocked versions of all the functions replacing the
existing implementations with one that holds the lock internally. We
also fix up the places where the lock was actually held on the caller
side.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Cc: stable@vger.kernel.org
Connect the DAPM graph through each BE DAI link to the componnent(s) on the
other side of the BE DAI link. This allows the graph to be walked on
both sides of the link when graph changes are made.
Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
SND_SOC_DAPM_MUX() doesn't currently initialize the .mask field. This
results in the mux never affecting HW, since no bits are ever set or
cleared. Fix SND_SOC_DAPM_MUX() to use SND_SOC_DAPM_INIT_REG_VAL() to
set up the reg, shift, on_val, and off_val fields like almost all other
SND_SOC_xxx() macros. It looks like this was a "typo" in the fixed
commit linked below.
This makes the speakers on the Toshiba AC100 (PAZ00) laptop work again.
Fixes: de9ba98b6d ("ASoC: dapm: Make widget power register settings more flexible")
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Cc: <stable@vger.kernel.org> # v3.12+
This patch adds support for virtual DAPM mixer controls. They are similar to
virtual DAPM enums. There is no hardware register backing the control, so
changing the control's value wont have any direct effect on the hardware. But it
still influences the DAPM graph by causing the path it sits on to be connected
or disconnected. This in turn can cause power changes for some of the widgets on
the DAPM graph, which will then modify the hardware state.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
snd_soc_dapm_new_widgets() works on the ASoC card as a whole not on a specific
DAPM context. The DAPM context that is passed as the parameter is only used to
look up the pointer to the card. This patch updates the signature of
snd_soc_dapm_new_widgets() to take the card directly.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
Some devices have the problem that if a internal audio signal source is disabled
the output of the source becomes undefined or goes to a undesired state (E.g.
DAC output goes to ground instead of VMID). In this case it is necessary, in
order to avoid unwanted clicks and pops, to disable any mixer input the signal
feeds into or to active a mute control along the path to the output. Often it is
still desirable to expose the same mixer input control to userspace, so cerain
paths can sill be disabled manually. This means we can not use conventional DAPM
to manage the mixer input control. This patch implements a method for letting
DAPM overwrite the state of a userspace visible control. I.e. DAPM will disable
the control if the path on which the control sits becomes inactive. Userspace
will then only see a cached copy of the controls state. Once DAPM powers the
path up again it will sync the userspace setting with the hardware and give
control back to userspace.
To implement this a new widget type is introduced. One widget of this type will
be created for each DAPM kcontrol which has the auto-disable feature enabled.
For each path that is controlled by the kcontrol the widget will be connected to
the source of that path. The new widget type behaves like a supply widget,
which means it will power up if one of its sinks are powered up and will only
power down if all of its sinks are powered down. In order to only have the mixer
input enabled when the source signal is valid the new widget type will be
disabled before all other widget types and only be enabled after all other
widget types.
E.g. consider the following simplified example. A DAC is connected to a mixer
and the mixer has a control to enable or disable the signal from the DAC.
+-------+
+-----+ | |
| DAC |-----[Ctrl]-| Mixer |
+-----+ : | |
| : +-------+
| :
+-------------+
| Ctrl widget |
+-------------+
If the control has the auto-disable feature enabled we'll create a widget for
the control. This widget is connected to the DAC as it is the source for the
mixer input. If the DAC powers up the control widget powers up and if the DAC
powers down the control widget is powered down. As long as the control widget
is powered down the hardware input control is kept disabled and if it is enabled
userspace can freely change the control's state.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
Currently the DAPM code is limited to only setting or clearing a single bit in a
register to power a widget up or down. This patch extends the DAPM code to be
more flexible in that regard and allow widgets to use arbitrary values to be
used to put a widget in either on or off state.
Since the snd_soc_dapm_widget struct already contains a on_val and off_val field
no additional fields need to be added and in fact the invert field can even be
removed. Also the generated code is slightly smaller.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
Currently we store for each path which control (if any at all) is associated
with that control. But we are only ever interested in the reverse relationship,
i.e. we want to know all the paths a certain control is associated with. This is
currently implemented by always iterating over all paths. This patch updates the
code to keep a list for each control which contains all the paths that are
associated with that control. This improves the run time of e.g.
soc_dapm_mixer_update_power() and soc_dapm_mux_update_power() from O(n) (with n
being the number of paths for the card) to O(1).
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
The 'value' field is really per control and not per widget. Currently it is only
used for virtual MUXes, which only have one control per widget. So in that case
there is not so much of a difference between whether it is stored per widget or
per control. Moving the 'value' field from the widget to the control will allow
us to use it also for cases where we have more than one control per widget. E.g.
for mixers with multiple input controls.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
We use the same 3 lines to get the CODEC for a kcontrol in a quite a few places.
This patch puts them into a common helper function. Having this encapsulated in
a helper function will also make it more easier to eventually change the data
layout of the kcontrol's private data.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
The update field of a DAPM context is only assigned while the card's dapm_mutex
is locked, the field is also cleared again while the mutex is stil locked. So
there will only ever be one DAPM context at a time with a non-NULL update field.
So it is safe to move the update field from the DAPM context struct to the card
struct. Doing so will allow further cleanups in this area.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
In order to avoid race conditions the assignment of dapm->update should happen
while card->dapm_mutex is being held. To allow CODEC drivers to run a register
update when using snd_soc_dapm_mux_update_power() or
snd_soc_dapm_mixer_update_power() add a update parameter to these two functions.
The update parameter will be assigned to dapm->update while card->dapm_mutex is
locked.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
Currently when updating a control that is shared between multiple widgets the
whole power-up/power-down sequence is being run once for each widget. The
control register is updated during the first run, which means the CODEC internal
routing is also updated for all widgets during this first run. The input and
output paths for each widgets are only updated though during the respective run
for that widget. This leads to a slight inconsistency between the CODEC's
internal state and ASoC's state, which causes non optimal behavior in regard to
click and pop avoidance.
E.g. consider the following setup where two MUXs share the same control.
+------+
A1 ------| |
| MUX1 |----- C1
B1 ------| |
+------+
|
control ---+
|
+------+
A2 ------| |
| MUX2 |----- C2
B2 ------| |
+------+
If the control is updated to switch the MUXs from input A to input B with the
current code the power-up/power-down sequence will look like this:
Run soc_dapm_mux_update_power for MUX1
Power-down A1
Update MUXing
Power-up B1
Run soc_dapm_mux_update_power for MUX2
Power-down A2
(Update MUXing)
Power-up B2
Note that the second 'Update Muxing' is a no-op, since the register was already
updated.
While the preferred order for avoiding pops and clicks should be:
Run soc_dapm_mux_update_power for control
Power-down A1
Power-down A2
Update MUXing
Power-up B1
Power-up B2
This patch changes the behavior to the later by running the updates for all
widgets that the control is attached to at the same time.
The new code is also a bit simpler since callers of
soc_dapm_{mux,muxer}_update_power don't have to loop over each widget anymore
and neither do we need to keep track for which of the kcontrol's widgets the
current update is.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
Since commit 85762e71 ("ASoC: dapm: Implement mixer control sharing") the
long_name field of the snd_soc_dapm_path struct is unused. All of the name
handling now happens entirely in dapm_create_or_share_mixmux_kcontrol(). So we
can remove the long_name field from the snd_soc_dapm_path struct.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
Even though they are virtual widgets DAI widgets still get counted for the
DAPM context power management so we can't just use the active state to
check if they should be powered as they may not be part of a complete path.
Instead split them into input and output widgets and do the same power
checks as we perform on AIFs.
Reported-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Some devices may benefit from being able to start some parts of the widget
power up/down sequence earlier on in the sequence than the point at which
the final power state is committed. Support these by providing events which
are called before any power state changes are done.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Commit 497098be ("ASoC: dapm: Remove bodges for no-widget CODECs") removed the
last user of the n_widgets field. Currently it is incremented for each widget
added, but the value is never used, so we can remove it.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Currently if a path loops back on itself we correctly skip over it to
avoid going into an infinite loop but this causes us to ignore the need
to power up the path as we don't count the loop for the purposes of
counting inputs and outputs. This means that internal loopbacks within a
device that have powered devices on them won't be powered up.
Fix this by treating any path that is currently in the process of being
recursed as having a single input or output so that it is counted for
the purposes of power decisions.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Allow regulators managed via DAPM to make use of the bypass support that
has recently been added to the regulator API by setting a flag
SND_SOC_DAPM_REGULATOR_BYPASS. When this flag is set the regulator will
be put into bypass mode before being disabled, allowing the regulator to
fall into bypass mode if it can't be disabled due to other users.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
This will be used to enable additional control of the regulators.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
Since bypass paths aren't part of DAPM streams and we may not have any
DAPM streams there may not be anything that triggers a DAPM sync for
them. Mark all input and output widgets as dirty and then sync to do so
at the end of suspend and resume.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
The only user was removed over two years ago in commit a6c65736 ("ASoC: Remove
current PGA control handling").
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Since we're now relying on DAPM for things like enabling clocks when we
reparent the clocks for widgets we need to either use conditional routes
(which are expensive) or remove routes at runtime. Add a route removal
API to support this use case.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
Adds a supply-widget variant for connection to the clock-framework.
This widget-type corresponds to the variant for regulators.
Signed-off-by: Ola Lilja <ola.o.lilja@stericsson.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
In preparation for ASoC DSP support.
Add a DAPM API call to determine whether a DAPM audio path is valid between
source and sink widgets. This also takes into account all kcontrol mux and mixer
settings in between the source and sink widgets to validate the audio path.
This will be used by the DSP core to determine the runtime DAI mappings
between FE and BE DAIs in order to run PCM operations.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
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<->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 <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
Supports larger register maps, not using unsigned ints for the full 32
bit as we rely on checking for negative registers.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
There are no users any more and new drivers should be using supply widgets
which fully replace it anyway.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Zeng Zhaoming <zengzm.kernel@gmail.com>
Currently DAPM widgets use the private data for their regulator.
Add a regulator * for widgets to use instead of private data.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Rename SND_SOC_DAPM_CLASS_PCM to SND_SOC_DAPM_CLASS_RUNTIME to
better match the usage and align with card mutex too.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark 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: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
It has now become necessary to use a DAPM mutex instead of the codec
mutex to lock the DAPM operations. This is due to the recent multi
component support and forth coming Dynamic PCM updates.
Currently we lock DAPM operations with the codec mutex of the calling
RTD context. However, DAPM operations can span the whole card context
and all components.
This patch updates the DAPM operations that use the codec mutex to
now use the DAPM mutex PCM subclass for all DAPM ops.
We also add a mutex subclass for DAPM init and PCM operations.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
"[RFC PATCH 0/2] audit of linux/device.h users in include/*"
https://lkml.org/lkml/2012/3/4/159
--
Nearly every subsystem has some kind of header with a proto like:
void foo(struct device *dev);
and yet there is no reason for most of these guys to care about the
sub fields within the device struct. This allows us to significantly
reduce the scope of headers including headers. For this instance, a
reduction of about 40% is achieved by replacing the include with the
simple fact that the device is some kind of a struct.
Unlike the much larger module.h cleanup, this one is simply two
commits. One to fix the implicit <linux/device.h> users, and then
one to delete the device.h includes from the linux/include/ dir
wherever possible.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJPbNxLAAoJEOvOhAQsB9HWR6QQAMRUZ94O2069/nW9h4TO/xTr
Hq/80lo/TBBiRmob3iWBP76lzgeeMPPVEX1I6N7YYlhL3IL7HsaJH1DvpIPPHXQP
GFKcBsZ5ZLV8c4CBDSr+/HFNdhXc0bw0awBjBvR7gAsWuZpNFn4WbhizJi4vWAoE
4ydhPu55G1G8TkBtYLJQ8xavxsmiNBSDhd2i+0vn6EVpgmXynjOMG8qXyaS97Jvg
pZLwnN5Wu21coj6+xH3QUKCl1mJ+KGyamWX5gFBVIfsDB3k5H4neijVm7t1en4b0
cWxmXeR/JE3VLEl/17yN2dodD8qw1QzmTWzz1vmwJl2zK+rRRAByBrL0DP7QCwCZ
ppeJbdhkMBwqjtknwrmMwsuAzUdJd79GXA+6Vm+xSEkr6FEPK1M0kGbvaqV9Usgd
ohMewewbO6ddgR9eF7Kw2FAwo0hwkPNEplXIym9rZzFG1h+T0STGSHvkn7LV765E
ul1FapSV3GCxEVRwWTwD28FLU2+0zlkOZ5sxXwNPTT96cNmW+R7TGuslZKNaMNjX
q7eBZxo8DtVt/jqJTntR8bs8052c8g1Ac1IKmlW8VSmFwT1M6VBGRn1/JWAhuUgv
dBK/FF+I1GJTAJWIhaFcKXLHvmV9uhS6JaIhLMDOetoOkpqSptJ42hDG+89WkFRk
o55GQ5TFdoOpqxVzGbvE
=3j4+
-----END PGP SIGNATURE-----
Merge tag 'device-for-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux
Pull <linux/device.h> avoidance patches from Paul Gortmaker:
"Nearly every subsystem has some kind of header with a proto like:
void foo(struct device *dev);
and yet there is no reason for most of these guys to care about the
sub fields within the device struct. This allows us to significantly
reduce the scope of headers including headers. For this instance, a
reduction of about 40% is achieved by replacing the include with the
simple fact that the device is some kind of a struct.
Unlike the much larger module.h cleanup, this one is simply two
commits. One to fix the implicit <linux/device.h> users, and then one
to delete the device.h includes from the linux/include/ dir wherever
possible."
* tag 'device-for-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux:
device.h: audit and cleanup users in main include dir
device.h: cleanup users outside of linux/include (C files)
The <linux/device.h> header includes a lot of stuff, and
it in turn gets a lot of use just for the basic "struct device"
which appears so often.
Clean up the users as follows:
1) For those headers only needing "struct device" as a pointer
in fcn args, replace the include with exactly that.
2) For headers not really using anything from device.h, simply
delete the include altogether.
3) For headers relying on getting device.h implicitly before
being included themselves, now explicitly include device.h
4) For files in which doing #1 or #2 uncovers an implicit
dependency on some other header, fix by explicitly adding
the required header(s).
Any C files that were implicitly relying on device.h to be
present have already been dealt with in advance.
Total removals from #1 and #2: 51. Total additions coming
from #3: 9. Total other implicit dependencies from #4: 7.
As of 3.3-rc1, there were 110, so a net removal of 42 gives
about a 38% reduction in device.h presence in include/*
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
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 <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
Neater and avoids warnings when used in other places where const strings
are desired.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.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: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
Everything now uses snd_soc_dapm_new_controls() instead so we don't need
to make it part of the external API.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
Allow for the operation of custom mixer and mux DAPM widgets that can call
snd_soc_dapm_mixer_update_power() and snd_soc_dapm_mux_update_power() directly
after updating their status. This is useful with complex DAPM Mixer operations
where we need to do additional work in addition to setting a few mixer register
bits.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Modern devices allow systems to enable and disable individual supplies on
the device, allowing additional power saving by switching off regulators
which power portions of the device which are not currently in use. Add a
new SND_SOC_DAPM_REGULATOR_SUPPLY widget type factoring out the code for
managing such widgets from individual drivers.
The widget name will be used as the supply name when requesting the
regulator from the regulator API.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
A signal generator behaves as an input would but is not considered for
any of the special behaviour associated with external input pins. This
is especially useful when automatically working out not connected widgets.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
