summaryrefslogtreecommitdiffstats
path: root/sound/soc/soc-dapm.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* ASoC: core - Add platform widget IOLiam Girdwood2011-07-051-2/+11
| | | | | | | Allow platform driver widgets to perform any IO required for DAPM. Signed-off-by: Liam Girdwood <lrg@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* ASoC: Fix DAPM sequence run for per-widget I/O methodsMark Brown2011-06-201-0/+6
| | | | | | | | | | | | | Previously we were using the DAPM context rather than a widget as the argument for update_bits() so we didn't need to care that our list walk of widgets left us one beyond the end of the list. Now we're using them for the register update we need to make sure we're pointing at an actual widget not the list_head. Fix originally suggested by Liam on IM. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
* ASoC: dapm - Refactor widget IO functions in preparation for platform widgets.Liam Girdwood2011-06-141-6/+43
| | | | | | | | | | | | | | This time with soc_widget_update_bits reflecting recent soc_update_bits changes. Currently widget IO is tightly coupled to the CODEC drivers. Future platform DSP devices have mixer components that can alter power usage and hence require full DAPM support. This provides a generic widget IO operation wrapper in preparation for future patches that implement platform driver DAPM. Signed-off-by: Liam Girdwood <lrg@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* ASoC: Add weak routes for sidetone style pathsMark Brown2011-06-131-0/+87
| | | | | | | | | | | | | | | | | | Normally DAPM will power up any connected audio path. This is not ideal for sidetone paths as with sidetone paths the audio path is not wanted in itself, it is only desired if the two paths it provides a sidetone between are both active. If the sidetone path causes a power up then it can be hard to minimise pops as we first power up either the sidetone or the main output path and then power the other, with the second power up potentially introducing a DC offset. Address this by introducing the concept of a weak path. If a path is marked as weak then DAPM will ignore that path when walking the graph, though all the relevant controls are still available to the application layer to allow these paths to be configured. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
* Merge branch 'for-3.0' into for-3.1Mark Brown2011-06-091-9/+8
|\
| * ASoC: snd_soc_new_{mixer,mux,pga} make sure to use right DAPM contextLars-Peter Clausen2011-06-091-9/+8
| | | | | | | | | | | | | | | | | | | | | | | | Currently it is possible that snd_soc_new_{mixer,mux,pga} is called with a DAPM context not matching the widgets context. This can lead to a wrong prefix_len calculation, which will result in undefined behaviour. To avoid this always use the DAPM context from the widget itself. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Liam Girdwood <lrg@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: stable@kernel.org
* | ASoC: Only provide a default bias level update for CODEC contextsMark Brown2011-06-061-4/+7
| | | | | | | | | | | | | | | | This allows the card driver to use the bias level variable more easily in multi component systems. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
* | ASoC: Add context parameter to card DAPM callbacksMark Brown2011-06-061-2/+2
| | | | | | | | | | | | | | | | | | The card callback will get called for each DAPM context in the card so it can be useful for it to know which device is currently undergoing a transition. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
* | ASoC: Simplify logic in snd_soc_dapm_set_bias_level()Mark Brown2011-06-061-10/+12
| | | | | | | | | | | | | | No functional changes but much less indentation. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
* | ASoC: Remove trace for DAPM bias level loggingMark Brown2011-06-061-18/+0
| | | | | | | | | | | | | | It's redundant now thanks to the use of the generic trace infrastructure. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
* | ASoC: Indentation fix for null loop operationMark Brown2011-06-061-1/+1
| | | | | | | | | | | | | | More with the legibility. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
* | ASoC: Don't bring the CODEC up to full power for supplies and biasesMark Brown2011-06-061-2/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | If the only widgets active within a CODEC are supplies and micbiases we are not passing audio, we are probably just doing microphone detection. This will not generally require either fully accurate reference voltages or much power so If this turns out to be unsuitable for some systems we can provide a facility to override this decision. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
* | ASoC: Specify target bias state directly as a bias stateMark Brown2011-06-061-27/+33
|/ | | | | | | | | | Rather than a simple flag to say if we want the DAPM context to be at full power specify the target bias state. This should have no current effect but is a bit more direct and so makes it easier to change our decisions about the which bias state to go into in future. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
* ASoC: Fix dapm_is_shared_kcontrol so everything isn't sharedStephen Warren2011-05-271-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit af46800 ("ASoC: Implement mux control sharing") introduced function dapm_is_shared_kcontrol. When this function returns true, the naming of DAPM controls is derived from the kcontrol_new. Otherwise, the name comes from the widget (and possibly a widget's naming prefix). A bug in the implementation of dapm_is_shared_kcontrol made it return 1 in all cases. Hence, that commit caused a change in control naming for all controls instead of just shared controls. Specifically, a control is always considered shared because it is always compared against itself. Solve this by never comparing against the widget containing the control being created. Equally, controls should never be shared between DAPM contexts; when the same codec is instantiated multiple times, the same kcontrol_new will be used. However, the control should no be shared between the multiple instances. I tested that with the Tegra WM8903 driver: * Shared is now mostly 0 as expected, and sometimes 1. * The expected controls are still generated after this change. However, I don't have any systems that have a widget/control naming prefix, so I can't test that aspect. Thanks for Jarkko Nikula for pointing out how to fix this. Reported-by: Liam Girdwood <lrg@ti.com> Tested-by: Jarkko Nikula <jhnikula@gmail.com> Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Liam Girdwood <lrg@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* ASoC: Fix power down for widgetless per-card DAPM context caseJarkko Nikula2011-05-261-1/+1
| | | | | | | | | | | | | | | | | | | | Commit 52ba67b ("ASoC: Force all DAPM contexts into the same bias state") powers up all the DAPM contexts in a card if any DAPM context becomes active. Unfortunately power down newer happens if per-card DAPM context doesn't have any widgets. Reason for this is that power state of per-card DAPM context without widgets is never cleared and thus all the DAPM contexts remain permanently active. Test for widgetless calling DAPM context in dapm_power_widgets() doesn't work for per-card DAPM context since power change is never originating from widgetless per-card DAPM context. Fix this by pre-clearing power state flag of non-codec DAPM context at the beginning of power sequence. Signed-off-by: Jarkko Nikula <jhnikula@gmail.com> Acked-by: Liam Girdwood <lrg@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* ASoC: Implement mux control sharingStephen Warren2011-05-031-31/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Control sharing is enabled when two widgets include pointers to the same kcontrol_new in their definition. Specifically: static const struct snd_kcontrol_new adcinput_mux = SOC_DAPM_ENUM("ADC Input", adcinput_enum); static const struct snd_soc_dapm_widget wm8903_dapm_widgets[] = { SND_SOC_DAPM_MUX("Left ADC Input", SND_SOC_NOPM, 0, 0, &adcinput_mux), SND_SOC_DAPM_MUX("Right ADC Input", SND_SOC_NOPM, 0, 0, &adcinput_mux), }; This is useful when a single register bit or field affects multiple muxes at once. The common case is to have separate control bits or fields for each mux (channel). An alternative way of looking at this is that the mux is a stereo (or even n-channel) mux, rather than independant mono muxes. Without this change, a separate kcontrol will be created for each DAPM_MUX. This has the following disadvantages: * Confuses the user/programmer with redundant controls that don't map to separate hardware. * When one of the controls is changed, ASoC fails to update the DAPM logic for paths solely affected by the other controls impacted by the same register bits. This causes some paths not to be correctly powered up or down. Prior to this change, to work around this, the user or programmer had to manually toggle all duplicate controls away from the intended setting, and then back to it. Control sharing implies that the control is named based on the kcontrol_new itself, not any of the widgets that are affected by it. Control sharing is implemented by: When creating kcontrols, if a kcontrol does not yet exist for a particular kcontrol_new, then a new kcontrol is created with a list of widgets containing just a single entry. This is the normal case. However, if a kcontrol does already exists for the given kcontrol_new, the current widget is simply added to that kcontrol's list of affected widgets. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Liam Girdwood <lrg@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* ASoC: Store a list of widgets in a DAPM mux/mixer kcontrolStephen Warren2011-05-031-56/+131
| | | | | | | | | | | | | | | | | | | A future change will allow multiple widgets to be affected by the same control. For example, a single register bit that controls separate muxes in both the L and R audio paths. This change updates the code that handles relevant controls to be able to iterate over a list of affected widgets. Note that only the put functions need significant modification to implement the iteration; the get functions do not need to iterate, nor unify the results, since all affected widgets reference the same kcontrol. When creating the list of widgets, always create a 1-sized list, since the control sharing is not implemented in this change. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Liam Girdwood <lrg@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* ASoC: Add w->kcontrols, and populate itStephen Warren2011-05-031-0/+12
| | | | | | | | | Future changes will need reference to the kcontrol created for a given kcontrol_new. Store the created kcontrol values now. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Liam Girdwood <lrg@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* ASoC: s/w->kcontrols/w->kcontrol_news/gStephen Warren2011-05-031-13/+15
| | | | | | | | | | A future change will modify struct snd_soc_dapm_widget to store the actual kcontrol pointers for each kcontrol_new in a field named kcontrols. Rename the existing kcontrols field to enable this. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Liam Girdwood <lrg@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* ASoC: Remove DAPM debugfs entries before freeing widgetsLars-Peter Clausen2011-05-031-0/+10
| | | | | | | | | Remove the DAPM debugfs entries before freeing the context's widgets, otherwise a use after free situation might occur. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Liam Girdwood <lrg@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* ASoC: Move DAPM widget debugfs entry creation to snd_soc_dapm_new_widgetsLars-Peter Clausen2011-05-031-12/+23
| | | | | | | | | | | | | | | | | | | | Currently debugfs entries for a DAPM widgets are only added in snd_soc_dapm_debugfs_init. If a widget is added later (for example in the dai_link's probe callback) it will not show up in debugfs. This patch moves the creation of the widget debugfs entry to snd_soc_dapm_new_widgets where it will be added after the widget has been properly instantiated. As a side-effect this will also reduce the number of times the DAPM widget list is iterated during a card's instantiation. Since it is possible that snd_soc_dapm_new_widgets is invoked form the codecs or cards probe callbacks, the creation of the debugfs dapm directory has to be moved before these are called. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Liam Girdwood <lrg@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* ASoC: Move DAPM debugfs directory creation to snd_soc_dapm_debugfs_initLars-Peter Clausen2011-05-031-3/+10
| | | | | | | | | Move the creation of the DAPM debugfs directory to snd_soc_dapm_debugfs_init instead of having the same duplicated code in both codec and card DAPM setup. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Liam Girdwood <lrg@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* ASoC: Add dapm_find_widget helperLars-Peter Clausen2011-04-271-70/+45
| | | | | | | | | | | This patch adds a helper function for searching DAPM widgets by name. This allows to streamline functions which operate on widgets by name. It also allows to get rid of copy'n'pasted code which was added to fallback to widgets from other contexts if the widget was not found in the current context. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Liam Girdwood <lrg@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* ASoC: fix a simple coding style issueLu Guanqun2011-04-201-1/+1
| | | | | | Signed-off-by: Lu Guanqun <guanqun.lu@intel.com> Acked-by: Liam Girdwood <lrg@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* ASoC: snd_soc_dapm_get_pin_status: Match other contexts tooStephen Warren2011-04-201-0/+6
| | | | | | | | | | | | | | | | | Not all widgets on a card are within the codec's DAPM context. Fix snd_soc_dapm_get_pin_status to search all contexts when looking for a widget. This change is required when modifying tegra_wm8903 to use snd_soc_card.widgets rather than calling snd_soc_dapm_new_controls; the former adds the widgets to the card's DAPM context, whereas tegra_wm8903 uses the codec's DAPM context when calling snd_soc_dapm_new_controls. By code inspection, I suspect this also applies to Samsung Speyside. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Liam Girdwood <lrg@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* ASoC: Allow DAPM pin operations to match any contextMark Brown2011-04-091-0/+24
| | | | | | | | | | | | | | | The DAPM pin operations currently require that the specific DAPM context that the pin being operated in is contained in be specified. With multi component and especially with the addition of a per-card DAPM context this isn't ideal as it means that things like disabling unused pins on CODECs require looking up the CODEC DAPM context. Fix this by falling back to matching a widget in any context if there isn't a match in the current context. The code isn't ideal currently but will do the job. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
* ASoC: Force all DAPM contexts into the same bias stateMark Brown2011-04-091-0/+9
| | | | | | | | | | | | | Currently we allow all DAPM contexts to determine their own bias level. While this should in general work in most situations and will deliver the lowest possible power it causes problems for our integration with the card bias level as we're calling the card bias level functions for each DAPM context even though they're card wide but don't say which CODEC we're calling them for. Mitigate against this by forcing everything to be in the same state. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
* ASoC: Remove special casing for registerless widgetsMark Brown2011-04-081-100/+0
| | | | | | | | | | | | | Since we recently explicitly set the register for registerless widgets to no register there is no longer any need to special case power updates for them, we can allow them to be handled with the register compression code as other widgets are. As this is the only remaining user of dapm_generic_apply_power() and dapm_update_bits() also remove those functions. Noticed-by: Lu Guanqun <guanqun.lu@intel.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* ASoC: Add bias level data to DAPM context debugfsMark Brown2011-04-051-0/+48
| | | | | | | This is also in the old sysfs diagnostics but it's nice to have everything in one place. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* Merge branch 'for-2.6.38' into for-2.6.39Mark Brown2011-03-091-1/+1
|\ | | | | | | | | | | Conflicts: sound/soc/codecs/wm8978.c sound/soc/soc-dapm.c
| * ASoC: Use the correct DAPM context when cleaning up final widget setMark Brown2011-03-091-1/+1
| | | | | | | | | | | | | | | | | | | | Now we've got multi-component we need to make sure that the DAPM context (and hence register I/O context) we use to apply the pending updates at the end of a DAPM sequence is the one we were processing rather than the one that was used to initate the state change. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
* | ASoC: Fix double addition of prefixes due to widget prefixingMark Brown2011-03-091-3/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We're not only prefixing all controls, we're also prefixing the widget names in the runtime data. This causes us to add the prefix twice - once when using the widget name to generate the control name and once when adding the control. Really we shouldn't be prefixing the widget names at all, the matching code should be handing this as we always know which DAPM context a widget came from and always display the widget name in terms of a DAPM context. However, we're quite close to the merge window and that's relatively invasive. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Reported-by: Jarkko Nikula <jhnikula@gmail.com> Acked-by: Jarkko Nikula <jhnikula@gmail.com> Acked-by: Liam Girdwood <lrg@ti.com>
* | ASoC: Fix prefixing of DAPM controls by factoring prefix into snd_soc_cnew()Mark Brown2011-03-081-2/+14
| | | | | | | | | | | | | | | | | | Currently will ignore prefixes when creating DAPM controls. Since currently all control creation goes through snd_soc_cnew() we can fix this by factoring the prefixing into that function. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@ti.com>
* | ASoC: Check for a CODEC before dereferencing in DAPMMark Brown2011-03-031-3/+3
| | | | | | | | | | | | | | | | A CODEC pointer is optional (and is checked for in most contexts within DAPM) - add checks to the few places where it was missed. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
* | ASoC: Get the card directly from the DAPM contextMark Brown2011-03-031-4/+4
| | | | | | | | | | | | | | | | Rather than indirecting through the CODEC we can look the card up directly from the card pointer in the DAPM context. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
* | ASoC: soc-dapm: Include quotes around contents in debugfs entriesDimitris Papastamos2011-02-251-2/+2
| | | | | | | | | | | | | | | | | | | | Sometimes the name of the control switch of a dapm route contains spaces which makes it impossible to distinguish it from the source widget. Add quotes around the names of the widgets to makes these parsable. Signed-off-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@slimlogic.co.uk> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* | ASoC: Run bias level changes for all DAPM contexts in parallelMark Brown2011-02-221-51/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As bias level changes can be quite time consuming and the bias changes for multiple devices aren't strongly tied to each other (if anything it can be advantageous to bring different devices up together) we can improve the state transition time for multi-component systems by running the bias level changes for all the devices in parallel. This is very simple to achieve using the kernel async functionality so use that to schedule the work. This should have no practical effect for the overwhelming majority of systems which have a single DAPM context - we'll bounce into another thread to do the bias level change but otherwise everything will happen in exactly the same order as it did before. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
* | ASoC: Remove card from snd_soc_dapm_set_bias_level()Mark Brown2011-02-221-11/+11
| | | | | | | | | | | | | | | | We can get the card from the DAPM context so don't bother passing it as an argument. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
* | ASoC: Remove export of snd_soc_dapm_stream_event()Mark Brown2011-02-181-1/+0
| | | | | | | | | | | | | | | | The only thing that should ever be calling this is soc-core and that is built as part of the same module so doesn't need the export. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
* | Merge branch 'for-2.6.38' into for-2.6.39Mark Brown2011-02-131-1/+9
|\|
| * ASoC: Ensure supplies are maintained for force enabled widgetsMark Brown2011-02-131-1/+9
| | | | | | | | | | | | | | | | | | | | | | If a widget has been force enabled then not only do we need to keep the widget itself enabled, we also need to keep any supplies the widget requires enabled. The user could force all the individual widgets on but this requires too much knowledge of device internals. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Tested-by: Stephen Warren <swarren@nvidia.com> Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
* | Merge branch 'for-2.6.38' into for-2.6.39Mark Brown2011-02-091-0/+13
|\|
| * ASoC: Sync initial widget state with hardwareMark Brown2011-02-091-0/+13
| | | | | | | | | | | | | | | | | | | | | | ASoC generally uses the register defaults for everything, but in some cases the hardware will default to enabling some of the DAPM widgets (clocks for example). Ensure that DAPM knows about the actual widget state at initialisation by reading the enable bits after instantiating the widgets so they don't get left enabled needlessly. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
* | Merge branch 'for-2.6.38' into for-2.6.39Mark Brown2011-01-281-3/+3
|\|
| * ASoC: Fix mask/val_mask confusion snd_soc_dapm_put_volsw()Stephen Warren2011-01-281-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | snd_soc_dapm_put_volsw() has variables for both the unshifted and shifted mask for updates commit 97404f (ASoC: Do DAPM control updates in the middle of DAPM sequences) got confused between the two of these. Since there's no need to keep a copy of the unshifted mask fix this and simplify the code by using only one mask variable. [Completely rewrote the changelog to describe the issue -- broonie.] Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Liam Girdwood <lrg@slimlogic.co.uk> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
* | ASoC: Add subsequence information to seq_notify callbacksMark Brown2011-01-271-2/+3
| | | | | | | | | | | | | | | | Allows drivers to distinguish which subsequence is being notified when they get called back. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
* | ASoC: Provide per widget type callback when executing DAPM sequencesMark Brown2011-01-191-1/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | Many modern devices have features such as DC servos which take time to start. Currently these are handled by per-widget events but this makes it difficult to paralleise operations on multiple widgets, meaning delays can end up being needlessly serialised. By providing a callback to drivers when all widgets of a given type have been handled during a DAPM sequence the core allows drivers to start operations separately and wait for them to complete much more simply. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
* | ASoC: Add support for sequencing withinMark Brown2011-01-191-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With larger devices there may be many widgets of the same type in series in an audio path. Allow drivers to specify an additional level of ordering within each widget type by adding a subsequence number to widgets and then splitting operations on widgets so that widgets of the same type but different sequence numbers are processed separately. A typical example would be a supply widget which requires that another widget be enabled to provide power or clocking. SND_SOC_DAPM_PGA_S() and SND_SOC_DAPM_SUPPLY_S() macros are provided allowing this to be used with PGAs and supplies as these are the most commonly affected widgets. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
* | ASoC: Explicitly say if we're powering up or downMark Brown2011-01-191-12/+25
|/ | | | | | | | | | Rather than passing the sequence to use for DAPM widgets around by reference explicitly say if we're powering up or down until the point where we need the sequence itself. This should make no practical difference in itself but supports future refactoring. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
* ASoC: don't pass the string as the format arguemtn for dev_info()Takashi Iwai2010-12-221-1/+1
| | | | Signed-off-by: Takashi Iwai <tiwai@suse.de>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-26 22:47:05 +0100