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

[alsa-devel] [PATCH] ACPI / device_sysfs: change _ADR representation to 64 bits
by Pierre-Louis Bossart 01 May '19

01 May '19

Standards such as the MIPI DisCo for SoundWire 1.0 specification assume the _ADR field is 64 bits. _ADR is defined as an "Integer" represented as 64 bits since ACPI 2.0 released in 2002. The low levels already use _ADR as 64 bits, e.g. in struct acpi_device_info. This patch bumps the representation used for sysfs to 64 bits. Example with a SoundWire device, the results show the complete vendorID and linkID which were omitted before: Before: $ more /sys/bus/acpi/devices/device\:38/adr 0x5d070000 After: $ more /sys/bus/acpi/devices/device\:38/adr 0x000010025d070000 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> --- drivers/acpi/device_sysfs.c | 3 +-- include/acpi/acpi_bus.h | 2 +- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/acpi/device_sysfs.c b/drivers/acpi/device_sysfs.c index 8940054d6250..f8d73ae42529 100644 --- a/drivers/acpi/device_sysfs.c +++ b/drivers/acpi/device_sysfs.c @@ -428,8 +428,7 @@ static ssize_t acpi_device_adr_show(struct device *dev, { struct acpi_device *acpi_dev = to_acpi_device(dev); - return sprintf(buf, "0x%08x\n", - (unsigned int)(acpi_dev->pnp.bus_address)); + return sprintf(buf, "0x%016llx\n", acpi_dev->pnp.bus_address); } static DEVICE_ATTR(adr, 0444, acpi_device_adr_show, NULL); diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h index f7981751ac77..9075e28ea60a 100644 --- a/include/acpi/acpi_bus.h +++ b/include/acpi/acpi_bus.h @@ -230,7 +230,7 @@ struct acpi_device_dir { /* Plug and Play */ typedef char acpi_bus_id[8]; -typedef unsigned long acpi_bus_address; +typedef u64 acpi_bus_address; typedef char acpi_device_name[40]; typedef char acpi_device_class[20]; -- 2.17.1

3 5

[alsa-devel] [PATCH 00/19] ASoC: SOF: improvements for ABI checks and Intel code
by Pierre-Louis Bossart 01 May '19

01 May '19

This series is a set of relatively small SOF changes after the big batch merged last week (Thanks!). Since we are very close to the merge window and in May where most of the world takes time off, it'd be perfectly understandable if those patches were queued for 5.3, after feedback and corrections as needed. First we added optional stricter ABI checks when the firmware, topology and kernel ABI levels differ, which can happen when patches are merged at different times on Github. This is mainly for developers and the Github CI to track disconnects, should they happen despite our new process to keep evolutions under control. This option has no impact on the usual problem of updating the kernel without updating the firmware files. The Intel changes are mainly a) fixes for the slave mode suppport b) clean-ups such as removal of a static index for HDAudio support or removal of unneeded include file c) use of a workqueue to defer period elapsed events after the IPC completion. d) simplification of the IRQ code e) fixes to deal with resume on HDaudio links. In the previous patchset we removed the RESUME_INFO flag but missed the need to explicitly set the hw_params on resume. f) a set of routines to dump the Intel IPC registers, mainly for early platform enablement. Keyon Jie (7): ASoC: SOF: Intel: cnl: add pointer ops to use DPIB position ASoC: SOF: PCM: add period_elapsed work to fix race condition in interrupt context ASoC: SOF: Intel: use snd_sof_pcm_period_elapsed ASoC: SOF: ipc: use snd_sof_pcm_period_elapsed ASoC: SOF: Intel: hda-ipc: simplify handling of IPC IRQ ASoC: SOF: Intel: hda-stream: store stream capabilities ASoC: SOF: Intel: hda-stream: handle real stream interrupts only Pan Xiuli (3): ASoC: SOF: IPC: add ipc dump function ASoC: SOF: Intel: APL: add ipc dump function ASoC: SOF: Intel: CNL: add ipc dump function Pierre-Louis Bossart (4): ASoC: SOF: add Kconfig option for strict ABI checks ASOC: SOF: ipc: add support for stricter ABI checks ASoC: SOF: topology: add support for stricter ABI checks ASoC: SOF: Intel: hda-pcm: remove useless dependency on hdac_ext Ranjani Sridharan (1): ASoC: SOF: intel: hda: add hw_params_upon_resume flag for hda stream Zhu Yingjiang (4): ASoC: SOF: Intel: hda: add the SSP Host Device memory space ASoC: SOF: Intel: hda: add SSP info to the chip info struct ASoC: SOF: Intel: hda: set I2S slave before enabling DSP ASoC: SOF: Intel: hda: set bus->idx as 0 sound/soc/sof/Kconfig | 15 ++++++++++ sound/soc/sof/intel/apl.c | 4 +++ sound/soc/sof/intel/cnl.c | 27 +++++++++++++++--- sound/soc/sof/intel/hda-bus.c | 9 ++++-- sound/soc/sof/intel/hda-dai.c | 23 +++++++++------ sound/soc/sof/intel/hda-dsp.c | 16 +++++++++++ sound/soc/sof/intel/hda-ipc.c | 13 ++++----- sound/soc/sof/intel/hda-loader.c | 11 ++++++++ sound/soc/sof/intel/hda-pcm.c | 1 - sound/soc/sof/intel/hda-stream.c | 15 ++++++++-- sound/soc/sof/intel/hda.c | 18 ++++++++++++ sound/soc/sof/intel/hda.h | 23 +++++++++++++++ sound/soc/sof/intel/shim.h | 2 ++ sound/soc/sof/ipc.c | 12 +++++++- sound/soc/sof/ops.h | 12 ++++++++ sound/soc/sof/pcm.c | 48 ++++++++++++++++++++++++++++++++ sound/soc/sof/pm.c | 3 ++ sound/soc/sof/sof-priv.h | 5 +++- sound/soc/sof/topology.c | 43 +++++++++++++++++++--------- 19 files changed, 257 insertions(+), 43 deletions(-) -- 2.17.1

1 19

[alsa-devel] [PATCH 0/3] ASoC: Intel: machine drivers for SOF
by Pierre-Louis Bossart 01 May '19

01 May '19

Add support for the two main machine drivers used by SOF (not tested with the Skylake driver due to lack of hardware and/or firmware signature/ missing topology) The DMIC support for HDaudio-based devices is very much needed for a number of WhiskyLake+ platforms designed for Windows. SOF will be the only Intel driver supporting this configuration. A firmware binary signed with the required production key should be available shortly. The rt5682 codec is the main validation vehicle of the Intel SOF team, with eval boards connected to the Baytrail MinnowBoard as well as more recent devices. The main difference with traditional Intel machine drivers is that the dai links are added dynamically at probe time to avoid multiple table copy/pastes. Bard liao (1): ASoC: Intel: add sof-rt5682 machine driver Rander Wang (2): ASoC: Intel: skl_hda_dsp_generic: add DMIC support ASoC: Intel: skl_hda_dsp_generic:refine code style sound/soc/intel/boards/Kconfig | 16 + sound/soc/intel/boards/Makefile | 2 + sound/soc/intel/boards/skl_hda_dsp_common.c | 22 +- sound/soc/intel/boards/skl_hda_dsp_common.h | 2 +- sound/soc/intel/boards/skl_hda_dsp_generic.c | 19 +- sound/soc/intel/boards/sof_rt5682.c | 563 ++++++++++++++++++ .../intel/common/soc-acpi-intel-byt-match.c | 6 + .../intel/common/soc-acpi-intel-cht-match.c | 6 + .../intel/common/soc-acpi-intel-cnl-match.c | 19 + .../intel/common/soc-acpi-intel-icl-match.c | 6 + 10 files changed, 656 insertions(+), 5 deletions(-) create mode 100644 sound/soc/intel/boards/sof_rt5682.c -- 2.17.1

1 3

[alsa-devel] [PATCH v3 0/5] soundwire: code cleanup
by Pierre-Louis Bossart 30 Apr '19

30 Apr '19

SoundWire support will be provided in Linux with the Sound Open Firmware (SOF) on Intel platforms. Before we start adding the missing pieces, there are a number of warnings and style issues reported by checkpatch, cppcheck and Coccinelle that need to be cleaned-up. Changes since v2: fixed inversion of devm_kcalloc parameters, detected while rebasing additional patches. Changes since v1: added missing newlines in new patch (suggested by Joe Perches) Pierre-Louis Bossart (5): soundwire: intel: fix inversion in devm_kcalloc parameters soundwire: fix style issues soundwire: bus: remove useless initializations soundwire: stream: remove useless initialization of local variable soundwire: add missing newlines in dynamic debug logs drivers/soundwire/Kconfig | 2 +- drivers/soundwire/bus.c | 137 ++++++++------- drivers/soundwire/bus.h | 16 +- drivers/soundwire/bus_type.c | 4 +- drivers/soundwire/cadence_master.c | 99 +++++------ drivers/soundwire/cadence_master.h | 22 +-- drivers/soundwire/intel.c | 103 ++++++----- drivers/soundwire/intel.h | 4 +- drivers/soundwire/intel_init.c | 12 +- drivers/soundwire/mipi_disco.c | 116 +++++++------ drivers/soundwire/slave.c | 10 +- drivers/soundwire/stream.c | 267 +++++++++++++++-------------- 12 files changed, 404 insertions(+), 388 deletions(-) -- 2.17.1

6 24

[alsa-devel] snd-usb-audio Buffer Sizes and Round Trip Latency
by Jonathan Liu 30 Apr '19

30 Apr '19

Hi, I want to start a discussion regarding round trip latency for class compliant USB audio interfaces on Linux. In particular, I am noticing with my USB 2.0 RME Babyface Pro audio interface that the round trip latency is considerably higher on Linux than on macOS High Sierra and Windows 10. I tested the round trip latency using a loopback audio cable and the ReaInsert plugin included with Reaper DAW (www.reaper.fm) that can be downloaded for Windows/macOS/Linux to calculate the additional delay. Here are the results for 48000 Hz, 24-bit on my RME Babyface Pro: === block_size/periods block_size*periods + additional_delay ~ round_trip_latency round_trip_latency = (block_size*periods + additional_delay) / 48000 * 1000 Linux 4.17.14, Class Compliant Mode (snd-usb-audio, ALSA backend): 16/2 32 + 80 ~ 2.333 ms 16/3 48 + 109 ~ 3.271 ms 32/2 64 + 129 ~ 4.021 ms 32/3 96 + 166 ~ 5.458 ms 64/2 128 + 205 ~ 6.938 ms 64/3 192 + 242 ~ 9.042 ms 128/2 256 + 352 ~ 12.667 ms 128/3 384 + 496 ~ 18.334 ms 256/2 512 + 650 ~ 24.208 ms 256/3 768 + 650 ~ 29.542 ms 512/2 1024 + 634 ~ 34.542 ms 512/3 1536 + 634 ~ 45.208 ms 1024/2 2048 + 650 ~ 56.208 ms 1024/3 3072 + 650 ~ 77.542 ms 2048/2 4096 + 633 ~ 98.521 ms 2048/3 6144 + 633 ~ 141.188 ms macOS High Sierra, Class Compliant Mode (Apple Driver): 16/2 32 + 205 ~ 4.938 ms 32/2 64 + 205 ~ 5.604 ms 64/2 128 + 205 ~ 6.938 ms 128/2 256 + 205 ~ 9.604 ms 256/2 512 + 205 ~ 14.938 ms 512/2 1024 + 205 ~ 25.604 ms 1024/2 2048 + 205 ~ 46.938 ms 2048/2 4096 + 205 ~ 89.604 ms macOS High Sierra, PC Mode (RME Driver v3.08): 16/2 32 + 59 ~ 1.896 ms 32/2 64 + 59 ~ 2.563 ms 64/2 128 + 59 ~ 3.896 ms 128/2 256 + 59 ~ 6.563 ms 256/2 512 + 59 ~ 11.596 ms 512/2 1024 + 59 ~ 22.563 ms 1024/2 2048 + 59 ~ 43.896 ms 2048/2 4096 + 59 ~ 86.563 ms Windows 10, PC Mode (RME Driver 1.099): 48/2 96 + 63 ~ 3.313 ms 64/2 128 + 63 ~ 3.979 ms 96/2 192 + 63 ~ 5.313 ms 128/2 256 + 63 ~ 6.646 ms 256/2 512 + 63 ~ 11.979 ms 512/2 1024 + 63 ~ 22.646 ms 1024/2 2048 + 63 ~ 43.979 ms 2048/2 4096 + 63 ~ 86.646 ms === Some things in particular I noticed on Linux: - additional_delay varies a bit if I close and open the audio device again - additional_delay seems to increase as the block_size increases. I can make the additional_delay stay about the same rather than increasing by setting MAX_PACKS and MAX_PACKS_HS to 1 in sound/usb/card.h. In Linux versions before 3.13 there was a nrpacks parameter for snd-usb-audio to control this but it was removed with commit https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… - additional_delay is not constant as block_size is increased like on macOS and Windows I made a patch to snd-usb-audio to expose the snd-usb-audio constants as runtime adjustable module parameters (/sys/module/snd_usb_audio/parameters/) for testing (takes effect when the device is disconnected+reconnected and logs the parameter values to dmesg): https://aur.archlinux.org/cgit/aur.git/plain/parameters.patch?h=snd-usb-aud… The patch is used in my Arch Linux AUR package for convenience (using DKMS to avoid having to recompile entire kernel): https://aur.archlinux.org/packages/snd-usb-audio-lowlatency-dkms/ Can snd-usb-audio be improved so the additional_delay is always the same when closing/opening/reconfiguring the audio device and does not increase as the block_size increases? I noticed using USB audio on Linux at lower latencies (block_size <= 128) is more prone to audio dropouts under load compared to macOS and Windows, even with CPU power management disabled (writing 0 to /dev/cpu_dma_latency). What can be done about this? Thanks. Regards, Jonathan

4 11

[alsa-devel] [PATCH] ALSA: hda - Register irq handler after the chip initialization
by Takashi Iwai 30 Apr '19

30 Apr '19

Currently the IRQ handler in HD-audio controller driver is registered before the chip initialization. That is, we have some window opened between the azx_acquire_irq() call and the CORB/RIRB setup. If an interrupt is triggered in this small window, the IRQ handler may access to the uninitialized RIRB buffer, which leads to a NULL dereference Oops. This is usually no big problem since most of Intel chips do register the IRQ via MSI, and we've already fixed the order of the IRQ enablement and the CORB/RIRB setup in the former commit b61749a89f82 ("sound: enable interrupt after dma buffer initialization"), hence the IRQ won't be triggered in that room. However, some platforms use a shared IRQ, and this may allow the IRQ trigger by another source. Another possibility is the kdump environment: a stale interrupt might be present in there, the IRQ handler can be falsely triggered as well. For covering this small race, let's move the azx_acquire_irq() call after hda_intel_init_chip() call. Although this is a bit radical change, it can cover more widely than checking the CORB/RIRB setup locally in the callee side. Reported-by: Liwei Song <liwei.song(a)windriver.com> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/pci/hda/hda_intel.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 2ec91085fa3e..789308f54785 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -1788,9 +1788,6 @@ static int azx_first_init(struct azx *chip) chip->msi = 0; } - if (azx_acquire_irq(chip, 0) < 0) - return -EBUSY; - pci_set_master(pci); synchronize_irq(bus->irq); @@ -1904,6 +1901,9 @@ static int azx_first_init(struct azx *chip) return -ENODEV; } + if (azx_acquire_irq(chip, 0) < 0) + return -EBUSY; + strcpy(card->driver, "HDA-Intel"); strlcpy(card->shortname, driver_short_names[chip->driver_type], sizeof(card->shortname)); -- 2.16.4

1 0

[alsa-devel] [PATCH] ALSA: hda: check RIRB to avoid use NULL pointer
by Song liwei 30 Apr '19

30 Apr '19

From: Liwei Song <liwei.song(a)windriver.com> Fix the following BUG: BUG: unable to handle kernel NULL pointer dereference at 000000000000000c Workqueue: events azx_probe_work [snd_hda_intel] RIP: 0010:snd_hdac_bus_update_rirb+0x80/0x160 [snd_hda_core] Call Trace: <IRQ> azx_interrupt+0x78/0x140 [snd_hda_codec] __handle_irq_event_percpu+0x49/0x300 handle_irq_event_percpu+0x23/0x60 handle_irq_event+0x3c/0x60 handle_edge_irq+0xdb/0x180 handle_irq+0x23/0x30 do_IRQ+0x6a/0x140 common_interrupt+0xf/0xf The Call Trace happened when run kdump on a NFS rootfs system. Exist the following calling sequence when boot the second kernel: azx_first_init() --> azx_acquire_irq() <-- interrupt come in, azx_interrupt() was called --> hda_intel_init_chip() --> azx_init_chip() --> snd_hdac_bus_init_chip() --> snd_hdac_bus_init_cmd_io(); --> init rirb.buf and corb.buf Interrupt happened after azx_acquire_irq() while RIRB still didn't got initialized, then NULL pointer will be used when process the interrupt. Check the value of RIRB to ensure it is not NULL, to aviod some special case may hang the system. Fixes: 14752412721c ("ALSA: hda - Add the controller helper codes to hda-core module") Signed-off-by: Liwei Song <liwei.song(a)windriver.com> --- sound/hda/hdac_controller.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/sound/hda/hdac_controller.c b/sound/hda/hdac_controller.c index 74244d8e2909..2f0fa5353361 100644 --- a/sound/hda/hdac_controller.c +++ b/sound/hda/hdac_controller.c @@ -195,6 +195,9 @@ void snd_hdac_bus_update_rirb(struct hdac_bus *bus) return; bus->rirb.wp = wp; + if (!bus->rirb.buf) + return; + while (bus->rirb.rp != wp) { bus->rirb.rp++; bus->rirb.rp %= AZX_MAX_RIRB_ENTRIES; -- 2.7.4

3 5

[alsa-devel] [GIT PULL] soundwire updates for v5.2-rc1
by Vinod Koul 30 Apr '19

30 Apr '19

Hey Greg, Please PULL to receive updates to soundwire subsystem The following changes since commit bfeffd155283772bbe78c6a05dec7c0128ee500c: Linux 5.0-rc1 (2019-01-06 17:08:20 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire.git tags/soundwire-5.2-rc1 for you to fetch changes up to 4abbd783d126cabfc20d1b8d50b1d5026b5cba09: soundwire: intel: fix implicit header use of module.h/export.h (2019-04-14 15:52:50 +0530) ---------------------------------------------------------------- soundwire updates for v5.2-rc1 This round saw interest from Intel, Linaro and Cadence in Soundwire. More patches are in pipeline (maybe next cycle) - removal of useless initialzation in core - couple of header and kcalloc inversion fixes on Intel driver ---------------------------------------------------------------- Paul Gortmaker (1): soundwire: intel: fix implicit header use of module.h/export.h Pierre-Louis Bossart (3): soundwire: intel: fix inversion in devm_kcalloc parameters soundwire: remove useless initializations soundwire: stream: remove useless initialization of local variable drivers/soundwire/bus.c | 2 -- drivers/soundwire/intel.c | 5 +++-- drivers/soundwire/intel_init.c | 2 ++ drivers/soundwire/stream.c | 2 +- 4 files changed, 6 insertions(+), 5 deletions(-) Thanks -- ~Vinod

3 4

[alsa-devel] move eapd coef function before ACT_PRE_PROBE state
by Kailang 30 Apr '19

30 Apr '19

Hi Takashi, alc_fill_eapd_coef(),this function was change EAPD control to default. Default was set EAPD by verb control. This function was run in ACT_INIT state. Move it to ACT_PRE_PROBE above. It will have a chance to change EAPD control on ACT_PRE_PROBE state. It could change control by 0x20 coef bit. BR, Kailang

2 1

Re: [alsa-devel] ALC892 acquisition stutter
by Takashi Iwai 30 Apr '19

30 Apr '19

On Tue, 30 Apr 2019 08:27:54 +0200, rodomar705(a)protonmail.com wrote: > > Nope, neither adding AZX_DCAPS_PM_RUNTIME as seen on other AMD codecs below seems to affect it, unfortunately. Please don't drop Cc to ML and others. And, did you try other position_fix option value, too? Otherwise I have out of idea. It must be platform-specific issue only the hardware vendors know. Takashi > > Sent with ProtonMail Secure Email. > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > Il lunedì 29 aprile 2019 21:28, Takashi Iwai <tiwai(a)suse.de> ha scritto: > > > On Mon, 29 Apr 2019 20:21:22 +0200, > > rodomar705(a)protonmail.com wrote: > > > > > Whoops, sorry. Here it is. > > > > OK, it's an AMD chip and not listed explicitly in the driver config. > > Does the patch below have any influence? > > > > Takashi > > > > --- a/sound/pci/hda/hda_intel.c > > +++ b/sound/pci/hda/hda_intel.c > > @@ -2452,6 +2452,9 @@ static const struct pci_device_id azx_ids[] = { > > /* AMD Hudson */ > > { PCI_DEVICE(0x1022, 0x780d), > > .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_SB }, > > > > - /* AMD family 17h */ > > - { PCI_DEVICE(0x1022, 0x1457), > > - .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_SB }, > > > > > > /* AMD Stoney */ > > { PCI_DEVICE(0x1022, 0x157a), > > .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_SB | > > > >

1 0