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

Re: RFC: usb: gadget: u_audio: Notifying gadget that host started playback/capture?
by Pavel Hofman 30 Oct '23

30 Oct '23

Hi, Dne 08. 09. 21 v 10:21 Pavel Hofman napsal(a): > Hi, > > The current audio gadget has no way to inform the gadget side that the > host side has started playback/capture and that gadget-side alsa > processes should be started. > > Playback/capture processes on the host side do not get stuck without the > gadget side consuming/producing data (OUT requests are ignored in > u_audio_iso_complete, IN ones send initial zeros in their req->buf). > > However, playback/capture processes on the gadget side get stuck without > the host side sending playback OUT packets or capture IN requests and > time out with error. If there was a way to inform the gadget side that > playback/capture has started on the host side, the gadget clients could > react accordingly. > I drafted a simple patch for u_audio.c which defines read-only boolean ctl elems "Capture Requested" and "Playback Requested". Their values are set/reset in methods u_audio_start_capture/playback and u_audio_stop_capture/playback, i.e. at changes of respective altsettings from 0 to 1 and back. Every ctl elem value change sends notification via snd_ctl_notify. The principle works OK for capture/playback start/stop on the host, as monitored by alsactl: pi@raspberrypi:~ $ alsactl monitor hw:UAC2Gadget node hw:UAC2Gadget, #4 (3,0,0,Capture Requested,0) VALUE node hw:UAC2Gadget, #4 (3,0,0,Capture Requested,0) VALUE node hw:UAC2Gadget, #3 (3,0,0,Playback Requested,0) VALUE node hw:UAC2Gadget, #3 (3,0,0,Playback Requested,0) VALUE However at enumeration the USB host switches both playback and capture altsettings repeatedly, generating "fake" events from the gadget side POW. The host even sends regular-sized EP-OUT packets filled with zeros during enumeration (tested on linux only for now). Please is there any way to "detect" the enumeration stage to mask out the "fake" playback/capture start/stop events? The attached patch does not apply cleanly to mainline u_audio.c because it's rebased on other patches not submitted yet but it's only a discussion inducer for now. Thanks a lot, Pavel.

2 6

[alsa-devel] echo-cancellation plugin advice?
by Max Klein 27 Oct '23

27 Oct '23

> Well, asym wouldn't be the answer. Basically you'll need to open two > slave PCMs in one plugin. So, it's no simple filter-type plugin. > It's doable, but not easy as it sounds, I guess. Takashi, can you please further explain why asym is not the solution and what you see as a problem? I am also trying to figure out if it would be possible to create such a plugin for ALSA? I am still searching for some good starting points on how to write an ALSA plugin... Jean-Marc Valin (http://lists.linuxaudio.org/pipermail/linux-audio-dev/2005-June/012454.html) already released his work as part of speex but as far I know there is no plugin that has been made out of it? Thanks for any hint! -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a

3 2

[PATCH] ASoC: fsl_sai: Enable MCTL_MCLK_EN bit for master mode
by Shengjiu Wang 07 Jul '23

07 Jul '23

On i.MX8MM, the MCTL_MCLK_EN bit it is not only the gate for MCLK output to PAD, but also the gate bit between root clock and SAI module, So it is need to be enabled for master mode, otherwise there is no bclk generated. Signed-off-by: Shengjiu Wang <shengjiu.wang(a)nxp.com> --- sound/soc/fsl/fsl_sai.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c index fa950dde5310..dae16a14f177 100644 --- a/sound/soc/fsl/fsl_sai.c +++ b/sound/soc/fsl/fsl_sai.c @@ -437,6 +437,12 @@ static int fsl_sai_set_bclk(struct snd_soc_dai *dai, bool tx, u32 freq) FSL_SAI_CR2_DIV_MASK | FSL_SAI_CR2_BYP, savediv / 2 - 1); + if (sai->soc_data->max_register >= FSL_SAI_MCTL) { + /* SAI is in master mode at this point, so enable MCLK */ + regmap_update_bits(sai->regmap, FSL_SAI_MCTL, + FSL_SAI_MCTL_MCLK_EN, FSL_SAI_MCTL_MCLK_EN); + } + return 0; } -- 2.17.1

5 11

Re: [PATCH] kernel/drivers: Remove redundant driver match function
by Uwe Kleine-König 19 Mar '23

