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

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

[PATCH v2 18/19] xen/sndfront: use xenbus_setup_ring() and xenbus_teardown_ring()
by Juergen Gross 28 Apr '22

28 Apr '22

Simplify sndfront's ring creation and removal via xenbus_setup_ring() and xenbus_teardown_ring(). Signed-off-by: Juergen Gross <jgross(a)suse.com> --- sound/xen/xen_snd_front_evtchnl.c | 44 +++++++------------------------ 1 file changed, 10 insertions(+), 34 deletions(-) diff --git a/sound/xen/xen_snd_front_evtchnl.c b/sound/xen/xen_snd_front_evtchnl.c index 3e21369c8216..26d1b3987887 100644 --- a/sound/xen/xen_snd_front_evtchnl.c +++ b/sound/xen/xen_snd_front_evtchnl.c @@ -143,12 +143,12 @@ void xen_snd_front_evtchnl_flush(struct xen_snd_front_evtchnl *channel) static void evtchnl_free(struct xen_snd_front_info *front_info, struct xen_snd_front_evtchnl *channel) { - unsigned long page = 0; + void *page = NULL; if (channel->type == EVTCHNL_TYPE_REQ) - page = (unsigned long)channel->u.req.ring.sring; + page = channel->u.req.ring.sring; else if (channel->type == EVTCHNL_TYPE_EVT) - page = (unsigned long)channel->u.evt.page; + page = channel->u.evt.page; if (!page) return; @@ -167,10 +167,7 @@ static void evtchnl_free(struct xen_snd_front_info *front_info, xenbus_free_evtchn(front_info->xb_dev, channel->port); /* End access and free the page. */ - if (channel->gref != INVALID_GRANT_REF) - gnttab_end_foreign_access(channel->gref, page); - else - free_page(page); + xenbus_teardown_ring(&page, 1, &channel->gref); memset(channel, 0, sizeof(*channel)); } @@ -196,8 +193,7 @@ static int evtchnl_alloc(struct xen_snd_front_info *front_info, int index, enum xen_snd_front_evtchnl_type type) { struct xenbus_device *xb_dev = front_info->xb_dev; - unsigned long page; - grant_ref_t gref; + void *page; irq_handler_t handler; char *handler_name = NULL; int ret; @@ -207,12 +203,9 @@ static int evtchnl_alloc(struct xen_snd_front_info *front_info, int index, channel->index = index; channel->front_info = front_info; channel->state = EVTCHNL_STATE_DISCONNECTED; - channel->gref = INVALID_GRANT_REF; - page = get_zeroed_page(GFP_KERNEL); - if (!page) { - ret = -ENOMEM; + ret = xenbus_setup_ring(xb_dev, GFP_KERNEL, &page, 1, &channel->gref); + if (ret) goto fail; - } handler_name = kasprintf(GFP_KERNEL, "%s-%s", XENSND_DRIVER_NAME, type == EVTCHNL_TYPE_REQ ? @@ -226,33 +219,18 @@ static int evtchnl_alloc(struct xen_snd_front_info *front_info, int index, mutex_init(&channel->ring_io_lock); if (type == EVTCHNL_TYPE_REQ) { - struct xen_sndif_sring *sring = (struct xen_sndif_sring *)page; + struct xen_sndif_sring *sring = page; init_completion(&channel->u.req.completion); mutex_init(&channel->u.req.req_io_lock); - SHARED_RING_INIT(sring); - FRONT_RING_INIT(&channel->u.req.ring, sring, XEN_PAGE_SIZE); - - ret = xenbus_grant_ring(xb_dev, sring, 1, &gref); - if (ret < 0) { - channel->u.req.ring.sring = NULL; - goto fail; - } + XEN_FRONT_RING_INIT(&channel->u.req.ring, sring, XEN_PAGE_SIZE); handler = evtchnl_interrupt_req; } else { - ret = gnttab_grant_foreign_access(xb_dev->otherend_id, - virt_to_gfn((void *)page), 0); - if (ret < 0) - goto fail; - - channel->u.evt.page = (struct xensnd_event_page *)page; - gref = ret; + channel->u.evt.page = page; handler = evtchnl_interrupt_evt; } - channel->gref = gref; - ret = xenbus_alloc_evtchn(xb_dev, &channel->port); if (ret < 0) goto fail; @@ -279,8 +257,6 @@ static int evtchnl_alloc(struct xen_snd_front_info *front_info, int index, return 0; fail: - if (page) - free_page(page); kfree(handler_name); dev_err(&xb_dev->dev, "Failed to allocate ring: %d\n", ret); return ret; -- 2.34.1

