- 19 2月, 2014 1 次提交
-
-
由 Charles Keepax 提交于
The error messages for bypassing/unbypassing a regulator appear to be swapped round, this patch corrects these. Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: NMark Brown <broonie@linaro.org>
-
- 18 1月, 2014 1 次提交
-
-
由 Arun Shamanna Lakshmi 提交于
The prefix for the codec driver can be used during dual identical codec usecases. However, dapm adds prefix twice for codec DAI widget in snd_soc_dapm_add_route API. This change is to avoid double prefix addition for codec DAI widget and is needed while using identical dual codecs. Signed-off-by: NSonghee Baek <sbaek@nvidia.com> Signed-off-by: NArun Shamanna Lakshmi <aruns@nvidia.com> Signed-off-by: NMark Brown <broonie@linaro.org>
-
- 15 1月, 2014 1 次提交
-
-
由 Arun Shamanna Lakshmi 提交于
soc_widget_read API returns the register data and it is possible that a register can contain 0xffffffff. Thus, change the prototype of soc_widget_read to return only the error code and pass the reg data through pointer argument. Signed-off-by: NArun Shamanna Lakshmi <aruns@nvidia.com> Signed-off-by: NMark Brown <broonie@linaro.org>
-
- 08 1月, 2014 1 次提交
-
-
由 Liam Girdwood 提交于
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: NLiam Girdwood <liam.r.girdwood@linux.intel.com> Signed-off-by: NMark Brown <broonie@linaro.org>
-
- 17 12月, 2013 1 次提交
-
-
由 Nenghua Cao 提交于
DPCM can dynamically alter the FE to BE PCM links at runtime based on mixer/mux setting updates. Add soc_dpcm_runtime_update() calling in get/put function for mixer/mux to support this feature. Signed-off-by: NNenghua Cao <nhcao@marvell.com> Signed-off-by: NMark Brown <broonie@linaro.org>
-
- 08 11月, 2013 2 次提交
-
-
由 Takashi Iwai 提交于
Leaving BUG_ON() in a core layer like dapm is rather inappropriate as it leads to panic(), even though sanity checks might be still useful for debugging. Instead, Use WARN_ON(), and handle the error cases accordingly. Signed-off-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NMark Brown <broonie@linaro.org>
-
由 Takashi Iwai 提交于
BUG() used in the driver is just to spit the stack trace on buggy points, not really needed to stop the whole operation. For that purpose, it'd be more convenient to use WARN() instead with more error information. Signed-off-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NMark Brown <broonie@linaro.org>
-
- 29 10月, 2013 2 次提交
-
-
由 Takashi Iwai 提交于
... instead of NULL dereferences. Spotted by coverity CID 402004. Signed-off-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NMark Brown <broonie@linaro.org>
-
由 Takashi Iwai 提交于
... due to a copy & paste error. Spotted by coverity CID 710923. Signed-off-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NMark Brown <broonie@linaro.org> Cc: stable@vger.kernel.org
-
- 10 10月, 2013 2 次提交
-
-
由 Mark Brown 提交于
In order to avoid trying to use an external clock or supply for an on-chip supply prior to it being enabled move the clock and regulator supply events to a separate step in DAPM sequencing from normal supply events. This should have minimal practical impact since these widgets are sorted using SND_SOC_NOPM which is a negative value and hence sorted separately to any real register writes, though it may be relevant if supplies have event callbacks only. Signed-off-by: NMark Brown <broonie@linaro.org>
-
由 Mark Brown 提交于
Within a DAPM sequence we normally don't care about when exactly a register write has completed so long as they happen in the order we requested. This means that we can issue most of the writes we do asynchronously which should maximise the ability of the underlying frameworks to keep the hardware busy, providing a small performance improvement on some systems. We currently ensure that all writes are completed both when changing to a different device and when calling into the regulator and clock frameworks. This should ensure that the previous ordering is maintained. We also ensure that writes are completed prior to calling into widget event functions since some event functions implement delays. This should be improved in future so that widgets can disable this sync in order to add extra writes. Signed-off-by: NMark Brown <broonie@linaro.org>
-
- 07 10月, 2013 2 次提交
-
-
由 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>
-
由 Lars-Peter Clausen 提交于
VMID widgets behave very similar to signal generator widgets. Both are always considered to be powered up. This means that we need to ignore the VMID widgets in the same way as signal generator widgets when calculating the DAPM context's target bias level. Otherwise the presence of a VMID widget, regardless whether it is on an active path or not, will cause the DAPM context to be powered up. Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@linaro.org>
-
- 30 8月, 2013 1 次提交
-
-
由 Lars-Peter Clausen 提交于
We need to make sure that the control's cached value is initialized to the same value as the control's widget->on_val. Otherwise updates might be lost. Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@linaro.org>
-
- 27 8月, 2013 2 次提交
-
-
由 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>
-
由 Lars-Peter Clausen 提交于
The current calls to dapm_mark_dirty() in snd_soc_dapm_add_path() are on a path that is only reached if the sink widget is either a mixer or a mux. Move the calls further up so they are called for all widget types. Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@linaro.org>
-
- 13 8月, 2013 2 次提交
-
-
由 Mark Brown 提交于
Ensure that the recently added path kcontrol list is initialised otherwise we may crash trying to delete routes that don't have kcontrols. Signed-off-by: NMark Brown <broonie@linaro.org> Acked-by: NLars-Peter Clausen <lars@metafoo.de>
-
由 Mark Brown 提交于
Attempting to create the route as part of adding a mux control causes us to attempt to add the same route twice since we loop over all sources for the mux after creating the control. Instead do the addition in the callers. Signed-off-by: NMark Brown <broonie@linaro.org> Acked-by: NLars-Peter Clausen <lars@metafoo.de>
-
- 06 8月, 2013 1 次提交
-
-
由 Russell King 提交于
ASoC automatically creates snd_soc_dapm_dai_in and snd_soc_dapm_dai_out widgets for DAI drivers, and adds them to the list. Later on, ASoC creates automatic routes between these widgets and a widget with a stream name. We look for a snd_soc_dapm_dai_in or snd_soc_dapm_dai_out widget, and use this to obtain the DAI structure. We then scan all widgets for any with a stream name refering to either the capture or the playback stream, and create routes. If you have both a snd_soc_dapm_dai_in and a snd_soc_dapm_dai_out referring to the same DAI structure, this ends up creating one set of routes for the DAI for the snd_soc_dapm_dai_in widget, and a duplicated set of routes for the snd_soc_dapm_dai_out widget. Fix this by checking that the stream name for the widget matches the DAI widget name. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk> 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>
-
- 02 8月, 2013 2 次提交
-
-
由 Lars-Peter Clausen 提交于
list_first_entry() will always return a valid pointer, even if the list is empty. So the check whether path is NULL will always be false. So we end up calling dapm_create_or_share_mixmux_kcontrol() with a path struct that points right in the middle of the widget struct and by trying to modify the path the widgets memory will become corrupted. Fix this by using list_emtpy() to check if the widget doesn't have any paths. Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Tested-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NMark Brown <broonie@linaro.org> Cc: stable@vger.kernel.org
-
由 Lars-Peter Clausen 提交于
When calling krealloc for the kcontrol data the items in the path list that point back to the head of the list will now point to freed memory, which causes the list to become corrupted. To fix this, instead of resizing the whole data struct, only resize the widget list. Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@linaro.org>
-
- 01 8月, 2013 1 次提交
-
-
由 Lars-Peter Clausen 提交于
snd_soc_cnew() can return NULL, so we should check the result before trying to use it. Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@linaro.org>
-
- 31 7月, 2013 1 次提交
-
-
由 Dan Carpenter 提交于
There is a typo here so we end up using the old freed pointer instead of the newly allocated one. (If the "n" is zero then the code works, obviously). Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Acked-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@linaro.org>
-
- 30 7月, 2013 9 次提交
-
-
由 Lars-Peter Clausen 提交于
Wait with updating the widgets power field until the changes are actually written to the hardware in dapm_seq_run_coalesced(). This will allow us to query the current hardware state between calling dapm_power_one_widget() and actually writing the new power state to hardware. Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@linaro.org>
-
由 Lars-Peter Clausen 提交于
snd_soc_dapm_add_path() is similar to snd_soc_dapm_add_route() except that it expects the pointer to the source and sink widgets instead of their names. This allows us to simplify the case where we already have a pointer to widgets. (E.g. as we have in snd_soc_dapm_link_dai_widgets()). snd_soc_dapm_add_route() will be updated to just look up the widget and then use snd_soc_dapm_add_path() to handle everything else. Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@linaro.org>
-
由 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 提交于
In preparation for adding additional per control data wrap all access to the widget list in helper functions. 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 提交于
DAPM operations are always performed on the card as a whole. Yet (primarily for historic reasons) dapm_power_widgets() takes a DAPM context as its parameter. The DAPM context is mainly used to look up a pointer to the card. The same is true for a couple of functions that are being called from dapm_power_widgets(). This patch changes the signature of dapm_power_widgets() and a couple of related functions to take a snd_soc_card instead of a snd_soc_dapm_context. Some of the functions also use the DAPM's device to print error and debug messages. This can be a bit confusing though since this means the messages for all widgets, also those from other contexts, will be printed with that device. The patch updates those cases to use the device of the widget's DAPM context. 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 5 次提交
-
-
由 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>
-
由 Lars-Peter Clausen 提交于
soc_dpcm_runtime_update() operates on a ASoC card as a whole. Currently it takes a snd_soc_dapm_widget as its only parameter though. The widget is then used to look up the card and is otherwise unused. This patch changes the function to take a pointer to the card directly. This makes it possible to to call soc_dpcm_runtime_update() for updates which are not related to one specific widget. Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@linaro.org>
-
由 Mark Brown 提交于
As noticed by Lars-Peter Clausen since the move to using widgets to hook into the DAIs we no longer directly manage the power of AIF or DAC/ADC widgets from the stream integration so they can just use the generic power checks instead of the custom stream integration ones they currently do. Signed-off-by: NMark Brown <broonie@linaro.org>
-
由 Lars-Peter Clausen 提交于
The ALSA core expect the put callback of a control to return 1 if the value of the control changed and 0 if it did not. Both snd_soc_dapm_put_volsw() and snd_soc_dapm_put_enum_virt() currently always returns 0. For both functions we already have a 'change' variable which either contains 1 or 0 depending on whether the value has changed or not, so just return that. Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@linaro.org>
-
- 23 7月, 2013 1 次提交
-
-
由 Lars-Peter Clausen 提交于
These two functions were added two years ago in commit 4805608a ("ASoC: dapm - Add methods to retrieve snd_card and soc_card from dapm context.") but have remained unused so far. Considering that the dapm context actually has a direct pointer to the card the functions also seem to be unnecessary. E.g. the expressions 'dapm_get_soc_card(dapm)' and 'dapm->card' yield the same result. Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@linaro.org>
-
- 14 6月, 2013 1 次提交
-
-
由 Lars-Peter Clausen 提交于
The power up/down sequence order for DAPM switch widgets is not explicitly initialized, causing them to be run always as the first widget type for both power up and down. Move it to the same position in the sequence as other mixer widget types. Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@linaro.org>
-