- 24 11月, 2013 1 次提交
-
-
由 Stephen Warren 提交于
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: de9ba98b ("ASoC: dapm: Make widget power register settings more flexible") Signed-off-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NMark Brown <broonie@linaro.org> Cc: <stable@vger.kernel.org> # v3.12+
-
- 07 10月, 2013 1 次提交
-
-
由 Lars-Peter Clausen 提交于
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: NLars-Peter Clausen <lars@metafoo.de> Tested-by: NPeter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: NMark Brown <broonie@linaro.org>
-
- 27 8月, 2013 1 次提交
-
-
由 Lars-Peter Clausen 提交于
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: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@linaro.org>
-
- 05 8月, 2013 1 次提交
-
-
由 Lars-Peter Clausen 提交于
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: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@linaro.org>
-
- 30 7月, 2013 5 次提交
-
-
由 Lars-Peter Clausen 提交于
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: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@linaro.org>
-
由 Lars-Peter Clausen 提交于
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: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@linaro.org>
-
由 Lars-Peter Clausen 提交于
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: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@linaro.org>
-
由 Lars-Peter Clausen 提交于
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: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@linaro.org>
-
由 Lars-Peter Clausen 提交于
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: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@linaro.org>
-
- 24 7月, 2013 2 次提交
-
-
由 Lars-Peter Clausen 提交于
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: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@linaro.org>
-
由 Lars-Peter Clausen 提交于
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: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@linaro.org>
-
- 14 6月, 2013 1 次提交
-
-
由 Lars-Peter Clausen 提交于
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: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@linaro.org>
-
- 07 6月, 2013 1 次提交
-
-
由 Mark Brown 提交于
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: NStephen Warren <swarren@nvidia.com> Tested-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NMark Brown <broonie@linaro.org>
-
- 13 5月, 2013 1 次提交
-
-
由 Mark Brown 提交于
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: NMark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: NLiam Girdwood <liam.r.girdwood@linux.intel.com>
-
- 08 3月, 2013 1 次提交
-
-
由 Lars-Peter Clausen 提交于
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: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
-
- 25 2月, 2013 1 次提交
-
-
由 Mark Brown 提交于
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: NMark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: NLiam Girdwood <liam.r.girdwood@linux.intel.com>
-
- 26 9月, 2012 1 次提交
-
-
由 Mark Brown 提交于
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: NMark Brown <broonie@opensource.wolfsonmicro.com>
-
- 08 9月, 2012 1 次提交
-
-
由 Mark Brown 提交于
This will be used to enable additional control of the regulators. Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: NLiam Girdwood <lrg@ti.com>
-
- 06 9月, 2012 2 次提交
-
-
由 Mark Brown 提交于
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: NMark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: NLiam Girdwood <lrg@ti.com>
-
由 Lars-Peter Clausen 提交于
The only user was removed over two years ago in commit a6c65736 ("ASoC: Remove current PGA control handling"). Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
-
- 07 7月, 2012 1 次提交
-
-
由 Mark Brown 提交于
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: NMark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: NLiam Girdwood <lrg@ti.com>
-
- 03 6月, 2012 1 次提交
-
-
由 Ola Lilja 提交于
Adds a supply-widget variant for connection to the clock-framework. This widget-type corresponds to the variant for regulators. Signed-off-by: NOla Lilja <ola.o.lilja@stericsson.com> Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
-
- 19 4月, 2012 1 次提交
-
-
由 Liam Girdwood 提交于
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: NLiam Girdwood <lrg@ti.com> Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
-
- 17 4月, 2012 1 次提交
-
-
由 Mark Brown 提交于
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: NMark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: NLiam Girdwood <lrg@ti.com>
-
- 04 4月, 2012 1 次提交
-
-
由 Mark Brown 提交于
Supports larger register maps, not using unsigned ints for the full 32 bit as we rely on checking for negative registers. Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: NLiam Girdwood <lrg@ti.com>
-
- 01 4月, 2012 5 次提交
-
-
由 Mark Brown 提交于
There are no users any more and new drivers should be using supply widgets which fully replace it anyway. Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: NZeng Zhaoming <zengzm.kernel@gmail.com>
-
由 Liam Girdwood 提交于
Currently DAPM widgets use the private data for their regulator. Add a regulator * for widgets to use instead of private data. Signed-off-by: NLiam Girdwood <lrg@ti.com> Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
-
由 Liam Girdwood 提交于
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: NLiam Girdwood <lrg@ti.com> Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
-
由 Liam Girdwood 提交于
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>
-
由 Liam Girdwood 提交于
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: NLiam Girdwood <lrg@ti.com> Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
-
- 16 3月, 2012 1 次提交
-
-
由 Paul Gortmaker 提交于
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: NPaul Gortmaker <paul.gortmaker@windriver.com>
-
- 18 2月, 2012 4 次提交
-
-
由 Mark Brown 提交于
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: NMark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: NLiam Girdwood <lrg@ti.com>
-
由 Mark Brown 提交于
Neater and avoids warnings when used in other places where const strings are desired. Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: NLiam Girdwood <lrg@ti.com>
-
由 Mark Brown 提交于
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>
-
由 Mark Brown 提交于
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: NMark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: NLiam Girdwood <lrg@ti.com>
-
- 07 2月, 2012 1 次提交
-
-
由 Liam Girdwood 提交于
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: NLiam Girdwood <lrg@ti.com> Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
-
- 27 1月, 2012 1 次提交
-
-
由 Mark Brown 提交于
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: NMark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: NLiam Girdwood <lrg@ti.com>
-
- 02 12月, 2011 1 次提交
-
-
由 Mark Brown 提交于
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: NMark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: NLiam Girdwood <lrg@ti.com>
-
- 24 11月, 2011 1 次提交
-
-
由 Stephen Warren 提交于
A card is fully routed if the DAPM route table describes all connections on the board. When a card is fully routed, some operations can be automated by the ASoC core. The first, and currently only, such operation is described below, and implemented by this patch. Codecs often have a large number of external pins, and not all of these pins will be connected on all board designs. Some machine drivers therefore call snd_soc_dapm_nc_pin() for all the unused pins, in order to tell the ASoC core never to activate them. However, when a card is fully routed, the information needed to derive the set of unused pins is present in card->dapm_routes. In this case, have the ASoC core automatically call snd_soc_dapm_nc_pin() for each unused codec pin. This has been tested with soc/tegra/tegra_wm8903.c and soc/tegra/trimslice.c. Signed-off-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
-
- 10 10月, 2011 1 次提交
-
-
由 Mark Brown 提交于
We really should be doing this in the core, not in a driver... Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com> Tested-by: NJarkko Nikula <jarkko.nikula@bitmer.com>
-