- 08 Aug, 2023 22 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:
-
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 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 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:
-
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:
-
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:
-
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:
-
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:
-
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:
-
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:
-
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:
-
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:
-
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:
-
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:
-
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:
-
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:
-
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:
-
Charles Keepax authored
Add the missing new lines. Reviewed-by:
-
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:
-
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:
-
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 18 commits
-
-
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:
Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/20230807210959.506849-21-pierre-louis.bossart@linux.intel.comSigned-off-by:
-
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 authored
The solution used before LunarLake relies on a 'Multi-gateway' firmware configuration. This is no longer needed with the DMA hardware handling multiple links directly. To avoid adding a platform-specific quirk in the generic IPC4 code, this patch resets the device count when fetching the stream context. Suggested-by:
-
Pierre-Louis Bossart authored
We need to retrieve the current value to deal with the HDAudio WAKEEN/WAKESTS setup. Signed-off-by:
Rander Wang <rander.wang@intel.com> Link: https://lore.kernel.org/r/20230807210959.506849-18-pierre-louis.bossart@linux.intel.comSigned-off-by:
-
Pierre-Louis Bossart authored
The existing code cannot work for LunarLake, let's add a layer of abstraction. No functional change in this patch. Signed-off-by:
-
Pierre-Louis Bossart authored
These callbacks are just wrappers to keep the code relatively clean. Signed-off-by:
-
Pierre-Louis Bossart authored
During the hw_params and hw_free stages, we need to map the stream tag and channels in the PCMSyCM registers. The trigger callback is just a wrapper. Signed-off-by:
-
Pierre-Louis Bossart authored
Same abstraction as SSP/DMIC, with only the get_hlink helper changing. Signed-off-by:
-
Pierre-Louis Bossart authored
When we have multiple CPU DAIs in a dailink, typically for SoundWire aggregated solutions with amplifiers on multiple links, we only want to allocate one HDaudio stream_tag. The simplest solution is to allocate the hext_stream/stream_tag for the DAI with index 0 in the dailink, and reuse the same stream for all other CPU DAIs. This assumption relies on serialization of DAIs by the ASoC core, where all CPU DAIs are handled in a loop. The stream release follows the same idea of releasing the tag for the first DAI only. Ideally we would want the loop to be handled in reverse-order to summetry, but there is no risk of reusing a stream_tag which is no longer valid. Signed-off-by:
-
Pierre-Louis Bossart authored
We can reuse the same helpers as for SSP, with just the link type being different. Signed-off-by:
Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by:
Jaska Uimonen <jaska.uimonen@linux.intel.com> Link: https://lore.kernel.org/r/20230807210959.506849-12-pierre-louis.bossart@linux.intel.comSigned-off-by:
-
Pierre-Louis Bossart authored
Add new ops for SSP. Signed-off-by:
-
Pierre-Louis Bossart authored
The DMA widget ops are almost similar to the HDaudio ones, with the exception of codec_dai_set_hext_stream() which is not relevant and the format calculation which isn't dependent on the codec dai. The DMA ops can be selected only starting with ACE_2_0. Signed-off-by:
-
Pierre-Louis Bossart authored
In the LunarLake hardware, the default IP ownership changed to the host driver, instead of the firmware in previous generation. In the absence of any capability negotiation, we need to assume a fixed partitioning between host driver and firmware. The OFLEN bit needs to be set as early as possible for resources handled by the firmware, since we can't control when the firmware might try to access the resources. For now DMIC and SSP are handled by the DSP firmware. SoundWire is a separate case, the OFLEN bit can be set when starting-up and resuming the aux device for each link. Signed-off-by:
-
Pierre-Louis Bossart authored
It was just a matter of time before we found a case where we needed separate ops for MTL and LNL. For LNL we need to set the DMIC/SSP OFLEN bit in the probe and resume steps, and this can only be done cleanly with separate ops. The function prototypes in mtl.h were added in the same order as their implementation in mtl.c. Signed-off-by:
-
Ranjani Sridharan authored
Add initial support for Lunarlake. For now only HDAudio interfaces are supported, DMIC/SSP/SoundWire require additional work so that the DAIs reuse the HDaudio DMA stream allocation. Signed-off-by:
-
Pierre-Louis Bossart authored
All interfaces are accessible without the DSP and rely on the HDaudio DMA only. Signed-off-by:
-
Pierre-Louis Bossart authored
The initial code had a logic flaw where the gateway config length kept increasing after each playback/capture trigger, with the DMA config TLV being added at every call of sof_ipc4_prepare_copier_module() This didn't cause any issues with regular playback/capture, but this was flagged as an error by firmware in the case of multiple amplifiers on different links. Fixes: a0659f81 ("ASoC: SOF: ipc4-topology: add DMA config TLV to IPC data") Signed-off-by:
-
Ranjani Sridharan authored
When a pipeline contains multiple DAI widgets, the pipe_widget is not set up except for the first DAI. This result in the pipe_widget having a default instance 0, which can conflict with another real the pipeline instance 0 and leads to spurious transitions. This patch makes sure the instance_id is properly initialized to a -EINVAL value. Signed-off-by:
-
