- Alsa-devel - mailman.alsa-project.org

Re: [v4 13/18] ASoC: mediatek: mt8186: add platform driver
by Mark Brown 29 Apr '22

29 Apr '22

On Thu, Apr 28, 2022 at 05:33:50PM +0800, Jiaxin Yu wrote: > Add mt8186 platform and affiliated driver. > > Signed-off-by: Jiaxin Yu <jiaxin.yu(a)mediatek.com> > --- > sound/soc/mediatek/Kconfig | 44 + > sound/soc/mediatek/Makefile | 1 + > sound/soc/mediatek/mt8186/Makefile | 22 + > sound/soc/mediatek/mt8186/mt8186-afe-common.h | 235 ++ > .../soc/mediatek/mt8186/mt8186-afe-control.c | 261 ++ > sound/soc/mediatek/mt8186/mt8186-afe-pcm.c | 3005 +++++++++++++++++ > .../mediatek/mt8186/mt8186-interconnection.h | 69 + > .../soc/mediatek/mt8186/mt8186-misc-control.c | 294 ++ > .../mediatek/mt8186/mt8186-mt6366-common.c | 59 + > .../mediatek/mt8186/mt8186-mt6366-common.h | 17 + > sound/soc/mediatek/mt8186/mt8186-reg.h | 2913 ++++++++++++++++ > 11 files changed, 6920 insertions(+) This looks mostly good though it is enormous so I might've missed some things. The patch series is already very large but it might still be worth splitting this up a bit more, perhaps split the code and data tables/register definitions into separate patches? A few relatively minor issues with the controls. > +/* this order must match reg bit amp_div_ch1/2 */ > +static const char * const mt8186_sgen_amp_str[] = { > + "1/128", "1/64", "1/32", "1/16", "1/8", "1/4", "1/2", "1" }; > +static const char * const mt8186_sgen_mute_str[] = { > + "Off", "On" > +}; On/off controls should be normal Switch controls not enums so userspace can display things sensibly. > +static int mt8186_sgen_set(struct snd_kcontrol *kcontrol, > + struct snd_ctl_elem_value *ucontrol) > +{ > + struct snd_soc_component *cmpnt = snd_soc_kcontrol_component(kcontrol); > + struct mtk_base_afe *afe = snd_soc_component_get_drvdata(cmpnt); > + struct mt8186_afe_private *afe_priv = afe->platform_priv; > + struct soc_enum *e = (struct soc_enum *)kcontrol->private_value; > + int mode; > + int mode_idx; > + > + if (ucontrol->value.enumerated.item[0] >= e->items) > + return -EINVAL; ... > + 0x3f << INNER_LOOP_BACK_MODE_SFT); > + } > + > + afe_priv->sgen_mode = mode; > + > + return 0; > +} This should return 1 if the value is different from the previous value so event generation works, please run mixer-test against a system using the driver to help spot issues like this. The same issue applies to at least some of the other custom controls. > +static int mt8186_sgen_mute_set(struct snd_kcontrol *kcontrol, > + struct snd_ctl_elem_value *ucontrol) > +{ > + struct snd_soc_component *cmpnt = snd_soc_kcontrol_component(kcontrol); > + struct mtk_base_afe *afe = snd_soc_component_get_drvdata(cmpnt); > + struct soc_enum *e = (struct soc_enum *)kcontrol->private_value; > + int mute; > + > + if (ucontrol->value.enumerated.item[0] >= e->items) > + return -EINVAL; > + > + mute = ucontrol->value.integer.value[0]; > + > + dev_dbg(afe->dev, "%s(), kcontrol name %s, mute %d\n", > + __func__, kcontrol->id.name, mute); > + > + if (strcmp(kcontrol->id.name, SGEN_MUTE_CH1_KCONTROL_NAME) == 0) { > + regmap_update_bits(afe->regmap, AFE_SINEGEN_CON0, > + MUTE_SW_CH1_MASK_SFT, > + mute << MUTE_SW_CH1_SFT); > + } else { > + regmap_update_bits(afe->regmap, AFE_SINEGEN_CON0, > + MUTE_SW_CH2_MASK_SFT, > + mute << MUTE_SW_CH2_SFT); > + } > + > + return 0; > +} I can't tell why some of these are done with custom code rather than using a normal SOC_SINGLE()?

