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

[alsa-devel] [PATCH] ALSA: hda: Add support of Zhaoxin controller
by Tony W Wang-oc 02 Aug '19

02 Aug '19

Add the new PCI ID 0x1d17 0x3288 Zhaoxin controller support Signed-off-by: Tony W Wang-oc <TonyWWang-oc(a)zhaoxin.com> --- sound/pci/hda/hda_intel.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 324a4b2..d08da0e 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -266,6 +266,7 @@ enum { AZX_DRIVER_CTX, AZX_DRIVER_CTHDA, AZX_DRIVER_CMEDIA, + AZX_DRIVER_ZHAOXIN, AZX_DRIVER_GENERIC, AZX_NUM_DRIVERS, /* keep this as last entry */ }; @@ -379,6 +380,7 @@ static char *driver_short_names[] = { [AZX_DRIVER_CTX] = "HDA Creative", [AZX_DRIVER_CTHDA] = "HDA Creative", [AZX_DRIVER_CMEDIA] = "HDA C-Media", + [AZX_DRIVER_ZHAOXIN] = "HDA Zhaoxin", [AZX_DRIVER_GENERIC] = "HD-Audio Generic", }; @@ -2589,6 +2591,8 @@ static const struct pci_device_id azx_ids[] = { .class = PCI_CLASS_MULTIMEDIA_HD_AUDIO << 8, .class_mask = 0xffffff, .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_HDMI }, + /* Zhaoxin */ + { PCI_DEVICE(0x1d17, 0x3288), .driver_data = AZX_DRIVER_ZHAOXIN }, { 0, } }; MODULE_DEVICE_TABLE(pci, azx_ids); -- 2.7.4

2 1

[alsa-devel] [PATCH] ALSA: isa/wavefront: remove redundant assignment to pointer bptr
by Colin King 02 Aug '19

02 Aug '19

From: Colin Ian King <colin.king(a)canonical.com> The pointer bptr is being assigned a value that is never read and it is being updated in the next statement with a new value. The initialization is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- sound/isa/wavefront/wavefront_synth.c | 1 - 1 file changed, 1 deletion(-) diff --git a/sound/isa/wavefront/wavefront_synth.c b/sound/isa/wavefront/wavefront_synth.c index aec1c46e6697..c5b1d5900eed 100644 --- a/sound/isa/wavefront/wavefront_synth.c +++ b/sound/isa/wavefront/wavefront_synth.c @@ -788,7 +788,6 @@ wavefront_send_patch (snd_wavefront_t *dev, wavefront_patch_info *header) dev->patch_status[header->number] |= WF_SLOT_FILLED; - bptr = buf; bptr = munge_int32 (header->number, buf, 2); munge_buf ((unsigned char *)&header->hdr.p, bptr, WF_PATCH_BYTES); -- 2.20.1

2 1

[alsa-devel] [PATCH v2 0/6] ASoC: improve codec to codec link support
by Jerome Brunet 01 Aug '19

01 Aug '19

