- 05 Nov, 2019 1 commit
-
-
Ranjani Sridharan authored
Currently, the trigger orders SND_SOC_DPCM_TRIGGER_PRE/POST determine the order in which FE DAI and BE DAI are triggered. In the case of SND_SOC_DPCM_TRIGGER_PRE, the FE DAI is triggered before the BE DAI and in the case of SND_SOC_DPCM_TRIGGER_POST, the BE DAI is triggered before the FE DAI. And this order remains the same irrespective of the trigger command. In the case of the SOF driver, during playback, the FW expects the BE DAI to be triggered before the FE DAI during the START trigger. The BE DAI trigger handles the starting of Link DMA and so it must be started before the FE DAI is started to prevent xruns during pause/release. This can be addressed by setting the trigger order for the FE dai link to SND_SOC_DPCM_TRIGGER_POST. But during the STOP trigger, the FW expects the FE DAI to be triggered before the BE DAI. Retaining the same order during the START and STOP commands, results in FW error as the DAI component in the FW is still active. The issue can be fixed by mirroring the trigger order of FE and BE DAI's during the START and STOP trigger. So, with the trigger order set to SND_SOC_DPCM_TRIGGER_PRE, the FE DAI will be trigger first during SNDRV_PCM_TRIGGER_START/STOP/RESUME and the BE DAI will be triggered first during the STOP/SUSPEND/PAUSE commands. Conversely, with the trigger order set to SND_SOC_DPCM_TRIGGER_POST, the BE DAI will be triggered first during the SNDRV_PCM_TRIGGER_START/STOP/RESUME commands and the FE DAI will be triggered first during the SNDRV_PCM_TRIGGER_STOP/SUSPEND/PAUSE commands. Signed-off-by:
Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20191104224812.3393-2-ranjani.sridharan@linux.intel.comSigned-off-by:
Mark Brown <broonie@kernel.org>
-
- 04 Nov, 2019 15 commits
-
-
Pierre-Louis Bossart authored
The wrong dependency is used and the build can be broken Signed-off-by:
-
Pierre-Louis Bossart authored
Geminilake machine drivers are only tested and recommended with SOF. Signed-off-by:
-
Pierre-Louis Bossart authored
The same driver is reused for 3 different configurations, but the driver will only be build if ApolloLake is selected. Fix and make sure each device can work without dependencies on others (useful for minimal configurations). Signed-off-by:
-
Pierre-Louis Bossart authored
This option is only required with the Skylake platform driver, there is no reason to have this option in machine drivers. This is e.g. useless for SOF-based solutions. Signed-off-by:
-
Pierre-Louis Bossart authored
This option famously broke audio on Linus' laptop and the problem have not been fixed. Mark as DEPRECATED to avoid any ambiguity with distros. Use SOF if you need HDaudio support w/ the DSP enabled, e.g. for DMIC capture. Signed-off-by:
-
Pierre-Louis Bossart authored
So far we used select to use the relevant built-in/module options, but this led to blurring layers between core and Intel Kconfigs. Use def_tristate works just as well and removes Intel stuff from the code. Suggested-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Pierre-Louis Bossart authored
updated solution to the problem reported with randconfig: CONFIG_SND_SOC_SOF_IMX depends on CONFIG_SND_SOC_SOF, but is in turn referenced by the sof-of-dev driver. This creates a reverse dependency that manifests in a link error when CONFIG_SND_SOC_SOF_OF is built-in but CONFIG_SND_SOC_SOF_IMX=m: sound/soc/sof/sof-of-dev.o:(.data+0x118): undefined reference to `sof_imx8_ops' use def_trisate to propagate the right settings without select. Fixes: f4df4e40 ("ASoC: SOF: imx8: Fix COMPILE_TEST error") Fixes: 202acc56 ("ASoC: SOF: imx: Add i.MX8 HW support") Suggested-by:
-
Pierre-Louis Bossart authored
Some distros select all possible options, despite existing warnings to be careful. This leads to e.g. user reports that the HDaudio codec and DMIC are not handled by SOF. Add an explicit menu item to unlock developer options, and make them dependent on CONFIG_EXPERT. Hopefully with this double-lock these options will only be selected by developers. GitHub issue: https://github.com/thesofproject/sof/issues/1885Signed-off-by:
-
Pierre-Louis Bossart authored
This legacy driver is already deprecated, let's make sure there is no conflict with SOF. Signed-off-by:
-
Pierre-Louis Bossart authored
Some distros select all options blindly, which leads to confusion and bug reports. SOF does not fully support Broadwell due to firmware dependencies, the machine drivers can only support one option, and UCM/topology files are still being propagated to downstream distros, so make SOF on Broadwell an opt-in option that first require distros to opt-out of existing defaults. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204237 Fixes: f35bf70f ('ASoC: Intel: Make sure BDW based machine drivers build for SOF') Signed-off-by:
-
Pierre-Louis Bossart authored
Some distros select all options blindly, which leads to confusion and bug reports. Since SOF does not support Baytrail-CR for now, and UCM/topology files are still being propagated to downstream distros, make SOF on Baytrail an opt-in option that first require distros to opt-out of existing defaults. Signed-off-by:
-
Ranjani Sridharan authored
Remove the retry argument for the hda_dsp_wait_d0i3c_done() function and use the HDA_DSP_REG_POLL_RETRY_COUNT macro directly. Signed-off-by:
-
Naveen Manohar authored
Machine driver to enable RT5682 on SSP0, DMIC, HDMI and RT1011 AMP on SSP1 with 2 CH / 24 bit TDM Playback over 4 individual codecs and 4 CH / 24 bit Capture to provide feedback. Signed-off-by:
Naveen Manohar <naveen.m@intel.com> Signed-off-by:
Sathya Prakash M R <sathya.prakash.m.r@intel.com> Signed-off-by:
Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by:
-
Naveen Manohar authored
Add match for CML m/c with RT1011 and RT5682 Signed-off-by:
-
zhong jiang authored
local variable "status" is not used. hence it is safe to remove and just return 0. Signed-off-by:
zhong jiang <zhongjiang@huawei.com> Link: https://lore.kernel.org/r/1572528855-25990-1-git-send-email-zhongjiang@huawei.comSigned-off-by:
-
- 31 Oct, 2019 5 commits
-
-
Shuming Fan authored
There is no other code use the RT1011_INIT_REG_LEN definition, except rt1011_reg_init(). Hence, we remove it and fix the typo. Signed-off-by:
Shuming Fan <shumingf@realtek.com> Link: https://lore.kernel.org/r/20191031115446.21108-1-shumingf@realtek.comSigned-off-by:
-
Shuming Fan authored
The driver will check the range for temperature_calib. It should be from 1 to 255. Signed-off-by:
-
Shuming Fan authored
There are unnecessary tabs inside some statements. It uses sapces instead. Signed-off-by:
-
Shuming Fan authored
If there is a wrong format setting, the driver will goto the end of the function directly. Signed-off-by:
-
Shuming Fan authored
The !component->card->instantiated statement should remove in kcontrol. It is no need to check the card->instantiated in kcontrol. Signed-off-by:
-
- 30 Oct, 2019 4 commits
-
-
Shuming Fan authored
The btndet-delay device property could control the HW debounce time. It is easy to adjust the sensitivity of push button. Signed-off-by:
-
Shuming Fan authored
The sensitivity could improve by decreasing the HW debounce time and reduce the delay time of workequeue. This patch added a device property for HW debounce time control. We could change this value to tune the sensitivity of push button. Signed-off-by:
-
Kuninori Morimoto authored
snd_soc_tplg_component_remove() is pair of snd_soc_tplg_component_load(), and it is topology related cleanup function. The driver which called _load() needs to call _remove() by its responsibility. Today, skl-pcm and topology are the user, and these are calling both _load() and _remove(). soc-core doesn't need to call it. This patch remove it. Signed-off-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/8736fbdnwt.wl-kuninori.morimoto.gx@renesas.comSigned-off-by:
-
Kuninori Morimoto authored
This patch fixup this warning LINUX/sound/soc/codecs/rt5677-spi.c: In function ‘rt5677_spi_pcm_close’: LINUX/sound/soc/codecs/rt5677-spi.c:114:30: warning: unused variable ‘rtd’ [-Wunused-variable] struct snd_soc_pcm_runtime *rtd = substream->private_data; ^~~ Fixes: a0e0d135 ("ASoC: rt5677: Add a PCM device for streaming hotword via SPI") Signed-off-by:
-
- 29 Oct, 2019 15 commits
-
-
Kai Vehmanen authored
Add support for using snd-hda-codec-hdmi driver for HDMI/DP instead of ASoC hdac-hdmi. This is aligned with how other HDA codecs are already handled. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Reviewed-by:
-
Kai Vehmanen authored
Add support for using snd-hda-codec-hdmi driver for HDMI/DP instead of ASoC hdac-hdmi. This is aligned with how other HDA codecs are already handled. Signed-off-by:
-
Kai Vehmanen authored
Add support for using snd-hda-codec-hdmi driver for HDMI/DP instead of ASoC hdac-hdmi. This is aligned with how other HDA codecs are already handled. Signed-off-by:
-
Kai Vehmanen authored
Add support for using snd-hda-codec-hdmi driver for HDMI/DP instead of ASoC hdac-hdmi. This is aligned with how other HDA codecs are already handled. Signed-off-by:
-
Kai Vehmanen authored
Add support to implement HDMI/DP audio by using the common snd-hda-codec-hdmi driver. Change of codec driver affects user-space as the two drivers expose different mixer controls. A new kernel module option "use_common_hdmi" is added to user-space to indicate which interface should be used. The default driver can be selected via a Kconfig option. Signed-off-by:
-
Kai Vehmanen authored
Match the include guard define to actual filename. The source directory now has an actual hda_dsp_common.h header, so the old include guard may cause confusion. Signed-off-by:
-
Kai Vehmanen authored
Add support for using snd-hda-codec-hdmi driver for HDMI/DP instead of ASoC hdac-hdmi. This is aligned with how other HDA codecs are already handled. When snd-hda-codec-hdmi is used, the PCM device numbers are parsed from card topology and passed to the codec driver. This needs to be done at runtime as topology changes may affect PCM device allocation. Signed-off-by:
-
Kai Vehmanen authored
Handle all HDA codecs using same logic, including HDMI/DP. Call to snd_hda_codec_build_controls() is delayed for HDMI/DP HDA devices. This is needed to discover the PCM device numbers as defined in topology. Signed-off-by:
-
Kai Vehmanen authored
To support the DP-MST multiple streams via single connector feature, the HDMI driver was extended with the concept of backup PCMs. See commit 9152085d ("ALSA: hda - add DP MST audio support"). This implementation works fine with snd_hda_intel.c as PCM topology is fully managed within the single driver. When the HDA codec driver is used from ASoC components, the concept of backup PCMs no longer fits. For ASoC topologies, the physical HDMI converters are presented as backend DAIs and these should match with hardware capabilities. The ASoC topology may define arbitrary PCMs (i.e. frontend DAIs) and have processing elements before eventual routing to the HDMI BE DAIs. With backup PCMs, the link between FE and BE DAIs would become dynamic and change when monitors are (un)plugged. This would lead to modifying the topology every time hotplug events happen, which is not currently possible in ASoC and there does not seem to be any obvious benefits from this design. To overcome above problems and enable the HDMI driver to be used from ASoC, this patch adds a new mode (mst_no_extra_pcms flags) to patch_hdmi.c. In this mode, the codec driver does not assume the backup PCMs to be created. Signed-off-by:
-
Cheng-Yi Chiang authored
In machine driver, create a jack and let hdmi-codec report jack status. Signed-off-by:
Cheng-Yi Chiang <cychiang@chromium.org> Link: https://lore.kernel.org/r/20191028071930.145899-5-cychiang@chromium.orgSigned-off-by:
-
Cheng-Yi Chiang authored
Support three different use cases with rockchip_max98090 driver. The three use cases: - max98090 only: Current usage, where HDMI link is missing. - HDMI only: Needed use case for veyron_mickey board. - max98090 + HDMI: Ideal use case for veyron_jerry, veyron_minnie..etc. The presence of max98090 is determined by the presence of rockchip,audio-codec device property. The presence of HDMI is determined by the presence of rockchip,hdmi-codec device property. Create different sound card based on the configuration. Note that we keep max98090 only usage for backward compatibility. Signed-off-by:
-
Cheng-Yi Chiang authored
Add one optional property "rockchip,hdmi-codec" to let user specify HDMI device node in DTS so machine driver can find hdmi-codec device node for HDMI codec DAI. Use the presence of rockchip,audio-codec and rockchip,hdmi-codec to specify the use case. Use max98090 only : specify rockchip,audio-codec. Use HDMI only: specify rockchip,hdmi-codec. Use both max98090 and HDMI: specify rockchip,audio-codec and rockchip,hdmi-codec. Move these properties to optional because they are not needed for HDMI-only use case. "rockchip,audio-codec": The phandle of the MAX98090 audio codec "rockchip,headset-codec": The phandle of Ext chip for jack detection Signed-off-by:
-
Cheng-Yi Chiang authored
Allow codec driver register callback function for plug event. The callback registration flow: dw-hdmi <--- hw-hdmi-i2s-audio <--- hdmi-codec dw-hdmi-i2s-audio implements hook_plugged_cb op so codec driver can register the callback. dw-hdmi exports a function dw_hdmi_set_plugged_cb so platform device can register the callback. When connector plug/unplug event happens, report this event using the callback. Make sure that audio and drm are using the single source of truth for connector status. Signed-off-by:
-
Jaroslav Kysela authored
Appearently the CONFIG_SND_SOC_SOF_KABYLAKE and CONFIG_SND_SOC_SOF_SKYLAKE options are not present in Kconfig and 'struct snd_sof_dsp_ops sof_skl_ops' is not declared in the code, too. Signed-off-by:
Jaroslav Kysela <perex@perex.cz> Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Cc: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20191028173329.29538-1-perex@perex.czSigned-off-by:
-
Jaroslav Kysela authored
Those strings are exposed to the user space as the card name thus used in the GUIs. The common standard is to avoid '_' here. The worst case is 'sof-skl_hda_card' string. Signed-off-by:
-