2 1

[PATCH 0/2] Let userspace know when snd-hda-intel needs i915
by Mauro Carvalho Chehab 29 Apr '22

29 Apr '22

Currently, kernel/module annotates module dependencies when request_symbol is used, but it doesn't cover more complex inter-driver dependencies that are subsystem and/or driver-specific. In the case of hdmi sound, depending on the CPU/GPU, sometimes the snd_hda_driver can talk directly with the hardware, but sometimes, it uses the i915 driver. When the snd_hda_driver uses i915, it should first be unbind/rmmod, as otherwise trying to unbind/rmmod the i915 driver cause driver issues, as as reported by CI tools with different GPU models: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_6415/fi-tgl-1115g4/igt@core_ho… https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11495/bat-adlm-1/igt@i915_m… In the past, just a few CPUs were doing such bindings, but this issue now applies to all "modern" Intel CPUs that have onboard graphics, as well as to the newer discrete GPUs. With the discrete GPU case, the HDA controller is physically separate and requires i915 to power on the hardware for all hardware access. In this case, the issue is hit basicly 100% of the time. With on-board graphics, i915 driver is needed only when the display codec is accessed. If i915 is unbind during runtime suspend, while snd-hda-intel is still bound, nothing bad happens, but unbinding i915 on other situations may also cause issues. So, add support at kernel/modules to allow snd-hda drivers to properly annotate when a dependency on a DRM driver dependencies exists, and add a call to such new function at the snd-hda driver when it successfully binds into the DRM driver. This would allow userspace tools to check and properly remove the audio driver before trying to remove or unbind the GPU driver. It should be noticed that this series conveys the hidden module dependencies. Other changes are needed in order to allow removing or unbinding the i915 driver while keeping the snd-hda-intel driver loaded/bound. With that regards, there are some discussions on how to improve this at alsa-devel a while back: https://mailman.alsa-project.org/pipermail/alsa-devel/2021-September/190099… So, future improvements on both in i915 and the audio drivers could be made. E.g. with discrete GPUs, it's the only codec of the card, so it seems feasible to detach the ALSA card if i915 is bound (using infra made for VGA switcheroo), but, until these improvements are done and land in upstream, audio drivers needs to be unbound if i915 driver goes unbind. Yet, even if such fixes got merged, this series is still needed, as it makes such dependencies more explicit and easier to debug. PS.: This series was generated against next-20220428. Luis/Takashi/Daniel/David, If OK for you, I would prefer to have such patches applied via the drm-tip tree once reviewed, in order to make easier to use them by some patches I'm preparing to improve the CI tests that use i915 unbind logic. Mauro Carvalho Chehab (2): module: add a function to add module references ALSA: hda - identify when audio is provided by a video driver include/linux/module.h | 7 +++++++ kernel/module/main.c | 31 +++++++++++++++++++++++++++++++ sound/hda/hdac_component.c | 8 ++++++++ 3 files changed, 46 insertions(+) -- 2.35.1

1 1

conf: Use LFS calls when reading config files
by GitHub pull_request - opened 29 Apr '22

29 Apr '22

alsa-project/alsa-lib pull request #223 was opened from dos1: Although at first glance it doesn't seem useful to support config files larger than 2GB, LFS also influences inode size. Without this, 32-bit libasound may be unable to read config files on filesystems with 64-bit inodes, such as Btrfs or NFS. Signed-off-by: Sebastian Krzyszkowiak <dos(a)dosowisko.net> Request URL : https://github.com/alsa-project/alsa-lib/pull/223 Patch URL : https://github.com/alsa-project/alsa-lib/pull/223.patch Repository URL: https://github.com/alsa-project/alsa-lib

1 0

Re: [PATCH] ASoC: wm8960: Add ACPI support
by Mark Brown 28 Apr '22

28 Apr '22

