- 08 Aug, 2023 17 commits
-
-
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:
-
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 23 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:
-
Pierre-Louis Bossart authored
Likely a combination of copy-paste and test coverage problem. Oops. Fixes: 87a6ddc0 ("ASoC: SOF: Intel: hda-mlink: program SoundWire LSDIID registers") Signed-off-by:
-
Pierre-Louis Bossart authored
The HCHAN parameter should be the highest channel number, not the channel count. While we're at it, handle LCHAN with the dual __ffs helper. Fixes: ccc2f0c1 ("ASoC: SOF: Intel: hda-mlink: add helper to program SoundWire PCMSyCM registers") Signed-off-by:
-
Yang Yingliang authored
Use memdup_user_nul() helper instead of open-coding to simplify the code. Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20230725120247.509422-1-yangyingliang@huawei.comSigned-off-by:
-
Hans de Goede authored
If SNDRV_PCM_IOCTL_PREPARE is called when the mixer settings linking frontend and backend have not been setup yet this results in e.g. the following errors getting logged: [ 43.244549] Baytrail Audio Port: ASoC: no backend DAIs enabled for Baytrail Audio Port [ 43.244744] Baytrail Audio Port: ASoC: error at dpcm_fe_dai_prepare on Baytrail Audio Port: -22 pipewire triggers this leading to 96 lines getting logged after the user has logged into a GNOME session. Change the actual "no backend DAIs enabled for ... Port" error to dev_err_once() to avoid it getting repeated 48 times. While at it also improve the error by hinting the user how to fix this. To not make developing new UCM profiles harder, also log the error at dev_dbg() level all the time (vs once). So that e.g. dyndbg can be used to (re)enable the messages. Also changes _soc_pcm_ret() to not log for -EINVAL errors, to fix the other error getting logged 48 times. Userspace passing wrong parameters should not lead to dmesg messages. Link: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3407Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
-
Mark Brown authored
Merge series from Alper Nebi Yasak <alpernebiyasak@gmail.com>: This patchset adds missing jack kcontrols for each independently detectable audio peripheral and maps jack pins to those kcontrols accordingly, with the primary intent to enable/improve jack detection handling in PulseAudio and PipeWire through JackControl UCM values. Usually it's just splitting a joint anything-is-connected "Headset Jack" kcontrol (from [1]) into those like "Headphone Jack" and "Headset Mic" (similar to a previous series for Intel Chromebooks [2]). This split is important to avoid automatically switching to a nonexistent external microphone when a headphone-only device is connected. When the underlying hardware seems to support it, this also adds a "Line Out" kcontrol. This is important in case the hardware can actually support a line-level connection via a different configuration (bypassing output amplifiers?), or simply for userspace to display "Line Out" instead of "Headphones" to the user for connected line-out devices. Beyond the mappings, I had to add PIN_SWITCH card kcontrols and DAPM widgets to avoid "unknown pin" errors on my devices, so tried to do them for all. For Intel devices I saw a pattern of routing things to "Platform Clock" and added to that as well. Looking at patch 5/7 of a Mediatek-related series [3], I can only guess that routes could be further improved, but don't know exactly how for each device. And one more concern is I don't know if the names conflict with any controls from codecs, although I tried to keep to names of existing widgets. As far as I can tell, the root cause for most of why these are missing originates to things being developed for ChromeOS, whose userspace reads the jack input device and doesn't care for these kcontrols. There's non-ChromeOS cases as well, maybe things got copy-pasted around and people didn't need or couldn't figure out how to get more specific than a single jack kcontrol. The secondary intent in this patchset is to fix this *everywhere*, so future copy-pastes result in the right behaviour. For more context also see: [1] ASoC: soc-card: Create jack kcontrol without pins https://lore.kernel.org/alsa-devel/20220408041114.6024-1-akihiko.odaki@gmail.com/ [2] ASoC: Intel: Chromebooks: remap jack pins https://lore.kernel.org/alsa-devel/20220616214055.134943-1-pierre-louis.bossart@linux.intel.com/ [3] ASoC: mediatek: Allow separate handling of headphone and headset mic jack https://lore.kernel.org/alsa-devel/20220922235951.252532-1-nfraprado@collabora.com/ [4] ASoC: rk3399_gru_sound: Add DAPM pins, kcontrols for jack detection https://lore.kernel.org/alsa-devel/20200721182709.6895-1-alpernebiyasak@gmail.com/ This applies onto next-20230802. Unfortunately most of it is untested except for a few Chromebooks I have (Kevin, Lick, Hana, Cozmo), because I'm intentionally generalizing to everything.
-