19 Mar '23

Hello, On Thu, May 05, 2022 at 09:59:52PM -0700, lizhe wrote: > If there is no driver match function, the driver core assumes that each > candidate pair (driver, device) matches, see driver_match_device(). I wonder who is supposed to apply this patch. Either it should be split by file and go in via the respective maintainers, or it goes in via Greg's tree? I added Greg to To: for him to chime in. Best regards Uwe > Signed-off-by: lizhe <sensor1010(a)163.com> > --- > drivers/mfd/mcp-core.c | 6 ------ > drivers/nubus/bus.c | 6 ------ > drivers/s390/crypto/vfio_ap_drv.c | 6 ------ > drivers/scsi/scsi_debug.c | 7 ------- > drivers/target/loopback/tcm_loop.c | 7 ------- > drivers/w1/w1.c | 6 ------ > sound/ac97_bus.c | 11 ----------- > 7 files changed, 49 deletions(-) > > diff --git a/drivers/mfd/mcp-core.c b/drivers/mfd/mcp-core.c > index 2fa592c37c6f..281a9369f2b3 100644 > --- a/drivers/mfd/mcp-core.c > +++ b/drivers/mfd/mcp-core.c > @@ -20,11 +20,6 @@ > #define to_mcp(d) container_of(d, struct mcp, attached_device) > #define to_mcp_driver(d) container_of(d, struct mcp_driver, drv) > > -static int mcp_bus_match(struct device *dev, struct device_driver *drv) > -{ > - return 1; > -} > - > static int mcp_bus_probe(struct device *dev) > { > struct mcp *mcp = to_mcp(dev); > @@ -43,7 +38,6 @@ static void mcp_bus_remove(struct device *dev) > > static struct bus_type mcp_bus_type = { > .name = "mcp", > - .match = mcp_bus_match, > .probe = mcp_bus_probe, > .remove = mcp_bus_remove, > }; > diff --git a/drivers/nubus/bus.c b/drivers/nubus/bus.c > index 17fad660032c..72921e4f35f6 100644 > --- a/drivers/nubus/bus.c > +++ b/drivers/nubus/bus.c > @@ -14,11 +14,6 @@ > #define to_nubus_board(d) container_of(d, struct nubus_board, dev) > #define to_nubus_driver(d) container_of(d, struct nubus_driver, driver) > > -static int nubus_bus_match(struct device *dev, struct device_driver *driver) > -{ > - return 1; > -} > - > static int nubus_device_probe(struct device *dev) > { > struct nubus_driver *ndrv = to_nubus_driver(dev->driver); > @@ -39,7 +34,6 @@ static void nubus_device_remove(struct device *dev) > > struct bus_type nubus_bus_type = { > .name = "nubus", > - .match = nubus_bus_match, > .probe = nubus_device_probe, > .remove = nubus_device_remove, > }; > diff --git a/drivers/s390/crypto/vfio_ap_drv.c b/drivers/s390/crypto/vfio_ap_drv.c > index 29ebd54f8919..0a662c451f2a 100644 > --- a/drivers/s390/crypto/vfio_ap_drv.c > +++ b/drivers/s390/crypto/vfio_ap_drv.c > @@ -172,14 +172,8 @@ static void vfio_ap_matrix_dev_release(struct device *dev) > kfree(matrix_dev); > } > > -static int matrix_bus_match(struct device *dev, struct device_driver *drv) > -{ > - return 1; > -} > - > static struct bus_type matrix_bus = { > .name = "matrix", > - .match = &matrix_bus_match, > }; > > static struct device_driver matrix_driver = { > diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c > index 592a290e6cfa..8107489b36e8 100644 > --- a/drivers/scsi/scsi_debug.c > +++ b/drivers/scsi/scsi_debug.c > @@ -7844,15 +7844,8 @@ static void sdebug_driver_remove(struct device *dev) > scsi_host_put(sdbg_host->shost); > } > > -static int pseudo_lld_bus_match(struct device *dev, > - struct device_driver *dev_driver) > -{ > - return 1; > -} > - > static struct bus_type pseudo_lld_bus = { > .name = "pseudo", > - .match = pseudo_lld_bus_match, > .probe = sdebug_driver_probe, > .remove = sdebug_driver_remove, > .drv_groups = sdebug_drv_groups, > diff --git a/drivers/target/loopback/tcm_loop.c b/drivers/target/loopback/tcm_loop.c > index 4407b56aa6d1..eeb63deff94f 100644 > --- a/drivers/target/loopback/tcm_loop.c > +++ b/drivers/target/loopback/tcm_loop.c > @@ -83,15 +83,8 @@ static int tcm_loop_show_info(struct seq_file *m, struct Scsi_Host *host) > static int tcm_loop_driver_probe(struct device *); > static void tcm_loop_driver_remove(struct device *); > > -static int pseudo_lld_bus_match(struct device *dev, > - struct device_driver *dev_driver) > -{ > - return 1; > -} > - > static struct bus_type tcm_loop_lld_bus = { > .name = "tcm_loop_bus", > - .match = pseudo_lld_bus_match, > .probe = tcm_loop_driver_probe, > .remove = tcm_loop_driver_remove, > }; > diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c > index f2ae2e563dc5..a6ecfa1b3417 100644 > --- a/drivers/w1/w1.c > +++ b/drivers/w1/w1.c > @@ -58,11 +58,6 @@ MODULE_PARM_DESC(slave_ttl, > DEFINE_MUTEX(w1_mlock); > LIST_HEAD(w1_masters); > > -static int w1_master_match(struct device *dev, struct device_driver *drv) > -{ > - return 1; > -} > - > static int w1_master_probe(struct device *dev) > { > return -ENODEV; > @@ -174,7 +169,6 @@ static int w1_uevent(struct device *dev, struct kobj_uevent_env *env); > > static struct bus_type w1_bus_type = { > .name = "w1", > - .match = w1_master_match, > .uevent = w1_uevent, > }; > > diff --git a/sound/ac97_bus.c b/sound/ac97_bus.c > index b4685c53ff11..c7aee8c42c55 100644 > --- a/sound/ac97_bus.c > +++ b/sound/ac97_bus.c > @@ -75,19 +75,8 @@ int snd_ac97_reset(struct snd_ac97 *ac97, bool try_warm, unsigned int id, > } > EXPORT_SYMBOL_GPL(snd_ac97_reset); > > -/* > - * Let drivers decide whether they want to support given codec from their > - * probe method. Drivers have direct access to the struct snd_ac97 > - * structure and may decide based on the id field amongst other things. > - */ > -static int ac97_bus_match(struct device *dev, struct device_driver *drv) > -{ > - return 1; > -} > - > struct bus_type ac97_bus_type = { > .name = "ac97", > - .match = ac97_bus_match, > }; > > static int __init ac97_bus_init(void) > -- > 2.25.1 > > -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | https://www.pengutronix.de/ |

