- 27 Aug, 2019 5 commits
-
-
Katsuhiro Suzuki authored
This patch fix setting table of Headphone mixer volume. Current code uses 4 ... 7 values but these values are prohibited. Correct settings are the following: 0000 -12dB 0001 -10.5dB 0010 -9dB 0011 -7.5dB 0100 -6dB 1000 -4.5dB 1001 -3dB 1010 -1.5dB 1011 0dB Signed-off-by:
Katsuhiro Suzuki <katsuhiro@katsuster.net> Reviewed-by:
Daniel Drake <drake@endlessm.com> Link: https://lore.kernel.org/r/20190826153900.25969-1-katsuhiro@katsuster.netSigned-off-by:
Mark Brown <broonie@kernel.org>
-
Amadeusz Sławiński authored
oem_table_id is 8 chars long, so we need to limit it, otherwise it may print some unprintable characters into dmesg. Signed-off-by:
Amadeusz Sławiński <amadeuszx.slawinski@intel.com> Link: https://lore.kernel.org/r/20190827141712.21015-7-amadeuszx.slawinski@linux.intel.comReviewed-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by:
-
Amadeusz Sławiński authored
We use snd_soc_dapm_new_control_unlocked for topology and have local declaration, instead declare it properly in header like already declared snd_soc_dapm_new_control. Signed-off-by:
-
Amadeusz Sławiński authored
If ipc->ops.reply_msg_match is NULL, we may end up using uninitialized mask value. reported by smatch: sound/soc/intel/common/sst-ipc.c:266 sst_ipc_reply_find_msg() error: uninitialized symbol 'mask'. Signed-off-by:
-
Amadeusz Sławiński authored
For copying from __iomem, we should use __ioread32_copy. reported by sparse: sound/soc/intel/skylake/skl-debug.c:437:34: warning: incorrect type in argument 1 (different address spaces) sound/soc/intel/skylake/skl-debug.c:437:34: expected void [noderef] <asn:2> *to sound/soc/intel/skylake/skl-debug.c:437:34: got unsigned char * sound/soc/intel/skylake/skl-debug.c:437:51: warning: incorrect type in argument 2 (different address spaces) sound/soc/intel/skylake/skl-debug.c:437:51: expected void const *from sound/soc/intel/skylake/skl-debug.c:437:51: got void [noderef] <asn:2> *[assigned] fw_reg_addr Signed-off-by:
-
- 22 Aug, 2019 1 commit
-
-
YueHaibing authored
While do rand build without GPIOLIB, we get Kconfig warning:\ WARNING: unmet direct dependencies detected for SND_SOC_MAX98357A Depends on [n]: SOUND [=y] && !UML && SND [=m] && SND_SOC [=m] && GPIOLIB [=n] Selected by [m]: - SND_SOC_AMD_CZ_DA7219MX98357_MACH [=m] && SOUND [=y] && !UML && SND [=m] && SND_SOC [=m] && SND_SOC_AMD_ACP [=m] && I2C [=y] Add GPIOLIB dependency to fix this. Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20190822143007.73644-1-yuehaibing@huawei.comSigned-off-by:
-
- 20 Aug, 2019 9 commits
-
-
Codrin Ciubotariu authored
Since hw_free() can be called multiple times and not just after a stop trigger command, we should check whether the RX or TX ready interrupt was truly enabled previously. For this, we assure that the condition of the wait event is always true, except when RX/TX interrupts are enabled. Fixes: 7e0cdf545a55 ("ASoC: mchp-i2s-mcc: add driver for I2SC Multi-Channel Controller") Signed-off-by:Codrin Ciubotariu <codrin.ciubotariu@microchip.com> Link: https://lore.kernel.org/r/20190820162411.24836-3-codrin.ciubotariu@microchip.comSigned-off-by:
-
Codrin Ciubotariu authored
If hw_free() gets called after hw_params(), GCLK remains prepared, preventing further use of it. This patch fixes this by unpreparing the clock in hw_free() or if hw_params() gets an error. Fixes: 7e0cdf545a55 ("ASoC: mchp-i2s-mcc: add driver for I2SC Multi-Channel Controller") Signed-off-by: -
Maxime Ripard authored
So far the regmap and the dmaengine PCM are registered after our component has been, which means that our driver isn't properly initialised by then. Let's fix that. Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Link: https://lore.kernel.org/r/67e303f37f141ef73ce9ed47d7f831b63c694424.1566242458.git-series.maxime.ripard@bootlin.comSigned-off-by:
-
Michał Mirosław authored
Make '* Capture Mode' a mux. This makes DAPM know that in single-ended mode only inverting mux paths need to be enabled. Signed-off-by:
Michał Mirosław <mirq-linux@rere.qmqm.pl> Acked-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/125cd3c9f298da9b08a4d6002d4c00d70a898950.1566298834.git.mirq-linux@rere.qmqm.plSigned-off-by:
-
Michał Mirosław authored
Trivial fix for typo in "Capture Inverting Mux"es' name. Signed-off-by:
-
Daniel Stuart authored
Every single baytrail chromebook sets PMC to 0, as can be seeing below by searching through coreboot source code: $ grep -rl "PMC_PLT_CLK\[0\]" . ./rambi/variants/glimmer/devicetree.cb ./rambi/variants/clapper/devicetree.cb ./rambi/variants/swanky/devicetree.cb ./rambi/variants/enguarde/devicetree.cb ./rambi/variants/winky/devicetree.cb ./rambi/variants/kip/devicetree.cb ./rambi/variants/squawks/devicetree.cb ./rambi/variants/orco/devicetree.cb ./rambi/variants/ninja/devicetree.cb ./rambi/variants/heli/devicetree.cb ./rambi/variants/sumo/devicetree.cb ./rambi/variants/banjo/devicetree.cb ./rambi/variants/candy/devicetree.cb ./rambi/variants/gnawty/devicetree.cb ./rambi/variants/rambi/devicetree.cb ./rambi/variants/quawks/devicetree.cb Plus, Cyan (only non-baytrail chromebook with max98090) also needs this patch for audio to work. Thus, this commit adds all the missing devices to bsw_max98090 quirk table, implemented by commit a182ecd3 ("ASoC: intel: cht_bsw_max98090_ti: Add quirk for boards using pmc_plt_clk_0"). Signed-off-by:
Daniel Stuart <daniel.stuart14@gmail.com> Link: https://lore.kernel.org/r/20190815171300.30126-1-daniel.stuart14@gmail.comSigned-off-by:
-
Jerome Brunet authored
The tohdmitx glue uses regmap MMIO so it should require it. Fixes: c8609f38 ("ASoC: meson: add g12a tohdmitx control") Signed-off-by:
Jerome Brunet <jbrunet@baylibre.com> Link: https://lore.kernel.org/r/20190820123510.22491-1-jbrunet@baylibre.comSigned-off-by:
-
Jerome Brunet authored
Use the devm variant to get the formatter reset so it is properly freed on device removal Fixes: 751bd5db ("ASoC: meson: axg-tdm-formatter: add reset") Signed-off-by:
-
Kunihiko Hayashi authored
When transitioning to supend state, uniphier_aio_dai_suspend() is called and asserts reset lines and disables clocks. However, if there are two or more DAIs, uniphier_aio_dai_suspend() are called multiple times, and double reset assersion will cause. This patch defines the counter that has the number of DAIs at first, and whenever uniphier_aio_dai_suspend() are called, it decrements the counter. And only if the counter is zero, it asserts reset lines and disables clocks. In the same way, uniphier_aio_dai_resume() are called, it increments the counter after deasserting reset lines and enabling clocks. Fixes: 139a3420 ("ASoC: uniphier: add support for UniPhier AIO CPU DAI driver") Signed-off-by:
Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Link: https://lore.kernel.org/r/1566281764-14059-1-git-send-email-hayashi.kunihiko@socionext.comSigned-off-by:
-
- 16 Aug, 2019 1 commit
-
-
Shengjiu Wang authored
For i.MX6 SoloX, there is a mode of the SoC to shutdown all power source of modules during system suspend and resume procedure. Thus, AUDMUX needs to save all the values of registers before the system suspend and restore them after the system resume. Signed-off-by:
Shengjiu Wang <shengjiu.wang@nxp.com> Link: https://lore.kernel.org/r/1565931794-7218-1-git-send-email-shengjiu.wang@nxp.comSigned-off-by:
-
- 15 Aug, 2019 3 commits
-
-
YueHaibing authored
sound/soc/codecs/wm8737.c:112:29: warning: high_3d defined but not used [-Wunused-const-variable=] 'high_3d' should be used for 3D High Cut-off. Reported-by:
-
YueHaibing authored
sound/soc/codecs/cs4349.c:358:32: warning: cs4349_runtime_pm defined but not used [-Wunused-const-variable=] cs4349_runtime_pm ops already defined, it seems we should enable it. Reported-by:
-
YueHaibing authored
It seems 'es8328_rline_enum' should be used in es8328_right_line_controls Fixes: 567e4f98 ("ASoC: add es8328 codec driver") Signed-off-by:
-
- 13 Aug, 2019 1 commit
-
-
Cheng-Yi Chiang authored
From stress testing of arecord, we found that period size greater than ~900 will bring pl330 to DYING state and can not recover within 100 iterations. The result is that arecord will stuck and get I/O error, and issue can not be recovered until reboot. This issue does not happen when period size is small. Set constraint of period size to 240 to prevent such issue. With the constraint, there will be no issue after 2000 iterations. We can revert this patch once the root cause is found in rockchip's pl330 implementation. Signed-off-by:
Cheng-Yi Chiang <cychiang@chromium.org> Link: https://lore.kernel.org/r/20190813074430.191791-1-cychiang@chromium.orgSigned-off-by:
-
- 12 Aug, 2019 1 commit
-
-
Keyon Jie authored
We need add DAPM MIC endpoint widget "SoC DMIC" and route, to enable DMIC PCM DAPM support. Signed-off-by:
Keyon Jie <yang.jie@linux.intel.com> Signed-off-by:
-
- 09 Aug, 2019 1 commit
-
-
Takashi Iwai authored
hdac_hdmi_present_sense() calls the audio component to get ELD update, then it reports the jack status change and updates DAPM graph accordingly. This works when it's called from the normal code paths. However, it may lead to a dead lock when it's called from the audio component notifier. Namely, the DAPM update involves with the runtime PM, and it eventually calls again the audio component get_power() ops. Since i915 driver already takes a mutex around the audio component ops calls, we'll eventually get the mutex doubly. As a workaround, in this patch, only the jack state is updated in the code path from hdac_hdmi_eld_notify_cb(), and the DAPM update is deferred to a work so that it's processed in another context. Reported-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/20190809151531.24359-1-tiwai@suse.deSigned-off-by:
-
- 08 Aug, 2019 1 commit
-
-
Keyon Jie authored
There is a race between hda codec device removing and the jack-detecting work, which will lead to a page fault issue as the latter work is accessing codec device which could be already removed. Here add the cancellation of jack-detecting work before codecs are actually removed to avoid the race and fix the issue. Bug: https://github.com/thesofproject/linux/issues/1067Signed-off-by:
-
- 07 Aug, 2019 2 commits
-
-
Ranjani Sridharan authored
On some platforms, sound card registration fails when a HDMI monitor is not connected. This is caused by a recent commit that switched the order in which the HDA controller and the i915 are initialized. Initializing the i915 before initializing the HDA controller fixes the problem. Fixes: be1b577d ("ASoC: SOF: Intel: hda: fix the hda init chip" Signed-off-by:
Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by:
-
Kuninori Morimoto authored
ADG is using clk_get_rate() under atomic context, thus, we might have scheduling issue. To avoid this issue, we need to get/keep clk rate under non atomic context. We need to handle ADG as special device at Renesas Sound driver. From SW point of view, we want to impletent it as rsnd_mod_ops :: prepare, but it makes code just complicate. To avoid complicated code/patch, this patch adds new clk_rate[] array, and keep clk IN rate when rsnd_adg_clk_enable() was called. Reported-by:
Leon Kong <Leon.KONG@cn.bosch.com> Signed-off-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Tested-by:
-
- 06 Aug, 2019 1 commit
-
-
Mark Brown authored
Signed-off-by:
-
- 02 Aug, 2019 2 commits
-
-
Vijendar Mukunda authored
We shouldn't assume CPU physical address we get from page_to_phys() is same as DMA address we get from dma_alloc_coherent(). On x86_64, we won't run into any problem with the assumption when dma_ops is nommu_dma_ops. However, DMA address is IOVA when IOMMU is enabled. And it's most likely different from CPU physical address when AMD IOMMU is not in passthrough mode. This patch fixes page faults when IOMMU is enabled. Signed-off-by:
Vijendar Mukunda <vijendar.mukunda@amd.com> Link: https://lore.kernel.org/r/1564753899-17124-2-git-send-email-Vijendar.Mukunda@amd.comSigned-off-by:
-
Vijendar Mukunda authored
AMD platform device acp3x_rv_i2s created by parent PCI device driver. Pass struct device of the parent to snd_pcm_lib_preallocate_pages() so dma_alloc_coherent() can use correct dma_ops. Otherwise, it will use default dma_ops which is nommu_dma_ops on x86_64 even when IOMMU is enabled and set to non passthrough mode. Signed-off-by:
-
- 31 Jul, 2019 3 commits
-
-
fengchunguo authored
88200 and 96000 sampling rate was not enabled on driver, so can't be played. The error information: max98373 3-0031：rate 96000 not supported max98373 3-0031：ASoC: can't set max98373-aif1 hw params: -22 Signed-off-by:
fengchunguo <chunguo.feng@amlogic.com> Link: https://lore.kernel.org/r/20190731074156.5620-1-chunguo.feng@amlogic.comSigned-off-by:
-
Marcus Cooper authored
The A64 audio codec uses the original I2S block but the SR and WSS computation currently assigned is for the newer block. Fixes: 619c15f7 (ASoC: sun4i-i2s: Change SR and WSS computation) Signed-off-by:
Marcus Cooper <codekipper@gmail.com> Link: https://lore.kernel.org/r/20190729152130.27955-1-codekipper@gmail.comSigned-off-by:
-
Cezary Rojewski authored
Adding myself to Intel ASoC drivers maintainers list. Signed-off-by:
Cezary Rojewski <cezary.rojewski@intel.com> Acked-by:
-
- 26 Jul, 2019 4 commits
-
-
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:
Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/20190726064244.3762-2-peter.ujfalusi@ti.comSigned-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:
-
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:
-
- 24 Jul, 2019 1 commit
-
-
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 2 commits
-
-
Kai Vehmanen authored
Downgrade "nothing to do in IRQ thread" message from error to a debug message in the IPC interrupt handler thread. The spurious wake-up can happen if a HDA stream interrupt is raised while the IPC interrupt thread is running. IPC functionality is not impacted by this condition, so debug is a more appropriate trace level. Signed-off-by:
Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by:
-
Stephan Gerhold authored
apq8016_sbc_parse_of() sets up multiple DAI links, depending on the number of nodes in the device tree. However, at the moment CPU and platform components are only allocated for the first link. This causes an oops when more than one link is defined: Internal error: Oops: 96000044 [#1] SMP CPU: 0 PID: 1015 Comm: kworker/0:2 Not tainted 5.3.0-rc1 #4 Call trace: apq8016_sbc_platform_probe+0x1a8/0x3f0 platform_drv_probe+0x50/0xa0 ... Move the allocation inside the loop to ensure that each link is properly initialized. Fixes: 98b232ca ("ASoC: qcom: apq8016_sbc: use modern dai_link style") Signed-off-by:
Stephan Gerhold <stephan@gerhold.net> Acked-by:
-
- 22 Jul, 2019 2 commits
-
-
Wenwen Wang authored
In snd_soc_dapm_new_control_unlocked(), a kernel buffer is allocated in dapm_cnew_widget() to hold the new dapm widget. Then, different actions are taken according to the id of the widget, i.e., 'w->id'. If any failure occurs during this process, snd_soc_dapm_new_control_unlocked() should be terminated by going to the 'request_failed' label. However, the allocated kernel buffer is not freed on this code path, leading to a memory leak bug. To fix the above issue, free the buffer before returning from snd_soc_dapm_new_control_unlocked() through the 'request_failed' label. Signed-off-by:
Wenwen Wang <wenwen@cs.uga.edu> Link: https://lore.kernel.org/r/1563803864-2809-1-git-send-email-wang6495@umn.eduSigned-off-by:
-
Masahiro Yamada authored
When CONFIG_UAPI_HEADER_TEST=y, exported headers are compile-tested to make sure they can be included from user-space. Currently, header.h and fw.h are excluded from the test coverage. To make them join the compile-test, we need to fix the build errors attached below. For a case like this, we decided to use __u{8,16,32,64} variable types in this discussion: https://lkml.org/lkml/2019/6/5/18 Build log: CC usr/include/sound/sof/header.h.s CC usr/include/sound/sof/fw.h.s In file included from <command-line>:32:0: ./usr/include/sound/sof/header.h:19:2: error: unknown type name ‘uint32_t’ uint32_t magic; /**< 'S', 'O', 'F', '\0' */ ^~~~~~~~ ./usr/include/sound/sof/header.h:20:2: error: unknown type name ‘uint32_t’ uint32_t type; /**< component specific type */ ^~~~~~~~ ./usr/include/sound/sof/header.h:21:2: error: unknown type name ‘uint32_t’ uint32_t size; /**< size in bytes of data excl. this struct */ ^~~~~~~~ ./usr/include/sound/sof/header.h:22:2: error: unknown type name ‘uint32_t’ uint32_t abi; /**< SOF ABI version */ ^~~~~~~~ ./usr/include/sound/sof/header.h:23:2: error: unknown type name ‘uint32_t’ uint32_t reserved[4]; /**< reserved for future use */ ^~~~~~~~ ./usr/include/sound/sof/header.h:24:2: error: unknown type name ‘uint32_t’ uint32_t data[0]; /**< Component data - opaque to core */ ^~~~~~~~ In file included from <command-line>:32:0: ./usr/include/sound/sof/fw.h:49:2: error: unknown type name ‘uint32_t’ uint32_t size; /* bytes minus this header */ ^~~~~~~~ ./usr/include/sound/sof/fw.h:50:2: error: unknown type name ‘uint32_t’ uint32_t offset; /* offset from base */ ^~~~~~~~ ./usr/include/sound/sof/fw.h:64:2: error: unknown type name ‘uint32_t’ uint32_t size; /* bytes minus this header */ ^~~~~~~~ ./usr/include/sound/sof/fw.h:65:2: error: unknown type name ‘uint32_t’ uint32_t num_blocks; /* number of blocks */ ^~~~~~~~ ./usr/include/sound/sof/fw.h:73:2: error: unknown type name ‘uint32_t’ uint32_t file_size; /* size of file minus this header */ ^~~~~~~~ ./usr/include/sound/sof/fw.h:74:2: error: unknown type name ‘uint32_t’ uint32_t num_modules; /* number of modules */ ^~~~~~~~ ./usr/include/sound/sof/fw.h:75:2: error: unknown type name ‘uint32_t’ uint32_t abi; /* version of header format */ ^~~~~~~~ Signed-off-by:Masahiro Yamada <yamada.masahiro@socionext.com> Link: https://lore.kernel.org/r/20190721142308.30306-1-yamada.masahiro@socionext.comSigned-off-by:
-
