- 12 Aug, 2021 25 commits
-
-
Stefan Binding authored
Since delays when starting jack detection after initialization have been reduced/removed, it is necessary to add back in an extra 20ms delay after the init sequence to allow the CS42L42 to power up correctly. Signed-off-by:
Stefan Binding <sbinding@opensource.cirrus.com> Signed-off-by:
Vitaly Rodionov <vitalyr@opensource.cirrus.com> Link: https://lore.kernel.org/r/20210811185654.6837-26-vitalyr@opensource.cirrus.comSigned-off-by:
Takashi Iwai <tiwai@suse.de>
-
Stefan Binding authored
Signed-off-by:
-
Stefan Binding authored
CS42L42 is configured to use a fixed sample rate of 48kHz. Signed-off-by:
-
Stefan Binding authored
Headphones codec will keep reduced maximum volume. Line Out codec will have increased maximum volume. Signed-off-by:
-
Lucas Tanure authored
Dolphin devices have CS8409 HDA Bridge connected to two CS42L42 codecs. Codec 1 supports Headphone and Headset Mic. Codec 2 supports Line Out. Features: - Front and Read Jacks appear as separate jacks; Removal or connection of on jack should not affect the connection of the other. - Front Jack only shows up on jack detection. - Rear Jack is Phantom Jack. - Separate Volume Controls for each Jack Signed-off-by:
Lucas Tanure <tanureal@opensource.cirrus.com> Signed-off-by:
-
Stefan Binding authored
Some hardware configurations do not support jack type detection. Instead, for those configurations, only tip detection is supported. Signed-off-by:
-
Stefan Binding authored
Signed-off-by:
-
Lucas Tanure authored
To accommodate move, cs42l42_resume has been added to mirror the existing function cs42l42_suspend. Function cs42l42_reset is no longer required, since cs42l42_resume and cs42l42_suspend perform the same operations. Signed-off-by:
-
Lucas Tanure authored
Signed-off-by:
-
Lucas Tanure authored
This allows mutex locks to be moved into i2c functions, as the bulk read/write functions can lock/unlock themselves to prevent interruption of sequence reads/writes. Signed-off-by:
-
Lucas Tanure authored
Signed-off-by:
-
Lucas Tanure authored
Signed-off-by:
-
Lucas Tanure authored
Only disable I2C clock 25 ms after not being used. The current implementation enables and disables the I2C clock for each I2C transaction. Each enable/disable call requires two verb transactions. This means each I2C transaction requires a total of four verb transactions to enable and disable the clock. However, if there are multiple consecutive I2C transactions, it is not necessary to enable and disable the clock each time, instead it is more efficient to enable the clock for the first transaction, and disable it after the final transaction, which would improve performance. This is achieved by using a timeout which disables the clock if no request to enable the clock has occurred for 25 ms. Signed-off-by:
-
Lucas Tanure authored
Use amp offsets as indexes for saved volumes. Remove dependencies on NID inside volume control functions. Signed-off-by:
-
Lucas Tanure authored
Signed-off-by:
-
Stefan Binding authored
Cleanup interrupt masks. Remove unnecessary read/writes. Ensure Tip Sense/Type Detection interrupts are enabled/disabled when needed. Signed-off-by:
-
Stefan Binding authored
Wake events are not needed for jack detect. Signed-off-by:
-
Lucas Tanure authored
The subsequence suspend and remuse have their enable/disable unsolicited responses at the correct place already Signed-off-by:
-
Stefan Binding authored
Ensure unsolicited responses cannot occur whilst the sub codecs are being disabled. Signed-off-by:
-
Stefan Binding authored
Also remove unnecessary repeated register writes. Signed-off-by:
-
Stefan Binding authored
Enable HSBIAS_SENSE_EN for Cyborg during jack detect to reduce pops and clicks. Do not enable this for Warlock/Bullseye, as it causes ESD issues. Signed-off-by:
-
Stefan Binding authored
Signed-off-by:
-
Stefan Binding authored
Signed-off-by:
-
Lucas Tanure authored
Signed-off-by:
-
Lucas Tanure authored
Signed-off-by:
-
- 09 Aug, 2021 7 commits
-
-
Takashi Iwai authored
The old ISA MSND driver basically maps the iomem as the DMA buffer. For this type of buffer, we have already the standard mmap helper, snd_pcm_lib_mmap_iomem(). Correct the PCM info, set the DMA address and use the standard helper for handling the mmap on all architectures properly. Link: https://lore.kernel.org/r/20210809140532.11006-1-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
CS46xx driver switches the buffer depending on the number of periods, and in some cases it switches to the own buffer without updating the buffer type properly. This may cause a problem with the mmap on exotic architectures that require the own mmap call for the coherent DMA buffer. This patch addresses the potential breakage by replacing the buffer setup with the proper macro. It also simplifies the source code, too. Link: https://lore.kernel.org/r/20210809071829.22238-4-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
Although the regression of the mmap was fixed in the recent commit dc0dc8a7 ("ALSA: pcm: Fix mmap breakage without explicit buffer setup"), RME9652 and HDSP drivers have still potential issues with their mmap handling. Namely, they use the default mmap handler without the standard buffer preallocation, and PCM core wouldn't use the coherent DMA mapping. It's practically OK on x86, but on some exotic architectures, it wouldn't work. This patch addresses the potential breakage by replacing the buffer setup with the proper macro. It also simplifies the source code, too. Link: https://lore.kernel.org/r/20210809071829.22238-3-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
Currently we check only the substream->dma_buffer as the preset of the buffer configuration for verifying the availability of mmap. But a few drivers rather set up the buffer in the own way without the standard buffer preallocation using substream->dma_buffer, and they miss the proper checks. (Now it's working more or less fine as most of them are running only on x86). Actually, they may set up the runtime dma_buffer (referred via snd_pcm_get_dma_buf()) at the open callback, though. That is, this could have been used as the primary source. This patch changes the hw_support_mmap() function to check the runtime dma buffer at first. It's usually NULL with the standard buffer preallocation, and in that case, we continue checking substream->dma_buffer as fallback. Link: https://lore.kernel.org/r/20210809071829.22238-2-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
Harmony driver never uses CONTINUOUS buffer type any longer, hence the code setting the address is superfluous. Moreover, the recent change in the ALSA core already covered the missing address field; it's already set up. So let's drop the superfluous line, which includes the full hw_params callback. Link: https://lore.kernel.org/r/20210809071250.21846-1-tiwai@suse.deSigned-off-by:
-
Takashi Iwai authored
-
Takashi Iwai authored
The recent fix c4824ae7 ("ALSA: pcm: Fix mmap capability check") restricts the mmap capability only to the drivers that properly set up the buffers, but it caused a regression for a few drivers that manage the buffer on its own way. For those with UNKNOWN buffer type (i.e. the uninitialized / unused substream->dma_buffer), just assume that the driver handles the mmap properly and blindly trust the hardware info bit. Fixes: c4824ae7 ("ALSA: pcm: Fix mmap capability check") Reported-and-tested-by:
Jeff Woods <jwoods@fnordco.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/s5him0gpghv.wl-tiwai@suse.deSigned-off-by:
-
- 08 Aug, 2021 1 commit
-
-
Takashi Iwai authored
The code refactoring to move the WC page handling into the common memalloc layer caused a breakage for HD-audio HDMI. I overlooked that the driver is using the SG-buffer, which isn't covered by the patch. This patch adds the mmap workaround for WC pages to SG-buffer handler. A caveat is that it falls back to the default handler by returning an error after setting the pgprot, so it won't work in all cases but merely for PCM (which is currently the only use case). Fixes: 623c1010 ("ALSA: memalloc: Fix pgprot for WC mmap on x86") Reported-and-tested-by:
Andy Lavr <andy.lavr@gmail.com> Link: https://lore.kernel.org/r/20210808080034.20337-1-tiwai@suse.deSigned-off-by:
-
- 07 Aug, 2021 1 commit
-
-
Luke D Jones authored
The ASUS GV301QH sound appears to work well with the quirk for ALC294_FIXUP_ASUS_DUAL_SPK. Signed-off-by:
Luke D Jones <luke@ljones.dev> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210807025805.27321-1-luke@ljones.devSigned-off-by:
-
- 06 Aug, 2021 1 commit
-
-
Takashi Iwai authored
Merge tag 'asoc-fix-v5.14-rc4' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v5.14 Quite a lot of fixes here, the biggest set being for the cs42l42 driver which is reasonably old but has seen a sudden uptick in activity. There's also some fixes for correctly referencing PCM buffer addresses and the removal of some driver-local bodges that had been done for the lack of prefix handling in DAPM which were broken by the core handling that as expected.
-
- 05 Aug, 2021 5 commits
-
-
Richard Fitzgerald authored
I2S always has two LRCLK phases and both CH1 and CH2 of the RX must be enabled (corresponding to the low and high phases of LRCLK.) The selection of the valid data channels is done by setting the DAC CHA_SEL and CHB_SEL. CHA_SEL is always the first (left) channel, CHB_SEL depends on the number of active channels. Previously for mono ASP CH2 was not enabled, the result was playing mono data would not produce any audio output. Signed-off-by:
Richard Fitzgerald <rf@opensource.cirrus.com> Fixes: 621d65f3 ("ASoC: cs42l42: Provide finer control on playback path") Link: https://lore.kernel.org/r/20210805161111.10410-4-rf@opensource.cirrus.comSigned-off-by:
Mark Brown <broonie@kernel.org>
-
Richard Fitzgerald authored
The lowest valid SCLK corresponds to 44.1 kHz at 16-bit. Sample rates less than this would produce SCLK below the minimum when using a normal I2S frame. A constraint must be applied to prevent this. The constraint is not applied if the machine driver sets SCLK, to allow setups where the host generates additional bits per LRCLK phase to increase the SCLK frequency. In these cases the machine driver would always have to inform this driver of the actual SCLK, and it must select a legal SCLK. Signed-off-by:
-
Richard Fitzgerald authored
An I2S frame starts on the falling edge of LRCLK so ASP_STP must be 0. At the same time, move other format settings in the same register from cs42l42_pll_config() to cs42l42_set_dai_fmt() where you'd expect to find them, and merge into a single write. Signed-off-by:
-
Richard Fitzgerald authored
Both SCLK and PLL clocks must be running to drive the glitch-free mux behind MCLK_SRC_SEL and complete the switchover. This patch moves the writing of MCLK_SRC_SEL to when the PLL is started and stopped, so that it only transitions while the PLL is running. The unconditional write MCLK_SRC_SEL=0 in cs42l42_mute_stream() is safe because if the PLL is not running MCLK_SRC_SEL is already 0. Signed-off-by:
-
Takashi Iwai authored
The recent refactoring of es1688 object creation with the use of devres caused a problem with the non-PnP probe of GUS driver, as it tries to probe multiple times with different parameters That is, this object needs the immediate resource release and the devres doesn't fit for it. This patch reverts partially the commit for restoring the classic resource management for es1688 object. Fixes: 1bb11c1c ("ALSA: es1688: Allocate resources with device-managed APIs") Reported-by:
kernel test robot <oliver.sang@intel.com> Link: https://lore.kernel.org/r/20210805032513.GA30485@xsang-OptiPlex-9020 Link: https://lore.kernel.org/r/20210805062148.30951-1-tiwai@suse.deSigned-off-by:
-
