- 26 Jul, 2019 6 commits
-
-
Peter Ujfalusi authored
Implement custom snd_pcm_hw_rule to filter the available formats for the second stream to make it symmetric and allow only formats which require the same amount of bits on the bus as the running stream. A simple constraint is not working correctly because for example: the first stream is started with S24_LE If we place 24 as constraint for the SAMPLE_BITS then the second stream can not use S24_LE as it is physically 32bits. If we would place 32 as constraint (physical width) then S32_LE would have been allowed, but S24_3LE is not. Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20190726064244.3762-3-peter.ujfalusi@ti.comSigned-off-by:
Mark Brown <broonie@kernel.org>
-
Mark Brown authored
-
Peter Ujfalusi authored
The slot_width is a property for the bus while the constraint for SNDRV_PCM_HW_PARAM_SAMPLE_BITS is for the in memory format. Applying slot_width constraint to sample_bits works most of the time, but it will blacklist valid formats in some cases. With slot_width 24 we can support S24_3LE and S24_LE formats as they both look the same on the bus, but a a 24 constraint on sample_bits would not allow S24_LE as it is stored in 32bits in memory. Implement a simple hw_rule function to allow all formats which require less or equal number of bits on the bus as slot_width (if configured). Signed-off-by:
-
Cheng-Yi Chiang authored
This reverts commit db51707b. Revert "ASoC: rockchip: i2s: Support mono capture" Previous discussion in https://patchwork.kernel.org/patch/10147153/ explains the issue of the patch. While device is configured as 1-ch, hardware is still generating a 2-ch stream. When user space reads the data and assumes it is a 1-ch stream, the rate will be slower by 2x. Revert the change so 1-ch is not supported. User space can selectively take one channel data out of two channel if 1-ch is preferred. Currently, both channels record identical data. Signed-off-by:
Cheng-Yi Chiang <cychiang@chromium.org> Link: https://lore.kernel.org/r/20190726044202.26866-1-cychiang@chromium.orgSigned-off-by:
-
Christophe JAILLET authored
Fix some typo to have the filaname given in a comment match the real name of the file. Some 'acpi' have erroneously been written 'apci' Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/20190725053523.16542-1-christophe.jaillet@wanadoo.frSigned-off-by:
-
Peter Ujfalusi authored
When running McASP as master capture alone will not record any audio unless a parallel playback stream is running. As soon as the playback stops the captured data is going to be silent again. In McASP master mode we need to set the PDIR for the clock pins and fix the mcasp_set_axr_pdir() to skip the bits in the PDIR registers above AMUTE. This went unnoticed as most of the boards uses McASP as slave and neither of these issues are visible (audible) in those setups. Fixes: ca3d9433 ("ASoC: davinci-mcasp: Update PDIR (pin direction) register handling") Signed-off-by:
-
- 25 Jul, 2019 10 commits
-
-
Jerome Brunet authored
When there is an event on codec to codec dai_link, we only need to deal with params if the event is SND_SOC_DAPM_PRE_PMU, when .hw_params() is called. For the other events, it is useless. Also, dealing with the codec to codec params just before calling .hw_params() callbacks give change to either party on the link to alter params content in .startup(), which might be useful in some cases Signed-off-by:
Jerome Brunet <jbrunet@baylibre.com> Link: https://lore.kernel.org/r/20190725165949.29699-4-jbrunet@baylibre.comSigned-off-by:
-
Jerome Brunet authored
At the moment, codec to codec dai link widgets are named after the cpu dai and the 1st codec valid on the link. This might be confusing if there is multiple valid codecs on the link for one stream direction. Instead, use the dai link name and the stream direction to name the the dai link widget Signed-off-by:
-
Jerome Brunet authored
When handling dai_link events on codec to codec links, run all .startup() callbacks on sinks and sources before running any .hw_params(). Same goes for hw_free() and shutdown(). This is closer to the behavior of regular dai links Signed-off-by:
-
Stuart Henderson authored
Adds the codec driver for the CS47L92 SmartCodec. This is a multi-functional codec based on the Cirrus Logic Madera platform. Signed-off-by:
Stuart Henderson <stuarth@opensource.wolfsonmicro.com> Signed-off-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20190725163931.24964-3-ckeepax@opensource.cirrus.comSigned-off-by:
-
Richard Fitzgerald authored
Adds the codec driver for the CS47L15 SmartCodec. This is a multi-functional codec based on the Cirrus Logic Madera platform. Signed-off-by:
Richard Fitzgerald <rf@opensource.wolfsonmicro.com> Signed-off-by:
Jaswinder Jassal <jjassal@opensource.wolfsonmicro.com> Signed-off-by:
-
Charles Keepax authored
There is no need for end drivers to add helper functions to allow the bus error handler to be called, simply update the prototype so it can be called directly. Signed-off-by:
-
Jaroslav Kysela authored
Use the proper module name. The objs assignments are already there. Signed-off-by:
Jaroslav Kysela <perex@perex.cz> Cc: Liam Girdwood <liam.r.girdwood@linux.intel.com> Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Cc: Takashi Iwai <tiwai@suse.de> Cc: Mark Brown <broonie@kernel.org>0 Link: https://lore.kernel.org/r/20190725133743.22145-1-perex@perex.czSigned-off-by:
-
Peter Ujfalusi authored
When multiple serializers are used we need to track the number of serializers used by the other stream direction to avoid killing data lines when the first stream used more serializers than the second would need. We are still protected against the case when the second stream uses more serializers which had affected the running stream as well. To take advantage of the improved serializer logic we need to modify the channel constraints rule as well to allow the use of multiple serializers for the second stream as additional ones will not affect the FS/BCLK on the bus. Signed-off-by:
-
Peter Ujfalusi authored
The formater unit's rotation needs to be programmed differently for right aligned bus format to have the data moved to the correct place. Take the opportunity and simplify the formater unit setup code. Signed-off-by:
-
Peter Ujfalusi authored
If multi DIN/DOUT mode is selected (tdm_slots == 2) then configure the channel constraint to allow all channels. Signed-off-by:
-
- 24 Jul, 2019 9 commits
-
-
Cezary Rojewski authored
With removal of MCPS, CPS and CPC ambiguity, ibs and obs params for struct skl_module_cfg have been left unused. Update struct declaration by removing these two. Signed-off-by:
Cezary Rojewski <cezary.rojewski@intel.com> Link: https://lore.kernel.org/r/20190723145854.8527-8-cezary.rojewski@intel.comSigned-off-by:
-
Cezary Rojewski authored
As per FW Interface Modules Configuration, init instance IPC request requires base initial module configuration. This configuration structure is made of: - cpc (chunks per cycle) - ibs (input buffer size) - obs (output buffer size) - is_pages (memory pages required) - audio_fmt (self explanatory) Skylake topology accepts following tokens: MCPS, CPS and CPC. All of these are directly connected. Moreover, assigning one of these allows to calculate the remaining two. In simplest scenario and assuming 1ms scheduling, following is true: CPS = CPC times 1000 MCPS = CPS times 1000 000 Note: these calculations vary depending on scenario and scheduling requirements. Given the current implementation, userspace is allowed to provide different values for all three causing informational chaos. On top of that, struct skl_base_cfg which represents base module configuration, incorrectly takes CPS param instead of CPC. This ambiguity may lead to user unintentionally providing improper values to DSP firmware and thus impacting module scheduling in unexpected fashion. Fix by making MCPS and CPS topology params obsolete and relying solely on CPC value. Signed-off-by:
-
Amadeusz Sławiński authored
As per FW team recommendation we should not disable notifications. By default, all notifications are enabled in DSP firmware. These notifications provide a vital information whenever an error occurs. Currently, driver disables them during boot sequences. By doing so, Skylake may silently ignore severe stream errors. Correct that by removing permissive code. Signed-off-by:
Amadeusz Sławiński <amadeuszx.slawinski@intel.com> Signed-off-by:
-
Cezary Rojewski authored
Current memory availability check is a stub, while actual memory management takes place in firmware. Leave this task to firmware entirely and remove redundant code. Signed-off-by:
-
Cezary Rojewski authored
The entire logic for MCPS calculation and DSP scheduling is found within DSP firmware. Currently driver implements simplistic, inaccurate logic itself which may prevent pipeline creation despite firmware being completely fine its parameters. Remove that logic and leave the MCPS calculation to DSP alone. Signed-off-by:
-
Amadeusz Sławiński authored
As both modules are core part of Skylake driver and none can live without the other, combine snd_soc_skl_ipc and snd_soc_skl. It's highly probable IPC module was to be treated as an interface for platform specific code implementations e.g.: possibility of existence of BXT specific code without SKL one. However, most funtionalities are being inherited from one DSP firmware to another, and thus this assumption fails. skl-sst, bxt-sst and cnl-sst are not individuals pointing respectively to SKL (cAVS 1.5), BXT (cAVS 1.5+) & CNL (cAVS 1.8) standalone implementations. Code found within these is shared among all platforms whenever necessary to avoid code duplication and reduce development burden. Merge also helps in cleaning up internal code in future changes. Signed-off-by:
-
Cezary Rojewski authored
Skylake driver is divided into two modules: - snd_soc_skl - snd_soc_skl_ipc and nothing would be wrong if not for the fact that both cannot exist without one another. IPC module is not some kind of extension, as it is the case for snd_hda_ext_core which is separated from snd_hda_core - legacy hda interface. It's as much core Skylake module as snd_soc_skl is. Statement backed up by existence of circular dependency between this two. To eliminate said problem, struct skl_sst has been created. From that very momment, Skylake has been plagued by header errors (incomplete structs, unknown references etc.) whenever something new is to be added or code is cleaned up. As this design is being corrected, struct skl_sst is no longer needed, so combine it with struct skl. To avoid ambiguity when searching for skl stuff (struct skl *skl) it has also been renamed to skl_dev. No functional changes. Signed-off-by:
Piotr Maziarz <piotrx.maziarz@intel.com> Signed-off-by:
-
Christophe JAILLET authored
This should be 'wm8955_pll_factors()' instead. Fix it and use it. Signed-off-by:
-
Ricard Wanderlof authored
If the DAI format setup fails, there is no valid communication format between CPU and CODEC, so fail card instantiation, rather than continue with a card that will most likely not function properly. Signed-off-by:
Ricard Wanderlof <ricardw@axis.com> Link: https://lore.kernel.org/r/alpine.DEB.2.20.1907241132350.6338@lnxricardw1.se.axis.comSigned-off-by:
-
- 23 Jul, 2019 15 commits
-
-
Kuninori Morimoto authored
snd_soc_dai_stream_valid() is function to check stream validity. But, some code is using it, some code are checking stream->channels_min directly. Doing samethings by different method is confusable. This patch uses same funcntion for same purpose. Signed-off-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87ftmyhmzz.wl-kuninori.morimoto.gx@renesas.comSigned-off-by:
-
Kuninori Morimoto authored
ALSA SoC already has snd_soc_dai_digital_mute() for digital_mute, let's use it. Signed-off-by:
-
Kuninori Morimoto authored
Current ALSA SoC is directly using dai->driver->xxx, thus, it has deep nested bracket, and it makes code unreadable. This patch adds new snd_soc_dai_compress_new() and use it. Signed-off-by:
-
Kuninori Morimoto authored
Current ALSA SoC is directly using dai->driver->xxx, thus, it has deep nested bracket, and it makes code unreadable. This patch adds new snd_soc_dai_remvoe() and use it. Signed-off-by:
-
Kuninori Morimoto authored
Current ALSA SoC is directly using dai->driver->xxx, thus, it has deep nested bracket, and it makes code unreadable. This patch adds new snd_soc_dai_probe() and use it. Signed-off-by:
-
Kuninori Morimoto authored
Current ALSA SoC is directly using dai->driver->xxx, thus, it has deep nested bracket, and it makes code unreadable. This patch adds new snd_soc_dai_resume() and use it. Signed-off-by:
-
Kuninori Morimoto authored
Current ALSA SoC is directly using dai->driver->xxx, thus, it has deep nested bracket, and it makes code unreadable. This patch adds new snd_soc_dai_suspend() and use it. Signed-off-by:
-
Kuninori Morimoto authored
Current ALSA SoC is directly using dai->driver->ops->xxx, thus, it has deep nested bracket, and it makes code unreadable. This patch adds new snd_soc_dai_delay() and use it. Signed-off-by:
-
Kuninori Morimoto authored
Current ALSA SoC is directly using dai->driver->ops->xxx, thus, it has deep nested bracket, and it makes code unreadable. This patch adds new snd_soc_dai_bespoke_trigger() and use it. Signed-off-by:
-
Kuninori Morimoto authored
Current ALSA SoC is directly using dai->driver->ops->xxx, thus, it has deep nested bracket, and it makes code unreadable. This patch adds new snd_soc_dai_trigger() and use it. Signed-off-by:
-
Kuninori Morimoto authored
Current ALSA SoC is directly using dai->driver->ops->xxx, thus, it has deep nested bracket, and it makes code unreadable. This patch adds new snd_soc_dai_prepare() and use it. Signed-off-by:
-
Kuninori Morimoto authored
Current ALSA SoC is directly using dai->driver->ops->xxx, thus, it has deep nested bracket, and it makes code unreadable. This patch adds new snd_soc_dai_shutdown() and use it. Signed-off-by:
-
Kuninori Morimoto authored
Current ALSA SoC is directly using dai->driver->ops->xxx, thus, it has deep nested bracket, and it makes code unreadable. This patch adds new snd_soc_dai_startup() and use it. Signed-off-by:
-
Kuninori Morimoto authored
Current ALSA SoC is directly using dai->driver->ops->xxx, thus, it has deep nested bracket, and it makes code unreadable. This patch adds new snd_soc_dai_hw_free() and use it. Signed-off-by:
-
Kuninori Morimoto authored
Sometimes ALSA SoC naming is very random. Current soc_dai_hw_params() should use snd_soc_dai_xxx() style. And then, 1st parameter should be dai. Otherwise it is confusable. - soc_dai_hw_params(..., dai); + snd_soc_dai_hw_params(dai, ...); Signed-off-by:
-
