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

[PATCH] ALSA: hda: Fix discovery of i915 graphics PCI device
by Takashi Iwai 21 Jun '22

21 Jun '22

It's been reported that the recent fix for skipping the component-binding with D-GPU caused a regression on some systems; it resulted in the completely missing component binding with i915 GPU. The problem was the use of pci_get_class() function. It matches with the full PCI class bits, while we want to match only partially the PCI base class bits. So, when a system has an i915 graphics device with the PCI class 0380, it won't hit because we're looking for only the PCI class 0300. This patch fixes i915_gfx_present() to look up each PCI device and match with PCI base class explicitly instead of pci_get_class(). Fixes: c9db8a30d9f0 ("ALSA: hda/i915 - skip acomp init if no matching display") Reviewed-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> Tested-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> Cc: <stable(a)vger.kernel.org> Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1200611 Link: https://lore.kernel.org/r/87bkunztec.wl-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/hda/hdac_i915.c | 15 ++++++--------- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/sound/hda/hdac_i915.c b/sound/hda/hdac_i915.c index 3f35972e1cf7..161a9711cd63 100644 --- a/sound/hda/hdac_i915.c +++ b/sound/hda/hdac_i915.c @@ -119,21 +119,18 @@ static int i915_component_master_match(struct device *dev, int subcomponent, /* check whether Intel graphics is present and reachable */ static int i915_gfx_present(struct pci_dev *hdac_pci) { - unsigned int class = PCI_BASE_CLASS_DISPLAY << 16; struct pci_dev *display_dev = NULL; - bool match = false; - do { - display_dev = pci_get_class(class, display_dev); - - if (display_dev && display_dev->vendor == PCI_VENDOR_ID_INTEL && + for_each_pci_dev(display_dev) { + if (display_dev->vendor == PCI_VENDOR_ID_INTEL && + (display_dev->class >> 16) == PCI_BASE_CLASS_DISPLAY && connectivity_check(display_dev, hdac_pci)) { pci_dev_put(display_dev); - match = true; + return true; } - } while (!match && display_dev); + } - return match; + return false; } /** -- 2.35.3

1 0

[PATCH 0/3] ASoC: sun50i-codec-analog: Internal bias support
by Samuel Holland 21 Jun '22

21 Jun '22

This series adds support for enabling the codec's internal microphone bias, which is needed on at least some versions of the PinePhone. Arnaud Ferraris (2): ASoC: dt-bindings: sun50i-codec: Add binding for internal bias ASoC: sun50i-codec-analog: Add support for internal bias Samuel Holland (1): arm64: dts: allwinner: pinephone: Enable internal HMIC bias .../allwinner,sun50i-a64-codec-analog.yaml | 5 ++++ .../allwinner/sun50i-a64-pinephone-1.0.dts | 4 +++ .../allwinner/sun50i-a64-pinephone-1.1.dts | 4 +++ sound/soc/sunxi/sun50i-codec-analog.c | 29 +++++++++++++++++++ 4 files changed, 42 insertions(+) -- 2.35.1

2 5

[PATCH 00/10] timer: rename tstamp methods with the word real_time
by GitHub pull_request - opened 21 Jun '22

21 Jun '22

alsa-project/alsa-gobject pull request #78 was opened from takaswie: In ALSATimer library some methods are named with the word `tstamp`. On the other hand, in ALSASeq library the similar methods are named with the word `real_time`. For consistency, this patchset renames methods in ALSATimer library. As a result, the word `tstamp` is not used at all. ``` Takashi Sakamoto (10): utils: successfully parse the string teminated by '\n' timer: move ALSATimer.TickEvent files for future rename timer: move ALSATimer.TstampEvent files for future rename timer: tick-time-event: rename boxed structure timer: real-time-event: rename boxed structure timer: enums: rename to ALSATimer.EventType.TICK_TIME and REAL_TIME timer: enums: rename to ALSATimer.RealTimeEventType timer: instance-status: rename method with real time timer: query: rename to ALSATimer.get_real_time_clock_id() seq: event: fix description about methods relevant to time stamp samples/timer | 26 +++---- src/seq/event.c | 16 ++-- src/timer/alsatimer-enum-types.h | 74 +++++++++---------- src/timer/alsatimer.h | 4 +- src/timer/alsatimer.map | 20 ++--- src/timer/instance-params.c | 20 ++--- src/timer/instance-params.h | 4 +- src/timer/instance-status.c | 22 +++--- src/timer/instance-status.h | 3 +- src/timer/meson.build | 8 +- src/timer/query.c | 16 ++-- src/timer/query.h | 2 +- src/timer/real-time-event.c | 65 ++++++++++++++++ src/timer/real-time-event.h | 25 +++++++ src/timer/tick-event.c | 51 ------------- src/timer/tick-event.h | 23 ------ src/timer/tick-time-event.c | 50 +++++++++++++ src/timer/tick-time-event.h | 22 ++++++ src/timer/tstamp-event.c | 64 ---------------- src/timer/tstamp-event.h | 24 ------ src/timer/user-instance.c | 56 +++++++------- src/timer/user-instance.h | 17 +++-- src/utils/string.c | 2 +- tests/alsatimer-enums | 8 +- tests/alsatimer-functions | 2 +- tests/alsatimer-instance-status | 2 +- ...tstamp-event => alsatimer-real-time-event} | 4 +- ...r-tick-event => alsatimer-tick-time-event} | 4 +- tests/alsatimer-user-instance | 8 +- tests/meson.build | 4 +- 30 files changed, 324 insertions(+), 322 deletions(-) create mode 100644 src/timer/real-time-event.c create mode 100644 src/timer/real-time-event.h delete mode 100644 src/timer/tick-event.c delete mode 100644 src/timer/tick-event.h create mode 100644 src/timer/tick-time-event.c create mode 100644 src/timer/tick-time-event.h delete mode 100644 src/timer/tstamp-event.c delete mode 100644 src/timer/tstamp-event.h rename tests/{alsatimer-tstamp-event => alsatimer-real-time-event} (84%) rename tests/{alsatimer-tick-event => alsatimer-tick-time-event} (83%) ``` Request URL : https://github.com/alsa-project/alsa-gobject/pull/78 Patch URL : https://github.com/alsa-project/alsa-gobject/pull/78.patch Repository URL: https://github.com/alsa-project/alsa-gobject