On Wed, 27 Apr 2022 22:29:16 +0100, Nicola Lunghi wrote: > HID made of either Wolfson/CirrusLogic PCI ID + 8960 identifier > > This helps enumerate the Waveshare WM8960 WM8960 Hi-Fi Sound > Card HAT on the Up2 platform. > > The scripts at https://github.com/thesofproject/acpi-scripts > can be used to add the ACPI initrd overlay. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: wm8960: Add ACPI support commit: 7e0bdbae446ff8a752484f6bcbcd7157e7484158 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark

1 0

pcm: dmix: fix wrong scaling in 32bits pcm mixing
by GitHub pull_request - edited 28 Apr '22

28 Apr '22

alsa-project/alsa-lib pull request #222 was edited from katsuster: Generic mixing function for 32bits pcm has used 8bits right shift for pre-scaling. But this is generating wrong result if pcm data is negative value because return value type of bswap_32() is unsigned int. This patch adds type cast bswap_32() result to signed int. Request URL : https://github.com/alsa-project/alsa-lib/pull/222 Patch URL : https://github.com/alsa-project/alsa-lib/pull/222.patch Repository URL: https://github.com/alsa-project/alsa-lib

1 0

pcm: dmix: fix wrong scaling in 32bits pcm mixing
by GitHub pull_request - opened 28 Apr '22

28 Apr '22

alsa-project/alsa-lib pull request #222 was opened from katsuster: Generic mixing function for 32bits pcm has used 8bits right shift for pre-scaling. But this is generating wrong result if pcm data is negative value because return value type of bswap_32() is unsigned int. This patch adds type cast bswap_32() result to signed int. Signed-off-by: Katsuhiro Suzuki <katsuhiro(a)katsuster.net> Request URL : https://github.com/alsa-project/alsa-lib/pull/222 Patch URL : https://github.com/alsa-project/alsa-lib/pull/222.patch Repository URL: https://github.com/alsa-project/alsa-lib

1 0

Play jitter coming from dshare
by GitHub issues - edited 28 Apr '22

28 Apr '22

alsa-project/alsa-lib issue #221 was edited from davidboulangerlatour: I have an application which plays a wav file (using dshare) at with a specific period (ie. every 720ms). This always worked well up to recently after upgrading alsa-lib from 1.1.7 to 1.2.4. With 1.2.4, the cycles look like this [750ms, 750ms, 750ms, 625ms], normally it would be [720ms, 720ms, ...]. When doing a bisect to find the issue, I found this commit to be the cause: ``` 7265e603bf880a9ec2cd01c3cf2afbd7709e5af4 is the first bad commit commit 7265e603bf880a9ec2cd01c3cf2afbd7709e5af4 Author: Vanitha Channaiah <vanitha.channaiah(a)in.bosch.com> Date: Wed May 15 11:56:33 2019 +0530 pcm: dshare: Added "hw_ptr_alignment" option in configuration for alignment of slave pointers This change adapt the fix commit 6b058fda9dce ("pcm: dmix: Add option to allow alignment of slave pointers") for dshare plugin Issue is that snd_pcm_wait() goes back to waiting because the hw_ptr is not period aligned. Therefore snd_pcm_wait() will block for a longer time as required. With these rcar driver changes the exact position of the dma is returned. During snd_pcm_start they read hw_ptr as reference, and this hw_ptr is now not period aligned, and is a little ahead over the period while it is read. Therefore when the avail is calculated during snd_pcm_wait(), it is missing the avail_min by a few frames. An additional option hw_ptr_alignment is provided to dshare configuration, to allow the user to configure the slave application and hw pointer alignment at startup Signed-off-by: Vanitha Channaiah <vanitha.channaiah(a)in.bosch.com> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> src/pcm/pcm_dshare.c | 40 +++++++++++++++++++++++++++++++++++----- 1 file changed, 35 insertions(+), 5 deletions(-) ``` I tried the more recent 1.2.6 with the same issue. I also tried all the "hw_ptr_alignment" options with no success. cc @VanithaChannaiah @tiwai Issue URL : https://github.com/alsa-project/alsa-lib/issues/221 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

Play jitter coming from dshare
by GitHub issues - opened 28 Apr '22

28 Apr '22