3 2

soundwire: user space test utilities
by Muni Sekhar 06 Mar '23

06 Mar '23

Hi all, I am looking for any existing user space test utilities to test SOUNDWIRE SUBSYSTEM in Linux kernel. Can someone please point me to this. -- Thanks, Sekhar

2 4

Regression playing 24bit/96kHz audio on USB audio interface between 5.10.94 and 5.15.21
by Ruud van Asseldonk 02 Jan '23

02 Jan '23

Hi, I have a program that configures a Behringer UMC404HD 192k USB audio interface for playback as follows (pseudocode): snd_pcm_hw_params_set_channels(pcm, hwp, 2); snd_pcm_hw_params_set_format(pcm, hwp, SND_PCM_FORMAT_S24_3LE); snd_pcm_hw_params_set_access(pcm, hwp, SND_PCM_ACCESS_MMAP_INTERLEAVED); snd_pcm_hw_params_set_rate(pcm, hwp, val=96000, dir=0); snd_pcm_hw_params_set_period_size_near(pcm, hwp, val=513, dir=0); // If I confirm at this point with snd_pcm_hw_params_get_period_size, // I get back 513. snd_pcm_hw_params_set_buffer_size_near(pcm, hwp, val=2052); snd_pcm_hw_params(pcm, hwp); // If I confirm with snd_pcm_hw_params_get_buffer_size, // I get back 2052. On Linux 5.10.94 (specifically Arch Linux ARM package linux-rpi-5.10.94-1), this succeeds, and I can play back audio just fine. On 5.15.21 (specifically linux-rpi-5.15.21-3), all the calls succeed apart from the last one, which returns EINVAL. (My actual program is written in Rust and uses a Rust wrapper library for libasound, https://docs.rs/alsa/0.6.0/alsa/, but the calls should be the ones listed.) I confirmed with snd_pcm_hw_params_test_format that the S24_3LE format is supported. On both kernels it is successful. I confirmed with snd_pcm_hw_params_test_rate that 96 kHz is supported. On both kernels it is successful. There are differences though. When I query these: snd_pcm_hw_params_get_period_size_min snd_pcm_hw_params_get_period_size_max snd_pcm_hw_params_get_buffer_size_min snd_pcm_hw_params_get_buffer_size_max Then on 5.10.94 (the good version), I get: period size min/max: 12/32768, buffer size min/max: 24/65536 But on 5.15.21 (the bad version), I get: period size min/max: 13/71332, buffer size min/max: 26/142663 Also, after I set the period size to 513, if I then query the buffer size min/max, on 5.10.94 I get: buffer size min/max: 1026/65536 But on 5.15.21 I get: buffer size min/max: 1027/142663 In lsmod, snd_usb_audio shows up, and from lsusb -v, the UMC404HD appears to be a standard USB audio interface. The lsusb output is identical on both kernels. Please let me know if there is anything I can do to help further diagnose the issue, or if I should report this elsewhere. Kind regards, Ruud van Asseldonk

