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

Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
by Pavel Machek 14 Oct '20

14 Oct '20

On Wed 2020-10-14 10:22:01, Udo van den Heuvel wrote: > On 14-10-2020 10:11, Pavel Machek wrote: > >> It's a computer, not a disco-light or anything like that. > > > > And you probably have numlock LED. > > On the case? no way. > It is on the keyboard, a separate device, and already has a function. > We also have a caps lock LED and scroll lock LED there, with separate > functions. > I do not need 'extra' functionality for those. > > > Additional config options have costs, too, and we don't want to > > support gazillion config options. > > That is not the issue. > One should have thought about stuff beforehand. We did. And decided this is best solution. > The non-selectability is not my fault. It also does not affect you in any way. Feel free to go to the mic LED discussion to see why we did it like this. Then you can come up with better solution for problem at hand. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

1 0

Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
by Randy Dunlap 14 Oct '20

14 Oct '20

On 10/13/20 10:16 PM, Udo van den Heuvel wrote: > On 14-10-2020 07:07, Randy Dunlap wrote: >> On 10/13/20 9:56 PM, Udo van den Heuvel wrote: > >>> I.e.: it looks like I will lose some funcionality when I disable >>> SND_HDA_CODEC_REALTEK. >> >> OK. At present you can't have it both ways, i.e., SND_HDA_CODEC_REALTEK >> with no LEDS. That driver apparently wants LEDS. > > Thanks but why have I gone for years without LEDS? > I do not need LEDS, I do not want LEDS, I do not have LEDS (that are > visible, usable, etc). > > Please make this selectable instead of forcing more bulk into my kernel. > > Kind regards, > Udo Hi Takashi, Regarding commit 7cdf8c49b1df0a385db06c4f9a5ba1b16510fdcc Author: Takashi Iwai <tiwai(a)suse.de> Date: Thu Jun 18 13:08:31 2020 +0200 ALSA: hda: generic: Add a helper for mic-mute LED with LED classdev and this Kconfig entry: config SND_HDA_CODEC_REALTEK tristate "Build Realtek HD-audio codec support" select SND_HDA_GENERIC select SND_HDA_GENERIC_LEDS it seems that LED support is not always wanted (please see above). I.e., user(s) would like to build a kernel without LED support at all. Can you make it a build option? thanks. -- ~Randy

3 8

Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
by Pavel Machek 14 Oct '20

14 Oct '20

On Wed 2020-10-14 10:05:42, Udo van den Heuvel wrote: > On 14-10-2020 09:58, Pavel Machek wrote: > > Contrary to his claims, Udo very probably has LEDs in his systems... > > We have a visible power LED. > WE have a HDD LED. > The board has LEDs, yes, but the SilverStone Fortress FT02 hides them > fairly well. > I did not ask for LEDs nor need them this way. > It's a computer, not a disco-light or anything like that. And you probably have numlock LED. > Whether the code is big or not does not matter, it is a matter of being > able to select what one needs without getting bothered with other code > that will do nothing. No. Additional config options have costs, too, and we don't want to support gazillion config options. LED core should be small enough that it does not matter. Sound was inventing its own "tiny LED core" before. > So please consider. I did. Answer is no. Please accept it. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

1 0

[PATCH 1/2] Asoc: qcom: lpass-cpu: Fix clock disable failure
by Srinivasa Rao Mandadapu 14 Oct '20

14 Oct '20

From: V Sujith Kumar Reddy <vsujithk(a)codeaurora.org> Disable MI2S bit clock from PAUSE/STOP/SUSPEND usecase instead of shutdown time. Acheive this by invoking clk_disable_unprepare API from cpu daiops shutdown to cpu daiops trigger. This Fix is update to the below patch. https://lore.kernel.org/patchwork/patch/1308101/ Signed-off-by: V Sujith Kumar Reddy <vsujithk(a)codeaurora.org> Signed-off-by: Srinivasa Rao Mandadapu <srivasam(a)codeaurora.org> --- sound/soc/qcom/lpass-cpu.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c index ba2aca3..2dfb921 100644 --- a/sound/soc/qcom/lpass-cpu.c +++ b/sound/soc/qcom/lpass-cpu.c @@ -88,8 +88,6 @@ static void lpass_cpu_daiops_shutdown(struct snd_pcm_substream *substream, { struct lpass_data *drvdata = snd_soc_dai_get_drvdata(dai); - clk_disable_unprepare(drvdata->mi2s_bit_clk[dai->driver->id]); - clk_disable_unprepare(drvdata->mi2s_osr_clk[dai->driver->id]); } @@ -324,6 +322,7 @@ static int lpass_cpu_daiops_trigger(struct snd_pcm_substream *substream, if (ret) dev_err(dai->dev, "error writing to i2sctl reg: %d\n", ret); + clk_disable_unprepare(drvdata->mi2s_bit_clk[dai->driver->id]); break; } -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