1 0

GoXLR Broken in 1.2.7.1
by GitHub issues - opened 21 Jun '22

21 Jun '22

alsa-project/alsa-ucm-conf issue #175 was opened from FrostyCoolSlug: The alsa profiles no longer set correctly for the GoXLR or GoXLR Mini since 5dcd69. >From what I can tell with some quick tests, if the DirectCardName isn't set, the profile doesn't seem to apply anymore. Removing the direct config, or adding a DirectCardName seems to solve the issue (although obviously, neither are ideal). Thanks. Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/175 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

[PATCH v5 00/14] ALSA: hda: cirrus: Add initial DSP support and firmware loading
by Vitaly Rodionov 21 Jun '22

21 Jun '22

The CS35L41 Amplifier contains a DSP, capable of running firmware. The firmware can run algorithms such as Speaker Protection, to ensure that playback at high gains do not harm the speakers. Adding support for CS35L41 firmware into the CS35L41 HDA driver also allows us to support several extra features, such as hiberation and interrupts. The chain adds support in stages: - General fixes to improve generalization and code re-use inside the CS35L41 HDA driver. - Add support for interrupts into the driver, which is required for complete support of the firmware. - Refactor ASoC CS35L41 code which deals with firmware to allow for code re-use inside the CS35L41 HDA driver. - Add support for loading firmware and tuning files from file system, and creating alsa controls to control it. - Support firmware load paths for different hardware systems. - Support suspend/resume in the driver when using firmware. The firmware supports hibernation, which allows the CS35L41 to drop into a low power mode during suspend. - Support the ability to unload firmware, swap and reload the firmware. This is to allow different firmware to run during calibration. The intended use-case is to load the firmware once on boot, and the driver autmatically tries to load the firmware after it binds to the HDA driver. This behaviour can be switched off using a kconfig, if desired. changes since v4: - Fully remove tlv remnants from control add apis - Remove unnecessary debug - Rename variable to be more generic - Remove redundent length check from read/write control apis - Use SNDRV_CTL_ELEM_IFACE_CARD for firmware load controls - Make kcontrol add/remove synchronous - Load firmware asynchronous when loading via control - Used cached controls when reloading firmware; only delete controls when removing the driver itself - Improve kcontrol remove - Fix control write + notify - Cleanup of unnecessary code - Fix race condition when loading firmware before playback - Ensure errors are properly propogated - Fix include for Module parameters Stefan Binding (13): ALSA: hda: hda_cs_dsp_ctl: Add Library to support CS_DSP ALSA controls ALSA: hda: hda_cs_dsp_ctl: Add apis to write the controls directly ALSA: hda: cs35l41: Save codec object inside component struct ALSA: hda: cs35l41: Save Subsystem ID inside CS35L41 Driver ALSA: hda: cs35l41: Support reading subsystem id from ACPI ALSA: hda: cs35l41: Support multiple load paths for firmware ALSA: hda: cs35l41: Support Speaker ID for laptops ALSA: hda: cs35l41: Support Hibernation during Suspend ALSA: hda: cs35l41: Read Speaker Calibration data from UEFI variables ALSA: hda: hda_cs_dsp_ctl: Add fw id strings ALSA: hda: cs35l41: Add defaulted values into dsp bypass config sequence ALSA: hda: cs35l41: Support Firmware switching and reloading ALSA: hda: cs35l41: Add module parameter to control firmware load Vitaly Rodionov (1): ALSA: hda: cs35l41: Add initial DSP support and firmware loading MAINTAINERS | 1 + include/sound/cs35l41.h | 4 + sound/pci/hda/Kconfig | 8 + sound/pci/hda/Makefile | 2 + sound/pci/hda/cs35l41_hda.c | 902 +++++++++++++++++++++++++++++++- sound/pci/hda/cs35l41_hda.h | 39 ++ sound/pci/hda/cs35l41_hda_i2c.c | 1 + sound/pci/hda/cs35l41_hda_spi.c | 1 + sound/pci/hda/hda_component.h | 4 + sound/pci/hda/hda_cs_dsp_ctl.c | 254 +++++++++ sound/pci/hda/hda_cs_dsp_ctl.h | 39 ++ sound/pci/hda/patch_realtek.c | 27 +- 12 files changed, 1277 insertions(+), 5 deletions(-) create mode 100644 sound/pci/hda/hda_cs_dsp_ctl.c create mode 100644 sound/pci/hda/hda_cs_dsp_ctl.h -- 2.34.1

