summaryrefslogtreecommitdiffstats
path: root/include/sound/soc-dapm.h
Commit message (Collapse)AuthorAgeFilesLines
...
* | ASoC: dapm: Handle SND_SOC_DAPM_REG() genericallyLars-Peter Clausen2014-05-121-5/+2
| | | | | | | | | | | | | | | | | | | | 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>
* | ASoC: Move IO abstraction to the component levelLars-Peter Clausen2014-04-221-0/+1
|/ | | | | | | | | | | | | | | | | | | | | 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>
* Merge remote-tracking branch 'asoc/topic/enum' into asoc-nextMark Brown2014-03-121-31/+7
|\
| * ASoC: dapm: Consolidate MUXs and virtual MUXsLars-Peter Clausen2014-03-011-18/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * ASoC: dapm: Consolidate MUXs and value MUXsLars-Peter Clausen2014-03-011-13/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | ASoC: dapm: Staticise dapm_mark_dirty()Mark Brown2014-03-101-1/+0
|/ | | | | | | The function is not called outside soc-dapm.c so there is no need for it to be exported. Signed-off-by: Mark Brown <broonie@linaro.org>
* ASoC: dapm: Add unlocked version of snd_soc_dapm_syncCharles Keepax2014-02-201-0/+1
| | | | | | | | | 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>
* ASoC: dapm: Add locking to snd_soc_dapm_xxxx_pin functionsCharles Keepax2014-02-201-0/+8
| | | | | | | | | | | | | | | 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
* Merge remote-tracking branch 'asoc/topic/dapm' into for-tiwaiMark Brown2014-01-161-0/+1
|\
| * ASoC: sapm: Automatically connect DAI link widgets in DAPM graph.Liam Girdwood2014-01-081-0/+1
| | | | | | | | | | | | | | | | | | 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>
* | ASoC: dapm: Use SND_SOC_DAPM_INIT_REG_VAL in SND_SOC_DAPM_MUXStephen Warren2013-11-241-1/+2
|/ | | | | | | | | | | | | | | | 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: de9ba98b6d26 ("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+
* ASoC: dapm: Add support for virtual mixer controlsLars-Peter Clausen2013-10-071-0/+4
| | | | | | | | | | | | | 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>
* ASoC: Pass card instead of dapm context to snd_soc_dapm_new_widgets()Lars-Peter Clausen2013-08-271-1/+1
| | | | | | | | | | 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>
* ASoC: dapm: Implement mixer input auto-disableLars-Peter Clausen2013-08-051-2/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ASoC: dapm: Make widget power register settings more flexibleLars-Peter Clausen2013-07-291-70/+93
| | | | | | | | | | | | | | 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>
* ASoC: dapm: Keep a list of paths per kcontrolLars-Peter Clausen2013-07-291-1/+1
| | | | | | | | | | | | | | 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>
* ASoC: dapm: Move 'value' field from widget to controlLars-Peter Clausen2013-07-291-1/+0
| | | | | | | | | | | | 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>
* ASoC: dapm: Add a helper to get the CODEC for DAPM kcontrolLars-Peter Clausen2013-07-291-0/+2
| | | | | | | | | | 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>
* ASoC: dapm: Move snd_soc_dapm_update from dapm context to cardLars-Peter Clausen2013-07-291-2/+0
| | | | | | | | | | | 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>
* ASoC: dapm: Add a update parameter to snd_soc_dapm_{mux,mixer}_update_powerLars-Peter Clausen2013-07-241-2/+5
| | | | | | | | | | | | 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>
* ASoC: dapm: Run widget updates for shared controls at the same timeLars-Peter Clausen2013-07-241-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Merge remote-tracking branch 'asoc/topic/dapm' into asoc-nextMark Brown2013-06-171-1/+0
|\
| * ASoC: dapm: Remove unused long_name field from snd_soc_dapm_path structLars-Peter Clausen2013-06-141-1/+0
| | | | | | | | | | | | | | | | | | | | 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>
* | Merge remote-tracking branch 'asoc/topic/core' into asoc-nextMark Brown2013-06-171-0/+2
|\ \
| * | ASoC: dapm: Provide early event callbacks for power up and downMark Brown2013-05-121-0/+2
| |/ | | | | | | | | | | | | | | | | | | 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>
* | ASoC: dapm: Treat DAI widgets like AIF widgets for powerMark Brown2013-06-071-1/+2
|/ | | | | | | | | | | | | 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>
* Merge remote-tracking branch 'asoc/topic/core' into asoc-nextMark Brown2013-04-121-1/+0
|\
| * ASoC: core: Remove unused "n_widgets" field from snd_soc_dapm structLars-Peter Clausen2013-03-081-1/+0
| | | | | | | | | | | | | | | | | | 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>
* | ASoC: dapm: Fix handling of loopsMark Brown2013-02-251-0/+1
|/ | | | | | | | | | | | | | | 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>
* ASoC: dapm: Allow regulators to bypass as well as disable when idleMark Brown2012-09-261-0/+3
| | | | | | | | | | 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>
* ASoC: dapm: Add flags to regulator suppliesMark Brown2012-09-081-2/+3
| | | | | | | 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>
* ASoC: dapm: Ensure bypass paths are suspended and resumedMark Brown2012-09-061-0/+1
| | | | | | | | | | 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>
* ASoC: Remove unused 'saved_value' field from snd_soc_dapm_widget structLars-Peter Clausen2012-09-061-1/+0
| | | | | | | | 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>
* ASoC: dapm: Allow routes to be deleted at runtimeMark Brown2012-07-061-0/+2
| | | | | | | | | | 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>
* ASoC: core: Add widget SND_SOC_DAPM_CLOCK_SUPPLYOla Lilja2012-06-031-0/+10
| | | | | | | | 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>
* ASoC: dapm: Add API call to query valid DAPM pathsLiam Girdwood2012-04-181-0/+5
| | | | | | | | | | | | | | 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>
* ASoC: core: Support transparent CODEC<->CODEC DAI linksMark Brown2012-04-161-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ASoC: dapm: Allow DAPM registers to be 31 bitMark Brown2012-04-041-1/+1
| | | | | | | | 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>
* ASoC: dapm: Remove SND_SOC_DAPM_MICBIAS_E()Mark Brown2012-04-011-4/+0
| | | | | | | | 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>
* ASoC: dapm: Add regulator member to struct dapm_widgetLiam Girdwood2012-04-011-0/+2
| | | | | | | | 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>
* ASoC: dapm: Rename dapm mutex subclass to better match usageLiam Girdwood2012-04-011-2/+2
| | | | | | | | 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>
* ASoC: dapm: Add platform stream event supportLiam Girdwood2012-04-011-2/+2
| | | | | | | | | | | | | | | | | | 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>
* ASoC: dapm: Use DAPM mutex for DAPM ops instead of codec mutexLiam Girdwood2012-04-011-0/+5
| | | | | | | | | | | | | | | | | | 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>
* Merge tag 'device-for-3.4' of ↵Linus Torvalds2012-03-241-1/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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)
| * device.h: audit and cleanup users in main include dirPaul Gortmaker2012-03-161-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | ASoC: dapm: Implement and instantiate DAI widgetsMark Brown2012-02-171-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | ASoC: dapm: Constify lots of names that are never modifiedMark Brown2012-02-171-4/+4
| | | | | | | | | | | | | | | | 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>
* | ASoC: dapm: Supply the DAI and substream when calling stream eventsMark Brown2012-02-171-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | ASoC: dapm: Unexport snd_soc_dapm_new_control()Mark Brown2012-02-171-2/+0
| | | | | | | | | | | | | | | | 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>
* | ASoC: dapm: Export mixer|mux_update_power() to public API.Liam Girdwood2012-02-061-0/+6
| | | | | | | | | | | | | | | | | | | | | | 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>
OpenPOWER on IntegriCloud