alsa-project/alsa-lib issue #221 was opened from davidboulangerlatour: I have an application which plays a wav file (using dshare) at with a specific period (ie. every 720ms). This always worked well up to recently after upgrading alsa-lib from 1.1.7 to 1.2.4. With 1.2.4, the cycles look like this [750ms, 750ms, 750ms, 625ms], normally it would be [720ms, 720ms, ...]. When doing a bisect to find the issue, I found this commit to be the cause: ``` 7265e603bf880a9ec2cd01c3cf2afbd7709e5af4 is the first bad commit commit 7265e603bf880a9ec2cd01c3cf2afbd7709e5af4 Author: Vanitha Channaiah <vanitha.channaiah(a)in.bosch.com> Date: Wed May 15 11:56:33 2019 +0530 pcm: dshare: Added "hw_ptr_alignment" option in configuration for alignment of slave pointers This change adapt the fix commit 6b058fda9dce ("pcm: dmix: Add option to allow alignment of slave pointers") for dshare plugin Issue is that snd_pcm_wait() goes back to waiting because the hw_ptr is not period aligned. Therefore snd_pcm_wait() will block for a longer time as required. With these rcar driver changes the exact position of the dma is returned. During snd_pcm_start they read hw_ptr as reference, and this hw_ptr is now not period aligned, and is a little ahead over the period while it is read. Therefore when the avail is calculated during snd_pcm_wait(), it is missing the avail_min by a few frames. An additional option hw_ptr_alignment is provided to dshare configuration, to allow the user to configure the slave application and hw pointer alignment at startup Signed-off-by: Vanitha Channaiah <vanitha.channaiah(a)in.bosch.com> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> src/pcm/pcm_dshare.c | 40 +++++++++++++++++++++++++++++++++++----- 1 file changed, 35 insertions(+), 5 deletions(-) ``` I tried the more recent 1.2.6 with the same issue. I also tried all the "hw_ptr_alignment" options with no success. Issue URL : https://github.com/alsa-project/alsa-lib/issues/221 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

[PATCH] ASoC: Intel: bytcr_rt5640: Add quirk for the HP Pro Tablet 408
by Hans de Goede 28 Apr '22

28 Apr '22

Add a quirk for the HP Pro Tablet 408, this BYTCR tablet has no CHAN package in its ACPI tables and uses SSP0-AIF1 rather then SSP0-AIF2 which is the default for BYTCR devices. It also uses DMIC1 for the internal mic rather then the default IN3 and it uses JD2 rather then the default JD1 for jack-detect. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=211485 Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- sound/soc/intel/boards/bytcr_rt5640.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/sound/soc/intel/boards/bytcr_rt5640.c b/sound/soc/intel/boards/bytcr_rt5640.c index d76a505052fb..f81ae742faa7 100644 --- a/sound/soc/intel/boards/bytcr_rt5640.c +++ b/sound/soc/intel/boards/bytcr_rt5640.c @@ -773,6 +773,18 @@ static const struct dmi_system_id byt_rt5640_quirk_table[] = { BYT_RT5640_OVCD_SF_0P75 | BYT_RT5640_MCLK_EN), }, + { /* HP Pro Tablet 408 */ + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"), + DMI_MATCH(DMI_PRODUCT_NAME, "HP Pro Tablet 408"), + }, + .driver_data = (void *)(BYT_RT5640_DMIC1_MAP | + BYT_RT5640_JD_SRC_JD2_IN4N | + BYT_RT5640_OVCD_TH_1500UA | + BYT_RT5640_OVCD_SF_0P75 | + BYT_RT5640_SSP0_AIF1 | + BYT_RT5640_MCLK_EN), + }, { /* HP Stream 7 */ .matches = { DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"), -- 2.36.0

3 2

WM8962 crashing on suspend
by Adam Ford 28 Apr '22

28 Apr '22

I have an imx8m Mini with a wm8962 codec. If I run a speaker test and suspend the board while the speaker test is running, I get the following upon wake: wm8962 3-001a: ASoC: error at soc_component_read_no_lock on wm8962.3-001a: -16 This message repeats itself over and over again. If I attempt to use any audio, it fails until I reboot the board. If I run the audio test, then exit and suspend, the audio works upon resume, so it appears to be related to suspending while running. I am hoping someone might have a suggestion as to what I might be able to do or try to allow this to successfully suspend and resume if the device is playing sound. thank you, adam

3 13