As explained in this previous series [0], on Amlogic, we are using codec to codec links to deal with the glue which is between the i2s backends and the synopsys hdmi controller. This worked well until I tried to .get_eld() support in the dw-hdmi-i2s driver. Doing so adds channel mapping controls to the codec. This shown several problem 1) .pcm_new() is not called on codec to codec links. struct snd_soc_pcm_runtime do not even have a valid .pcm 2) struct snd_pcm_substream and struct snd_pcm_runtime are ephemeral This is a problem if a control needs to access them The goal of this patchset is to resolve the above issues and improve the codec to codec link support enough to correctly handle the hdmi-codec The support of these codec to codec links could probably be improved in the future to behave like any other link and use soc_pcm_open(), soc_pcm_hw_params(), etc... The challenge lies in the dapm mutex. The soc_pcm call dapm function locking this mutex but the dapm mutex is already held in snd_soc_dai_link_event() Changes since v1 [1]: * Fix rebase on Murimoto-san's patches * Allocate params dynamically again and refactor the pre_pmu code to simplify the error handling and rollback a bit [0]: https://lkml.kernel.org/r/20190515131858.32130-1-jbrunet@baylibre.com [1]: https://lkml.kernel.org/r/20190724162405.6574-1-jbrunet@baylibre.com Jerome Brunet (6): ASoC: codec2codec: run callbacks in order ASoC: codec2codec: name link using stream direction ASoC: codec2codec: deal with params when necessary ASoC: create pcm for codec2codec links as well ASoC: codec2codec: remove ephemeral variables ASoC: codec2codec: fill some of the runtime stream parameters sound/soc/soc-core.c | 42 +++------ sound/soc/soc-dapm.c | 220 +++++++++++++++++++++++++++---------------- sound/soc/soc-pcm.c | 35 ++++++- 3 files changed, 182 insertions(+), 115 deletions(-) -- 2.21.0

2 12

[alsa-devel] [PATCH] ASoC: zx-tdm: remove redundant assignment to ts_width on error return path
by Colin King 01 Aug '19

01 Aug '19

From: Colin Ian King <colin.king(a)canonical.com> The value assigned to ts_width is never read on the error return path so the assignment is redundant and can be removed. Remove it. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- sound/soc/zte/zx-tdm.c | 1 - 1 file changed, 1 deletion(-) diff --git a/sound/soc/zte/zx-tdm.c b/sound/soc/zte/zx-tdm.c index 5e877fe9ba7b..0e5a05b25a77 100644 --- a/sound/soc/zte/zx-tdm.c +++ b/sound/soc/zte/zx-tdm.c @@ -211,7 +211,6 @@ static int zx_tdm_hw_params(struct snd_pcm_substream *substream, ts_width = 1; break; default: - ts_width = 0; dev_err(socdai->dev, "Unknown data format\n"); return -EINVAL; } -- 2.20.1

2 1

[alsa-devel] [PATCH v2 1/3] ASoC: Intel: SoC: skylake: no need to check return value of debugfs_create functions
by Greg Kroah-Hartman 01 Aug '19

01 Aug '19

When calling debugfs functions, there is no need to ever check the return value. The function can work or not, but the code logic should never do something different based on this. Also, if a debugfs call fails, userspace is notified with an error in the log, so no need to log the error again. Cc: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Cc: Liam Girdwood <liam.r.girdwood(a)linux.intel.com> Cc: Jie Yang <yang.jie(a)linux.intel.com> Cc: Mark Brown <broonie(a)kernel.org> Cc: Jaroslav Kysela <perex(a)perex.cz> Cc: Takashi Iwai <tiwai(a)suse.com> Cc: alsa-devel(a)alsa-project.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- v2: rebase on 5.3-rc1 change Subject line to match the subsystem better rework based on debugfs core now reporting errors. sound/soc/intel/skylake/skl-debug.c | 28 +++++----------------------- 1 file changed, 5 insertions(+), 23 deletions(-) diff --git a/sound/soc/intel/skylake/skl-debug.c b/sound/soc/intel/skylake/skl-debug.c index b9b4a72a4334..1d6240ad6112 100644 --- a/sound/soc/intel/skylake/skl-debug.c +++ b/sound/soc/intel/skylake/skl-debug.c @@ -162,10 +162,8 @@ void skl_debug_init_module(struct skl_debug *d, struct snd_soc_dapm_widget *w, struct skl_module_cfg *mconfig) { - if (!debugfs_create_file(w->name, 0444, - d->modules, mconfig, - &mcfg_fops)) - dev_err(d->dev, "%s: module debugfs init failed\n", w->name); + debugfs_create_file(w->name, 0444, d->modules, mconfig, + &mcfg_fops); } static ssize_t fw_softreg_read(struct file *file, char __user *user_buf, @@ -222,34 +220,18 @@ struct skl_debug *skl_debugfs_init(struct skl *skl) return NULL; /* create the debugfs dir with platform component's debugfs as parent */ - d->fs = debugfs_create_dir("dsp", - skl->component->debugfs_root); - if (IS_ERR(d->fs) || !d->fs) { - dev_err(&skl->pci->dev, "debugfs root creation failed\n"); - return NULL; - } + d->fs = debugfs_create_dir("dsp", skl->component->debugfs_root); d->skl = skl; d->dev = &skl->pci->dev; /* now create the module dir */ d->modules = debugfs_create_dir("modules", d->fs); - if (IS_ERR(d->modules) || !d->modules) { - dev_err(&skl->pci->dev, "modules debugfs create failed\n"); - goto err; - } - if (!debugfs_create_file("fw_soft_regs_rd", 0444, d->fs, d, - &soft_regs_ctrl_fops)) { - dev_err(d->dev, "fw soft regs control debugfs init failed\n"); - goto err; - } + debugfs_create_file("fw_soft_regs_rd", 0444, d->fs, d, + &soft_regs_ctrl_fops); return d; - -err: - debugfs_remove_recursive(d->fs); - return NULL; } void skl_debugfs_exit(struct skl *skl) -- 2.22.0