5 10

[alsa-devel] [PATCH 0/6] ASoC: mediatek: mt8183: support DP audio
by Tzung-Bi Shih 24 Nov '22

24 Nov '22

(This series depends on https://lore.kernel.org/patchwork/patch/1126819/ which has not applied to the maintainer's tree yet.) This series makes mt8183-mt6358-ts3a227-max98357 support DP (display port) audio output. ASoC: hdmi-codec: add PCM trigger operator - add a PCM trigger callback if codec driver is interested in PCM events. drm: bridge: it6505: bridge to hdmi-codec - add audio feature support of it6505. - bridge to hdmi-codec so that ASoC can use the audio feature. - defer the "enabling" after receiving PCM START or RESUME event. ASoC: dt-bindings: mt8183: add a property "mediatek,hdmi-codec" ASoC: mediatek: mt8183: use hdmi-codec - bind to hdmi-codec in mt8183-mt6358-ts3a227-max98357. drm: bridge: it6505: report connector status ASoC: mediatek: mt8183: support HDMI jack reporting - use the mechanism from the following patch https://mailman.alsa-project.org/pipermail/alsa-devel/2019-September/155302… to report jack status (from DRM to ASoC). Allen Chen (1): drm: bridge: it6505: bridge to hdmi-codec Tzung-Bi Shih (5): ASoC: hdmi-codec: add PCM trigger operator ASoC: dt-bindings: mt8183: add a property "mediatek,hdmi-codec" ASoC: mediatek: mt8183: use hdmi-codec drm: bridge: it6505: report connector status ASoC: mediatek: mt8183: support HDMI jack reporting .../sound/mt8183-mt6358-ts3a227-max98357.txt | 2 + drivers/gpu/drm/bridge/ite-it6505.c | 191 +++++++++++++++++- include/sound/hdmi-codec.h | 13 ++ sound/soc/codecs/hdmi-codec.c | 31 +++ sound/soc/mediatek/Kconfig | 3 +- .../mt8183/mt8183-mt6358-ts3a227-max98357.c | 36 +++- 6 files changed, 266 insertions(+), 10 deletions(-) -- 2.23.0.866.gb869b98d4c-goog

3 9

[PATCH v6 00/10] Add support for CS35L41 in HDA systems
by Lucas Tanure 31 Oct '22

31 Oct '22

Add support for laptops that have CS35L41 connected to an HDA codec by I2S and direct I2C connection to the CPU. Laptops that use CS35L41 and are SPI will be added in the future, after the support for it is resolved at i2c-multi-instantiate driver. i2c-multi-instantiate thread: https://lkml.org/lkml/2021/12/10/557 Hardware: - Some laptops have two CS35L41 amplifiers, connected to Realtek ALC287 by an I2S bus and by and direct I2C to the CPU. - The ALC287 codec is connected to the CPU by an HDA bus. - The CS35L41 has a DSP which will require firmware to be loaded. Architecture: - Creation of a library of shared functions for CS35L41 ASoC and HDA - HDA codec driver (RealTek) and CS35L41 HDA driver are combined by using component binding, where it uses device names to find the components and bind to the master - The HDA CS35L41 driver applies pre-defined registers sequences for each action in playback for HDA Sound card Changes from V5: - Fix build issues reported by Intel Test Bot - Check devm_kasprintf return - Add ACPI dependency to HDA drivers V5: https://lkml.org/lkml/2021/12/16/430 Changes from V4: - Save index received from ACPI for latter use in DSP Support - Move CS35L41_DSP1_CCM_CORE_CTRL to regmap_write so doesn't affect DSP hibernation feature V4: https://lkml.org/lkml/2021/12/14/487 Changes from V3: - SPI bus driver starter added - Use separate modules approach instead of liking library - Add CSC3551 ACPI _HID for more I2C laptops - Removed regulators from HDA driver - Add note about Non-conforming _HID V3: https://lkml.org/lkml/2021/11/23/723 Changes from V2: - Not an RFC - Create a new HDA driver for CS35L41 instead of using the ASoC one - Use component binding and device names to find the CS35L41 driver - Create a shared library for ASoC and HDA CS35L41 drivers v2: https://lkml.org/lkml/2021/10/8/344 Lucas Tanure (9): ASoC: cs35l41: Convert tables to shared source code ASoC: cs35l41: Move cs35l41_otp_unpack to shared code ASoC: cs35l41: Move power initializations to reg_sequence ASoC: cs35l41: Create shared function for errata patches ASoC: cs35l41: Create shared function for setting channels ASoC: cs35l41: Create shared function for boost configuration hda: cs35l41: Add support for CS35L41 in HDA systems ACPI / scan: Create platform device for CLSA0100 and CSC3551 ACPI nodes ALSA: hda/realtek: Add support for Legion 7 16ACHg6 laptop Stefan Binding (1): ALSA: hda/realtek: Add CS35L41 support for Thinkpad laptops MAINTAINERS | 2 + drivers/acpi/scan.c | 3 + drivers/platform/x86/i2c-multi-instantiate.c | 11 + include/sound/cs35l41.h | 739 ++++++++++++++++++ sound/pci/hda/Kconfig | 29 + sound/pci/hda/Makefile | 10 + sound/pci/hda/cs35l41_hda.c | 527 +++++++++++++ sound/pci/hda/cs35l41_hda.h | 69 ++ sound/pci/hda/cs35l41_hda_i2c.c | 66 ++ sound/pci/hda/cs35l41_hda_spi.c | 63 ++ sound/pci/hda/hda_component.h | 20 + sound/pci/hda/patch_realtek.c | 146 ++++ sound/soc/codecs/Kconfig | 11 +- sound/soc/codecs/Makefile | 4 +- sound/soc/codecs/cs35l41-i2c.c | 1 - .../{cs35l41-tables.c => cs35l41-lib.c} | 355 ++++++++- sound/soc/codecs/cs35l41-spi.c | 1 - sound/soc/codecs/cs35l41.c | 360 +-------- sound/soc/codecs/cs35l41.h | 734 ----------------- 19 files changed, 2055 insertions(+), 1096 deletions(-) create mode 100644 sound/pci/hda/cs35l41_hda.c create mode 100644 sound/pci/hda/cs35l41_hda.h create mode 100644 sound/pci/hda/cs35l41_hda_i2c.c create mode 100644 sound/pci/hda/cs35l41_hda_spi.c create mode 100644 sound/pci/hda/hda_component.h rename sound/soc/codecs/{cs35l41-tables.c => cs35l41-lib.c} (71%) -- 2.34.1

11 28

[PATCH 1/2] ALSA: hda: Add Intel DG2 PCI ID and HDMI codec vid
by Kai Vehmanen 14 Oct '22

14 Oct '22

Add HD Audio PCI ID and HDMI codec vendor ID for Intel DG2. Reviewed-by: Uma Shankar <uma.shankar(a)intel.com> Signed-off-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> --- sound/pci/hda/hda_intel.c | 12 +++++++++++- sound/pci/hda/patch_hdmi.c | 1 + 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 221afacbc7fd..b98d7975adea 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -335,7 +335,10 @@ enum { ((pci)->device == 0x0c0c) || \ ((pci)->device == 0x0d0c) || \ ((pci)->device == 0x160c) || \ - ((pci)->device == 0x490d)) + ((pci)->device == 0x490d) || \ + ((pci)->device == 0x4f90) || \ + ((pci)->device == 0x4f91) || \ + ((pci)->device == 0x4f92)) #define IS_BXT(pci) ((pci)->vendor == 0x8086 && (pci)->device == 0x5a98) @@ -2477,6 +2480,13 @@ static const struct pci_device_id azx_ids[] = { /* DG1 */ { PCI_DEVICE(0x8086, 0x490d), .driver_data = AZX_DRIVER_SKL | AZX_DCAPS_INTEL_SKYLAKE}, + /* DG2 */ + { PCI_DEVICE(0x8086, 0x4f90), + .driver_data = AZX_DRIVER_SKL | AZX_DCAPS_INTEL_SKYLAKE}, + { PCI_DEVICE(0x8086, 0x4f91), + .driver_data = AZX_DRIVER_SKL | AZX_DCAPS_INTEL_SKYLAKE}, + { PCI_DEVICE(0x8086, 0x4f92), + .driver_data = AZX_DRIVER_SKL | AZX_DCAPS_INTEL_SKYLAKE}, /* Alderlake-S */ { PCI_DEVICE(0x8086, 0x7ad0), .driver_data = AZX_DRIVER_SKL | AZX_DCAPS_INTEL_SKYLAKE}, diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index 65d2c5539919..98633d2684de 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -4382,6 +4382,7 @@ HDA_CODEC_ENTRY(0x80862814, "DG1 HDMI", patch_i915_tgl_hdmi), HDA_CODEC_ENTRY(0x80862815, "Alderlake HDMI", patch_i915_tgl_hdmi), HDA_CODEC_ENTRY(0x8086281c, "Alderlake-P HDMI", patch_i915_tgl_hdmi), HDA_CODEC_ENTRY(0x80862816, "Rocketlake HDMI", patch_i915_tgl_hdmi), +HDA_CODEC_ENTRY(0x80862819, "DG2 HDMI", patch_i915_tgl_hdmi), HDA_CODEC_ENTRY(0x8086281a, "Jasperlake HDMI", patch_i915_icl_hdmi), HDA_CODEC_ENTRY(0x8086281b, "Elkhartlake HDMI", patch_i915_icl_hdmi), HDA_CODEC_ENTRY(0x80862880, "CedarTrail HDMI", patch_generic_hdmi), base-commit: d7aca8d8f548570f650d9b1dfedf6902f56f2bce -- 2.34.1

