summaryrefslogtreecommitdiff
path: root/sound/soc/soc-dapm.c
AgeCommit message (Collapse)Author
2017-01-17ASoC: dapm: handle probe deferralsLinus Walleij
This starts to handle probe deferrals on regulators and clocks on the ASoC DAPM. I came to this patch after audio stopped working on Ux500 ages ago and I finally looked into it to see what is wrong. I had messages like this in the console since a while back: ab8500-codec.0: ASoC: Failed to request audioclk: -517 ab8500-codec.0: ASoC: Failed to create DAPM control audioclk ab8500-codec.0: Failed to create new controls -12 snd-soc-mop500.0: ASoC: failed to instantiate card -12 snd-soc-mop500.0: Error: snd_soc_register_card failed (-12)! snd-soc-mop500: probe of snd-soc-mop500.0 failed with error -12 Apparently because the widget table for the codec looks like this (sound/soc/codecs/ab8500-codec.c): static const struct snd_soc_dapm_widget ab8500_dapm_widgets[] = { /* Clocks */ SND_SOC_DAPM_CLOCK_SUPPLY("audioclk"), /* Regulators */ SND_SOC_DAPM_REGULATOR_SUPPLY("V-AUD", 0, 0), SND_SOC_DAPM_REGULATOR_SUPPLY("V-AMIC1", 0, 0), SND_SOC_DAPM_REGULATOR_SUPPLY("V-AMIC2", 0, 0), SND_SOC_DAPM_REGULATOR_SUPPLY("V-DMIC", 0, 0), So when we call snd_soc_register_codec() and any of these widgets get a deferred probe we do not get an -EPROBE_DEFER (-517) back as we should and instead we just fail. Apparently the code assumes that clocks and regulators must be available at this point and not defer. After this patch it rather looks like this: ab8500-codec.0: Failed to create new controls -517 snd-soc-mop500.0: ASoC: failed to instantiate card -517 snd-soc-mop500.0: Error: snd_soc_register_card failed (-517)! (...) abx500-clk.0: registered clocks for ab850x snd-soc-mop500.0: ab8500-codec-dai.0 <-> ux500-msp-i2s.1 mapping ok snd-soc-mop500.0: ab8500-codec-dai.1 <-> ux500-msp-i2s.3 mapping ok I'm pretty happy about the patch as it it, but I'm a bit uncertain on how to proceed: there are a lot of users of the external functions snd_soc_dapm_new_control() (111 sites) and that will now return an occassional error pointer, which is not handled in the calling sites. I want an indication from the maintainers whether I should just go in and augment all these call sites, or if deferred probe is frowned upon when it leads to this much overhead. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-11-02ASoC: dapm: Implement stereo mixer control supportChen-Yu Tsai
While DAPM is mono or single channel, its controls can be shared between widgets, such as sharing one stereo mixer control between the left and right channel widgets. An example such as the following routes [Line In Left]----------<Line In Playback Switch>-------[Left Mixer] ^ ^ ^ | ^ (inputs) (paths) <shared stereo mixer control> (outputs) v v | v v [Line In Right]---------<Line In Playback Switch>-------[Right Mixer] where we have separate widgets and paths for the left and right channels from "Line In" to "Mixer", but a shared stereo mixer control for the 2 paths. This patch introduces support for such shared mixer controls, allowing more than 1 path to be attached to a single stereo control, and being able to control left/right channels independently. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-11-02ASoC: dapm: Support second register for DAPM control updatesChen-Yu Tsai
To support double channel shared controls split across 2 registers, one for each channel, we must be able to update both registers together. Add a second set of register fields to struct snd_soc_dapm_update, and update the DAPM control writeback (put) callbacks to support this. For codecs that use custom events which call into DAPM to do updates, also clear struct snd_soc_dapm_update before using it, so the second set of fields remains clean. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-09-29Merge remote-tracking branch 'asoc/topic/dapm' into asoc-nextMark Brown
2016-09-01ASoC: dapm: Fix kcontrol creation for output driver widgetChen-Yu Tsai
Commit d88429a695a4 ("ASoC: dapm: Add output driver widget") added the snd_soc_dapm_out_drv ID for the output driver widget, which is the same as the PGA widget, with a later power sequence number. Commit 19a2557b76d6 ("ASoC: dapm: Add kcontrol support for PGAs") then added kcontrol support for PGA widgets, but failed to account for output driver widgets. Attempts to use kcontrols with output driver widgets result in silent failures, with the developer having little idea about what went on. Add snd_soc_dapm_out_drv to the switch/case block under snd_soc_dapm_pga in dapm_create_or_share_kcontrol, since they are essentially the same. Fixes: 19a2557b76d6 (ASoC: dapm: Add kcontrol support for PGAs) Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-09-01ASoC: dapm: Fix value setting for _ENUM_DOUBLE MUX's second channelChen-Yu Tsai
The value for the second channel in _ENUM_DOUBLE (double channel) MUXs is not correctly updated, due to using the wrong bit shift. Use the correct bit shift, so both channels toggle together. Fixes: 3727b4968453 (ASoC: dapm: Consolidate MUXs and value MUXs) Signed-off-by: Chen-Yu Tsai <wens@csie.org> Reviewed-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-09-01ASoC: dapm: Fix possible uninitialized variable in snd_soc_dapm_get_volsw()Chen-Yu Tsai
If soc_dapm_read() fails, val will be uninitialized, and bogus values will be written later: ret = soc_dapm_read(dapm, reg, &val); val = (val >> shift) & mask; However, the compiler does not give a warning. Return on error before val is really used to avoid this. This is similar to the commit 6912831623c5 ("ASoC: dapm: Fix uninitialized variable in snd_soc_dapm_get_enum_double()") Fixes: ce0fc93ae56e (ASoC: Add DAPM support at the component level) Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-08-16ASoC: dapm: Fix typos in commentPeter Meerwald-Stadler
Signed-off-by: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-07-27ASoC: dapm: Add a dummy snd_pcm_runtime to avoid NULL pointer accessNicolin Chen
The SND_SOC_DAPM_PRE_PMU case would call startup()/hw_params() that might access substream->runtime through other functions. For example: Unable to handle kernel NULL pointer dereference at virtual address [....] PC is at snd_pcm_hw_rule_add+0x24/0x1b0 LR is at snd_pcm_hw_constraint_list+0x20/0x28 [....] Process arecord (pid: 424, stack limit = 0xffffffc1ecaf0020) Call trace: [<ffffffc00086be68>] snd_pcm_hw_rule_add+0x24/0x1b0 [<ffffffc00086c014>] snd_pcm_hw_constraint_list+0x20/0x28 [<ffffffc0008b47a4>] cs53l30_pcm_startup+0x24/0x30 [<ffffffc0008a6260>] snd_soc_dai_link_event+0x290/0x354 [<ffffffc0008a7528>] dapm_seq_check_event.isra.31+0x134/0x2c8 [<ffffffc0008a7768>] dapm_seq_run_coalesced+0x94/0x1c8 [<ffffffc0008a7940>] dapm_seq_run+0xa4/0x404 [<ffffffc0008a8bac>] dapm_power_widgets+0x524/0x984 [<ffffffc0008ab1c4>] snd_soc_dapm_stream_event+0x8c/0xa8 [<ffffffc0008ac7f4>] soc_pcm_prepare+0x10c/0x1ec [<ffffffc000865b9c>] snd_pcm_do_prepare+0x1c/0x38 [<ffffffc000865600>] snd_pcm_action_single+0x40/0x88 [<ffffffc0008656b8>] snd_pcm_action_nonatomic+0x70/0x90 [<ffffffc000868d28>] snd_pcm_common_ioctl1+0xb6c/0xdd8 [<ffffffc000869508>] snd_pcm_capture_ioctl1+0x200/0x334 [<ffffffc00086a084>] snd_pcm_ioctl_compat+0x648/0x95c [<ffffffc0001ff4b4>] compat_SyS_ioctl+0xac/0xfc4 [<ffffffc000084cf0>] el0_svc_naked+0x24/0x28 ---[ end trace 0dc4f99c2759c35c ]--- So this patch adds a dummy runtime for the original dummy substream to merely avoid the NULL pointer access. Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-07-24Merge remote-tracking branches 'asoc/topic/dpcm', 'asoc/topic/dt', ↵Mark Brown
'asoc/topic/dwc' and 'asoc/topic/fsl' into asoc-next
2016-07-05ASoC: dapm: Export snd_soc_dapm_new_controlSubhransu S. Prusty
This is useful outside the core, when one dapm element is added at a time. Signed-off-by: Subhransu S. Prusty <subhransu.s.prusty@intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-06-15ASoC: dapm: Fix to return correct path list in is_connected_ep.Jeeja KP
In is_connected_ep, when custom_stop_condition is true, need to return the correct paths instead of con which is 0. Fixes: 6742064aef7f('ASoC: dapm: support user-defined stop condition in dai_get_connected_widgets') Signed-off-by: Jeeja KP <jeeja.kp@intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-05-30ASoC: dapm: support user-defined stop condition in dai_get_connected_widgetsPiotr Stankiewicz
Certain situations may warrant examining DAPM paths only to a certain arbitrary point, as opposed to always following them to the end. For instance, when establishing a connection between a front-end DAI link and a back-end DAI link in a DPCM path, it does not make sense to walk the DAPM graph beyond the first widget associated with a back-end link. This patch introduces a mechanism which lets a user of dai_get_connected_widgets supply a function which will be called for every node during the graph walk. When invoked, this function can execute arbitrary logic to decide whether the walk, given a DAPM widget and walk direction, should be terminated at that point or continued as normal. Signed-off-by: Piotr Stankiewicz <piotrs@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-03-18ASoC: dapm: Make sure we have a card when displaying component widgetsMark Brown
The dummy component is reused for all cards so we special case and don't bind it to any of them. This means that code like that displaying the component widgets that tries to look at the card will crash. In the future we will fix this by ensuring that the dummy component looks like other components but that is invasive and so not suitable for a fix. Instead add a special case check here. Reported-by: Harry Pan <harry.pan@intel.com> Suggested-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
2016-03-13Merge remote-tracking branch 'asoc/topic/dapm' into asoc-nextMark Brown
2016-03-05Merge remote-tracking branch 'asoc/fix/dapm' into asoc-linusMark Brown
2016-03-05ASoC: dapm: Remove unneeded variable ret returning 0Rajan Vaja
This patch fixes coccicheck report: Unneeded variable: "ret". Return "0" on line 2817 Remove unneccesary variable ret created to return zero. Signed-off-by: Rajan Vaja <rajan.vaja@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-03-01ASoC: dapm: Fix ctl value accesses in a wrong typeTakashi Iwai
snd_soc_dapm_dai_link_get() and _put() access the associated ctl values as value.integer.value[]. However, this is an enum ctl, and it has to be accessed via value.enumerated.item[]. The former is long while the latter is unsigned int, so they don't align. Fixes: c66150824b8a ('ASoC: dapm: add code to configure dai link parameters') Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-04ASoC: dapm: Don't prefix autodisable widgets twiceLars-Peter Clausen
When a DAPM context has a prefix the autodisable widgets get prefixed twice, once for the control and once for the widget. To avoid this use the un-prefixed control name to construct the autodisable widget name. This change is purely cosmetic. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-12-23Merge remote-tracking branch 'asoc/topic/pcm-list' into asoc-nextMark Brown
2015-12-23Merge remote-tracking branch 'asoc/topic/dapm' into asoc-nextMark Brown
2015-12-02ASoC: dapm: Make enable/disable_pin work with always on widgetsCharles Keepax
Always on widgets currently have some odd interactions with DAPM. Enabling/disabling a widget (snd_soc_dapm_enable_pin) then connecting it to a path works as expected, ie. when the widget is disabled the path doesn't power up and it does when the widget is enabled. However once in a path enabling the widget does not cause anything to power up, dapm_widget_set_power will return the current power state of the widget as 1, meaning we never check peer power states. This patch updates dapm_always_on_check_power to return w->connected such that it is effected by snd_soc_dapm_enable_pin and the like. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-11-25ASoC: dapm: add a dapm sink widgetVinod Koul
DAPM models various widgets but lacks a sink widget. DSPs can have modules which take audio data, process it and are capable of generating events thus acting as a sink of data. To make the dapm graph complete for such paths we need a dapm sink widget for these modules, so add a SND_SOC_DAPM_SINK to declare such a widget. This widget will be treated as SND_SOC_DAPM_EP_SINK endpoint in the dapm graph Signed-off-by: Vinod Koul <vinod.koul@intel.com> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-11-18ASoC: Change the PCM runtime array to a listMengdong Lin
Currently the number of DAI links is statically defined by the machine driver at build time using an array. This makes it difficult to shrink/ grow the number of DAI links at runtime in order to reflect any changes in topology. We can change the DAI link array in the core to a list so that PCMs and FE DAI links can be added and deleted at runtime to reflect changes in use case and DSP topology. The machine driver can still register DAI links as an array. As the 1st step, this patch change the PCM runtime array to a list. A new PCM runtime is added to the list when a DAI link is bound successfully. Later patches will further implement the DAI link list. More: - define snd_soc_new/free_pcm_runtime() to create/free a runtime. - define soc_add_pcm_runtime() to add a runtime to the rtd list. - define soc_remove_pcm_runtimes() to clean up the runtime list. - traverse the rtd list to probe the link components and dais. - Add a field "num" to PCM runtime struct, used to specify the device number when creating the pcm device, and for a soc card to access its dai_props array. - The following 3rd party machine/platform drivers iterate the rtd list to check the runtimes: sound/soc/intel/atom/sst-mfld-platform-pcm.c sound/soc/intel/boards/cht_bsw_rt5645.c sound/soc/intel/boards/cht_bsw_rt5672.c sound/soc/intel/boards/cht_bsw_max98090_ti.c Signed-off-by: Mengdong Lin <mengdong.lin@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-11-10ASoC: dapm: Reset dapm wcache after freeing damp widgetsJyri Sarha
If there is anything in damp->path_source_cache or damp->path_sink_cache, it can not be valid after the widgets have been freed. Without this patch a repeated remove and load of a machine driver may cause NULL pointer reference in dapm_wcache_lookup() when a freed widget, not belonging to any list, is haunting in the wcache. Signed-off-by: Jyri Sarha <jsarha@ti.com> Reported-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-10-26Merge remote-tracking branch 'asoc/topic/dapm' into asoc-nextMark Brown
2015-10-22ASoC: dapm: Add snd_soc_dapm_kcontrol_widget()Mythri P K
Given a kcontrol, we may want to access the parent widget and it's associated data. So export function to return it. Signed-off-by: Mythri P K <mythri.p.k@intel.com> Signed-off-by: Jeeja KP <jeeja.kp@intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-10-22ASoC: dapm: Add startup & shutdown for dai_linksJeeja KP
For DAI link events, DSPs would like to get notified for startup and shutdown event as well apart for existing hw_params. This helps managing DSP resource allocation and freeup on these events So add support for startup and shutdown for snd_soc_dai_link_event() Signed-off-by: Jeeja KP <jeeja.kp@intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-10-22ASoC: dapm: Add kcontrol support for PGAsJeeja KP
For DSPs we can define processing blocks as DAPM PGA widgets. Some of these proceesing blocks can be configured by usermode like EQ etc. So we need to add support of kcontrol for PGA widgets. Signed-off-by: Jeeja KP <jeeja.kp@intel.com> Signed-off-by: Mythri P K <mythri.p.k@intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-09-11ASoC: dapm: fix memory leakSudip Mukherjee
Incase of an unknown event we were directly returning but we missed freeing params. Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-30Merge remote-tracking branches 'asoc/topic/davinci', ↵Mark Brown
'asoc/topic/davinci-vcif', 'asoc/topic/doc' and 'asoc/topic/dpcm' into asoc-next
2015-08-30Merge remote-tracking branch 'asoc/topic/rt5645' into asoc-nextMark Brown
2015-08-30Merge remote-tracking branch 'asoc/topic/dapm' into asoc-nextMark Brown
2015-08-30Merge remote-tracking branch 'asoc/topic/core' into asoc-nextMark Brown
2015-08-28ASoC: Clean up docbook warningsJonathan Corbet
A number of functions and structures in the sound subsystem had incomplete and/or obsolete DocBook comments, leading to warnings when the docs were built. Correct those comments so that we can enjoy our audio in the absence of warning noise. Signed-off-by: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-13ASoC: dapm: Consolidate path trace eventsLars-Peter Clausen
The snd_soc_dapm_input_path and snd_soc_dapm_output_path trace events are identical except for the direction. Instead of having two events have a single one that has a field that contains the direction. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-13ASoC: dapm: Consolidate input and output path handlingLars-Peter Clausen
After the recent cleanups and generalizations of the DAPM algorithm the handling of input and output paths is now fully symmetric. This means by making some slight changes to the data structure and using arrays with one entry for each direction, rather than separate fields, it is possible to create a generic implementation that is capable of handling both input and output paths. Unfortunately this generalization significantly increases the code size on the hot path of is_connected_{input,output}_ep() and dapm_widget_invalidate_{input,output}_paths(), which has a negative impact on the overall performance. The inner loops of those functions are quite small and the generic implementation adds extra pointer arithmetic in a few places. Testing on ARM shows that the combined code size of the specialized functions is about 50% larger than the generalized function in relative numbers. But in absolute numbers its less than 200 bytes, which is still quite small. On the other hand the generalized function increases the execution time of dapm_power_one_widget() by 30%. Given that this function is one of the most often called functions of the DAPM framework the trade-off of getting better performance at expense of generating slightly larger code at seems to be worth it. To avoid this still keep two versions of these functions around, one for input and one for output. But have a generic implementation of the algorithm which gets inlined by those two versions. And then let the compiler take care of optimizing it and removing he extra instructions. This still reduces the source code size as well as the makes making changes to the implementation more straight forward since the same change does no longer need to be done in two separate places. Also on the slow paths we can use a generic implementations that handle both input and output paths. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-13ASoC: dapm: dapm_dai_get_connected_widgets: Fix missing mutex unlockLars-Peter Clausen
Make sure to unlock the DAPM mutex when dapm_widget_list_create() fails. This means the function will now generate a trace_snd_soc_dapm_connected event, even if the creation of the list fails. But that was the behavior before the patch that introduced the unlock issue, so that should be fine. Fixes: 1ce43acff0c0 ("ASoC: dapm: Simplify list creation in dapm_dai_get_connected_widgets()") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-29ASoC: dapm: Add widget path iteratorsLars-Peter Clausen
Add helper iterator macros for iterating over the source and sink paths of widget. This will make it easier to change the implementation later on. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-29ASoC: dapm: Simplify list creation in dapm_dai_get_connected_widgets()Lars-Peter Clausen
When running dapm_dai_get_connected_widgets() currently in is_connected_{input,output}_ep() for each widget that gets added the array is resized and the code also loops over all existing entries to avoid adding a widget multiple times. The former can be avoided by collecting the widgets in a linked list and only once we have all widgets allocate the array. The later can be avoided by changing when the widget is added. Currently it is added when walking the neighbor lists of a widget. Since a widget can be neighbors with multiple other widgets it could get added twice and hence the check is necessary. But the main body of is_connected_{input,output}_ep is guaranteed to be only executed at most once per widget. So adding the widget to the list at the beginning of the function automatically makes sure that each widget gets only added once. The only difference is that using this method the starting point itself will also end up on the list, but it can easily be skipped when creating the array. Overall this reduces the code size and speeds things slightly up. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-29ASoC: dapm: Drop always true checksLars-Peter Clausen
list_first_entry() always returns non NULL and since the code previously checked that list is not empty it will also be a valid pointer. Furthermore a path has always a sink or a source widget. So both checks are redundant and can be removed. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-21ASoC: dapm: Avoid duplicating immutable stringsLars-Peter Clausen
When creating a new widget from a template the name string of the template is duplicated for the newly created widget. This is necessary because in some cases the string might be stored on the stack or other volatile memory locations. But most of the time the string is static const data, which means it is possible to use it directly without having to worry that it might get freed or changed. Use kstrdup_const() to handle duplicating the string. This function is capable of detecting whether a string is immutable and if it is returns the input without duplicating it. This will slightly reduce the runtime memory footprint of DAPM and also speed up initialization. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-21ASoC: dapm: Add helper function to free a widgetLars-Peter Clausen
snd_soc_tplg_widget_remove_all() has a verbatim copy of an older version of the widget freeing code from dapm_free_widgets(). Add a new helper function that takes care of freeing a widget and use it in both places. This removes the duplicated code and also makes sure that future changes to the widget freeing code only have to be made in one location. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-21ASoC: dapm: Don't add prefix to widget stream nameLars-Peter Clausen
Commit fdb6eb0a1287 ("ASoC: dapm: Modify widget stream name according to prefix") fixed the case where a DAPM route between a DAI widget and a DAC/ADC/AIF widget with a matching stream name was not created when the DAPM context was using a prefix. Unfortunately the patch introduced a few issues on its own like leaking the dynamically allocated stream name memory and also not checking whether the allocation succeeded in the first place. It is also incomplete in that it still does not handle the case where stream name of the widget is a substring of the stream name of the DAI, which is explicitly allowed and works fine if no DAPM prefix is used. Revert the commit and take a slightly different approach to solving the issue. Instead of comparing the widget's stream name to the name of the DAI widget compare it to the stream name of the DAI widget. The stream name of the DAI widget is identical to the name of the DAI widget except that it wont have the DAPM prefix added. So this approach behaves identical regardless to whether the DAPM context uses a prefix or not. We don't have to worry about potentially matching with a widget with the same stream name, but from a different DAPM context with a different prefix, since the code already makes sure that both the DAI widget and the matched widget are from the same DAPM context. Fixes: fdb6eb0a1287 ("ASoC: dapm: Modify widget stream name according to prefix") Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
2015-07-08ASoC: dapm: Fix kcontrol widget name memory managementLars-Peter Clausen
The name field of the widget template is only used inside snd_soc_dapm_new_control_unlocked() which allocates a copy for the actual widget. This means we need to free the name allocated for the template in dapm_kcontrol_data_alloc() and not the name of the actual widget in dapm_kcontrol_free(). Otherwise we get a double free on the widget name and a memory leak on the template name. Fixes: 773da9b358bf ("ASoC: dapm: Append "Autodisable" to autodisable widget names") Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-07ASoC: core: Don't probe the component which is dummyShengjiu Wang
Dummy dai can be used by multiple sound card. But it only belong to one card's dapm list. If another card use it, there will be dapm_assert_locked warning. [ 20.015782] WARNING: CPU: 1 PID: 661 at sound/soc/soc-dapm.c:124 dapm_assert_locked.isra.36+0x4c/0x58() [ 20.025249] Modules linked in: [ 20.028349] CPU: 1 PID: 661 Comm: aplay Not tainted 4.1.0-rc6-next-20150605-00004-gaee05d8-dirty #92 [ 20.037528] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [ 20.044110] Backtrace: [ 20.046614] [<80012e00>] (dump_backtrace) from [<80012fa0>] (show_stack+0x18/0x1c) [ 20.054229] r6:809e8060 r5:00000000 r4:00000000 r3:00000000 [ 20.060002] [<80012f88>] (show_stack) from [<807a0f74>] (dump_stack+0x80/0x9c) [ 20.067293] [<807a0ef4>] (dump_stack) from [<8002b144>] (warn_slowpath_common+0x7c/0xb4) [ 20.075427] r5:0000007c r4:00000000 [ 20.079065] [<8002b0c8>] (warn_slowpath_common) from [<8002b1a0>] (warn_slowpath_null+0x24/0x2c) [ 20.087898] r8:00000001 r7:88007c28 r6:ed94a680 r5:809e83e4 r4:ed83d6c0 [ 20.094747] [<8002b17c>] (warn_slowpath_null) from [<8058403c>] (dapm_assert_locked.isra.36+0x4c/0x58) [ 20.104101] [<80583ff0>] (dapm_assert_locked.isra.36) from [<805842ec>] (dapm_mark_dirty+0x64/0xa4) [ 20.113165] [<80584288>] (dapm_mark_dirty) from [<805853a8>] (soc_dapm_dai_stream_event.isra.42+0x30/0xc8) [ 20.122863] r8:ed9b5dbc r7:00000000 r6:00000001 r5:00000001 r4:ed83d6c0 [ 20.129706] [<80585378>] (soc_dapm_dai_stream_event.isra.42) from [<80587e28>] (snd_soc_dapm_stream_event+0x78/0xa0) [ 20.140264] r5:ee2ee62c r4:00000001 [ 20.143918] [<80587db0>] (snd_soc_dapm_stream_event) from [<8058957c>] (soc_pcm_prepare+0x138/0x21c) [ 20.153058] r8:ed8d9480 r7:00000000 r6:ed9b0e00 r5:00000001 r4:ee2ee62c r3:00000000 ... This patch is to not probe the dummy component in soc_probe_component. Then there is no widget created for dummy DAI, and also don't need to check the dummy dai in dapm_connect_dai_link_widgets(). Signed-off-by: Shengjiu Wang <shengjiu.wang@freescale.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-07ASoC: dapm_widget_show_codec: Use component instead of CODECLars-Peter Clausen
There is nothing snd_soc_codec specific in this function, just use snd_soc_component instead. With this also the last reference of snd_soc_codec form soc-dapm.c. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-06ASoC: dapm: Lock during userspace accessLars-Peter Clausen
The DAPM lock must be held when accessing the DAPM graph status through sysfs or debugfs, otherwise concurrent changes to the graph can result in undefined behaviour. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
2015-06-26ASoC: dapm: Fix deadlock on auto-disable mux controlsCharles Keepax
The commit 02aa78abec6e ("ASoC: DAPM: Add APIs to create individual DAPM controls.") added locking to the snd_soc_dapm_new_control function but did not update the call to snd_soc_dapm_new_control in the auto-disable mux code, this appears to be because the patches were sent at fairly similar times. This patch change the call in the auto-disable mux code to use the new snd_soc_dapm_new_control_unlocked function instead. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-06-05Merge remote-tracking branch 'asoc/topic/dapm' into asoc-nextMark Brown