2 2

Accessing pending hw_params in SND_PCM_HOOK_TYPE_HW_PARAMS call back
by alsa＠scripple.org 13 Oct '20

13 Oct '20

Hello, I'll try again with a more specific question. Is there a way one can access the hw_params that cause the SND_PCM_HOOK_TYPE_HW_PARAMS call back to be called inside the call back function? The hook only provides access to the snd_pcm_t object, but all the public calls to get hw_params fail because it's not in a prepared state yet. If there isn't a way to get them now could we please add the ability with a patch like the one below? With this patch a call to snd_pcm_hook_get_hw_params provides access to the pending hw_params structure and the pending parameters can be accessed with standard calls like snd_pcm_hw_params_get_channels. Hopefully I'm just missing how to get them without the patch, but if not they really should be made accessible. diff --git a/alsa-lib-1.1.8/include/pcm.h b/pcm.h index 5b07823..0cf5dca 100644 --- a/alsa-lib-1.1.8/include/pcm.h +++ b/pcm.h @@ -1181,6 +1181,7 @@ typedef struct _snd_pcm_hook snd_pcm_hook_t; /** PCM hook callback function */ typedef int (*snd_pcm_hook_func_t)(snd_pcm_hook_t *hook); snd_pcm_t *snd_pcm_hook_get_pcm(snd_pcm_hook_t *hook); +snd_pcm_hw_params_t *snd_pcm_hook_get_hw_params(snd_pcm_hook_t *hook); void *snd_pcm_hook_get_private(snd_pcm_hook_t *hook); void snd_pcm_hook_set_private(snd_pcm_hook_t *hook, void *private_data); int snd_pcm_hook_add(snd_pcm_hook_t **hookp, snd_pcm_t *pcm, diff --git a/alsa-lib-1.1.8/src/pcm/pcm_hooks.c b/pcm_hooks.c index 4416d36..f56c3af 100644 --- a/alsa-lib-1.1.8/src/pcm/pcm_hooks.c +++ b/pcm_hooks.c @@ -38,6 +38,7 @@ const char *_snd_module_pcm_hooks = ""; #ifndef DOC_HIDDEN struct _snd_pcm_hook { snd_pcm_t *pcm; + snd_pcm_hw_params_t *params; snd_pcm_hook_func_t func; void *private_data; struct list_head list; @@ -117,6 +118,7 @@ static int snd_pcm_hooks_hw_params(snd_pcm_t *pcm, snd_pcm_hw_params_t *params) return err; list_for_each_safe(pos, next, &h->hooks[SND_PCM_HOOK_TYPE_HW_PARAMS]) { snd_pcm_hook_t *hook = list_entry(pos, snd_pcm_hook_t, list); + hook->params = params; err = hook->func(hook); if (err < 0) return err; @@ -563,6 +565,17 @@ snd_pcm_t *snd_pcm_hook_get_pcm(snd_pcm_hook_t *hook) return hook->pcm; } +/** + * \brief Get hw_params handle for a PCM hook + * \param hook PCM hook handle + * \return hw_params handle + */ +snd_pcm_hw_params_t *snd_pcm_hook_get_hw_params(snd_pcm_hook_t *hook) +{ + assert(hook); + return hook->params; +} + /** * \brief Get callback function private data for a PCM hook * \param hook PCM hook handle @@ -609,6 +622,7 @@ int snd_pcm_hook_add(snd_pcm_hook_t **hookp, snd_pcm_t *pcm, if (!h) return -ENOMEM; h->pcm = pcm; + h->params = NULL; h->func = func; h->private_data = private_data; hooks = pcm->private_data;

1 0

[PATCH v2 0/6] Ancillary bus implementation and SOF multi-client support
by Dave Ertman 13 Oct '20

13 Oct '20

Version 2 of this patchset is being pushed out when there are still some issues up in the air. This push, along with the changes in the change log below, is to fix the broken distribution among mailing lists and individuals of the first version submission. At least two items still under discussion are: Final name for the bus Documentation of sysfs directories Brief history of Ancillary Bus ============================== The ancillary bus code was originally submitted upstream as virtual bus, and was submitted through the netdev tree.  This process generated up to v4.  This discussion can be found here: https://lore.kernel.org/netdev/20191111192219.30259-1-jeffrey.t.kirsher@int… At this point, GregKH requested that we take the review and revision process to an internal mailing list and garner the buy-in of a respected kernel contributor. The ancillary bus (then known as virtual bus) was originally submitted along with implementation code for the ice driver and irdma drive, causing the complication of also having dependencies in the rdma tree. This new submission is utilizing an ancillary bus consumer in only the sound driver tree to create the initial implementation and a single user. Since implementation work has started on this patch set, there have been multiple inquiries about the time frame of its completion. It appears that there will be numerous consumers of this functionality. The process of internal review and implementation using the sound drivers generated 19 internal versions.  The changes, including the name change from virtual bus to ancillary bus, from these versions can be summarized as the following: - Fixed compilation and checkpatch errors - Improved documentation to address the motivation for virtual bus. - Renamed virtual bus to ancillary bus - increased maximum device name size - Correct order in Kconfig and Makefile - removed the mid-layer adev->release layer for device unregister - pushed adev->id management to parent driver - all error paths out of ancillary_device_register return error code - all error paths out of ancillary_device_register use put_device - added adev->name element - modname in register cannot be NULL - added KBUILD_MODNAME as prefix for match_name - push adev->id responsibility to registering driver - uevent now parses adev->dev name - match_id function now parses adev->dev name - changed drivers probe function to also take an ancillary_device_id param - split ancillary_device_register into device_initialize and device_add - adjusted what is done in device_initialize and device_add - change adev to ancildev and adrv to ancildrv - change adev to ancildev in documentation ========================== Introduces the ancillary bus implementation along with the example usage in the Sound Open Firmware(SOF) audio driver. In some subsystems, the functionality of the core device (PCI/ACPI/other) may be too complex for a single device to be managed as a monolithic block or a part of the functionality might need to be exposed to a different subsystem. Splitting the functionality into smaller orthogonal devices makes it easier to manage data, power management and domain-specific communication with the hardware. Also, common ancillary_device functionality across primary devices can be handled by a common ancillary_device. A key requirement for such a split is that there is no dependency on a physical bus, device, register accesses or regmap support. These individual devices split from the core cannot live on the platform bus as they are not physical devices that are controlled by DT/ACPI. The same argument applies for not using MFD in this scenario as it relies on individual function devices being physical devices that are DT enumerated. An example for this kind of requirement is the audio subsystem where a single IP handles multiple entities such as HDMI, Soundwire, local devices such as mics/speakers etc. The split for the core's functionality can be arbitrary or be defined by the DSP firmware topology and include hooks for test/debug. This allows for the audio core device to be minimal and tightly coupled with handling the hardware-specific logic and communication. The ancillary bus is intended to be minimal, generic and avoid domain-specific assumptions. Each ancillary bus device represents a part of its parent functionality. The generic behavior can be extended and specialized as needed by encapsulating an ancillary bus device within other domain-specific structures and the use of .ops callbacks. The SOF driver adopts the ancillary bus for implementing the multi-client support. A client in the context of the SOF driver represents a part of the core device's functionality. It is not a physical device but rather an ancillary device that needs to communicate with the DSP via IPCs. With multi-client support,the sound card can be separated into multiple orthogonal ancillary devices for local devices (mic/speakers etc), HDMI, sensing, probes, debug etc. In this series, we demonstrate the usage of the ancillary bus with the help of the IPC test client which is used for testing the serialization of IPCs when multiple clients talk to the DSP at the same time. v2 changes: defined pr_fmt for kernel messages replaced WARN_ON calls in registration with pr_err calls adding kernel-doc function comments for device_initialize and device_add fix typo in documentation removed inaccurate line in documentation fixed formatting in drivers/bus/Makefile changed unwind path for sof_client_dev_alloc() improved comments for client list and mem freeing during client unreg removed debugfs entries in sof_ipc_test_client_drv during remove changed the signature of sof_debug_ipc_flood_test() fix a looping error in ancillary_match_id updated error value in sof_client_dev_register() mutex held while traversing client list when unregistering clients updated includes in sof-client.h Dave Ertman (1): Add ancillary bus support Fred Oh (1): ASoC: SOF: debug: Remove IPC flood test support in SOF core Ranjani Sridharan (4): ASoC: SOF: Introduce descriptors for SOF client ASoC: SOF: Create client driver for IPC test ASoC: SOF: ops: Add ops for client registration ASoC: SOF: Intel: Define ops for client registration Documentation/driver-api/ancillary_bus.rst | 229 ++++++++++++++ Documentation/driver-api/index.rst | 1 + drivers/bus/Kconfig | 3 + drivers/bus/Makefile | 3 + drivers/bus/ancillary.c | 225 ++++++++++++++ include/linux/ancillary_bus.h | 69 +++++ include/linux/mod_devicetable.h | 8 + scripts/mod/devicetable-offsets.c | 3 + scripts/mod/file2alias.c | 8 + sound/soc/sof/Kconfig | 29 +- sound/soc/sof/Makefile | 7 + sound/soc/sof/core.c | 12 + sound/soc/sof/debug.c | 230 -------------- sound/soc/sof/intel/Kconfig | 9 + sound/soc/sof/intel/Makefile | 3 + sound/soc/sof/intel/apl.c | 18 ++ sound/soc/sof/intel/bdw.c | 18 ++ sound/soc/sof/intel/byt.c | 22 ++ sound/soc/sof/intel/cnl.c | 18 ++ sound/soc/sof/intel/intel-client.c | 53 ++++ sound/soc/sof/intel/intel-client.h | 26 ++ sound/soc/sof/ops.h | 14 + sound/soc/sof/sof-client.c | 119 ++++++++ sound/soc/sof/sof-client.h | 69 +++++ sound/soc/sof/sof-ipc-test-client.c | 332 +++++++++++++++++++++ sound/soc/sof/sof-priv.h | 19 +- 26 files changed, 1308 insertions(+), 239 deletions(-) create mode 100644 Documentation/driver-api/ancillary_bus.rst create mode 100644 drivers/bus/ancillary.c create mode 100644 include/linux/ancillary_bus.h create mode 100644 sound/soc/sof/intel/intel-client.c create mode 100644 sound/soc/sof/intel/intel-client.h create mode 100644 sound/soc/sof/sof-client.c create mode 100644 sound/soc/sof/sof-client.h create mode 100644 sound/soc/sof/sof-ipc-test-client.c -- 2.26.2

10 71

support the Roland UA-4FX2 card
by kalashnikov-HJ4JGG 13 Oct '20

13 Oct '20

Hello i am juan and i am trying to use this (Roland UA-4FX2) sound card on linux, I posted this on the github and they recommended to put it on this mailing list. from https://github.com/alsa-project/alsa-lib/issues/81 hi i'm trying to use this audio card with a Raspberry pi and y get this from the command dmesg on linux console ``` usb 3-2: new high-speed USB device number 6 using xhci_hcd usb 3-2: New USB device found, idVendor=0582, idProduct=01e2, bcdDevice= 0.2b usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 3-2: Product: UA-4FX2 usb 3-2: Manufacturer: ROLAND mc: Linux media interface: v0.10 usbcore: registered new interface driver snd-usb-audio usb 3-2: Unable to change format on ep #8e: already in use usb 3-2: Unable to change format on ep #8e: already in use : : ``` and when i try to select the device on a program get this ``` ALSA lib pcm.c:2642:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear ALSA lib pcm.c:2642:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe ALSA lib pcm.c:2642:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side ALSA lib pcm_route.c:869:(find_matching_chmap) Found no matching channel map ALSA lib pcm_oss.c:377:(_snd_pcm_oss_open) Unknown field port ALSA lib pcm_oss.c:377:(_snd_pcm_oss_open) Unknown field port ALSA lib pcm_usb_stream.c:486:(_snd_pcm_usb_stream_open) Invalid type for card ALSA lib pcm_usb_stream.c:486:(_snd_pcm_usb_stream_open) Invalid type for card ``` it seems that the card is not supported by ALSA lib. How is the procedure to add new cards to the driver? How can I help to do this? Thank you

1 0

[PATCH] ALSA: hda/hdmi: fix incorrect locking in hdmi_pcm_close
by Kai Vehmanen 13 Oct '20

13 Oct '20

A race exists between closing a PCM and update of ELD data. In hdmi_pcm_close(), hinfo->nid value is modified without taking spec->pcm_lock. If this happens concurrently while processing an ELD update in hdmi_pcm_setup_pin(), converter assignment may be done incorrectly. This bug was found by hitting a WARN_ON in snd_hda_spdif_ctls_assign() in a HDMI receiver connection stress test: [2739.684569] WARNING: CPU: 5 PID: 2090 at sound/pci/hda/patch_hdmi.c:1898 check_non_pcm_per_cvt+0x41/0x50 [snd_hda_codec_hdmi] ... [2739.684707] Call Trace: [2739.684720] update_eld+0x121/0x5a0 [snd_hda_codec_hdmi] [2739.684736] hdmi_present_sense+0x21e/0x3b0 [snd_hda_codec_hdmi] [2739.684750] check_presence_and_report+0x81/0xd0 [snd_hda_codec_hdmi] [2739.684842] intel_audio_codec_enable+0x122/0x190 [i915] Fixes: 42b2987079ec ("ALSA: hda - hdmi playback without monitor in dynamic pcm bind mode") Signed-off-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> --- sound/pci/hda/patch_hdmi.c | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index 0ffbfcb91256..ccd1df059654 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -2046,22 +2046,25 @@ static int hdmi_pcm_close(struct hda_pcm_stream *hinfo, int pinctl; int err = 0; + mutex_lock(&spec->pcm_lock); if (hinfo->nid) { pcm_idx = hinfo_to_pcm_index(codec, hinfo); - if (snd_BUG_ON(pcm_idx < 0)) - return -EINVAL; + if (snd_BUG_ON(pcm_idx < 0)) { + err = -EINVAL; + goto unlock; + } cvt_idx = cvt_nid_to_cvt_index(codec, hinfo->nid); - if (snd_BUG_ON(cvt_idx < 0)) - return -EINVAL; + if (snd_BUG_ON(cvt_idx < 0)) { + err = -EINVAL; + goto unlock; + } per_cvt = get_cvt(spec, cvt_idx); - snd_BUG_ON(!per_cvt->assigned); per_cvt->assigned = 0; hinfo->nid = 0; azx_stream(get_azx_dev(substream))->stripe = 0; - mutex_lock(&spec->pcm_lock); snd_hda_spdif_ctls_unassign(codec, pcm_idx); clear_bit(pcm_idx, &spec->pcm_in_use); pin_idx = hinfo_to_pin_index(codec, hinfo); @@ -2091,10 +2094,11 @@ static int hdmi_pcm_close(struct hda_pcm_stream *hinfo, per_pin->setup = false; per_pin->channels = 0; mutex_unlock(&per_pin->lock); - unlock: - mutex_unlock(&spec->pcm_lock); } +unlock: + mutex_unlock(&spec->pcm_lock); + return err; } -- 2.28.0

2 1

[PATCH] Asoc: qcom: lpass-cpu: Fix dp audio failure on monitors
by Srinivasa Rao Mandadapu 13 Oct '20

13 Oct '20

From: V Sujith Kumar Reddy <vsujithk(a)codeaurora.org> Make LPASS_HDMI_TX_PARITY_ADDR reg as volatile to fix dp audio failure with external monitors. This patch is upgrade to below patch series. https://lore.kernel.org/patchwork/project/lkml/list/?series=466460 Signed-off-by: V Sujith Kumar Reddy <vsujithk(a)codeaurora.org> Signed-off-by: Srinivasa Rao Mandadapu <srivasam(a)codeaurora.org> --- sound/soc/qcom/lpass-cpu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c index ba2aca3..78de888 100644 --- a/sound/soc/qcom/lpass-cpu.c +++ b/sound/soc/qcom/lpass-cpu.c @@ -660,6 +660,8 @@ static bool lpass_hdmi_regmap_volatile(struct device *dev, unsigned int reg) return true; if (reg == LPASS_HDMI_TX_LEGACY_ADDR(v)) return true; + if (reg == LPASS_HDMI_TX_PARITY_ADDR(v)) + return true; for (i = 0; i < v->rdma_channels; ++i) { if (reg == LPAIF_HDMI_RDMACURR_REG(v, i)) -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

1 0

[PATCH] ASoC: dmaengine: Document support for TX only or RX only streams
by Mark Brown 13 Oct '20

13 Oct '20

We intentionally do not return an error if we get a permanent failure from dma_request_chan() in order to support systems which have TX only or RX only channels. Add a comment documenting this. Reported-by: Andy Shevchenko <andriy.shevchenko(a)intel.com> Signed-off-by: Mark Brown <broonie(a)kernel.org> --- sound/soc/soc-generic-dmaengine-pcm.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/sound/soc/soc-generic-dmaengine-pcm.c b/sound/soc/soc-generic-dmaengine-pcm.c index fb95c1464e66..9ef80a48707e 100644 --- a/sound/soc/soc-generic-dmaengine-pcm.c +++ b/sound/soc/soc-generic-dmaengine-pcm.c @@ -386,6 +386,11 @@ static int dmaengine_pcm_request_chan_of(struct dmaengine_pcm *pcm, name = config->chan_names[i]; chan = dma_request_chan(dev, name); if (IS_ERR(chan)) { + /* + * Only report probe deferral errors, channels + * might not be present for devices that + * support only TX or only RX. + */ if (PTR_ERR(chan) == -EPROBE_DEFER) return -EPROBE_DEFER; pcm->chan[i] = NULL; -- 2.20.1

2 9