3 3

[PATCH v6 0/4] Let userspace know when snd-hda-intel needs i915
by Mauro Carvalho Chehab 28 Sep '22

28 Sep '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. That's because module_try_get() and symbol_get() doesn't try to setup the module owner. 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 properly set the holders when try_module_get() and symbol_get() are used. This allow allow audio 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. With that, userspace tools can now 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-20220506. --- v6: - dropped an unused function prototype for __symbol_get_gpl(); - addressed several issues that were noticed while testing the series on an slow atom machine; - also add holders when symbol_get() is used. v5: - while v4 works fine, it ends calling try_module_format() recursively, which is not what it it was supposed to do. So, change the logic to avoid such recursion, by adding a static __try_module_format() and renaming the new version that takes two arguments as try_module_format_owner(). v4: - fix a compilation warning reported by Intel's Kernel robot when !CONFIG_MODULE_UNLOAD or !CONFIG_MODULE. v3: minor fixes: - fixed a checkpatch warning; - use a single line for the new function prototype. v2: - the dependencies are now handled directly at try_module_get(). Mauro Carvalho Chehab (4): module: drop prototype for non-existing __symbol_get_gpl() module: update dependencies at try_module_get() module: set holders when symbol_get() is used ALSA: hda - identify when audio is provided by a video driver drivers/mtd/chips/gen_probe.c | 4 +- include/linux/module.h | 13 +++-- kernel/module/main.c | 76 ++++++++++++++++++++----- samples/hw_breakpoint/data_breakpoint.c | 2 +- sound/hda/hdac_component.c | 2 +- 5 files changed, 72 insertions(+), 25 deletions(-) -- 2.35.3

5 9