#
943f4e64 |
|
13-Feb-2023 |
Vitaly Rodionov <vitalyr@opensource.cirrus.com> |
ALSA: hda: cs35l41: Correct error condition handling Function cs_dsp_coeff_write_ctrl() can return 3 possible values: 0 - no change, 1 - value has changed and -1 - error, so positive value is not an error. Fixes: 7406bdbc4fb8 ("ASoC: wm_adsp: Return whether changed when writing controls") Signed-off-by: Vitaly Rodionov <vitalyr@opensource.cirrus.com> Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com> Link: https://lore.kernel.org/r/20230213145008.1215849-2-sbinding@opensource.cirrus.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
#
e57d904a |
|
24-Nov-2022 |
Richard Fitzgerald <rf@opensource.cirrus.com> |
firmware: cs_dsp: Make the exports namespaced Move all the exports into a namespace. This also adds the MODULE_IMPORT_NS to the 3 drivers that use the exported functions. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Link: https://lore.kernel.org/r/20221124134556.3343784-3-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
2176c6b5 |
|
11-Oct-2022 |
Richard Fitzgerald <rf@opensource.cirrus.com> |
ALSA: hda/cs_dsp_ctl: Fix mutex inversion when creating controls Redesign the creation of ALSA controls so that the cs_dsp pwr_lock is not held when calling snd_ctl_add(). Instead of creating the ALSA control from the cs_dsp control_add callback, do it after cs_dsp_power_up() has completed. The existing functions are changed to return void instead of passing errors back - this duplicates the original behaviour, as cs_dsp does not abort firmware load if creation of a control fails. It is safe to walk the control list without taking any mutex provided that the caller is not trying to load a new firmware or remove the driver in parallel. There is no other situation that the list can change. So the caller can trigger creation of ALSA controls after cs_dsp_power_up() has returned. A cs_dsp control will have a non-NULL priv pointer if we have created an ALSA control. With the previous code the ALSA controls were created from the cs_dsp control_add callback. But this is called with pwr_lock held (as it is part of the DSP power-up sequence). The kernel lock checking will show a mutex inversion between this and the control creation path: control_add pwr_lock held, takes controls_rwsem (in snd_ctl_add) get/put controls_rwsem held, takes pwr_lock to call cs_dsp. This is not completely theoretical. Although the time window is very small, it is possible for these to run in parallel and deadlock the old implementation. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com> Link: https://lore.kernel.org/r/20221011143552.621792-4-sbinding@opensource.cirrus.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
#
06f3a0a7 |
|
11-Oct-2022 |
Stefan Binding <sbinding@opensource.cirrus.com> |
ALSA: hda: hda_cs_dsp_ctl: Ensure pwr_lock is held before reading/writing controls These apis require the pwr_lock to be held. Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com> Link: https://lore.kernel.org/r/20221011143552.621792-3-sbinding@opensource.cirrus.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
#
49b0dea1 |
|
11-Oct-2022 |
Stefan Binding <sbinding@opensource.cirrus.com> |
ALSA: hda: hda_cs_dsp_ctl: Minor clean and redundant code removal The cs_dsp core will return an error if passed a NULL cs_dsp struct so there is no need for the hda_cs_dsp_write|read_ctl functions to manually check that. The cs_dsp core will also check the data is within bounds of the control so the additional bounds check is redundant too. Simplify things a bit by removing said code. Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com> Link: https://lore.kernel.org/r/20221011143552.621792-2-sbinding@opensource.cirrus.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
#
291e7c22 |
|
29-Jun-2022 |
Stefan Binding <sbinding@opensource.cirrus.com> |
ALSA: hda: hda_cs_dsp_ctl: Add fw id strings This will be used to define the firmware names. Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com> Signed-off-by: Vitaly Rodionov <vitalyr@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220630002335.366545-12-vitalyr@opensource.cirrus.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
#
e414b05e |
|
29-Jun-2022 |
Stefan Binding <sbinding@opensource.cirrus.com> |
ALSA: hda: hda_cs_dsp_ctl: Add apis to write the controls directly DSP controls are exposed as ALSA controls, however, some of these controls are required to be accessed by the driver. Add apis which allow read/write of these controls. The write api will also notify the ALSA control on value change. Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com> Signed-off-by: Vitaly Rodionov <vitalyr@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220630002335.366545-3-vitalyr@opensource.cirrus.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
#
3233b978 |
|
29-Jun-2022 |
Stefan Binding <sbinding@opensource.cirrus.com> |
ALSA: hda: hda_cs_dsp_ctl: Add Library to support CS_DSP ALSA controls The cs35l41 part contains a DSP which is able to run firmware. The cs_dsp library can be used to control the DSP. These controls can be exposed to userspace using ALSA controls. This library adds apis to be able to interface between cs_dsp and hda drivers and expose the relevant controls as ALSA controls. [ Note: the dependency of CONFIG_SND_HDA_CS_DSP_CONTROLS Kconfig is corrected. Also, this Kconfig isn't enabled now but will be actually enabled in a later patch -- tiwai ] Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com> Signed-off-by: Vitaly Rodionov <vitalyr@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220630002335.366545-2-vitalyr@opensource.cirrus.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
|