1 0

[PATCH v2 06/19] xen/sound: switch xen_snd_front to use INVALID_GRANT_REF
by Juergen Gross 28 Apr '22

28 Apr '22

Instead of using a private macro for an invalid grant reference use the common one. Signed-off-by: Juergen Gross <jgross(a)suse.com> --- sound/xen/xen_snd_front_evtchnl.c | 4 ++-- sound/xen/xen_snd_front_evtchnl.h | 9 --------- 2 files changed, 2 insertions(+), 11 deletions(-) diff --git a/sound/xen/xen_snd_front_evtchnl.c b/sound/xen/xen_snd_front_evtchnl.c index ecbc294fc59a..3e21369c8216 100644 --- a/sound/xen/xen_snd_front_evtchnl.c +++ b/sound/xen/xen_snd_front_evtchnl.c @@ -167,7 +167,7 @@ static void evtchnl_free(struct xen_snd_front_info *front_info, xenbus_free_evtchn(front_info->xb_dev, channel->port); /* End access and free the page. */ - if (channel->gref != GRANT_INVALID_REF) + if (channel->gref != INVALID_GRANT_REF) gnttab_end_foreign_access(channel->gref, page); else free_page(page); @@ -207,7 +207,7 @@ static int evtchnl_alloc(struct xen_snd_front_info *front_info, int index, channel->index = index; channel->front_info = front_info; channel->state = EVTCHNL_STATE_DISCONNECTED; - channel->gref = GRANT_INVALID_REF; + channel->gref = INVALID_GRANT_REF; page = get_zeroed_page(GFP_KERNEL); if (!page) { ret = -ENOMEM; diff --git a/sound/xen/xen_snd_front_evtchnl.h b/sound/xen/xen_snd_front_evtchnl.h index cbe51fd1ec15..3675fba70564 100644 --- a/sound/xen/xen_snd_front_evtchnl.h +++ b/sound/xen/xen_snd_front_evtchnl.h @@ -15,15 +15,6 @@ struct xen_snd_front_info; -#ifndef GRANT_INVALID_REF -/* - * FIXME: usage of grant reference 0 as invalid grant reference: - * grant reference 0 is valid, but never exposed to a PV driver, - * because of the fact it is already in use/reserved by the PV console. - */ -#define GRANT_INVALID_REF 0 -#endif - /* Timeout in ms to wait for backend to respond. */ #define VSND_WAIT_BACK_MS 3000 -- 2.34.1

1 0

Re: [PATCH] ASoC: wm8960: Add ACPI support
by Charles Keepax 28 Apr '22

28 Apr '22

On Wed, Apr 27, 2022 at 10:29:16PM +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. > > This commit is similar to the commit: > 960cdd50ca9f ("ASoC: wm8804: Add ACPI support") > > Signed-off-by: Nicola Lunghi <nick83ola(a)gmail.com> > --- Acked-by: Charles Keepax <ckeepax(a)opensource.cirrus.com> Thanks, Charles

1 0

[PATCH 04/11] dt-bindings: sound: add Arm PL041 AACI DT schema
by Andre Przywara 28 Apr '22

28 Apr '22

The Arm PrimeCell Advanced Audio CODEC Interface (AACI aka PL041) is a peripheral that provides communication with an audio CODEC. Add a simple DT schema binding for it, so that DTs can be validated automatically. Signed-off-by: Andre Przywara <andre.przywara(a)arm.com> --- .../devicetree/bindings/sound/amba-pl041.yaml | 62 +++++++++++++++++++ 1 file changed, 62 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/amba-pl041.yaml diff --git a/Documentation/devicetree/bindings/sound/amba-pl041.yaml b/Documentation/devicetree/bindings/sound/amba-pl041.yaml new file mode 100644 index 0000000000000..f00796d5ea473 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/amba-pl041.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/amba-pl041.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Arm Ltd. PrimeCell PL041 AACI sound interface + +maintainers: + - Andre Przywara <andre.przywara(a)arm.com> + +description: + The Arm PrimeCell Advanced Audio CODEC Interface (AACI) is an AMBA compliant + peripheral that provides communication with an audio CODEC using the AC-link + protocol. + +# We need a select here so we don't match all nodes with 'arm,primecell' +select: + properties: + compatible: + contains: + const: arm,pl041 + required: + - compatible + +properties: + compatible: + items: + - const: arm,pl041 + - const: arm,primecell + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + description: APB register access clock + + clock-names: + const: apb_pclk + +required: + - compatible + - reg + - interrupts + - clocks + +additionalProperties: false + +examples: + - | + aaci@40000 { + compatible = "arm,pl041", "arm,primecell"; + reg = <0x040000 0x1000>; + interrupts = <11>; + clocks = <&v2m_clk24mhz>; + clock-names = "apb_pclk"; + }; + +... -- 2.25.1

3 7

[PATCH v4 0/2] Add generic serial MIDI driver using serial bus API
by Daniel Kaehn 28 Apr '22

28 Apr '22

Generic serial MIDI driver adding support for using serial devices compatible with the serial bus as raw MIDI devices, allowing using additional serial devices not compatible with the existing serial-u16550 driver. Supports only setting standard serial baudrates on the underlying serial device; however, the underlying serial device can be configured so that a requested 38.4 kBaud is actually the standard MIDI 31.25 kBaud. Supports DeviceTree configuration. Changes in v4: - Fix regressed typo - Correct 3.84 kBaud -> 38.4 kBaud in DT & Kconfig (sorry about spam - noticed after sending v3 and didn't want to let the error sit around for too long) Changes in v3: - Replace use of snd_printk() with dev_* alternatives - Removed unnecessary initialization of err variables - Replaced instances of `== SERIAL_MODE_NOT_OPENED` with zero check - Loop on output_write to completely fill output buffer if data available - Depend on CONFIG_OF in Kconfig - Replace use of devm_kzalloc() with extra_size allocation in snd_devm_card_new() - Use module_serdev_device_driver() instead of module_init() and module_exit(0) Changes in v2: - Fix 'snd_serial_generic_write_wakeup' missing static keyword - Correct 3.125 kBaud > 31.25 kBaud in documentation for MIDI The need for this driver arose from a project using a Raspberry Pi4 which needed to receive and send raw MIDI with low latency. The pl011 UART used is not compatible with the existing serial MIDI driver made for u16550-style devices. Using a userspace program such as ttymidi to feed input from the TTY device to a virtual ALSA MIDI device was functional, but not ideal. I am not sure if a MIDI driver needing the mentioned 'hack' to clock 38.4 kBaud down to the standard MIDI baud is permissible in the mainline kernel, but am submitting nevertheless in case it is useful. To my knowledge, it doesn't seem that there would be any way for this driver to manually configure a serial port to 31.25 kBaud using the serial bus API (please correct me f I'm wrong). In my use case, I am actually configuring one port to run at 115.2 kBaud for faster communication with a custom onboard MIDI controller. Daniel Kaehn (2): dt-bindings: sound: Add generic serial MIDI device Add generic serial MIDI driver using serial bus API .../devicetree/bindings/sound/serialmidi.yaml | 41 +++ sound/drivers/Kconfig | 18 + sound/drivers/Makefile | 2 + sound/drivers/serial-generic.c | 319 ++++++++++++++++++ 4 files changed, 380 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/serialmidi.yaml create mode 100644 sound/drivers/serial-generic.c base-commit: d615b5416f8a1afeb82d13b238f8152c572d59c0 -- 2.33.0

3 8

[PATCH v3] ASoC: SOF: ipc3-topology: Correct get_control_data for non bytes payload
by Peter Ujfalusi 28 Apr '22

28 Apr '22

It is possible to craft a topology where sof_get_control_data() would do out of bounds access because it expects that it is only called when the payload is bytes type. Confusingly it also handles other types of controls, but the payload parsing implementation is only valid for bytes. Fix the code to count the non bytes controls and instead of storing a pointer to sof_abi_hdr in sof_widget_data (which is only valid for bytes), store the pointer to the data itself and add a new member to save the size of the data. In case of non bytes controls we store the pointer to the chanv itself, which is just an array of values at the end. In case of bytes control, drop the wrong cdata->data (wdata[i].pdata) check against NULL since it is incorrect and invalid in this context. The data is pointing to the end of cdata struct, so it should never be null. Reported-by: Sergey Senozhatsky <senozhatsky(a)chromium.org> Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com> --- Hi, Changes since v2: - Drop the cdata->data check against NULL as it is not a valid test and since we are in sof_get_control_data() the memory has been already allocated changes since v1: - adjust the payload size for non bytes controls by subtracting the size of the sof_ipc_ctrl_data struct, plus add comment to note this Regards, Peter sound/soc/sof/ipc3-topology.c | 37 +++++++++++++++++++++++------------ 1 file changed, 25 insertions(+), 12 deletions(-) diff --git a/sound/soc/sof/ipc3-topology.c b/sound/soc/sof/ipc3-topology.c index 572bcbfdb356..66034624e479 100644 --- a/sound/soc/sof/ipc3-topology.c +++ b/sound/soc/sof/ipc3-topology.c @@ -20,7 +20,8 @@ struct sof_widget_data { int ctrl_type; int ipc_cmd; - struct sof_abi_hdr *pdata; + void *pdata; + size_t pdata_size; struct snd_sof_control *control; }; @@ -784,16 +785,26 @@ static int sof_get_control_data(struct snd_soc_component *scomp, } cdata = wdata[i].control->ipc_control_data; - wdata[i].pdata = cdata->data; - if (!wdata[i].pdata) - return -EINVAL; /* make sure data is valid - data can be updated at runtime */ - if (widget->dobj.widget.kcontrol_type[i] == SND_SOC_TPLG_TYPE_BYTES && - wdata[i].pdata->magic != SOF_ABI_MAGIC) - return -EINVAL; + if (widget->dobj.widget.kcontrol_type[i] == SND_SOC_TPLG_TYPE_BYTES) { + if (cdata->data->magic != SOF_ABI_MAGIC) + return -EINVAL; + + wdata[i].pdata = cdata->data->data; + wdata[i].pdata_size = cdata->data->size; + } else { + /* points to the control data union */ + wdata[i].pdata = cdata->chanv; + /* + * wdata[i].control->size is calculated with struct_size + * and includes the size of struct sof_ipc_ctrl_data + */ + wdata[i].pdata_size = wdata[i].control->size - + sizeof(struct sof_ipc_ctrl_data); + } - *size += wdata[i].pdata->size; + *size += wdata[i].pdata_size; /* get data type */ switch (cdata->cmd) { @@ -876,10 +887,12 @@ static int sof_process_load(struct snd_soc_component *scomp, */ if (ipc_data_size) { for (i = 0; i < widget->num_kcontrols; i++) { - memcpy(&process->data[offset], - wdata[i].pdata->data, - wdata[i].pdata->size); - offset += wdata[i].pdata->size; + if (!wdata[i].pdata_size) + continue; + + memcpy(&process->data[offset], wdata[i].pdata, + wdata[i].pdata_size); + offset += wdata[i].pdata_size; } } -- 2.36.0

2 7

[PATCH v2 0/3] ASoC: sh: rz-ssi: Trivial fixes
by Lad Prabhakar 28 Apr '22

28 Apr '22

Hi All, This patch series aims to fix trivial issues found in rz-ssi driver. Cheers, Prabhakar v1->v2: * Updated patch description for patch 1/3 * Patch 2/3 unchanged * For patch 3/3 dropped devers action and instead called rz_ssi_release_dma_channels() in the error path. v1: https://patchwork.kernel.org/project/linux-renesas-soc/cover/ 20220421203555.29011-1-prabhakar.mahadev-lad.rj(a)bp.renesas.com/ Lad Prabhakar (3): ASoC: sh: rz-ssi: Drop SSIFSR_TDC and SSIFSR_RDC macros ASoC: sh: rz-ssi: Propagate error codes returned from platform_get_irq_byname() ASoC: sh: rz-ssi: Release the DMA channels in rz_ssi_probe() error path sound/soc/sh/rz-ssi.c | 24 +++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-) -- 2.25.1

6 9