- 21 7月, 2015 1 次提交
-
-
由 Lars-Peter Clausen 提交于
Commit fdb6eb0a ("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: fdb6eb0a ("ASoC: dapm: Modify widget stream name according to prefix") Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
-
- 09 7月, 2015 1 次提交
-
-
由 Lars-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: 773da9b3 ("ASoC: dapm: Append "Autodisable" to autodisable widget names") Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@kernel.org>
-
- 07 7月, 2015 1 次提交
-
-
由 Lars-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: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
-
- 26 6月, 2015 1 次提交
-
-
由 Charles Keepax 提交于
The commit 02aa78ab ("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: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: NMark Brown <broonie@kernel.org>
-
- 04 6月, 2015 1 次提交
-
-
由 Liam Girdwood 提交于
Fix the following error:- All error/warnings (new ones prefixed by >>): > > sound/built-in.o: In function `soc_tplg_dapm_widget_create': > >> :(.text+0x25a90): undefined reference to `snd_soc_dapm_new_control' Signed-off-by: NLiam Girdwood <liam.r.girdwood@linux.intel.com> Signed-off-by: NMark Brown <broonie@kernel.org>
-
- 03 6月, 2015 1 次提交
-
-
由 Vladimir Zapolskiy 提交于
The change fixes the following compilation problem: sound/soc/soc-dapm.c: In function 'dapm_kcontrol_data_alloc': sound/soc/soc-dapm.c:388:4: error: implicit declaration of function 'snd_soc_dapm_new_control' [-Werror=implicit-function-declaration] data->widget = snd_soc_dapm_new_control(widget->dapm, ^ sound/soc/soc-dapm.c:387:17: warning: assignment makes pointer from integer without a cast [enabled by default] data->widget = snd_soc_dapm_new_control(widget->dapm, ^ sound/soc/soc-dapm.c: At top level: sound/soc/soc-dapm.c:3269:1: error: conflicting types for 'snd_soc_dapm_new_control' snd_soc_dapm_new_control(struct snd_soc_dapm_context *dapm, ^ In addition to the fix add static qualifier to snd_soc_dapm_new_control() function to silence checkpatch. Fixes: 02aa78ab ("ASoC: DAPM: Add APIs to create individual DAPM controls.") Signed-off-by: NVladimir Zapolskiy <vz@mleia.com> Signed-off-by: NMark Brown <broonie@kernel.org>
-
- 29 5月, 2015 1 次提交
-
-
由 Liam Girdwood 提交于
The topology core needs to be able to create individual widget controls at runtime and driver init. Add a regular locked and unlocked API calls to facilitate this requirement. The unlocked call is used by the topology core during component driver probing where the card dapm_mutex is held by the ASoC core and the locked version at non component driver probe time. Signed-off-by: NLiam Girdwood <liam.r.girdwood@linux.intel.com> Signed-off-by: NMark Brown <broonie@kernel.org>
-
- 13 5月, 2015 1 次提交
-
-
由 Koro Chen 提交于
When there is prefix specified, currently we will add this prefix in widget->name, but not in widget->sname. it causes failure at snd_soc_dapm_link_dai_widgets: if (!w->sname || !strstr(w->sname, dai_w->name)) because dai_w->name has prefix added, but w->sname does not. We should also add prefix for stream name Signed-off-by: NKoro Chen <koro.chen@mediatek.com> Signed-off-by: NMark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
-
- 12 5月, 2015 1 次提交
-
-
由 Charles Keepax 提交于
Some CODECs have a significant number of DAPM routes and for each route, when it is added to the card, the entire card widget list must be searched. When adding routes it is very likely, however, that adjacent routes will require adjacent widgets. For example all the routes for a mux are likely added in a block and the sink widget will be the same each time and it is also quite likely that the source widgets are sequential located in the widget list. This patch adds a cache to the DAPM context, this cache will hold the source and sink widgets from the last call to snd_soc_dapm_add_route for that context. A small search of the widget list will be made from those points for both the sink and source. Currently this search only checks both the last widget and the one adjacent to it. On wm8280 which has approximately 500 widgets and 30000 routes (one of the largest CODECs in mainline), the number of paths that hit the cache is 24000, which significantly improves probe time. Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: NMark Brown <broonie@kernel.org>
-
- 11 5月, 2015 1 次提交
-
-
由 Charles Keepax 提交于
Currently snd_soc_dapm_add_route will continue to search the widget list even after both the source and sink for the route have been located. This patch breaks out of the search when both are located giving a small improvement in probe time for drivers. Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: NMark Brown <broonie@kernel.org>
-
- 08 5月, 2015 1 次提交
-
-
由 Charles Keepax 提交于
The is a missing mutex unlock on the error path in snd_soc_dapm_get_enum_double. This was introduced in commit 561ed680 ("ASoC: dapm: Add support for autodisable mux controls"). This patch adds the missing unlock. Reported-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: NMark Brown <broonie@kernel.org>
-
- 07 5月, 2015 5 次提交
-
-
由 Lars-Peter Clausen 提交于
A demux is conceptually similar to a mux. Where a mux has multiple input and one output and selects one of the inputs to be connected to the output, the demux has one input and multiple outputs and selects one of the outputs to which the input gets connected. This similarity makes it straight forward to support them in DAPM using the existing mux support, we only need to swap sinks and sources when initially setting up the paths. The only slightly tricky part is that there can only be one control per path. Since mixers/muxes are at the sink of a path and a demux is at the source and both types want a control it is not possible to directly connect a demux output to a mixer/mux input. The patch adds some sanity checks to make sure that this does not happen. Drivers who want to model hardware which directly connects a demux output to a mixer/mux input can do this by inserting a dummy widget between the two. E.g.: { "Dummy", "Demux Control", "Demux" }, { "Mixer", "Mixer Control", "Dummy" }, Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Lars-Peter Clausen 提交于
Currently new widgets are appended to the beginning of the cards widget list. This has the effect that widgets that are created while iterating over the widget list in snd_soc_dapm_new_widgets() (like e.g. the auto-disable widgets) are not covered during that invocation of the function. If no further invocations of snd_soc_dapm_new_widgets() happen these widgets will not be fully initialized and e.g. no debugfs entries are created for them. By adding new widgets to the end of the widget list we make sure that widgets that are created in snd_soc_dapm_new_widgets() will still be handled during the same snd_soc_dapm_new_widgets() invocation and are always fully initialized. Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Lars-Peter Clausen 提交于
Currently new widgets are appended to the beginning of the cards widget list. This has the effect that widgets that are created while iterating over the widget list in snd_soc_dapm_new_widgets() (like e.g. the auto-disable widgets) are not covered during that invocation of the function. If no further invocations of snd_soc_dapm_new_widgets() happen these widgets will not be fully initialized and e.g. no debugfs entries are created for them. By adding new widgets to the end of the widget list we make sure that widgets that are created in snd_soc_dapm_new_widgets() will still be handled during the same snd_soc_dapm_new_widgets() invocation and are always fully initialized. Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Charles Keepax 提交于
Commit 57295073 ("ASoC: dapm: Implement mixer input auto-disable") added support for autodisable controls, controls whose values are only written to the hardware when their respective widgets are powered up. But it only added support for controls based on the mixer abstraction. This patch add support for mux controls (DAPM controls based on the enum abstraction) to be auto-disabled as well. As each mux can only have a single control, there is no need to tie the autodisable widget to the inputs (as is done for the mixer controls) it can be tided directly to the mux widget itself. Note that it is assumed that the first entry in a autodisable mux control will always represent the off state for the mux and is what the mux will be set to whilst it is disabled. Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com> Reviewed-by: NLars-Peter Clausen <lars@metafoo.de> Tested-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Charles Keepax 提交于
This makes it a little easier to follow what is happening in debugfs. Additionally is also useful in facilitating work to add autodisable muxes because the control name is already used for the mux widget and thus shouldn't be reused for the autodisable widget. Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com> Reviewed-by: NLars-Peter Clausen <lars@metafoo.de> Tested-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@kernel.org>
-
- 04 5月, 2015 1 次提交
-
-
由 Charles Keepax 提交于
The memory subsystem is pretty chatty on failure no need to have local OOM messages as well. Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com> Reviewed-by: NLars-Peter Clausen <lars@metafoo.de> Tested-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@kernel.org>
-
- 28 4月, 2015 2 次提交
-
-
由 Lars-Peter Clausen 提交于
All drivers have the same line at the end of the set_bias_level callback to update the bias_level state. Move this update into snd_soc_dapm_force_bias_level() and remove them from the drivers. Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Lars-Peter Clausen 提交于
Currently drivers are responsible for managing the bias_level field of their DAPM context. The DAPM state itself is managed by the DAPM core though and the core has certain expectations on how and when the bias_level field should be updated. If drivers don't adhere to these undefined behavior can occur. This patch adds a few helper functions for manipulating the DAPM context state, each function with a description on when it should be used and what its effects are. This will also help us to move more of the bias_level management from drivers to the DAPM core. For convenience also add snd_soc_codec_* wrappers around these helpers. Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@kernel.org>
-
- 09 4月, 2015 1 次提交
-
-
由 Lars-Peter Clausen 提交于
If the registration of a debugfs directory fails this is treated as a non-fatal error in ASoC and operation continues as normal. This means we need to be careful and check if the parent debugfs directory exists if we try to register a debugfs file or sub-directory. Otherwise we might end up passing NULL for the parent and the file or directory will be registered in the top-level debugfs directory. Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@kernel.org>
-
- 25 3月, 2015 1 次提交
-
-
由 Charles Keepax 提交于
commit c6615082 ("ASoC: dapm: add code to configure dai link parameters") introduced the following build warning: sound/soc/soc-dapm.c: In function 'snd_soc_dapm_new_pcm': sound/soc/soc-dapm.c:3389:4: warning: passing argument 1 of 'snprintf' discards 'const' qualifier from pointer target type snprintf(w_param_text[count], len, This patch fixes this by switching to using devm_kasprintf. This also saves a couple of lines of code. Signed-off-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: NMark Brown <broonie@kernel.org>
-
- 18 3月, 2015 1 次提交
-
-
由 Nikesh Oswal 提交于
dai-link params for codec-codec links were fixed. The fixed link between codec and another chip which may be another codec, baseband, bluetooth codec etc may require run time configuaration changes. This change provides an optional alsa control to select one of the params from a list of params. Signed-off-by: NNikesh Oswal <nikesh@opensource.wolfsonmicro.com> Signed-off-by: NMark Brown <broonie@kernel.org>
-
- 16 3月, 2015 1 次提交
-
-
由 Lars-Peter Clausen 提交于
snd_soc_dapm_kcontrol_codec() is a extremely simple function and inlining it typically results in less code than necessary for calling the non-inlined version of the function. Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@kernel.org>
-
- 03 2月, 2015 1 次提交
-
-
由 Takashi Iwai 提交于
Instead of calling device_create_file() manually, assign the static attribute group entries at the device registration. This simplifies the error handling and avoids the possible races. Signed-off-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NMark Brown <broonie@kernel.org>
-
- 15 1月, 2015 1 次提交
-
-
由 Lars-Peter Clausen 提交于
There are no more users of this field left so it can finally be removed. New users should use snd_soc_dapm_to_codec(w->dapm); The reason why it is removed is because it doesn't fit to well anymore in the componentized ASoC hierarchy, where DAPM works on the snd_soc_component level. And the alternative of snd_soc_dapm_to_codec(w->dapm) typically generates the same amount of code, so there is really no reason to keep it. For automatic conversion the following coccinelle semantic patch can be used: // <smpl> @@ struct snd_soc_dapm_widget *w; @@ -w->codec +snd_soc_dapm_to_codec(w->dapm) // </smpl> Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@kernel.org>
-
- 07 1月, 2015 1 次提交
-
-
由 Mark Brown 提交于
The only user of the async I/O support in ASoC is SPI which was using it to avoid needless context thrashing and minimise controller runtime PM bounces. The SPI framework has now been enhanced so that even normal spi_sync() calls won't suffer these effects so we don't need to handle this in ASoC and in fact it can be more efficient not to since we don't need to set up and tear down the buffers needed to manage asynchronous I/O. The async completions that DAPM does are left in place so drivers can use them, they are very cheap if there is no asynchronous work queued. Signed-off-by: NMark Brown <broonie@kernel.org>
-
- 22 12月, 2014 2 次提交
-
-
由 Lars-Peter Clausen 提交于
For legacy reasons the ASoC framework assumes that a CODEC INPUT or OUTPUT widget that is not explicitly connected to a external source or sink is potentially connected to a source or a sink and hence the framework treats the widget itself as source (for INPUT) or sink (for OUTPUT). For this reason a INPUT or OUTPUT widget that is really not connected needs to be explicitly marked as so. Setting the card's fully_routed flag will cause the ASoC core, once that all widgets and routes have been registered, to go through the list of all widgets and mark all INPUT and OUTPUT that are not externally connected as non-connected. This essentially negates the default behaviour of treating INPUT or OUTPUT widgets without external routes as sources or sinks. This patch takes a different approach while getting the same result. Instead of first marking INPUT and OUTPUT widgets as sinks/sources and then later marking them as non-connected, just never mark them as a sink or a source if the fully_routed flag is set on a card. This requires a lot less code and also results in a slightly faster card initialization since there is no need to iterate over all widgets and check whether the INPUT and OUTPUT widgets are connected or not. Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Lars-Peter Clausen 提交于
The connected flag of a widget only affects widgets that are either a source or a sink. The MICBIAS widget is a simple pass-through widget though and hence its behavior is the same regardless of whether the connected flag is set or not. Hence there is not much point in trying to automatically mark MICBIAS widgets as non-connected, so just remove it. Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@kernel.org>
-
- 04 11月, 2014 1 次提交
-
-
由 Lars-Peter Clausen 提交于
The card field of the snd_soc_dai field is very rarely used. We can use dai->component->card instead and remove the card field from the snd_soc_dai struct. Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@kernel.org>
-
- 28 10月, 2014 8 次提交
-
-
由 Lars-Peter Clausen 提交于
Currently we cache the number of input and output paths going to/from a widget only within a power update sequence. But not in between power update sequences. But we know how changes to the DAPM graph affect the number of input (form a source) and output (to a sink) paths of a widget and only need to recalculate them if a operation has been performed that might have changed them. * Adding/removing or connecting/disconnecting a path means that the for the source of the path the number of output paths can change and for the sink the number of input paths can change. * Connecting/disconnecting a widget has the same effect has connecting/ disconnecting all paths of the widget. So for the widget itself the number of inputs and outputs can change, for all sinks of the widget the number of inputs can change and for all sources of the widget the number of outputs can change. * Activating/Deactivating a stream can either change the number of outputs on the sources of the widget associated with the stream or the number of inputs on the sinks. Instead of always invalidating all cached numbers of input and output paths for each power up or down sequence this patch restructures the code to only invalidate the cached numbers when a operation that might change them has been performed. This can greatly reduce the number of DAPM power checks for some very common operations. Since per DAPM operation typically only either change the number of inputs or outputs the number of path checks is reduced by at least 50%. The number of neighbor checks is also reduced about the same percentage, but since the number of neighbors encountered when walking from sink to source is not the same as when walking from source to sink the actual numbers will slightly vary from card to card (e.g. for a mixer we see 1 neighbor when walking from source to sink, but the number of inputs neighbors when walking from source to sink). Bigger improvements can be observed for widgets with multiple connected inputs and output (e.g. mixers probably being the most widespread form of this). Previously we had to re-calculate the number of inputs and outputs on all input and output paths. With this change we only have to re-calculate the number of outputs on the input path that got changed and the number of inputs on the output paths. E.g. imagine the following example: A --> B ----. v M --> N --> Z <-- S <-- R | v X Widget Z has multiple input paths, if any change was made that cause Z to be marked as dirty the power state of Z has to be re-computed. This requires to know the number of inputs and outputs of Z, which requires to know the number of inputs and outputs of all widgets on all paths from or to Z. Previously this meant re-computing all inputs and outputs of all the path going into or out of Z. With this patch in place only paths that actually have changed need to be re-computed. If the system is idle (or the part of the system affected by the changed path) the number of path checks drops to either 0 or 1, regardless of how large or complex the DAPM context is. 0 if there is no connected sink and no connected source. 1 if there is either a connected source or sink, but not both. The number of neighbor checks again will scale accordingly and will be a constant number that is the number of inputs or outputs of the widget for which we did the path check. When loading a state file or switching between different profiles typically multiple mixer and mux settings are changed, so we see the benefit of this patch multiplied for these kinds of operations. Testing with the ADAU1761 shows the following changes in DAPM stats for changing a single Mixer switch for a Mixer with 5 inputs while the DAPM context is idle. Power Path Neighbour Before: 2 12 30 After: 2 1 2 For the same switch, but with a active playback stream the stat changed are as follows. Power Path Neighbour Before: 10 20 54 After: 10 7 21 Cumulative numbers for switching the audio profile which changes 7 controls while the system is idle: Power Path Neighbour Before: 16 80 170 After: 16 7 23 Cumulative numbers for switching the audio profile which changes 7 controls while playback is active: Power Path Neighbour Before: 51 123 273 After: 51 29 109 Starting (or stopping) the playback stream: Power Path Neighbour Before: 34 34 117 After: 34 17 69 Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Lars-Peter Clausen 提交于
Supply widgets are somewhat special and not all kinds of paths to or from supply widgets make sense. This patch adds a few sanity checks that errors out during the path instantiation for those invalid paths. This will prevent drivers to depend on weird behavior resulting from such paths as well as will allow the DAPM algorithms to assume that they never see such paths. This patch adds checks for the following three invalid types of paths: * A path with a non-supply widget as a source connected to a supply widget as a sink. Such a path has no effect on either of the two connected widgets. * Paths with a connected() callback that have a non-supply widget as the source. The DAPM algorithm only uses the conneceted() callback for supply widget power checks. And since it prevents caching of the DAPM state there is no intention to make it more generic as it has negative performance implications. * Paths which connect a supply to a mixer or mux via a control. Controls are only meant to affect the routing of audio data. Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Lars-Peter Clausen 提交于
The state of endpoint widgets is affected by that card's power state. Endpoint widgets that do no have the ignore_suspend flag set will be considered inactive during suspend. So they have to be re-checked and marked dirty after the card's power state changes. Currently the input and output widgets are marked dirty instead, this works most of the time since typically a path from one endpoint to another will go via a input or output widget. But marking the endpoints dirty is technically more correct and will also work for odd corner cases. Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Lars-Peter Clausen 提交于
Supply widgets do not count towards the input and output widgets of their neighbors and for supply widgets themselves we do not care for the number of input or output paths. This means that a path that connects to a supply widget effectively behaves the same as a path that as the weak property set. This patch adds a new path flag that gets set to true when the path is connected to at least one supply widget. If a path with the flag set is encountered in is_connected_{input,output}_ep() is is skipped in the same way that weak paths are skipped. This slightly brings down the number of path checks. Since both the weak and the supply flag are implemented as bitfields which are stored in the same word there is no runtime overhead due to checking both rather than just one and also the size of the path struct is not increased by this patch. Another advantage is that we do not have to handle supply widgets in is_connected_{input,output}_ep() anymore since it will never be called for supply widgets. The only exception is from dapm_widget_power_read_file() where a check is added to special case supply widgets. Testing with the ADAU1761, which has a handful of supply widgets, shows the following changes in the DAPM stats for a playback stream start. Power Path Neighbour Before: 34 78 117 After: 34 48 117 Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Lars-Peter Clausen 提交于
DAPM widgets can be classified into four categories: * supply: Supply widgets do not affect the power state of their non-supply widget neighbors and unlike other widgets a supply widget is not powered up when it is on an active path, but when at least on of its neighbors is powered up. * source: A source is a widget that receives data from outside the DAPM graph or generates data. This can for example be a microphone, the playback DMA or a signal generator. A source widget will be considered powered up if there is an active path to a sink widget. * sink: A sink is a widget that transmits data to somewhere outside of the DAPM graph. This can e.g. be a speaker or the capture DMA. A sink widget will be considered powered up if there is an active path from a source widget. * normal: Normal widgets are widgets not covered by the categories above. A normal widget will be considered powered up if it is on an active path between a source widget and a sink widget. The way the number of input and output paths for a widget is calculated depends on its category. There are a bunch of factors which decide which category a widget is. Currently there is no formal classification of these categories and we calculate the category of the widget based on these factors whenever we want to know it. This is at least once for every widget during each power update sequence. The factors which determine the category of the widgets are mostly static though and if at all change rather seldom. This patch introduces three new per widget flags, one for each of non-normal widgets categories. Instead of re-computing the category each time we want to know them the flags will be checked. For the majority of widgets the category is solely determined by the widget id, which means it never changes and only has to be set once when the widget is created. The only widgets with dynamic categories are: snd_soc_dapm_dai_out: Is considered a sink iff the capture stream is active, otherwise normal. snd_soc_dapm_dai_in: Is considered a source iff the playback stream is active, otherwise normal. snd_soc_dapm_input: Is considered a sink iff it has no outgoing paths, otherwise normal. snd_soc_dapm_output: Is considered a source iff it has no incoming paths, otherwise normal. snd_soc_dapm_line: Is considered a sink iff it has no outgoing paths and is considered a source iff it has no incoming paths, otherwise normal. For snd_soc_dapm_dai_out/snd_soc_dapm_dai_in widgets the category will be updated when a stream is started or stopped. For the other dynamic widgets the category will be updated when a path connecting to it is added or removed. Introducing those new widget categories allows to make is_connected_{output,input}_ep, which are among the hottest paths of the DAPM algorithm, more generic and significantly shorter. The before and after sizes for is_connected_{output,input}_ep are: On ARM (defconfig + CONFIG_SND_SOC): function old new delta is_connected_output_ep 480 340 -140 is_connected_input_ep 456 352 -104 On amd64 (defconfig + CONFIG_SND_SOC): function old new delta is_connected_output_ep 579 427 -152 is_connected_input_ep 563 427 -136 Which is about a 25%-30% decrease, other architectures are expected to have similar numbers. At the same time the size of the snd_soc_dapm_widget struct does not change since the new flags are stored in the same word as the existing flags. Note: that since the per widget 'ext' flag was only used to decide whether a snd_soc_dapm_input or snd_soc_dapm_output widget was a source or a sink it is now unused and can be removed. Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Lars-Peter Clausen 提交于
Controls on a path only have an effect if the sink on the path is either a mixer or mux widget. Currently we sort of silently ignore controls on other paths, but since they don't do anything having them on other paths does not make much sense and it is probably safe to assume that if we see such a path it is a mistake in the driver that registered the path. This patch modifies snd_soc_dapm_add_path() to report an error if a path with and control is encountered where we didn't expect a control. This also allows to simplify the code quite a bit. The patch also moves the connecting of the path lists out of dapm_connect_mux() and dapm_connect_mixer() into snd_soc_dapm_add_path(). Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Lars-Peter Clausen 提交于
Paths that are directly connected to a MUX widget are not affected by changes to the MUX's control. Rather than checking if a path is directly connected each time the MUX is updated do it only once when MUX is created. We can also remove the check for e->texts[mux] != NULL, since if that condition was true the code would have had already crashed much earlier (And generally speaking if a enum's 'texts' entry is NULL it's a bug in the driver). Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Lars-Peter Clausen 提交于
Rework soc_dapm_{mixer,mux}_update_power() to only mark a path dirty if the connect state if the path has actually changed. This avoids unnecessary power state checks for the widgets involved. Also factor out the common code that is involved in this into a helper function. Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@kernel.org>
-
- 22 10月, 2014 3 次提交
-
-
由 Lars-Peter Clausen 提交于
The 'walked' flag was used to avoid walking paths that have already been walked. But since we started caching the number of inputs and outputs of a path we never actually get into a situation where we try to walk a path that has the 'walked' flag set. There are two cases in which we can end up walking a path multiple times within a single run of is_connected_output_ep() or is_connected_input_ep(). 1) If a path splits up and rejoins later: .--> C ---v A -> B E --> F '--> D ---^ When walking from A to F we'll end up at E twice, once via C and once via D. But since we do a depth first search we'll fully discover the path and initialize the number of outputs/inputs of the widget the first time we get there. The second time we get there we'll use the cached value and not bother to check any of the paths again. So we'll never see a path where 'walked' is set in this case. 2) If there is a circle: A --> B <-- C <-.--> F '--> D ---' When walking from A to F we'll end up twice at B. But since there is a circle the 'walking' flag will still be set on B once we get there the second time. This means we won't look at any of it's outgoing paths. So in this case we won't ever see a path where 'walked' is set either. So it is safe to remove the flag. This on one hand means we remove some always true checks from one of the hottest paths of the DAPM algorithm and on the other hand means we do not have to do the tedious clearing of the flag after checking the number inputs or outputs of a widget. Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Lars-Peter Clausen 提交于
dapm_adc_check_power() checks if the widget is active, if yes it only checks whether there are any connected input paths. Otherwise it calls dapm_generic_check_power() which will check for both connected input and output paths. But the function that checks for connected output paths will return true if the widget is a active sink. Which means the generic power check function will work just fine and there is no need for a special power check function. The same applies for dapm_dac_check_power(), but with input and output paths reversed. This patch removes both dapm_adc_check_power() and dapm_dac_check_power() and replace their usage with dapm_generic_check_power(). Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Lars-Peter Clausen 提交于
A path has always a valid source and a valid sink otherwise we wouldn't add it in the first place. Hence all tests that check if sink/source is non NULL always evaluate to true and can be removed. Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Signed-off-by: NMark Brown <broonie@kernel.org>
-