2 15

Enabling fsl_sai MCLK before codec probe
by Michael Welling 20 Jun '22

20 Jun '22

So I have a tricky race condition that comes up with hardware that combines imx8 with a pcm1681 codec. The pcm1681 requires that MCLK be enabled for 65536 cycles before accessing the I2C management port. The imx8 sai driver on the other hand does not start the built in MCLK until a confluence of events that is not triggered until just before streaming starts which is too late. Is there a clean way to start the imx8 sai MCLK before the codec probe occurs? Or have it started and delayed during the codec probe before it tries to access i2c? We have a working solution but it is a bit overreaching and adds a callback function to the snd_soc_dai_ops struct to start the clock, and adds the code to the fsl_sai.c to toggle the appropriate bits in the SoC sai driver to make a clock appear and registers to the new function callback. Then the simple-card was amended to add the appropriate enabling through the new callback such that the clock is on long enough before the codec is probed. There was some suggestion of caching the i2c registers until the clock is enabled but this would be difficult given the clock is not started until streaming starts and we don't want to stream until the codec is initialized. I am looking for a solution that is minimal and robust. Any pointers would be greatly appreciated.

1 1

Re: [PATCH 4/4] ASoC: wm8904: add DMIC support
by Pierluigi Passaro 20 Jun '22

20 Jun '22

> > Just for my understanding, are you suggesting to set a device tree > > property to force a fixed behavior in the driver ? > Yes. Why should we use a fixed behavior ? > > WM8904 allows using both a DMIC and LINEIN, switching between one or > > the other and this is how we currently use it. > > Why the user should not be allowed to switch between DMIC and LINEIN ? > The device shares pins between the line inputs and the DMIC inputs so at > least some of the configuration is going to be determinted at system > design time, that will fix the usable values of at least one of the > controls which ought to be reflected in the runtime behaviour. In our design we use: - pin 1: DMIC_CLK - pin 24: LINEIN2R - pin 26: LINEIN2L - pin 27: DMIC_DATA we have no pins shared among DMIC and LINEIN. We have several customer switching between DMIC and LINEIN at runtime. > Please fix your mail client to word wrap within paragraphs at something > substantially less than 80 columns. Doing this makes your messages much > easier to read and reply to. I beg your pardon: it should be fixed now.

2 1

Re: [PATCH 4/4] ASoC: wm8904: add DMIC support
by Pierluigi Passaro 20 Jun '22

20 Jun '22

> > > Via firmware description. > > Can you please provide any reference approach in the kernel code ? > git grep of_ > git grep fwnode_ > and I don't immediately remember what the prefix is for ACPI functions. Just for my understanding, are you suggesting to set a device tree property to force a fixed behavior in the driver ? WM8904 allows using both a DMIC and LINEIN, switching between one or the other and this is how we currently use it. Why the user should not be allowed to switch between DMIC and LINEIN ?

2 1

Re: [PATCH 3/4] ASoC: wm8904: extend device tree support
by Pierluigi Passaro 20 Jun '22

20 Jun '22

Hi All, > > + - num-drc-cfgs: Number of available DRC modes from drc-cfg-regs property > > + > > + - drc-cfg-regs: Default registers value for R40/41/42/43 (DRC) > > + The list must be (4 x num-drc-cfgs) entries long. > > + If absent or incomplete, DRC is disabled. > > What is the purpose of having num-drc-cfgs? We can tell how large > drc-cfg-regs is so it just seems redundant. Can you please point me to any reference implementation doing this ? > > + - num-retune-mobile-cfgs: Number of retune modes available from > > + retune-mobile-cfg-regs property > > Same here. Thanks Best Regards Pier

2 1

Re: [PATCH 4/4] ASoC: wm8904: add DMIC support
by Pierluigi Passaro 20 Jun '22

20 Jun '22

> > > > +static const char *cin_text[] = { > > > > + "ADC", "DMIC" > > > > +}; > > > > +static SOC_ENUM_SINGLE_DECL(cin_enum, > > > > + WM8904_DIGITAL_MICROPHONE_0, 12, cin_text); > > > Why would this be runtime selectable? I'd expect the decision to use > > > an analogue or digital microphone to be made in the hardware design. > > I agree that dedicated HW is required, but currently SW side there's no support at all. > > This patch is aiming to provide a way to enable DMIC on boards using it. > > Is this supposed to be managed in a different way ? > Via firmware description. Can you please provide any reference approach in the kernel code ?

2 1