3 6

[alsa-devel] [PATCH 1/3] ASoC: amd: use DMA addr rather than CPU pa for audio buffer
by Ravulapati Vishnu vardhan rao 01 Aug '19

01 Aug '19

We shouldn't assume CPU physical address we get from page_to_phys() is same as DMA address we get from dma_alloc_coherent(). On x86_64, we won't run into any problem with the assumption when dma_ops is nommu_dma_ops. However, DMA address is IOVA when IOMMU is enabled. And it's most likely different from CPU physical address when AMD IOMMU is not in passthrough mode. Signed-off-by: Vijendar Mukunda <vijendar.mukunda(a)amd.com> Tested-by: RAVULAPATI VISHNU VARDHAN RAO <Vishnuvardhanrao.Ravulapati(a)amd.com> --- sound/soc/amd/raven/acp3x-pcm-dma.c | 23 +++++++++++------------ 1 file changed, 11 insertions(+), 12 deletions(-) diff --git a/sound/soc/amd/raven/acp3x-pcm-dma.c b/sound/soc/amd/raven/acp3x-pcm-dma.c index a4ade6b..49c4872 100644 --- a/sound/soc/amd/raven/acp3x-pcm-dma.c +++ b/sound/soc/amd/raven/acp3x-pcm-dma.c @@ -31,7 +31,7 @@ struct i2s_stream_instance { u16 num_pages; u16 channels; u32 xfer_resolution; - struct page *pg; + dma_addr_t dma_addr; u64 bytescount; void __iomem *acp3x_base; }; @@ -211,11 +211,13 @@ static irqreturn_t i2s_irq_handler(int irq, void *dev_id) static void config_acp3x_dma(struct i2s_stream_instance *rtd, int direction) { u16 page_idx; - u64 addr; + dma_addr_t addr; u32 low, high, val, acp_fifo_addr; - struct page *pg = rtd->pg; - /* 8 scratch registers used to map one 64 bit address */ + addr = rtd->dma_addr; + /* 8 scratch registers used to map one 64 bit address. + * For 2 pages (8192 * 2 bytes), it will be 16 registers. + */ if (direction == SNDRV_PCM_STREAM_PLAYBACK) val = 0; else @@ -229,7 +231,6 @@ static void config_acp3x_dma(struct i2s_stream_instance *rtd, int direction) for (page_idx = 0; page_idx < rtd->num_pages; page_idx++) { /* Load the low address of page int ACP SRAM through SRBM */ - addr = page_to_phys(pg); low = lower_32_bits(addr); high = upper_32_bits(addr); @@ -239,7 +240,7 @@ static void config_acp3x_dma(struct i2s_stream_instance *rtd, int direction) + 4); /* Move to next physically contiguos page */ val += 8; - pg++; + addr += PAGE_SIZE; } if (direction == SNDRV_PCM_STREAM_PLAYBACK) { @@ -340,10 +341,8 @@ static int acp3x_dma_hw_params(struct snd_pcm_substream *substream, struct snd_pcm_hw_params *params) { int status; - u64 size; - struct page *pg; - struct snd_pcm_runtime *runtime = substream->runtime; - struct i2s_stream_instance *rtd = runtime->private_data; + uint64_t size; + struct i2s_stream_instance *rtd = substream->runtime->private_data; if (!rtd) return -EINVAL; @@ -355,8 +354,8 @@ static int acp3x_dma_hw_params(struct snd_pcm_substream *substream, memset(substream->runtime->dma_area, 0, params_buffer_bytes(params)); pg = virt_to_page(substream->dma_buffer.area); - if (pg) { - rtd->pg = pg; + if (substream->dma_buffer.area) { + rtd->dma_addr = substream->dma_buffer.addr; rtd->num_pages = (PAGE_ALIGN(size) >> PAGE_SHIFT); config_acp3x_dma(rtd, substream->stream); status = 0; -- 2.7.4

