summaryrefslogtreecommitdiffstats
path: root/include/sound/soc-dapm.h
Commit message (Collapse)AuthorAgeFilesLines
* ASoC: soc-component: move snd_soc_component_seq_notifier()Kuninori Morimoto2019-08-051-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | Current soc-dapm / soc-core are using a long way round to call .seq_notifier. if (driver->seq_notifier) dapm->seq_notifier = ...; ... if (dapm->seq_notifier) ret = dapm->seq_notifier(...); We can directly call it via driver->seq_notifier. One note here is that both Card and Component have dapm, but, Card's dapm doesn't have dapm->component. We need to check it. This patch moves snd_soc_component_seq_notifier() to soc-component.c, and updates parameters. dapm->seq_notifier is no longer needed Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87wog54d0v.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
* ASoC: Define a set of DAPM pre/post-up eventsOleksandr Suvorov2019-07-221-0/+2
| | | | | | | | | | | | | Prepare to use SND_SOC_DAPM_PRE_POST_PMU definition to reduce coming code size and make it more readable. Cc: stable@vger.kernel.org Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com> Reviewed-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Reviewed-by: Igor Opaniuk <igor.opaniuk@toradex.com> Reviewed-by: Fabio Estevam <festevam@gmail.com> Link: https://lore.kernel.org/r/20190719100524.23300-2-oleksandr.suvorov@toradex.com Signed-off-by: Mark Brown <broonie@kernel.org>
* ASoC: dapm: harden use of lookup tablesPierre-Louis Bossart2019-02-061-0/+3
| | | | | | | | | | | | | To detect potential errors, let's add: a) build-time warnings when the table size isn't aligned with the enum list b) run-time warnings when the values are not initialized. This requires an increase by one of all values to avoid the default 0. Suggested-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
* ASoC: dapm: Only power up active channels from a DAICharles Keepax2019-02-021-8/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | Currently all widgets attached to a DAI link will be powered up when the DAI is active, however this may include routes that are not actually in use if there are unused channels available on the DAI. The macros for creating AIF widgets already include an entry for slot, it is proposed to change that to channel. The effective difference here being respresenting the logical channel index rather than the physical slot index. The CODECs currently using the slot entry on the DAPM_AIF macros are using it in a manner consistent with this, the CODECs not using it just have the field set to zero. A variable is added to snd_soc_dapm_widget to represent this channel index and then for each AIF widget attached to a DAI this is compared against the number of channels on the stream. Enabling the links for those which will be in use. This has the nice property that the CODECs which haven't used the slot/channel entry in the macro will function exactly as before due to all the AIF widgets having a channel of zero and a stream by definition having at least one channel. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org>
* ASoC: topology: add SND_SOC_DOBJ_GRAPH type for dapm routesRanjani Sridharan2019-01-291-0/+2
| | | | | | | | | | | | | | | Add a new dobj type SND_SOC_DOBJ_GRAPH for dapm routes and add snd_soc_dobj member to struct snd_soc_dapm_route. This enables device drivers to save driver specific data pertaining to dapm routes and also be able to clean up the data when the driver module is unloaded. Also, reorder the snd_soc_dobj_type types to align with matching topology header types. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
* ASoC: dapm: Move CODEC to CODEC params from the widget to the runtimeCharles Keepax2018-09-051-3/+0
| | | | | | | | | | Larger CODECs may contain many several hundred widgets and which set of parameters is selected only needs to be recorded on a per DAI basis. As such move the selected CODEC to CODEC link params to be stored in the runtime rather than the DAPM widget, to save some memory. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org>
* ASoC: dapm: Move connection of CODEC to CODEC DAIsCharles Keepax2018-09-051-6/+0
| | | | | | | | | | | Currently, snd_soc_dapm_connect_dai_link_widgets connects up the routes representing normal DAIs, however CODEC to CODEC links are hooked up through separate infrastructure in soc_link_dai_widgets. Improve the consistency of the code by using snd_soc_dapm_connect_dai_link for both types of DAIs. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org>
* ASoC: dapm: Fix NULL pointer deference on CODEC to CODEC DAIsCharles Keepax2018-08-151-0/+1
| | | | | | | | | | | | | | | | | | Commit a655de808cbde ("ASoC: core: Allow topology to override machine driver FE DAI link config.") caused soc_dai_hw_params to be come dependent on the substream private_data being set with a pointer to the snd_soc_pcm_runtime. Currently, CODEC to CODEC links don't set this, which causes a NULL pointer dereference: [<4069de54>] (soc_dai_hw_params) from [<40694b68>] (snd_soc_dai_link_event+0x1a0/0x380) Since the ASoC core in general assumes that the substream private_data will be set to a pointer to the snd_soc_pcm_runtime, update the CODEC to CODEC links to respect this. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org>
* ASoC: soc-dapm: convert to SPDX identifiersKuninori Morimoto2018-07-021-7/+4
| | | | | Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org>
* ASoC: dapm: add support to pinctrl dapmSrinivas Kandagatla2018-03-131-0/+16
| | | | | | | | | | | | | Purpose of having pinctrl dapm is to dynamically put the pins in low power state when they are not actively used by the audio and saving power. Without this each driver has to set the pinctrl states, either during probe or dynamically depending on the callbacks received from ASoC core. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
* ASoC: dapm: Add new widget type for constructing DAPM graphs on DSPs.Liam Girdwood2017-06-301-0/+7
| | | | | | | | Add some DAPM widget types to better support the construction of DAPM graphs within DSPs. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
* ASoC: dapm: Introduce DAPM_DOUBLE_R dual channel dual register control typeChen-Yu Tsai2016-11-021-0/+5
| | | | | | | | | | | | | A DAPM_DOUBLE_R control type can be used for dual channel mixer input selectors / mute controls across 2 registers, possibly toggling both channels together. The control is meant to be shared by 2 widgets, 1 for each channel, such that the mixer control exposed to userspace remains a combined stereo control. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Mark Brown <broonie@kernel.org>
* ASoC: dapm: Introduce DAPM_DOUBLE dual channel control typeChen-Yu Tsai2016-11-021-0/+5
| | | | | | | | | | | | | A DAPM_DOUBLE control type can be used for dual channel mixer input selectors / mute controls in one register, possibly toggling both channels together. The control is meant to be shared by 2 widgets, 1 for each channel, such that the mixer control exposed to userspace remains a combined stereo control. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Mark Brown <broonie@kernel.org>
* ASoC: dapm: Support second register for DAPM control updatesChen-Yu Tsai2016-11-021-0/+4
| | | | | | | | | | | | | | | 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>
*-. Merge remote-tracking branches 'asoc/topic/dpcm', 'asoc/topic/dt', ↵Mark Brown2016-07-241-1/+4
|\ \ | | | | | | | | | 'asoc/topic/dwc' and 'asoc/topic/fsl' into asoc-next
| * | ASoC: dapm: support user-defined stop condition in dai_get_connected_widgetsPiotr Stankiewicz2016-05-301-1/+4
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* / ASoC: dapm: Export snd_soc_dapm_new_controlSubhransu S. Prusty2016-07-051-0/+3
|/ | | | | | | | | 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>
* ASoC: dapm: deprecate MICBIAS widget typeJohn Keeping2016-05-121-1/+2
| | | | | | | | | | | | | | | | Commit 086d7f804e26 ("ASoC: Convert WM8962 MICBIAS to a supply widget", 2011-09-23) says: A supply widget is generally clearer than a MICBIAS widget and a mic bias is just a type of supply so use a supply widget for the MICBIAS. This also avoids confusion with the routing when connected to multiple inputs. but this has never been documented as a policy. Add some comments to make it clear. Signed-off-by: John Keeping <john@metanate.com> Signed-off-by: Mark Brown <broonie@kernel.org>
* Merge remote-tracking branch 'asoc/topic/dapm' into asoc-nextMark Brown2015-12-231-0/+4
|\
| * ASoC: dapm: add a dapm sink widgetVinod Koul2015-11-251-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | ASoC: dapm: Reset dapm wcache after freeing damp widgetsJyri Sarha2015-11-101-0/+1
|/ | | | | | | | | | | | 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>
* ASoC: dapm: Add snd_soc_dapm_kcontrol_widget()Mythri P K2015-10-221-0/+3
| | | | | | | | | | 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>
* ASoC: dapm: Consolidate input and output path handlingLars-Peter Clausen2015-08-131-14/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ASoC: dapm: Add widget path iteratorsLars-Peter Clausen2015-07-291-0/+18
| | | | | | | | 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>
* ASoC: dapm: Add helper function to free a widgetLars-Peter Clausen2015-07-211-0/+1
| | | | | | | | | | | | 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>
*-. Merge remote-tracking branches 'asoc/topic/topology', 'asoc/topic/twl6040', ↵Mark Brown2015-06-051-0/+3
|\ \ | | | | | | | | | 'asoc/topic/wm5100', 'asoc/topic/wm8741' and 'asoc/topic/wm8960' into asoc-next
| * | ASoC: topology: Add topology coreLiam Girdwood2015-06-041-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The topology core parses the FW topology file for known block types and instanciates any common ALSA/ASoC objects that it discovers. The core also passes any block that is does not understand to client component drivers for enumeration. The core exports some APIs to client drivers in order to load and unload firmware topology data as use case require. Currently the core deals with the following object types :- o kcontrols. This includes TLV, enumerated and bytes controls. o DAPM widgets. All types with any associated kcontrol. o DAPM graph. o FE PCM. FE PCM capabilities and configuration can be defined. o BE DAI Link. BE DAI link capabilities and configuration can be defined. o Codec <-> codec style links capabilities and configuration. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
| * | ASoC: topology: Add topology UAPI headerLiam Girdwood2015-06-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ASoC topology UAPI header defines the structures required to define any DSP firmware audio topology and control objects from userspace. The following objects are supported :- o kcontrols including TLV controls. o DAPM widgets and graph elements o Vendor bespoke objects. o Coefficient data o FE PCM capabilities and config. o BE link capabilities and config. o Codec <-> codec link capabilities and config. o Topology object manifest. The file format is simple and divided into blocks for each object type and each block has a header that defines it's size and type. Blocks can be in any order of type and can either all be in a single file or spread across more than one file. Blocks also have a group identifier ID so that they can be loaded and unloaded by ID. Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
* | | Merge remote-tracking branch 'asoc/topic/dapm' into asoc-nextMark Brown2015-06-051-0/+46
|\| |
| * | ASoC: dapm: Add cache to speed up adding of routesCharles Keepax2015-05-121-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
| * | ASoC: dapm: Add demux supportLars-Peter Clausen2015-05-061-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
| * | ASoC: Add helper functions bias level managementLars-Peter Clausen2015-04-271-0/+34
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
* | Merge remote-tracking branch 'asoc/fix/dapm' into asoc-linusMark Brown2015-04-291-1/+1
|\ \ | |/ |/|
| * ASoC: dapm: Enable autodisable on SOC_DAPM_SINGLE_TLV_AUTODISABLECharles Keepax2015-04-221-1/+1
| | | | | | | | | | | | | | | | | | Correct small copy and paste error where autodisable was not being enabled for the SOC_DAPM_SINGLE_TLV_AUTODISABLE control. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
| |
| \
*-. | Merge remote-tracking branches 'asoc/topic/link-param', ↵Mark Brown2015-04-121-0/+3
|\ \| | | | | | | | | | 'asoc/topic/max98090', 'asoc/topic/max98925' and 'asoc/topic/nuc900' into asoc-next
| * | ASoC: dapm: add code to configure dai link parametersNikesh Oswal2015-03-171-0/+3
| |/ | | | | | | | | | | | | | | | | | | | | 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: Nikesh Oswal <nikesh@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
* | Merge remote-tracking branch 'asoc/topic/dapm' into asoc-nextMark Brown2015-04-121-1/+0
|\ \
| * | ASoC: Make snd_soc_dapm_kcontrol_codec() inlineLars-Peter Clausen2015-03-161-1/+0
| |/ | | | | | | | | | | | | | | | | 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: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
* | ASoC: dapm: Remove delayed_work from dapm context structLars-Peter Clausen2015-04-011-1/+0
| | | | | | | | | | | | | | | | | | | | The delayed_work field in the snd_soc_dapm_context struct is now unused and can be removed. Removing it reduces the size of the snd_soc_dapm_context struct by ~50% from 100 bytes to 48 bytes. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
* | ASoC: Remove suspend_bias_level from DAPM context structLars-Peter Clausen2015-04-011-1/+0
|/ | | | | | | | | | The only two users of the suspend_bias_level field were two rather old drivers which weren't exactly doing things by the book. Those drivers have been updated and field is now unused and can be removed. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
* Merge remote-tracking branch 'asoc/topic/w-codec' into asoc-nextMark Brown2015-02-041-1/+0
|\
| * ASoC: Remove codec field from snd_soc_dapm_widgetLars-Peter Clausen2015-01-151-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
* | Merge remote-tracking branch 'asoc/topic/dapm' into asoc-nextMark Brown2015-02-041-1/+0
|\ \
| * | ASoC: dapm: Simplify fully route card handlingLars-Peter Clausen2014-12-221-1/+0
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
* / ASoC: Add sysfs entries via static attribute groupsTakashi Iwai2015-02-021-1/+1
|/ | | | | | | | | 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: Takashi Iwai <tiwai@suse.de> Signed-off-by: Mark Brown <broonie@kernel.org>
* ASoC: dapm: Use more aggressive cachingLars-Peter Clausen2014-10-281-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
* ASoC: dapm: Mark endpoints instead of IO widgets dirty during suspend/resumeLars-Peter Clausen2014-10-281-1/+1
| | | | | | | | | | | | | | 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: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
* ASoC: dapm: Add a flag to mark paths connected to supply widgetsLars-Peter Clausen2014-10-281-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
* ASoC: dapm: Introduce toplevel widget categoriesLars-Peter Clausen2014-10-281-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
* ASoC: dapm: Remove path 'walked' flagLars-Peter Clausen2014-10-221-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-17 11:30:02 +0000