- 13 Aug, 2023 4 commits
-
-
Ruan Jinjie authored
The driver depends on CONFIG_OF, it is not necessary to use of_match_ptr() here. Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com Link: https://lore.kernel.org/r/20230811071426.2343133-5-ruanjinjie@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org
-
Ruan Jinjie authored
The driver depends on CONFIG_OF, it is not necessary to use of_match_ptr() here. Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com Link: https://lore.kernel.org/r/20230811071426.2343133-4-ruanjinjie@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org
-
Ruan Jinjie authored
The driver depends on CONFIG_OF, it is not necessary to use of_match_ptr() here. Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com Link: https://lore.kernel.org/r/20230811071426.2343133-3-ruanjinjie@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org
-
Ruan Jinjie authored
The driver depends on CONFIG_OF, it is not necessary to use of_match_ptr() here. Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com Link: https://lore.kernel.org/r/20230811071426.2343133-2-ruanjinjie@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org
-
- 10 Aug, 2023 3 commits
-
-
Yang Li authored
./sound/soc/sof/intel/lnl.c: hda.h is included more than once. Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20230810005555.4610-1-yang.lee@linux.alibaba.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Jack Yu authored
Add software reset before setting preset registers to make sure all the registers are the default value before preset. Signed-off-by: Jack Yu <jack.yu@realtek.com> Link: https://lore.kernel.org/r/4f405c7deb9642e1a8599c5f103b5759@realtek.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Guido Günther authored
This allows to us to document the channel and sampling rate requirements. Signed-off-by: Guido Günther <agx@sigxcpu.org> Reviewed-by: David Heidelberg <david@ixit.cz> Link: https://lore.kernel.org/r/b6e85fdfaa87d7684a120ccedc1e07d8fe87957f.1691606520.git.agx@sigxcpu.orgSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 09 Aug, 2023 6 commits
-
-
Nathan Chancellor authored
Clang warns (or errors with CONFIG_WERROR): sound/soc/sof/intel/hda.c:423:6: error: variable 'chip' is uninitialized when used here [-Werror,-Wuninitialized] 423 | if (chip && chip->check_sdw_wakeen_irq) | ^~~~ sound/soc/sof/intel/hda.c:418:39: note: initialize the variable 'chip' to silence this warning 418 | const struct sof_intel_dsp_desc *chip; | ^ | = NULL 1 error generated. Add the missing initialization, following the pattern of the other irq functions. Fixes: 9362ab78 ("ASoC: SOF: Intel: add abstraction for SoundWire wake-ups") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20230809-intel-hda-missing-chip-init-v1-1-61557ca6fa8a@kernel.orgSigned-off-by: Mark Brown <broonie@kernel.org>
-
Mark Brown authored
For the benefit of CI
-
Mark Brown authored
Merge series from Richard Fitzgerald <rf@opensource.cirrus.com>: Miscellaneous bugfixes for the cs35l56 codec driver.
-
Peter Ujfalusi authored
The sof_ipc4_update_resource_usage() call updates the CPC value in basecfg and it must be done prior to making a copy of the copier configuration for the init message. Other module types do the resource update as last step or in case of a process module at the correct time, before the memcpy. Fixes: d8a2c987 ("ASoC: SOF: ipc4-loader/topology: Query the CPC value from manifest") Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Adrian Bonislawski <adrian.bonislawski@intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Chao Song <chao.song@linux.intel.com> Link: https://lore.kernel.org/r/20230809125656.27585-1-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Marek Szyprowski authored
'Headphone Switch' control is already registered from sound/soc/codecs/wm_hubs.c:479, so duplicating it in midas_wm1811 causes following probe failure: midas-audio sound: control 2:0:0:Headphone Switch:0 is already present midas-audio sound: ASoC: Failed to add Headphone Switch: -16 midas-audio sound: Failed to register card: -16 midas-audio: probe of sound failed with error -16 Fix this by dropping duplicated control. Fixes: d27224a4 ("ASoC: samsung: midas_wm1811: Map missing jack kcontrols") Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20230809100446.2105825-1-m.szyprowski@samsung.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Kuninori Morimoto authored
We need to call of_node_put() when break from for_each_child_of_node(). This patch add missing of_node_put(). Reported-by: kernel test robot <lkp@intel.com> Reported-by: Julia Lawall <julia.lawall@inria.fr> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87bkfh9g68.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 08 Aug, 2023 23 commits
-
-
Simon Trimmer authored
When cs35l56_system_resume() needs to reload firmware it should call wm_adsp_power_down() to put cs_dsp into a powered-down state before cs35l56_secure_patch() or cs35l56_patch() calls wm_adsp_power_up(). Signed-off-by: Simon Trimmer <simont@opensource.cirrus.com> Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230808164702.21272-6-rf@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Simon Trimmer authored
To support self-booting DSPs that operate outside of a conventional DAPM event life cycle expose a companion function to wm_adsp_power_up() so that the correct state of the DSP firmware and controls can be recorded. Signed-off-by: Simon Trimmer <simont@opensource.cirrus.com> Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230808164702.21272-5-rf@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Richard Fitzgerald authored
The CS35L56 could be hard-reset during a system suspend-resume cycle, either by the codec driver, in cs35l56_system_resume_early(), or by ACPI. After a hard reset the driver must wait for the control port to be ready (datasheet tIRS time) before attempting to access the CS35L56. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230808164702.21272-4-rf@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Richard Fitzgerald authored
The ACPI setting for a GPIO default state has higher priority than the flag passed to devm_gpiod_get_optional() so ACPI can override the GPIOD_OUT_LOW. Explicitly set the GPIO low when hard resetting. Although GPIOD_OUT_LOW can't be relied on this doesn't seem like a reason to stop passing it to devm_gpiod_get_optional(). So we still pass it to state our intent, but can deal with it having no effect. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230808164702.21272-3-rf@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Richard Fitzgerald authored
Re-implement setting of ASP TDM slots so that only the common loop to build the register word is factored out. The original cs35l56_set_asp_slot_positions() had an apparent uninitialized variable if the passed register address was neither of the ASP slot registers. In fact this would never happen because the calling code passed valid registers. While it's trivial to initialize the variable or add a default case, actually the only common code was the loop at the end of the function, which simply manipulates some mask values and is identical for either register. Factoring out the regmap_write() didn't really gain anything. So instead re-implement the code to replace the original function with cs35l56_make_tdm_config_word() that only does the loop, and change the calling code to call regmap_write() directly. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230808164702.21272-2-rf@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Yu Liao authored
gcc with W=1 reports sound/soc/pxa/pxa-ssp.c:594:15: warning: variable 'acds' set but not used [-Wunused-but-set-variable] ^ This variable is not used so remove it. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202308040619.BEismjFv-lkp@intel.com/Signed-off-by: Yu Liao <liaoyu15@huawei.com> Link: https://lore.kernel.org/r/20230808132519.637452-1-liaoyu15@huawei.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Arnd Bergmann authored
aw88261_reg_update() returns an unintialized error code in the success path: sound/soc/codecs/aw88261.c:651:7: error: variable 'ret' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] if (aw_dev->prof_cur != aw_dev->prof_index) { ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ sound/soc/codecs/aw88261.c:660:9: note: uninitialized use occurs here return ret; ^~~ sound/soc/codecs/aw88261.c:651:3: note: remove the 'if' if its condition is always true if (aw_dev->prof_cur != aw_dev->prof_index) { ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Return zero instead here. Fixes: 028a2ae2 ("ASoC: codecs: Add aw88261 amplifier driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20230808125703.1611325-1-arnd@kernel.orgSigned-off-by: Mark Brown <broonie@kernel.org>
-
Charles Keepax authored
Now the first device on a link is not treated specially there is no need to have a separate loop to handle the current link over the future links, as the logic is identical. Combine this all into a single processing loop. Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230808132013.889419-12-ckeepax@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Charles Keepax authored
If the current code encounters a new type of device on a SoundWire link, it will abort processing that link and move onto the next link. However, there is no reason to disallow this setup, it would appear this was being disallowed to work around issues introduced by only the first endpoint on each link being checked, which is now fixed. The device type shouldn't determine which DAI link it is connected to, the group ID and aggregation status should. Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230808132013.889419-11-ckeepax@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Charles Keepax authored
The current code checks the first device on a link and assumes that all the other devices on the link will have the same endpoint aggregation status and endpoint group ID. Say for example a system looked like: SDW0 - Amp 1 (Aggregated, Group 1), Mic 1 (Aggregated, Group 2) SDW1 - Amp 2 (Aggregated, Group 1), Mic 2 (Aggregated, Group 2) The current code would create the DAI link for the aggregated amps, although it is worth noting that the only reason Mic 2 is not added is the additional check that aborts processing the link when the device changes. Then when processing the DAI link for the microphones, Mic 2 would not be added, as the check will only be done on the first device, which would be Amp 2 and thus the wrong group, causing the whole link to be skipped. Move the endpoint check to be for each device rather than the first device on each link. Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230808132013.889419-10-ckeepax@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Charles Keepax authored
The current loops at the top of create_sdw_dailink process the devices on each link starting from device index adr_index. But adr_index is only meaningful on the first on these SoundWire links, as it is the index of the current device on that link. This means devices will be skipped on later links. Say for example the system looks like this: SDW0 - Codec (Not Aggregated), Amp 1 (Aggregated, Group 1) SDW1 - Amp 2 (Aggregated, Group 1), Amp 3 (Aggregated, Group 1) The code should create 2 DAI links, one for the CODEC and one for the aggregated amps. It will create the DAI link for the codec no problem. When it creates the DAI link for Group 1 however, create_sdw_dailink will be called with an adr_index of 1, since that is the index of Amp 1 on SDW0. However, as the loop in create_sdw_dailink moves onto SDW1 it will again start from adr_index, skipping Amp 2. Resulting in the amp DAI link only have amps 1 and 3 in it. It is reasonable to start at adr_index on the first link, since earlier devices have by definition already been processed. However, update the code when processing later links to handle all devices. Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230808132013.889419-9-ckeepax@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Charles Keepax authored
There are two problems with the current range check on the codec_conf array. Firstly, adr_link_next->num_adr refers to the number of devices on the current SoundWire link, but adr_index refers to the first SoundWire link involved in the DAI link. This means that subtracting these two numbers is only meaningful on the first SoundWire link in the DAI and broken on later links. Secondly, the intention of the range check is to add the number of remaining devices on the currently link to the current index and ensure enough space remains. However, this assumes that all remaining devices on the SoundWire link will be added to the current DAI link. Ideally this would not be the case, and devices could be grouped as the user desired. Moving the range check into the inner loop both simplifies the code (no need to add and subtract offsets) and allows future refactoring such that devices on a single SoundWire link don't have to all be grouped onto a single DAI link. The check will be processed slightly more often since it is processed for each device rather each link but this is probe time and the numbers involved are very small here (4 links, likely no more than 2-4 devices per link). Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230808132013.889419-8-ckeepax@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Charles Keepax authored
In create_sdw_dailink, rather than bulk updating the index into the DAI link components array, at the end of processing a link, do so each time the code adds a new component. This simplifies things slightly, as an intermediate variable is no longer needed to track the current place in the DAI link components array. Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230808132013.889419-7-ckeepax@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Charles Keepax authored
The loops which fill the codec DAI link component structures are split across create_sdw_dailink and create_codec_dai_name. This causes the code to be rather confusing, needing to return out the function to allow the upper loop to iterate. Remove the create_codec_dai_name helper and pull its code up into create_sdw_dailink, this makes it more obvious what is happening in the code. This patch makes no functional change just hoists the code up a level. Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230808132013.889419-6-ckeepax@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Charles Keepax authored
Add a helper function to create a single codec DAI link component structure. This sets things up for more refactoring of the creating of the DAI links. Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230808132013.889419-5-ckeepax@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Charles Keepax authored
Move the check for a valid group id into get_dailink_info as well. This does cause a slight change in behaviour in that the system will return an error rather than just ignoring the link with an invalid group id. There are presently no systems with invalid group ids in mainline and failing seems more appropriate since it will better highlight the code needs fixing. Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230808132013.889419-4-ckeepax@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Charles Keepax authored
As get_dailink_info spins through all the links anyway simply check the link masks there. This saves an extra check and means the code will fail earlier if the mask is invalid. Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230808132013.889419-3-ckeepax@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Charles Keepax authored
get_dailink_info already checked if the adr_link pointer was NULL so there is no need to recheck later in sof_card_dai_links_create. Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230808132013.889419-2-ckeepax@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Charles Keepax authored
Add the missing new lines. Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230808132013.889419-1-ckeepax@opensource.cirrus.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Li Zetao authored
The module_rpmsg_driver() will set "THIS_MODULE" to driver.owner when register a rpmsg_driver driver, so it is redundant initialization to set driver.owner in the statement. Remove it for clean code. Signed-off-by: Li Zetao <lizetao1@huawei.com> Link: https://lore.kernel.org/r/20230808021728.2978035-1-lizetao1@huawei.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Alper Nebi Yasak authored
The RT5682, RT1015 and RT1015p codecs used in this driver do not seem capable of distinguishing Line Out connections from Headphone, but the driver configures its jack object as if it can. Remove the wrong value from the jack creation call to avoid any confusion. Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com> Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com> Tested-by: Akihiko Odaki <akihiko.odaki@daynix.com> Link: https://lore.kernel.org/r/20230805162216.441410-1-alpernebiyasak@gmail.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Ranjani Sridharan authored
With IPC3, we reset hw_params during the stop trigger, so we should also clean up the link DMA during the stop trigger. Fixes: 1bf83fa6 ("ASoC: SOF: Intel: hda-dai: Do not perform DMA cleanup during stop") Closes: https://github.com/thesofproject/linux/issues/4455 Closes: https://github.com/thesofproject/linux/issues/4482 Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217673Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://lore.kernel.org/r/20230808110627.32375-1-peter.ujfalusi@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Mark Brown authored
Merge series from Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>: This patchset first fixes a number of errors made in the hda-mlink support, then adds Lunar Lake definitions. The main contribution is the hda-dai changes where the HDaudio DMA is now used for SSP, DMIC and SoundWire. In previous hardware the GPDMA (aka DesignWare) was used and controlled by the audio firmware. The volume of code is minimized with the abstraction added in previous kernel cycles. Due to cross-dependencies between ASoC and SoundWire trees, the full support for jack detection will be deferred to the next kernel cycle. There's not much point to ask for a sync of the two trees to support one patch for each tree - we are at -rc5 already.
-
- 07 Aug, 2023 4 commits
-
-
jairaj-arava authored
The CS42142 soundwire codec button mapping is corrected to handle the button detection correctly. Fixes: 43cdea08 ("ASoC: Intel: sof_sdw: Add helper function for cs42l42 codec") Signed-off-by: jairaj-arava <jairaj.arava@intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230807215000.515846-2-pierre-louis.bossart@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Pierre-Louis Bossart authored
Experimental results show that the headset is only detected with the JD2 quirk. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20230807215000.515846-3-pierre-louis.bossart@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Pierre-Louis Bossart authored
When using more than one sublink for amplifier aggregation, we need to add the sublink info to debug the programming sequences. No functional change, only additional precisions in the log. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20230807210959.506849-21-pierre-louis.bossart@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Pierre-Louis Bossart authored
A pipeline is identified by two indices: 'instance_id' and 'pipeline_id' This is clearly seen in kernel logs when creating a pipeline "Create widget pipeline.20 instance 0 - pipe 20 - core 0" but other logs are less clear "ipc4 set pipeline 1 state 4" Change definitions and logs to make sure the logs clearly identify which of the two indices are used in state transitions. No functional change. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20230807210959.506849-20-pierre-louis.bossart@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>
-