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

[alsa-devel] [PATCH] ALSA: hda - repoll jack presence state on resume
by Jaroslav Kysela 12 Aug '16

12 Aug '16

The jack detection on resume might fail on some hardware (Lenovo T430s, T440s and X1 Carbon 2016). The codec registers reports that the jack is not used and the unsolicited event is not sent on change (or perhaps, it's lost?). This patch will repoll the jack presence state after 100ms again. Because the jack status is updated from two workqueues now, create a new codec->jack_mutex to protect the concurrent access. Signed-off-by: Jaroslav Kysela <perex(a)perex.cz> --- sound/pci/hda/hda_bind.c | 2 ++ sound/pci/hda/hda_codec.c | 9 ++++++++- sound/pci/hda/hda_codec.h | 1 + 3 files changed, 11 insertions(+), 1 deletion(-) diff --git a/sound/pci/hda/hda_bind.c b/sound/pci/hda/hda_bind.c index 6efadbf..81a9284 100644 --- a/sound/pci/hda/hda_bind.c +++ b/sound/pci/hda/hda_bind.c @@ -42,8 +42,10 @@ static void hda_codec_unsol_event(struct hdac_device *dev, unsigned int ev) { struct hda_codec *codec = container_of(dev, struct hda_codec, core); + mutex_lock(&codec->jack_mutex); if (codec->patch_ops.unsol_event) codec->patch_ops.unsol_event(codec, ev); + mutex_unlock(&codec->jack_mutex); } /** diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index 9913be8..4339e98 100644 --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -592,8 +592,10 @@ static void hda_jackpoll_work(struct work_struct *work) struct hda_codec *codec = container_of(work, struct hda_codec, jackpoll_work.work); + mutex_lock(&codec->jack_mutex); snd_hda_jack_set_dirty_all(codec); snd_hda_jack_poll_all(codec); + mutex_unlock(&codec->jack_mutex); if (!codec->jackpoll_interval) return; @@ -837,6 +839,7 @@ int snd_hda_codec_new(struct hda_bus *bus, struct snd_card *card, codec->addr = codec_addr; mutex_init(&codec->spdif_mutex); mutex_init(&codec->control_mutex); + mutex_init(&codec->jack_mutex); snd_array_init(&codec->mixers, sizeof(struct hda_nid_item), 32); snd_array_init(&codec->nids, sizeof(struct hda_nid_item), 32); snd_array_init(&codec->init_pins, sizeof(struct hda_pincfg), 16); @@ -3002,8 +3005,12 @@ static void hda_call_codec_resume(struct hda_codec *codec) if (codec->jackpoll_interval) hda_jackpoll_work(&codec->jackpoll_work.work); - else + else { snd_hda_jack_report_sync(codec); + /* Some hw requires a little time to settle things */ + schedule_delayed_work(&codec->jackpoll_work, + msecs_to_jiffies(100)); + } atomic_dec(&codec->core.in_pm); } diff --git a/sound/pci/hda/hda_codec.h b/sound/pci/hda/hda_codec.h index 373fcad..6a4a631 100644 --- a/sound/pci/hda/hda_codec.h +++ b/sound/pci/hda/hda_codec.h @@ -213,6 +213,7 @@ struct hda_codec { struct mutex spdif_mutex; struct mutex control_mutex; + struct mutex jack_mutex; struct snd_array spdif_out; unsigned int spdif_in_enable; /* SPDIF input enable? */ const hda_nid_t *slave_dig_outs; /* optional digital out slave widgets */ -- 2.5.5

2 1

[alsa-devel] [PATCH -next] ASoC: atmel-pdmic: add missing clk_disable_unprepare() on error in atmel_pdmic_cpu_dai_startup()
by Wei Yongjun 12 Aug '16

12 Aug '16

Add the missing clk_disable_unprepare() before return from atmel_pdmic_cpu_dai_startup() in the error handling case. Signed-off-by: Wei Yongjun <weiyj.lk(a)gmail.com> --- sound/soc/atmel/atmel-pdmic.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/sound/soc/atmel/atmel-pdmic.c b/sound/soc/atmel/atmel-pdmic.c index 2a3a41f..a67e31b 100644 --- a/sound/soc/atmel/atmel-pdmic.c +++ b/sound/soc/atmel/atmel-pdmic.c @@ -115,8 +115,10 @@ static int atmel_pdmic_cpu_dai_startup(struct snd_pcm_substream *substream, return ret; ret = clk_prepare_enable(dd->pclk); - if (ret) + if (ret) { + clk_disable_unprepare(dd->gclk); return ret; + } /* Clear all bits in the Control Register(PDMIC_CR) */ regmap_write(dd->regmap, PDMIC_CR, 0);

2 1

[alsa-devel] [PATCH -next] ASoC: topology: Fix error return code in soc_tplg_dapm_widget_create()
by Wei Yongjun 12 Aug '16

12 Aug '16

Fix to return error code -ENOMEM instead of 0 when failed to create widget, as done elsewhere in this function. Fixes: 8a9782346dcc ("ASoC: topology: Add topology core") Signed-off-by: Wei Yongjun <weiyj.lk(a)gmail.com> --- sound/soc/soc-topology.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/soc-topology.c b/sound/soc/soc-topology.c index 05a18f6..a9e83a2 100644 --- a/sound/soc/soc-topology.c +++ b/sound/soc/soc-topology.c @@ -1476,6 +1476,7 @@ widget: if (widget == NULL) { dev_err(tplg->dev, "ASoC: failed to create widget %s controls\n", w->name); + ret = -ENOMEM; goto hdr_err; }

2 1

[alsa-devel] [PATCH] ASoC: omap-mcbsp: Enable TX/RX under and overflow interrupts
by Peter Ujfalusi 12 Aug '16

12 Aug '16

FIFO under or overflow can cause channel swaps and data loss. Reporting them can help to identify such events. Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com> --- sound/soc/omap/mcbsp.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/soc/omap/mcbsp.c b/sound/soc/omap/mcbsp.c index 76ce33199bf9..06fec5699cc8 100644 --- a/sound/soc/omap/mcbsp.c +++ b/sound/soc/omap/mcbsp.c @@ -221,7 +221,8 @@ void omap_mcbsp_config(struct omap_mcbsp *mcbsp, /* Enable TX/RX sync error interrupts by default */ if (mcbsp->irq) - MCBSP_WRITE(mcbsp, IRQEN, RSYNCERREN | XSYNCERREN); + MCBSP_WRITE(mcbsp, IRQEN, RSYNCERREN | XSYNCERREN | + RUNDFLEN | ROVFLEN | XUNDFLEN | XOVFLEN); } /** -- 2.9.2

2 1

[alsa-devel] [PATCH v2 0/2] ASoC: Extended SPDIF support to Allwinner A31 SoCs
by codekipper＠gmail.com 12 Aug '16

12 Aug '16

From: Marcus Cooper <codekipper(a)gmail.com> This patch set extends the current support of the Allwinner SPDIF transceiver to include the A31 SoC. For now just the SPDIF transmitter has been tested on the Mele I7. In order for this patch set to be functional then we require changes to the clocks and the device tree. For those that are interested I've pushed all the required patches here https://github.com/codekipper/linux-sunxi/commits/a31-spdif Thanks in advance, CK --- Changes since v1: - Corrected mistake in bindings documentation Marcus Cooper (2): ASoC: sunxi: Add bindings for sun6i to SPDIF ASoC: sunxi: compatibility for sun6i to SPDIF .../devicetree/bindings/sound/sunxi,sun4i-spdif.txt | 3 +++ sound/soc/sunxi/sun4i-spdif.c | 17 ++++++++++++++++- 2 files changed, 19 insertions(+), 1 deletion(-) -- 2.9.2

2 3

[alsa-devel] [PATCH -next] ASoC: Intel: Skylake: Fix error return code in skl_probe()
by Wei Yongjun 12 Aug '16

12 Aug '16

Fix to return error code -ENODEV from the error handling case instead of 0, as done elsewhere in this function. Fixes: 87b2bdf02278 ("ASoC: Intel: Skylake: Initialize NHLT table") Signed-off-by: Wei Yongjun <weiyj.lk(a)gmail.com> --- sound/soc/intel/skylake/skl.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/sound/soc/intel/skylake/skl.c b/sound/soc/intel/skylake/skl.c index a893ca1..2989c16 100644 --- a/sound/soc/intel/skylake/skl.c +++ b/sound/soc/intel/skylake/skl.c @@ -672,8 +672,10 @@ static int skl_probe(struct pci_dev *pci, skl->nhlt = skl_nhlt_init(bus->dev); - if (skl->nhlt == NULL) + if (skl->nhlt == NULL) { + err = -ENODEV; goto out_free; + } skl_nhlt_update_topology_bin(skl);

2 1

Re: [alsa-devel] Underrun with 2 periods on skylake HDA driver
by Dharageswari R 12 Aug '16

12 Aug '16

On Tue, Aug 09, 2016 at 11:54:22PM -0700, Clemens Ladisch wrote: > Dharageswari R wrote: > > While doing the validation of Skylake HDA driver using aplay and > > following parameters, we noticed underrun issues. > > > > buffer_size : 9600 > > period_size : 4800 > > > > After doing further debugging, what I found is > > > > 1.DMA complete interrupt occurs for the first period. > > 2.Driver reads DMA position in buffer pointer and gets value of 4784. > > The interrupt says that the buffer descriptor list entry has been > completed, but the position in buffer pointer says that the entry has > not yet been completed. > yes > > I checked with HDA architects and they are saying that when the DMA > > completion interrupt occurs there can be slight delay before the DMA > > Position In Buffer Pointer gets updated. > > The driver's interrupt handler takes care to read the interrupt status > register first, so that any pending memory writes from the device are > flushed. > > Of course, this does not work if the device posts writes _after_ the > interrupt has been raised. This is a bug in the hardware. > > > So driver is expected to refill data based on whatever content is > > reflected in the DMA Position In Buffer. > > No, that's not how it works. The driver waits until all 4800 frames > are available, and the only way to wake it up is with an interrupt. > There is no other interrupt apart from the buffer completion interrupt to know the post write completion. The only option here would be to poll till the position is equal or more than the period boundary with timeout before the period elapsed reporting. I thought of avoiding this if possible but doesnt seem to be true. Thanks for your reply. I will make sure that the driver reports period ellapsed at or above the period boundary. > > It appears the driver must work around this bug by scheduling another > interrupt after the delay. Is there an upper limit (time or frames) for > this delay? The upper limit is not deterministic in this case. > > > Regards, > Clemens --

2 2

Re: [alsa-devel] [PATCH] ALSA: usb: caiaq: audio: don't print error when allocating urb fails
by Takashi Iwai 11 Aug '16

11 Aug '16

On Thu, 11 Aug 2016 22:40:11 +0200, Wolfram Sang wrote: > > kmalloc will print enough information in case of failure. > > Signed-off-by: Wolfram Sang <wsa-dev(a)sang-engineering.com> Applied, thanks. Takashi > --- > sound/usb/caiaq/audio.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/sound/usb/caiaq/audio.c b/sound/usb/caiaq/audio.c > index 327f8642ca80e6..8f66ba730d69d9 100644 > --- a/sound/usb/caiaq/audio.c > +++ b/sound/usb/caiaq/audio.c > @@ -739,7 +739,6 @@ static struct urb **alloc_urbs(struct snd_usb_caiaqdev *cdev, int dir, int *ret) > for (i = 0; i < N_URBS; i++) { > urbs[i] = usb_alloc_urb(FRAMES_PER_URB, GFP_KERNEL); > if (!urbs[i]) { > - dev_err(dev, "unable to usb_alloc_urb(), OOM!?\n"); > *ret = -ENOMEM; > return urbs; > } > -- > 2.8.1 > >

1 0

[alsa-devel] [PATCH v3 0/4] ALSA: seq: obsolete change of address limit
by Takashi Sakamoto 11 Aug '16

11 Aug '16

Hi, ALSA sequencer core has two types of clients; application and kernel. For kernel clients, the core should handle data in kernel space, meanwhile this is achieved with a hack of change of address limit. This should be purged. This patchset is a revised version of my previous one: [alsa-devel] obsolete change of address limit http://mailman.alsa-project.org/pipermail/alsa-devel/2016-August/110937.html Changes in v2: - Use '_IOC_SIZE' macro to calculate the size of argument of ioctl command. - Keep redundant longer name. - Improve comments. - Merge some patches relevant to the same features. Changes in v3: - Improve series of patch - Use 'dir' field of ioctl command to detect the length of argument Regards Takashi Sakamoto (4): ALSA: seq: add documentation for snd_seq_kernel_client_ctl ALSA: seq: add an alternative way to handle ioctl requests ALSA: seq: change ioctl command operation to get data in kernel space ALSA: seq: obsolete change of address limit sound/core/seq/seq_clientmgr.c | 721 ++++++++++++++++++----------------------- sound/core/seq/seq_compat.c | 7 +- 2 files changed, 317 insertions(+), 411 deletions(-) -- 2.7.4

3 8

Re: [alsa-devel] [PATCH v8 1/5] video: rmk's HDMI notification prototype
by Russell King - ARM Linux 11 Aug '16

11 Aug '16

On Thu, Aug 11, 2016 at 04:49:28PM +0200, Hans Verkuil wrote: > On 08/11/16 16:16, Russell King - ARM Linux wrote: > > On Thu, Aug 11, 2016 at 12:49:21PM +0200, Hans Verkuil wrote: > >> I thought this was the raw EDID data. But if you pass a struct edid around, > >> then why not make this const struct edid *edid? I fail to see why you would > >> want to use a void pointer here. > > > > struct edid is a DRM thing - it's not generic. Using struct edid here > > would force everyone to use the DRM structure, whereas other subsystems > > use, eg, unsigned char. > > So how the edid pointer should be interpreted depends on which subsystem > sends it? That doesn't sound right. It makes it really hard for the drivers > receiving the notifications. No, that's wrong... and I really don't see why you're trying to make a meal of this. In both cases, it's the EDID as received from the device. One subsystem happens to represent it internally as a "struct edid" in its drivers, another subsystem uses "unsigned char []". In order to _cleanly_ accept both styles, without having to resort to driver authors needing to litter their code with lots of idiotic casts, I'm accepting a void * pointer, so that we can accept _both_ a struct edid and an unsigned char array. Both are compatible with each other. Both have the same bytes at the same offset. There is no difference between them other than the C types that are used by each subsystem. > But I understand that currently the main purpose of the hdmi_event_new_edid > is to get the physical address from the EDID for CEC? Or do you have other > uses as well? That is one use, but if an audio driver wants to parse the raw EDID instead of the ELD, it can. What I want to avoid is having the video driver parse lots of different bits from the EDID and then send lots of events "just in case" something wants some of the parsed information - it's much more efficient to give drivers the raw information and allow them to parse what they need from the EDID. I'm not convinced that parsing out the physical address, and then passing that from the video side is a good idea. The reason I made an exception for the ELD is because (a) it's already passed between video and audio drivers, (b) the code we have present to convert an EDID to ELD is in DRM, and requires DRM data structures which won't be available in an audio driver. If you want a mechanism to pass just the physical address, we could add it, and require CEC drivers to make use of both the EDID or physical address events. That would mean situations where the physical address is known to be fixed before hand can be easily catered for. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.

1 0