2 4

[alsa-devel] standard read/write vs event waiting routines (poll) in ALSA
by Diego Buffa 01 Aug '19

01 Aug '19

Hi all, I am trying to learn more about ALSA, I always used example found in the howtos but now I would go further. I went though ALSA documentation ( https://www.alsa-project.org/alsa-doc/alsa-lib/pcm.html) and in the specific the transfer methods. Basically I don't understand the advantages of using poll instead of traditional blocking read/write. Generally I know that using poll I can multiplex I/O on several files, but in ALSA I cannot create the poll descriptor array as I want, as I must use snd_pcm_poll_descriptors() which requires that the poll descriptor array should have the size returned by snd_pcm_poll_descriptors_count(). Am I supposed to realloc the poll array descriptor once I set it up with ALSA, and add my own files? Should I then always check poll array descriptor with snd_pcm_poll_descriptors_revents() before checking my own files? And in this case it is safe to call snd_pcm_poll_descriptors_revents() with a poll array descriptor bigger than the size returned by snd_pcm_poll_descriptors_count()? Many thanks in advance.

2 2

[alsa-devel] snd_pcm_delay in snd_usb_audio
by Roeland Jansen 01 Aug '19

01 Aug '19

just subscribed to the list (I hope). while troubleshooting a different thing in audio I stumbled across the following and it's in the logs more than once. what do you need from me? this is opensuse 15.1 leap. warn:2019-07-31T19:12:58.207893+02:00 taplop pulseaudio[28164]: [alsa-source-USB Audio] alsa-util.c: Most likely this is a bug in the ALSA driver 'snd_usb_audio'. Please report this issue to the ALSA developers. warn:2019-07-31T19:12:58.208183+02:00 taplop pulseaudio[28164]: [alsa-source-USB Audio] alsa-util.c: snd_pcm_dump(): warn:2019-07-31T19:12:58.208473+02:00 taplop pulseaudio[28164]: [alsa-source-USB Audio] alsa-util.c: Hardware PCM card 2 'USB Audio CODEC' device 0 subdevice 0 warn:2019-07-31T19:12:58.208760+02:00 taplop pulseaudio[28164]: [alsa-source-USB Audio] alsa-util.c: Its setup is: warn:2019-07-31T19:12:58.209071+02:00 taplop pulseaudio[28164]: [alsa-source-USB Audio] alsa-util.c: stream : CAPTURE warn:2019-07-31T19:12:58.209366+02:00 taplop pulseaudio[28164]: [alsa-source-USB Audio] alsa-util.c: access : MMAP_INTERLEAVED warn:2019-07-31T19:12:58.209671+02:00 taplop pulseaudio[28164]: [alsa-source-USB Audio] alsa-util.c: format : S16_LE warn:2019-07-31T19:12:58.209958+02:00 taplop pulseaudio[28164]: [alsa-source-USB Audio] alsa-util.c: subformat : STD warn:2019-07-31T19:12:58.210245+02:00 taplop pulseaudio[28164]: [alsa-source-USB Audio] alsa-util.c: channels : 2 warn:2019-07-31T19:12:58.210588+02:00 taplop pulseaudio[28164]: [alsa-source-USB Audio] alsa-util.c: rate : 48000 warn:2019-07-31T19:12:58.210880+02:00 taplop pulseaudio[28164]: [alsa-source-USB Audio] alsa-util.c: exact rate : 48000 (48000/1) warn:2019-07-31T19:12:58.211198+02:00 taplop pulseaudio[28164]: [alsa-source-USB Audio] alsa-util.c: msbits : 16 warn:2019-07-31T19:12:58.211746+02:00 taplop pulseaudio[28164]: [alsa-source-USB Audio] alsa-util.c: buffer_size : 88200 warn:2019-07-31T19:12:58.212028+02:00 taplop pulseaudio[28164]: [alsa-source-USB Audio] alsa-util.c: period_size : 44100 warn:2019-07-31T19:12:58.212261+02:00 taplop pulseaudio[28164]: [alsa-source-USB Audio] alsa-util.c: period_time : 918750 warn:2019-07-31T19:12:58.212548+02:00 taplop pulseaudio[28164]: [alsa-source-USB Audio] alsa-util.c: tstamp_mode : ENABLE warn:2019-07-31T19:12:58.212785+02:00 taplop pulseaudio[28164]: [alsa-source-USB Audio] alsa-util.c: tstamp_type : MONOTONIC warn:2019-07-31T19:12:58.213014+02:00 taplop pulseaudio[28164]: [alsa-source-USB Audio] alsa-util.c: period_step : 1 warn:2019-07-31T19:12:58.213238+02:00 taplop pulseaudio[28164]: [alsa-source-USB Audio] alsa-util.c: avail_min : 44100 warn:2019-07-31T19:12:58.213470+02:00 taplop pulseaudio[28164]: [alsa-source-USB Audio] alsa-util.c: period_event : 0 warn:2019-07-31T19:12:58.213722+02:00 taplop pulseaudio[28164]: [alsa-source-USB Audio] alsa-util.c: start_threshold : -1 warn:2019-07-31T19:12:58.213995+02:00 taplop pulseaudio[28164]: [alsa-source-USB Audio] alsa-util.c: stop_threshold : 6206523236469964800 warn:2019-07-31T19:12:58.214465+02:00 taplop pulseaudio[28164]: [alsa-source-USB Audio] alsa-util.c: silence_threshold: 0 warn:2019-07-31T19:12:58.214730+02:00 taplop pulseaudio[28164]: [alsa-source-USB Audio] alsa-util.c: silence_size : 0 warn:2019-07-31T19:12:58.214971+02:00 taplop pulseaudio[28164]: [alsa-source-USB Audio] alsa-util.c: boundary : 6206523236469964800 warn:2019-07-31T19:12:58.215228+02:00 taplop pulseaudio[28164]: [alsa-source-USB Audio] alsa-util.c: appl_ptr : 45284903 warn:2019-07-31T19:12:58.215510+02:00 taplop pulseaudio[28164]: [alsa-source-USB Audio] alsa-util.c: hw_ptr : 55414415 warn:2019-07-31T21:55:16.513279+02:00 taplop pulseaudio[28164]: [alsa-sink-USB Audio] alsa-util.c: Got POLLNVAL from ALSA warn:2019-07-31T21:55:16.513748+02:00 taplop pulseaudio[28164]: [alsa-sink-USB Audio] alsa-util.c: Could not recover from POLLERR|POLLNVAL|POLLHUP with snd_pcm_prepare(): No such device

1 0