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

Re: [alsa-devel] twl4030: runtime audio capture channel swapping (kernel 3.18+)
by Peter Ujfalusi 15 Aug '16

15 Aug '16

Hi Akram, On 08/11/16 04:07, Akram Hameed wrote: > Hei Peter, > > Sorry to bother you directly, but I got no response to my questions on the > alsa-devel list and since you seem to be a maintainer of the omap mcbsp and > pcm code, I thought you would: Sorry, it looks like I have missed your mail in alsa-devel. Adding it to CC and also looping Jarkko. > a) Want to be aware of my issues > > b) Might help point me in a direction to fix things. > > In short: I am capturing a stereo audio stream, 16-bit, 48kHz using a gumstix > overo that is quite similar to the older beagleboards (we are using two > variants - one is OMAP3530 based and the other, DM3730). Periodically, left > channel audio will move to right channel and vice versa over time. > > Previously my company was using a branch from kernel 3.0 (made by Steve > Sakoman) and our audio capture was fine - no swapping, ever. Due to > instabilities with the old mmc interface (unpredictable failures using newer > UHS-3 cards), we have been forced to migrate to a newer kernel, and here I > encounter the channel swap issue. > > To me, it seems the problem is like what is described > here: http://processors.wiki.ti.com/index.php/McBSP_Channel_Swapping > Which I presume draws on a discussion you had years ago with one > Ying: http://mailman.alsa-project.org/pipermail/alsa-devel/2011-February/036895.h… > > After spending quite some time reading and investigating the various > registers, I come to the following conclusions: > > 1) Audio codec (TWL) appears to be configured in the same between working > (3.0) and non working (3.18) kernels, except that voice mode is active also > and some gain settings are different (different defaults, I suppose). I have a > comparison of these register maps if you want to see. > > 2) McBSP2 is also configured the same between old and new kernels, though I > note for some reason the ID pulled by dev_dbg looks spurious, though I guess > unrelated to my issue. > Configuring McBSP255 phys_base: 0x49022000 > **** McBSP255 regs **** > DRR2: 0xf88a > DRR1: 0x0000 > DXR2: 0x0000 > DXR1: 0x0000 > SPCR2: 0x0230 > SPCR1: 0x0031 > RCR2: 0x8041 > RCR1: 0x0040 > XCR2: 0x8041 > XCR1: 0x0040 > SRGR2: 0x001f > SRGR1: 0x0f00 > PCR0: 0x000f > *********************** We must drop the DRR1/2 (and probably DXR1/2) dump... By reading the DRR register with the debug code we introduce underflow. The data must be only moved by the DMA from the DATA registers. If we have low threshold it is more likely to cause channel swap and it is for sure going to introduce missing data - the data is going to the kernel log instead of the receive buffer. > 3) My channel swapping occurs when using dma_op_mode element OR threshold mode > in kernel 3.18+ (I have only tested on 3.18 and 4.4, for the record). Setting > a threshold of 960 with period size 10ms reduces the frequency of the swap. > > I did notice that DMA CCR is different between kernel 3 and 3.18 when > operating in ELEMENT mode. > > Version 3 kernel: > > DMA4:Chan5 @ 48056200:CCR=/dev/mem opened. > Memory mapped at address 0x4013b000. > Read at address 0x48056200 (0x4013b200): 0x01084482 > > > Version 3.18 kernel: > > DMA4:Chan5 @ 48056200:CCR=/dev/mem opened. > Memory mapped at address 0xb6fa1000. > Read at address 0x48056200 (0xb6fa1200): 0x010C44A2 <- McBSP2 RX request. > > > Interestingly, it appears the new kernel (3.18+) is using packet mode even > when 'element' is selected. If I choose dma_op_mode THRESHOLD in the older > kernel 3.0, I see the same 0x010C44A2 in the CCR as I do in 3.18+. Yes, I have made a change that if we are in element mode we will still use packet mode to transfer one sample per DMA request. Real element mode will be used only in case of mono audio. If the audio is 2+ channels we are using packet mode to transfer the sample. This does helped to avoid swaps as we send/receive one sample at a time from/to McBSP. > 4) I have not observed playback channel swapping. I am unsure why. > > 5) I enabled underflow and overflow reporting in the McBSP IRQ handler (kernel > 3.18+ since older 3 kernel did not have such a handler and I have not patched > one in yet), and found several interesting things. I can not recall the history, but between 3.0 and 3.18 we might moved to dmaengine based PCM for OMAPs. But I still have no recollection to experience capture side channel swap. > a) Swap definitely is happening due to Overflow, but so far I only observe an > overflow when using dma_op_mode THRESHOLD. When using dma_op_mode THRESHOLD, > the swap does not seem to coincide with an underflow, so I am at a loss to > explain further. How does you application works? What are the parameters ALSA is configured for capture/playback (cat /proc/asound/card0/pcm0p/sub0/hw_params; cat /proc/asound/card0/pcm0c/sub0/hw_params) - number of periods, etc? > b) In dma_op_mode ELEMENT, I get Underflow reported almost every second in > this newer kernel (again, using 10ms period size). Channel swap only seems to > occur ever few hours, however, and I do not believe I have observed the > overflow at all in ELEMENT mode. So, the swap occurs due to underflow, maybe? Underflow in McBSP or Underflow by ALSA? Underflow in McBSP RX tells that DMA is trying to read data when the FIFO is empty. This can only happen if something else is reading data also from the McBSP since we configure the McBSP and sDMA in sync. Overflow in McBSP happens when DAM is failing to read the data out from McBSP FIFO in time - FIFO is full and McBSP discards the incoming data) ALSA underflow is different, it happens when the application fails to process the period in time and the DMA starts to rewrite the buffer. This happens when you have one thread to capture/process/play. If the process/play takes more time than we go round in the boffer (buffer time) we have ALSA underflow. You can try to increase the number of periods or separate the capture and process/play jobs into separate threads. > My plan from now is to get my JTAG up and running and try and make the change > "If you are working with 16-bit stereo data a nice solution is to configure > the McBSP for a single 32-bit element instead of 2 16-bit elements. " The McBSP driver does not have support for this ATM. There is a side effect of this AFAIK: channels will be swapped, but I have not tested it. Using 32bit element instead of 2x16bit helps in case when you do not have FIFO for sure to give more time for the DMA. Also in case of underrun/overrun you will be loosing both channel's data so the swap would not happen. > If you have any helpful suggestions, I would really appreciate them. I am > operating under the assumption I can leave the TWL codec settings as they are > and just 'lie' to McBSP about the data framing. Namely, specify single phase > frame with 1 word of 32 bits, and set DMA packet size to a 32bit word also. > Since 16 bit mode operates by default in dual phase, I am not sure if the > signalling will work correctly, but I guess I will find out. Yeah, this is also going to be a problem. As twl4030 is using I2S when in stereo mode, with fake mono 32bit you can not use I2S signals. But since McBSP is looking for the start condition, configuring it for DSP_A mode will probably going to start the reception/playback at the correct time. > Again, my apologies for contacting you directly. Hopefully the information I > have provided can help diagnosing the real problem in the kernel. No problem. Sorry for that I have missed your mail in alsa-devel. > For me, I > must find a solution in the near-term so I will try to figure out some hacks > as described in the Wiki article. The wiki page was written for daVinci devices AFAIK where they don't have FIFO for their McBSP. -- Péter

2 3

[alsa-devel] [PATCH 0/2] ALSA: rawmidi: add runtime error state for disorder of data transmission
by Takashi Sakamoto 14 Aug '16

14 Aug '16

Hi, This patchset is based on an idea addressed in this thread: http://mailman.alsa-project.org/pipermail/alsa-devel/2016-February/104589.h… For packet-oriented drivers such as USB Audio Device class, message transmission can fail due to data bus issue. In this case, corresponding rawmidi runtime should be closed. Although, current ALSA rawmidi core has no mechanism to help applications/drivers to handle this situation. This commit adds a helper functions for this aim. Takashi Sakamoto (2): ALSA: rawmidi: handle error state for broken logical channel ALSA: rawmidi: add a helper to set runtime error include/sound/rawmidi.h | 3 ++ sound/core/rawmidi.c | 86 ++++++++++++++++++++++++++++++++++++++++++++++--- 2 files changed, 84 insertions(+), 5 deletions(-) -- 2.7.4

1 3

[alsa-devel] [PATCH v2] drm/i915/dp: DP audio API changes for MST
by Dhinakaran Pandiyan 13 Aug '16

13 Aug '16

DP MST provides the capability to send multiple video and audio streams through a single port. This requires the API's between i915 and audio drivers to distinguish between multiple audio capable displays that can be connected to a port. Currently only the port identity is shared in the APIs. This patch adds support for MST with an additional parameter 'int pipe'. The existing parameter 'port' does not change it's meaning. pipe = MST : display pipe that the stream originates from Non-MST : -1 Affected APIs: struct i915_audio_component_ops - int (*sync_audio_rate)(struct device *, int port, int rate); + int (*sync_audio_rate)(struct device *, int port, int pipe, + int rate); - int (*get_eld)(struct device *, int port, bool *enabled, - unsigned char *buf, int max_bytes); + int (*get_eld)(struct device *, int port, int pipe, + bool *enabled, unsigned char *buf, int max_bytes); struct i915_audio_component_audio_ops - void (*pin_eld_notify)(void *audio_ptr, int port); + void (*pin_eld_notify)(void *audio_ptr, int port, int pipe); This patch makes dummy changes in the audio drivers (Libin) for build to succeed. The audio side drivers will send the right 'pipe' values in patches that will follow. v2: Renamed the new API parameter from 'dev_id' to 'pipe'. (Jim, Ville) Included Asoc driver API compatibility changes from Jeeja. Added WARN_ON() for invalid pipe in get_saved_encoder(). (Takashi) Added comment for av_enc_map[] definition. (Takashi) Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan(a)intel.com> --- drivers/gpu/drm/i915/i915_drv.h | 3 +- drivers/gpu/drm/i915/intel_audio.c | 92 ++++++++++++++++++++++++++------------ include/drm/i915_component.h | 6 +-- include/sound/hda_i915.h | 11 ++--- sound/hda/hdac_i915.c | 9 ++-- sound/pci/hda/patch_hdmi.c | 7 +-- sound/soc/codecs/hdac_hdmi.c | 2 +- 7 files changed, 85 insertions(+), 45 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index c36d176..8e4a88f 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -2036,7 +2036,8 @@ struct drm_i915_private { /* perform PHY state sanity checks? */ bool chv_phy_assert[2]; - struct intel_encoder *dig_port_map[I915_MAX_PORTS]; + /* Used to save the pipe-to-encoder mapping for audio */ + struct intel_encoder *av_enc_map[I915_MAX_PIPES]; /* * NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch diff --git a/drivers/gpu/drm/i915/intel_audio.c b/drivers/gpu/drm/i915/intel_audio.c index ef20875..240dad2 100644 --- a/drivers/gpu/drm/i915/intel_audio.c +++ b/drivers/gpu/drm/i915/intel_audio.c @@ -500,6 +500,7 @@ void intel_audio_codec_enable(struct intel_encoder *intel_encoder) struct i915_audio_component *acomp = dev_priv->audio_component; struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder); enum port port = intel_dig_port->port; + enum pipe pipe = -1; connector = drm_select_eld(encoder); if (!connector) @@ -524,12 +525,18 @@ void intel_audio_codec_enable(struct intel_encoder *intel_encoder) mutex_lock(&dev_priv->av_mutex); intel_encoder->audio_connector = connector; + /* referred in audio callbacks */ - dev_priv->dig_port_map[port] = intel_encoder; + dev_priv->av_enc_map[pipe] = intel_encoder; mutex_unlock(&dev_priv->av_mutex); + + if (intel_encoder->type == INTEL_OUTPUT_DP_MST) + pipe = crtc->pipe; + if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify) - acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr, (int) port); + acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr, + (int) port, (int) pipe); } /** @@ -542,22 +549,28 @@ void intel_audio_codec_enable(struct intel_encoder *intel_encoder) void intel_audio_codec_disable(struct intel_encoder *intel_encoder) { struct drm_encoder *encoder = &intel_encoder->base; + struct intel_crtc *crtc = to_intel_crtc(encoder->crtc); struct drm_device *dev = encoder->dev; struct drm_i915_private *dev_priv = to_i915(dev); struct i915_audio_component *acomp = dev_priv->audio_component; struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder); enum port port = intel_dig_port->port; + enum pipe pipe = -1; if (dev_priv->display.audio_codec_disable) dev_priv->display.audio_codec_disable(intel_encoder); mutex_lock(&dev_priv->av_mutex); intel_encoder->audio_connector = NULL; - dev_priv->dig_port_map[port] = NULL; + dev_priv->av_enc_map[pipe] = NULL; mutex_unlock(&dev_priv->av_mutex); + if (intel_encoder->type == INTEL_OUTPUT_DP_MST) + pipe = crtc->pipe; + if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify) - acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr, (int) port); + acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr, + (int) port, (int) pipe); } /** @@ -632,15 +645,39 @@ static int i915_audio_component_get_cdclk_freq(struct device *dev) return dev_priv->cdclk_freq; } -static int i915_audio_component_sync_audio_rate(struct device *dev, - int port, int rate) +static struct intel_encoder *get_saved_encoder(struct intel_encoder *av_enc_map[], + int port, int pipe) +{ + struct drm_encoder *encoder; + + if (WARN_ON(pipe >= I915_MAX_PIPES)) + return NULL; + + /* MST */ + if (pipe != -1) + return av_enc_map[pipe]; + + /* Non-MST */ + for (pipe = PIPE_A; pipe < I915_MAX_PIPES; pipe++) { + if (!av_enc_map[pipe]) + continue; + + encoder = &av_enc_map[pipe]->base; + if (port == enc_to_dig_port(encoder)->port) + return av_enc_map[pipe]; + } + + return NULL; +} + +static int i915_audio_component_sync_audio_rate(struct device *dev, int port, + int pipe, int rate) { struct drm_i915_private *dev_priv = dev_to_i915(dev); struct intel_encoder *intel_encoder; struct intel_crtc *crtc; struct drm_display_mode *mode; struct i915_audio_component *acomp = dev_priv->audio_component; - enum pipe pipe = INVALID_PIPE; u32 tmp; int n; int err = 0; @@ -654,25 +691,20 @@ static int i915_audio_component_sync_audio_rate(struct device *dev, i915_audio_component_get_power(dev); mutex_lock(&dev_priv->av_mutex); + /* 1. get the pipe */ - intel_encoder = dev_priv->dig_port_map[port]; - /* intel_encoder might be NULL for DP MST */ + intel_encoder = get_saved_encoder(dev_priv->av_enc_map, port, pipe); if (!intel_encoder || !intel_encoder->base.crtc || intel_encoder->type != INTEL_OUTPUT_HDMI) { - DRM_DEBUG_KMS("no valid port %c\n", port_name(port)); + DRM_DEBUG_KMS("Not valid for port %c\n", port_name(port)); err = -ENODEV; goto unlock; } + + /* pipe passed from the audio driver will be -1 for non-mst case */ crtc = to_intel_crtc(intel_encoder->base.crtc); pipe = crtc->pipe; - if (pipe == INVALID_PIPE) { - DRM_DEBUG_KMS("no pipe for the port %c\n", port_name(port)); - err = -ENODEV; - goto unlock; - } - DRM_DEBUG_KMS("pipe %c connects port %c\n", - pipe_name(pipe), port_name(port)); mode = &crtc->config->base.adjusted_mode; /* port must be valid now, otherwise the pipe will be invalid */ @@ -708,7 +740,7 @@ static int i915_audio_component_sync_audio_rate(struct device *dev, } static int i915_audio_component_get_eld(struct device *dev, int port, - bool *enabled, + int pipe, bool *enabled, unsigned char *buf, int max_bytes) { struct drm_i915_private *dev_priv = dev_to_i915(dev); @@ -717,16 +749,20 @@ static int i915_audio_component_get_eld(struct device *dev, int port, int ret = -EINVAL; mutex_lock(&dev_priv->av_mutex); - intel_encoder = dev_priv->dig_port_map[port]; - /* intel_encoder might be NULL for DP MST */ - if (intel_encoder) { - ret = 0; - *enabled = intel_encoder->audio_connector != NULL; - if (*enabled) { - eld = intel_encoder->audio_connector->eld; - ret = drm_eld_size(eld); - memcpy(buf, eld, min(max_bytes, ret)); - } + + intel_encoder = get_saved_encoder(dev_priv->av_enc_map, port, pipe); + if (!intel_encoder) { + DRM_DEBUG_KMS("Not valid for port %c\n", port_name(port)); + mutex_unlock(&dev_priv->av_mutex); + return ret; + } + + ret = 0; + *enabled = intel_encoder->audio_connector != NULL; + if (*enabled) { + eld = intel_encoder->audio_connector->eld; + ret = drm_eld_size(eld); + memcpy(buf, eld, min(max_bytes, ret)); } mutex_unlock(&dev_priv->av_mutex); diff --git a/include/drm/i915_component.h b/include/drm/i915_component.h index b46fa0e..545c6e0 100644 --- a/include/drm/i915_component.h +++ b/include/drm/i915_component.h @@ -64,7 +64,7 @@ struct i915_audio_component_ops { * Called from audio driver. After audio driver sets the * sample rate, it will call this function to set n/cts */ - int (*sync_audio_rate)(struct device *, int port, int rate); + int (*sync_audio_rate)(struct device *, int port, int pipe, int rate); /** * @get_eld: fill the audio state and ELD bytes for the given port * @@ -77,7 +77,7 @@ struct i915_audio_component_ops { * Note that the returned size may be over @max_bytes. Then it * implies that only a part of ELD has been copied to the buffer. */ - int (*get_eld)(struct device *, int port, bool *enabled, + int (*get_eld)(struct device *, int port, int pipe, bool *enabled, unsigned char *buf, int max_bytes); }; @@ -97,7 +97,7 @@ struct i915_audio_component_audio_ops { * status accordingly (even when the HDA controller is in power save * mode). */ - void (*pin_eld_notify)(void *audio_ptr, int port); + void (*pin_eld_notify)(void *audio_ptr, int port, int pipe); }; /** diff --git a/include/sound/hda_i915.h b/include/sound/hda_i915.h index 796cabf..07fd64e 100644 --- a/include/sound/hda_i915.h +++ b/include/sound/hda_i915.h @@ -10,8 +10,9 @@ int snd_hdac_set_codec_wakeup(struct hdac_bus *bus, bool enable); int snd_hdac_display_power(struct hdac_bus *bus, bool enable); void snd_hdac_i915_set_bclk(struct hdac_bus *bus); -int snd_hdac_sync_audio_rate(struct hdac_device *codec, hda_nid_t nid, int rate); -int snd_hdac_acomp_get_eld(struct hdac_device *codec, hda_nid_t nid, +int snd_hdac_sync_audio_rate(struct hdac_device *codec, hda_nid_t nid, + int pipe, int rate); +int snd_hdac_acomp_get_eld(struct hdac_device *codec, hda_nid_t nid, int pipe, bool *audio_enabled, char *buffer, int max_bytes); int snd_hdac_i915_init(struct hdac_bus *bus); int snd_hdac_i915_exit(struct hdac_bus *bus); @@ -29,13 +30,13 @@ static inline void snd_hdac_i915_set_bclk(struct hdac_bus *bus) { } static inline int snd_hdac_sync_audio_rate(struct hdac_device *codec, - hda_nid_t nid, int rate) + hda_nid_t nid, int pipe, int rate) { return 0; } static inline int snd_hdac_acomp_get_eld(struct hdac_device *codec, hda_nid_t nid, - bool *audio_enabled, char *buffer, - int max_bytes) + int pipe, bool *audio_enabled, + char *buffer, int max_bytes) { return -ENODEV; } diff --git a/sound/hda/hdac_i915.c b/sound/hda/hdac_i915.c index c9af022..b99994b 100644 --- a/sound/hda/hdac_i915.c +++ b/sound/hda/hdac_i915.c @@ -201,7 +201,8 @@ static int pin2port(struct hdac_device *codec, hda_nid_t pin_nid) * This function sets N/CTS value based on the given sample rate. * Returns zero for success, or a negative error code. */ -int snd_hdac_sync_audio_rate(struct hdac_device *codec, hda_nid_t nid, int rate) +int snd_hdac_sync_audio_rate(struct hdac_device *codec, hda_nid_t nid, + int pipe, int rate) { struct hdac_bus *bus = codec->bus; struct i915_audio_component *acomp = bus->audio_component; @@ -212,7 +213,7 @@ int snd_hdac_sync_audio_rate(struct hdac_device *codec, hda_nid_t nid, int rate) port = pin2port(codec, nid); if (port < 0) return -EINVAL; - return acomp->ops->sync_audio_rate(acomp->dev, port, rate); + return acomp->ops->sync_audio_rate(acomp->dev, port, pipe, rate); } EXPORT_SYMBOL_GPL(snd_hdac_sync_audio_rate); @@ -236,7 +237,7 @@ EXPORT_SYMBOL_GPL(snd_hdac_sync_audio_rate); * thus it may be over @max_bytes. If it's over @max_bytes, it implies * that only a part of ELD bytes have been fetched. */ -int snd_hdac_acomp_get_eld(struct hdac_device *codec, hda_nid_t nid, +int snd_hdac_acomp_get_eld(struct hdac_device *codec, hda_nid_t nid, int pipe, bool *audio_enabled, char *buffer, int max_bytes) { struct hdac_bus *bus = codec->bus; @@ -249,7 +250,7 @@ int snd_hdac_acomp_get_eld(struct hdac_device *codec, hda_nid_t nid, port = pin2port(codec, nid); if (port < 0) return -EINVAL; - return acomp->ops->get_eld(acomp->dev, port, audio_enabled, + return acomp->ops->get_eld(acomp->dev, port, pipe, audio_enabled, buffer, max_bytes); } EXPORT_SYMBOL_GPL(snd_hdac_acomp_get_eld); diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index d0d5ad8..67890df 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -1485,7 +1485,7 @@ static void sync_eld_via_acomp(struct hda_codec *codec, mutex_lock(&per_pin->lock); eld->monitor_present = false; - size = snd_hdac_acomp_get_eld(&codec->core, per_pin->pin_nid, + size = snd_hdac_acomp_get_eld(&codec->core, per_pin->pin_nid, -1, &eld->monitor_present, eld->eld_buffer, ELD_MAX_SIZE); if (size > 0) { @@ -1739,7 +1739,8 @@ static int generic_hdmi_playback_pcm_prepare(struct hda_pcm_stream *hinfo, /* Call sync_audio_rate to set the N/CTS/M manually if necessary */ /* Todo: add DP1.2 MST audio support later */ if (codec_has_acomp(codec)) - snd_hdac_sync_audio_rate(&codec->core, pin_nid, runtime->rate); + snd_hdac_sync_audio_rate(&codec->core, pin_nid, -1, + runtime->rate); non_pcm = check_non_pcm_per_cvt(codec, cvt_nid); mutex_lock(&per_pin->lock); @@ -2285,7 +2286,7 @@ static void haswell_set_power_state(struct hda_codec *codec, hda_nid_t fg, snd_hda_codec_set_power_to_all(codec, fg, power_state); } -static void intel_pin_eld_notify(void *audio_ptr, int port) +static void intel_pin_eld_notify(void *audio_ptr, int port, int pipe) { struct hda_codec *codec = audio_ptr; int pin_nid; diff --git a/sound/soc/codecs/hdac_hdmi.c b/sound/soc/codecs/hdac_hdmi.c index 2abb742..cf57ab3 100644 --- a/sound/soc/codecs/hdac_hdmi.c +++ b/sound/soc/codecs/hdac_hdmi.c @@ -1366,7 +1366,7 @@ static int hdac_hdmi_parse_and_map_nid(struct hdac_ext_device *edev, return hdac_hdmi_init_dai_map(edev); } -static void hdac_hdmi_eld_notify_cb(void *aptr, int port) +static void hdac_hdmi_eld_notify_cb(void *aptr, int port, int pipe) { struct hdac_ext_device *edev = aptr; struct hdac_hdmi_priv *hdmi = edev->private_data; -- 2.5.0

4 10

Re: [alsa-devel] Correct modules for Bay Trail MAX98090 soc?
by Pierre-Louis Bossart 12 Aug '16

12 Aug '16

On 8/11/16 3:42 PM, Laura Abbott wrote: > Hi, > > Fedora got a bug report[1] that sound was failing on Intel Bay Trail Socs > that use the MAX98090 module. I found > > Author: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> > Date: Mon Feb 8 10:45:38 2016 +0530 > > ASoC: Intel: Load the atom DPCM driver only > DPCM driver is recommended for BYT, CHT based platforms, so if > CONFIG_SND_SST_IPC_ACPI is selected then don't compile the BYT > Device IDs in common ACPI driver to avoid probe conflicts. > Signed-off-by: Pierre-Louis Bossart > <pierre-louis.bossart(a)linux.intel.com> > Acked-by: Jie Yang <yang.jie(a)intel.com> > Signed-off-by: Vinod Koul <vinod.koul(a)intel.com> > Signed-off-by: Mark Brown <broonie(a)kernel.org> > > > which changed the dependencies for CONFIG_SND_SOC_INTEL_BYT_MAX98090_MACH. > The set of options Fedora selects means that > CONFIG_SND_SOC_INTEL_BYT_MAX98090_MACH > can't be selected. Is there another driver that's supposed to replace > CONFIG_SND_SOC_INTEL_BYT_MAX98090_MACH on Bay Trail or do the dependencies > need to be updated? The bugzilla has alsa-info for working and non- > working cases and the Fedora config is attached. If you remove support for all other baytrail options this driver should still be there and selectable. We just can't support both this driver for Chromebooks and the rest for other machines with the same distribution at the moment.

3 6

[alsa-devel] [PATCH] amidi: add delay option
by Felipe F. Tonello 12 Aug '16

12 Aug '16

This patch adds a new options to amidi tool to add a delay (in milliseconds) to each MIDI message. This is very useful when sending firmware updates to a remote device via SysEx or any other use that requires this delay in between messages. Signed-off-by: Felipe F. Tonello <eu(a)felipetonello.com> --- amidi/amidi.1 | 14 ++++++++++++ amidi/amidi.c | 72 ++++++++++++++++++++++++++++++++++++++++++++++++++++++----- 2 files changed, 81 insertions(+), 5 deletions(-) diff --git a/amidi/amidi.1 b/amidi/amidi.1 index 1b4cfb1ea956..40402c17e374 100644 --- a/amidi/amidi.1 +++ b/amidi/amidi.1 @@ -111,6 +111,12 @@ to stop receiving data. Does not ignore Active Sensing bytes (FEh) when saving or printing received MIDI commands. +.TP +.I \-D, \-\-delay=mseconds +Adds a delay in between each MIDI message sent to a device. It is +useful when sending firmware updates via SysEx messages to a remote +device. + .SH EXAMPLES .TP @@ -121,6 +127,14 @@ to port .I hw:0. .TP +.B amidi \-p hw:1,0,0 -s firmware.syx \-D 100 +will send the MIDI commands in +.I firmware.syx +to port +.I hw:1,0,0 +with 100 milliseconds delay in between MIDI messages. + +.TP .B amidi \-S 'F0 43 10 4C 00 00 7E 00 F7' sends an XG Reset to the default port. diff --git a/amidi/amidi.c b/amidi/amidi.c index cedf18c5fd39..f45abfa7eac0 100644 --- a/amidi/amidi.c +++ b/amidi/amidi.c @@ -48,6 +48,7 @@ static int receive_file; static int dump; static int timeout; static int stop; +static int delay; static snd_rawmidi_t *input, **inputp; static snd_rawmidi_t *output, **outputp; @@ -77,7 +78,8 @@ static void usage(void) "-d, --dump print received data as hexadecimal bytes\n" "-t, --timeout=seconds exits when no data has been received\n" " for the specified duration\n" - "-a, --active-sensing don't ignore active sensing bytes\n"); + "-a, --active-sensing don't ignore active sensing bytes\n" + "-D, --delay=mseconds delay in between each sent MIDI message\n"); } static void version(void) @@ -305,6 +307,35 @@ static void parse_data(void) send_data_length = i; } +static int message_length(unsigned char byte) +{ + static int rstate_len = 0; + + switch (byte) { + case 0xf8 ... 0xff: + return 1; + case 0xf0: + return -1; /* variable size */ + case 0xf1: + case 0xf3: + return 2; + case 0xf2: + return 3; + case 0xf4: + case 0xf5: + return 0; /* ignore */ + case 0xf6: + return 1; + case 0xf7: + return 0; /* ignore */ + case 0x80 ... 0xef: + rstate_len = (byte >= 0xc0 && byte <= 0xdf) ? 2 : 3; + return rstate_len; + case 0x00 ... 0x7f: + return rstate_len ?: rstate_len - 1; + } +} + /* * prints MIDI commands, formatting them nicely */ @@ -406,7 +437,7 @@ static void add_send_hex_data(const char *str) int main(int argc, char *argv[]) { - static const char short_options[] = "hVlLp:s:r:S::dt:a"; + static const char short_options[] = "hVlLp:s:r:S::dt:aD:"; static const struct option long_options[] = { {"help", 0, NULL, 'h'}, {"version", 0, NULL, 'V'}, @@ -419,6 +450,7 @@ int main(int argc, char *argv[]) {"dump", 0, NULL, 'd'}, {"timeout", 1, NULL, 't'}, {"active-sensing", 0, NULL, 'a'}, + {"delay", 1, NULL, 'D'}, { } }; int c, err, ok = 0; @@ -463,6 +495,9 @@ int main(int argc, char *argv[]) case 'a': ignore_active_sensing = 0; break; + case 'D': + delay = atoi(optarg); + break; default: error("Try `amidi --help' for more information."); return 1; @@ -538,9 +573,36 @@ int main(int argc, char *argv[]) error("cannot set blocking mode: %s", snd_strerror(err)); goto _exit; } - if ((err = snd_rawmidi_write(output, send_data, send_data_length)) < 0) { - error("cannot send data: %s", snd_strerror(err)); - goto _exit; + if (!delay) { + if ((err = snd_rawmidi_write(output, send_data, send_data_length)) < 0) { + error("cannot send data: %s", snd_strerror(err)); + return err; + } + } else { + unsigned char *data = (unsigned char *)send_data; + + while (data < ((unsigned char *)send_data + send_data_length)) { + + if (data > (unsigned char *)send_data) + usleep(delay * 1000); + + int len = message_length(*data); + + /* check for variable length */ + if (len == -1) { + int i = 0; + while (data[i++] != 0xf7); + len = i; + } + + if (len > 0 && + (err = snd_rawmidi_write(output, data, len)) < 0) { + error("cannot send data: %s", snd_strerror(err)); + return err; + } + + data += len ?: 1; + } } } -- 2.9.2

4 5

[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 12 Aug '16

12 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

Re: [alsa-devel] SND_PCM_STREAM_CAPTURE and SND_PCM_NONBLOCK producing strange artifacts
by Takashi Iwai 11 Aug '16

11 Aug '16

Please don't drop Cc to ML. Also avoid top-post. On Tue, 05 Jul 2016 09:02:12 +0200, Trent Reed wrote: > > Thanks Takashi, > > My implementation does only use the "hw:N" devices, unfortunately - I am > not using MMAP because I was under the impression that you must poll when > directly accessing the hardware. And yes, 48kHz is the exact rate I'm > attempting. :( > I do have an update, though - I'm able to reproduce the issue quite simply > by running the ALSA test application latency with the following command: > > `latency -P <playback-device> -C <capture-device> -r 48000` > > This, as far as I understand from the source code, should open R/W > interleaved streams on ("hw:2" is what I'm using for both, though the > problem persists in non-duplex mode, e.g. "hw:2" "hw:0") in non-blocking > mode without polling. > > What happens is the latency application does normalize around some value > (say, 16ms roundtrip time), but the audio is awful and broken, a lot of > this "static" I'm talking about. It seems to me that it's the same problem > that I have in my above-mentioned sample code. > > I would love to help more, so if I can in any way, please let me know! But > I feel at a loss for how to further debug. The latency program is too complex to analyze the issue. Check arecord with --nonblock --test-nowait options and with the hw device. Does the issue happen always? Or does it depend on the buffer or period size? Takashi > > Thanks, > - Trent Reed > > On Mon, Jul 4, 2016 at 11:52 PM, Takashi Iwai <tiwai(a)suse.de> wrote: > > > On Sat, 02 Jul 2016 23:58:28 +0200, > > Trent Reed wrote: > > > > > > (Ping) > > > > > > I'm afraid I still don't understand why this is failing. I found that a > > > call to sdn_pcm_wait() when -EAGAIN is returned fixes the problem because > > > it waits for samples to be ready, but I don't understand why it is a > > > problem in the first place. Much of the sample code is written in a way > > > that suggests that the call to snd_pcm_wait() is optional, and only > > > required when directly reading/writing from the device (MMAP, I'm not > > doing > > > this). > > > > > > I'm just wondering what is wrong with basically looping over a call to > > > snd_pcm_readi() in non-blocking mode, reacting to errors, and capturing > > > frames. This produces awful static (which is basically garbage samples), > > is > > > it a requirement that I call snd_pcm_wait() when -EAGAIN is passed back > > to > > > wait for a full period to be ready? > > > > Well, in the API level, it should work as you expected. So there must > > be definitely some bug(s). But it's hard to spot out, as there are > > several layers behind the scene. > > > > As a first shot, try to reproduce without alsa-lib plugins, i.e. only > > with "hw" PCM device, if not done yet. Also, it's interesting to see > > whether it happens with or without mmap r/w. > > > > Another point is whether it depends on the parameter. Did you try > > 48kHz instead of 44.1kHz? > > > > > > Takashi > > > > > > > > > > Thanks, > > > - Trent Reed > > > > > > > > > On Tue, Jun 28, 2016 at 7:27 PM, Trent Reed <treed0803(a)gmail.com> wrote: > > > > > > > Hey All, > > > > > > > > I've been banging my head against the wall for about a week on this > > bug. > > > > The following gist shows my sample reproduction code: > > > > https://gist.github.com/TReed0803/985c5d5c3d295245e19006a27be447c3 > > > > > > > > I'm simply opening up a non-blocking PCM capture stream and writing the > > > > contents of the reads to stdout. > > > > (Originally, I was writing to the playback stream, but I was hearing > > this > > > > strange static occasionally!) > > > > > > > > It's the static I'm trying to debug. It doesn't happen every time. In > > > > fact, sometimes I'll go a few consecutive executions without hearing > > it. > > > > I was able to capture some of the bad data, and I loaded it up in > > Audacity > > > > for visualization: > > > > > > > > > > https://drive.google.com/file/d/0B-1aumGKQcQTcUJoZzIwRWhYSFE/view?usp=shari… > > > > > > > > It looks like the internal buffer occasionally is sending me more data > > > > than it actually captured, and I end up either reading old PCM data > > from > > > > the internal ring buffer, or (at the very beginning) a bunch of zeros. > > > > > > > > Can anyone help me understand what is going on? What could cause these > > > > definitely incorrect samples to be recorded? (I get the same effect > > > > regardless of hardware, but I will list hardware just in case.) > > > > > > > > I hope I have all the information you might need: > > > > Hardware: Samson Meteor Mic (USB-Audio, USB Mixer) [Though, it even > > > > happens with my built-in microphone] > > > > ALSA version: Advanced Linux Sound Architecture Driver Version > > > > k4.4.0-28-generic. > > > > apt-cache policy (installed alsa-lib version): 1.1.0-0ubuntu1 > > > > > > > > Thanks, > > > > - Trent Reed > > > > > > > _______________________________________________ > > > Alsa-devel mailing list > > > Alsa-devel(a)alsa-project.org > > > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > > >

2 3

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 12:49:21PM +0200, Hans Verkuil wrote: > On 08/11/16 12:39, Russell King - ARM Linux wrote: > > On Thu, Aug 11, 2016 at 12:30:03PM +0200, Hans Verkuil wrote: > >> Hi Russell, > >> > >> I like this approach and it is something I will need for other CEC drivers > >> (not yet merged) as well. > >> > >> Just a few comments: > >> > >> On 08/11/16 11:20, Philipp Zabel wrote: > >>> This is Russell's HDMI notification prototype [1], currently waiting > >>> for the HDMI CEC situation to resolve. > >>> > >>> The use case for the notifications on MediaTek MT8173 is to let the > >>> (dis)connection notifications control an ALSA jack object. > >>> > >>> No Signed-off-by since this is not my code, and still up for discussion. > >>> > >>> [1] https://patchwork.kernel.org/patch/8351501/ > >>> --- > >>> drivers/video/Kconfig | 3 +++ > >>> drivers/video/Makefile | 1 + > >>> drivers/video/hdmi-notifier.c | 61 +++++++++++++++++++++++++++++++++++++++++++ > >>> include/linux/hdmi-notifier.h | 44 +++++++++++++++++++++++++++++++ > >>> 4 files changed, 109 insertions(+) > >>> create mode 100644 drivers/video/hdmi-notifier.c > >>> create mode 100644 include/linux/hdmi-notifier.h > >>> > >>> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig > >>> index 3c20af9..1ee7b9f 100644 > >>> --- a/drivers/video/Kconfig > >>> +++ b/drivers/video/Kconfig > >>> @@ -36,6 +36,9 @@ config VIDEOMODE_HELPERS > >>> config HDMI > >>> bool > >>> > >>> +config HDMI_NOTIFIERS > >>> + bool > >>> + > >>> if VT > >>> source "drivers/video/console/Kconfig" > >>> endif > >>> diff --git a/drivers/video/Makefile b/drivers/video/Makefile > >>> index 9ad3c17..65f5649 100644 > >>> --- a/drivers/video/Makefile > >>> +++ b/drivers/video/Makefile > >>> @@ -1,5 +1,6 @@ > >>> obj-$(CONFIG_VGASTATE) += vgastate.o > >>> obj-$(CONFIG_HDMI) += hdmi.o > >>> +obj-$(CONFIG_HDMI_NOTIFIERS) += hdmi-notifier.o > >>> > >>> obj-$(CONFIG_VT) += console/ > >>> obj-$(CONFIG_LOGO) += logo/ > >>> diff --git a/drivers/video/hdmi-notifier.c b/drivers/video/hdmi-notifier.c > >>> new file mode 100644 > >>> index 0000000..a233359 > >>> --- /dev/null > >>> +++ b/drivers/video/hdmi-notifier.c > >>> @@ -0,0 +1,61 @@ > >>> +#include <linux/export.h> > >>> +#include <linux/hdmi-notifier.h> > >>> +#include <linux/notifier.h> > >>> +#include <linux/string.h> > >>> + > >>> +static BLOCKING_NOTIFIER_HEAD(hdmi_notifier); > >>> + > >>> +int hdmi_register_notifier(struct notifier_block *nb) > >>> +{ > >>> + return blocking_notifier_chain_register(&hdmi_notifier, nb); > >>> +} > >>> +EXPORT_SYMBOL_GPL(hdmi_register_notifier); > >>> + > >>> +int hdmi_unregister_notifier(struct notifier_block *nb) > >>> +{ > >>> + return blocking_notifier_chain_unregister(&hdmi_notifier, nb); > >>> +} > >>> +EXPORT_SYMBOL_GPL(hdmi_unregister_notifier); > >>> + > >>> +void hdmi_event_connect(struct device *dev) > >>> +{ > >>> + struct hdmi_event_base base; > >>> + > >>> + base.source = dev; > >>> + > >>> + blocking_notifier_call_chain(&hdmi_notifier, HDMI_CONNECTED, &base); > >>> +} > >>> +EXPORT_SYMBOL_GPL(hdmi_event_connect); > >>> + > >>> +void hdmi_event_disconnect(struct device *dev) > >>> +{ > >>> + struct hdmi_event_base base; > >>> + > >>> + base.source = dev; > >>> + > >>> + blocking_notifier_call_chain(&hdmi_notifier, HDMI_DISCONNECTED, &base); > >>> +} > >>> +EXPORT_SYMBOL_GPL(hdmi_event_disconnect); > >>> + > >>> +void hdmi_event_new_edid(struct device *dev, const void *edid, size_t size) > >> > >> I would prefer const u8 *edid. It is after all just a u8 array and not some > >> opaque data structure. > > > > In DRM, the edid is of type "struct edid" (defined in > > include/drm/drm_edid.h). So, making it "const u8 *" means that all > > DRM drivers will have to explicitly cast it - not something I'm in > > favour of. > > 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. > Also struct edid is for the first EDID block only, whereas CEC drivers need > the CEA-861 block to get the physical address. That may be, but DRM parses the HDMI vendor block too while still using struct edid to represent it. See drm_find_edid_extension() in drivers/gpu/drm/drm_edid.c This is just how DRM is... I'm not sure what the design decisions were that came up with this, but it's what we have, and I'm not sure whether DRM would be open to changing it. > > The ELD stands for EDID-like data. See information on HDA039. It's a > > method of conveying the EDID data specific to audio drivers to them > > without having the complexities of parsing the full EDID each time. > > It's also exported to userland so that userland can determine the > > capabilities of the audio path, again, without having to have full > > EDID parsers and exporting the full EDID data block through audio > > drivers. > > > > OK. Since eld is an unsigned char array I would suggest changing void to > unsigned char here. > > Or perhaps const unsigned char eld[128]. Yes, I'll make that change. -- 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

[alsa-devel] [PATCH] ASoC: arizona: Connect ASRCs to both clock domains
by Charles Keepax 11 Aug '16

11 Aug '16

The two clock domains are enabled based on each input and output of the chip being connected to its respective clock domain. The ASRC however can bridge the two domains and as such can function as an input/output to either domain. The hardware also requires that both clocks are enabled before the ASRC is. Ensure these constraints by linking the ASRCs to both SYSCLK and ASYNCCLK. Signed-off-by: Charles Keepax <ckeepax(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/cs47l24.c | 10 ++++++++++ sound/soc/codecs/wm5102.c | 10 ++++++++++ sound/soc/codecs/wm5110.c | 10 ++++++++++ sound/soc/codecs/wm8998.c | 10 ++++++++++ 4 files changed, 40 insertions(+) diff --git a/sound/soc/codecs/cs47l24.c b/sound/soc/codecs/cs47l24.c index 779a7bf..257b152 100644 --- a/sound/soc/codecs/cs47l24.c +++ b/sound/soc/codecs/cs47l24.c @@ -746,6 +746,16 @@ static const struct snd_soc_dapm_route cs47l24_dapm_routes[] = { { "IN2L", NULL, "SYSCLK" }, { "IN2R", NULL, "SYSCLK" }, + { "ASRC1L", NULL, "SYSCLK" }, + { "ASRC1R", NULL, "SYSCLK" }, + { "ASRC2L", NULL, "SYSCLK" }, + { "ASRC2R", NULL, "SYSCLK" }, + + { "ASRC1L", NULL, "ASYNCCLK" }, + { "ASRC1R", NULL, "ASYNCCLK" }, + { "ASRC2L", NULL, "ASYNCCLK" }, + { "ASRC2R", NULL, "ASYNCCLK" }, + { "MICBIAS1", NULL, "MICVDD" }, { "MICBIAS2", NULL, "MICVDD" }, diff --git a/sound/soc/codecs/wm5102.c b/sound/soc/codecs/wm5102.c index 1295978..2d6c19d 100644 --- a/sound/soc/codecs/wm5102.c +++ b/sound/soc/codecs/wm5102.c @@ -1521,6 +1521,16 @@ static const struct snd_soc_dapm_route wm5102_dapm_routes[] = { { "IN3L", NULL, "SYSCLK" }, { "IN3R", NULL, "SYSCLK" }, + { "ASRC1L", NULL, "SYSCLK" }, + { "ASRC1R", NULL, "SYSCLK" }, + { "ASRC2L", NULL, "SYSCLK" }, + { "ASRC2R", NULL, "SYSCLK" }, + + { "ASRC1L", NULL, "ASYNCCLK" }, + { "ASRC1R", NULL, "ASYNCCLK" }, + { "ASRC2L", NULL, "ASYNCCLK" }, + { "ASRC2R", NULL, "ASYNCCLK" }, + { "MICBIAS1", NULL, "MICVDD" }, { "MICBIAS2", NULL, "MICVDD" }, { "MICBIAS3", NULL, "MICVDD" }, diff --git a/sound/soc/codecs/wm5110.c b/sound/soc/codecs/wm5110.c index 3e7f873..fa35e19 100644 --- a/sound/soc/codecs/wm5110.c +++ b/sound/soc/codecs/wm5110.c @@ -1745,6 +1745,16 @@ static const struct snd_soc_dapm_route wm5110_dapm_routes[] = { { "IN4L", NULL, "SYSCLK" }, { "IN4R", NULL, "SYSCLK" }, + { "ASRC1L", NULL, "SYSCLK" }, + { "ASRC1R", NULL, "SYSCLK" }, + { "ASRC2L", NULL, "SYSCLK" }, + { "ASRC2R", NULL, "SYSCLK" }, + + { "ASRC1L", NULL, "ASYNCCLK" }, + { "ASRC1R", NULL, "ASYNCCLK" }, + { "ASRC2L", NULL, "ASYNCCLK" }, + { "ASRC2R", NULL, "ASYNCCLK" }, + { "MICBIAS1", NULL, "MICVDD" }, { "MICBIAS2", NULL, "MICVDD" }, { "MICBIAS3", NULL, "MICVDD" }, diff --git a/sound/soc/codecs/wm8998.c b/sound/soc/codecs/wm8998.c index 315b23b..edaa4cf 100644 --- a/sound/soc/codecs/wm8998.c +++ b/sound/soc/codecs/wm8998.c @@ -966,6 +966,16 @@ static const struct snd_soc_dapm_route wm8998_dapm_routes[] = { { "IN2A", NULL, "SYSCLK" }, { "IN2B", NULL, "SYSCLK" }, + { "ASRC1L", NULL, "SYSCLK" }, + { "ASRC1R", NULL, "SYSCLK" }, + { "ASRC2L", NULL, "SYSCLK" }, + { "ASRC2R", NULL, "SYSCLK" }, + + { "ASRC1L", NULL, "ASYNCCLK" }, + { "ASRC1R", NULL, "ASYNCCLK" }, + { "ASRC2L", NULL, "ASYNCCLK" }, + { "ASRC2R", NULL, "ASYNCCLK" }, + { "SPD1", NULL, "SYSCLK" }, { "SPD1", NULL, "SPD1TX1" }, { "SPD1", NULL, "SPD1TX2" }, -- 2.1.4

1 0

[alsa-devel] [PATCH] ASoC: wm2000: Fix return of uninitialised varible
by Charles Keepax 11 Aug '16

11 Aug '16

Anything that sets ret in wm2000_anc_transition will have immediately returned anyway as such we will always return an uninitialised ret at the bottom of the function. Simply replace the return with a return 0; Signed-off-by: Charles Keepax <ckeepax(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm2000.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/wm2000.c b/sound/soc/codecs/wm2000.c index 1ebaf99..199a3d8 100644 --- a/sound/soc/codecs/wm2000.c +++ b/sound/soc/codecs/wm2000.c @@ -581,7 +581,7 @@ static int wm2000_anc_transition(struct wm2000_priv *wm2000, if (anc_transitions[i].dest == ANC_OFF) clk_disable_unprepare(wm2000->mclk); - return ret; + return 0; } static int wm2000_anc_set_mode(struct wm2000_priv *wm2000) -- 2.1.4

1 0

[alsa-devel] [PATCH] ASoC: Fix leak of rtd in soc_bind_dai_link
by Charles Keepax 11 Aug '16

11 Aug '16

If we fail to find a platform we simply return EPROBE_DEFER, but we have allocated the rtd pointer. All error paths before soc_add_pcm_runtime need to call soc_free_pcm_runtime first to avoid leaking the rtd pointer. A suitable error path already exists and is used else where in the function so simply use that here as well. Signed-off-by: Charles Keepax <ckeepax(a)opensource.wolfsonmicro.com> --- sound/soc/soc-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 054d94f..84e3fa1 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -1056,7 +1056,7 @@ static int soc_bind_dai_link(struct snd_soc_card *card, if (!rtd->platform) { dev_err(card->dev, "ASoC: platform %s not registered\n", dai_link->platform_name); - return -EPROBE_DEFER; + goto _err_defer; } soc_add_pcm_runtime(card, rtd); -- 2.1.4

1 0

[alsa-devel] [PATCH] ASoC: rt5659: Add mclk controls
by Nicolin Chen 11 Aug '16

11 Aug '16

The codec driver should control the mclk. So this patch adds this support. Signed-off-by: Nicolin Chen <nicoleotsuka(a)gmail.com> --- Documentation/devicetree/bindings/sound/rt5659.txt | 3 +++ sound/soc/codecs/rt5659.c | 24 ++++++++++++++++++++++ sound/soc/codecs/rt5659.h | 1 + 3 files changed, 28 insertions(+) diff --git a/Documentation/devicetree/bindings/sound/rt5659.txt b/Documentation/devicetree/bindings/sound/rt5659.txt index 5f79e7f..1766e05 100644 --- a/Documentation/devicetree/bindings/sound/rt5659.txt +++ b/Documentation/devicetree/bindings/sound/rt5659.txt @@ -12,6 +12,9 @@ Required properties: Optional properties: +- clocks: The phandle of the master clock to the CODEC +- clock-names: Should be "mclk" + - realtek,in1-differential - realtek,in3-differential - realtek,in4-differential diff --git a/sound/soc/codecs/rt5659.c b/sound/soc/codecs/rt5659.c index 1b30914..d9ead96 100644 --- a/sound/soc/codecs/rt5659.c +++ b/sound/soc/codecs/rt5659.c @@ -9,6 +9,7 @@ * published by the Free Software Foundation. */ +#include <linux/clk.h> #include <linux/module.h> #include <linux/moduleparam.h> #include <linux/init.h> @@ -3565,7 +3566,9 @@ static int rt5659_set_bclk_ratio(struct snd_soc_dai *dai, unsigned int ratio) static int rt5659_set_bias_level(struct snd_soc_codec *codec, enum snd_soc_bias_level level) { + struct snd_soc_dapm_context *dapm = snd_soc_codec_get_dapm(codec); struct rt5659_priv *rt5659 = snd_soc_codec_get_drvdata(codec); + int ret; switch (level) { case SND_SOC_BIAS_PREPARE: @@ -3582,6 +3585,17 @@ static int rt5659_set_bias_level(struct snd_soc_codec *codec, RT5659_PWR_FV1 | RT5659_PWR_FV2); break; + case SND_SOC_BIAS_STANDBY: + if (dapm->bias_level == SND_SOC_BIAS_OFF) { + ret = clk_prepare_enable(rt5659->mclk); + if (ret) { + dev_err(codec->dev, + "failed to enable MCLK: %d\n", ret); + return ret; + } + } + break; + case SND_SOC_BIAS_OFF: regmap_update_bits(rt5659->regmap, RT5659_PWR_DIG_1, RT5659_PWR_LDO, 0); @@ -3591,6 +3605,7 @@ static int rt5659_set_bias_level(struct snd_soc_codec *codec, RT5659_PWR_MB | RT5659_PWR_VREF2); regmap_update_bits(rt5659->regmap, RT5659_DIG_MISC, RT5659_DIG_GATE_CTRL, 0); + clk_disable_unprepare(rt5659->mclk); break; default: @@ -4020,6 +4035,15 @@ static int rt5659_i2c_probe(struct i2c_client *i2c, regmap_write(rt5659->regmap, RT5659_RESET, 0); + /* Check if MCLK provided */ + rt5659->mclk = devm_clk_get(&i2c->dev, "mclk"); + if (IS_ERR(rt5659->mclk)) { + if (PTR_ERR(rt5659->mclk) == -EPROBE_DEFER) + return -EPROBE_DEFER; + /* Otherwise mark the mclk pointer to NULL */ + rt5659->mclk = NULL; + } + rt5659_calibrate(rt5659); /* line in diff mode*/ diff --git a/sound/soc/codecs/rt5659.h b/sound/soc/codecs/rt5659.h index d31c9e5..d69b0eb 100644 --- a/sound/soc/codecs/rt5659.h +++ b/sound/soc/codecs/rt5659.h @@ -1796,6 +1796,7 @@ struct rt5659_priv { struct gpio_desc *gpiod_reset; struct snd_soc_jack *hs_jack; struct delayed_work jack_detect_work; + struct clk *mclk; int sysclk; int sysclk_src; -- 2.1.4

5 15

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 12:30:03PM +0200, Hans Verkuil wrote: > Hi Russell, > > I like this approach and it is something I will need for other CEC drivers > (not yet merged) as well. > > Just a few comments: > > On 08/11/16 11:20, Philipp Zabel wrote: > > This is Russell's HDMI notification prototype [1], currently waiting > > for the HDMI CEC situation to resolve. > > > > The use case for the notifications on MediaTek MT8173 is to let the > > (dis)connection notifications control an ALSA jack object. > > > > No Signed-off-by since this is not my code, and still up for discussion. > > > > [1] https://patchwork.kernel.org/patch/8351501/ > > --- > > drivers/video/Kconfig | 3 +++ > > drivers/video/Makefile | 1 + > > drivers/video/hdmi-notifier.c | 61 +++++++++++++++++++++++++++++++++++++++++++ > > include/linux/hdmi-notifier.h | 44 +++++++++++++++++++++++++++++++ > > 4 files changed, 109 insertions(+) > > create mode 100644 drivers/video/hdmi-notifier.c > > create mode 100644 include/linux/hdmi-notifier.h > > > > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig > > index 3c20af9..1ee7b9f 100644 > > --- a/drivers/video/Kconfig > > +++ b/drivers/video/Kconfig > > @@ -36,6 +36,9 @@ config VIDEOMODE_HELPERS > > config HDMI > > bool > > > > +config HDMI_NOTIFIERS > > + bool > > + > > if VT > > source "drivers/video/console/Kconfig" > > endif > > diff --git a/drivers/video/Makefile b/drivers/video/Makefile > > index 9ad3c17..65f5649 100644 > > --- a/drivers/video/Makefile > > +++ b/drivers/video/Makefile > > @@ -1,5 +1,6 @@ > > obj-$(CONFIG_VGASTATE) += vgastate.o > > obj-$(CONFIG_HDMI) += hdmi.o > > +obj-$(CONFIG_HDMI_NOTIFIERS) += hdmi-notifier.o > > > > obj-$(CONFIG_VT) += console/ > > obj-$(CONFIG_LOGO) += logo/ > > diff --git a/drivers/video/hdmi-notifier.c b/drivers/video/hdmi-notifier.c > > new file mode 100644 > > index 0000000..a233359 > > --- /dev/null > > +++ b/drivers/video/hdmi-notifier.c > > @@ -0,0 +1,61 @@ > > +#include <linux/export.h> > > +#include <linux/hdmi-notifier.h> > > +#include <linux/notifier.h> > > +#include <linux/string.h> > > + > > +static BLOCKING_NOTIFIER_HEAD(hdmi_notifier); > > + > > +int hdmi_register_notifier(struct notifier_block *nb) > > +{ > > + return blocking_notifier_chain_register(&hdmi_notifier, nb); > > +} > > +EXPORT_SYMBOL_GPL(hdmi_register_notifier); > > + > > +int hdmi_unregister_notifier(struct notifier_block *nb) > > +{ > > + return blocking_notifier_chain_unregister(&hdmi_notifier, nb); > > +} > > +EXPORT_SYMBOL_GPL(hdmi_unregister_notifier); > > + > > +void hdmi_event_connect(struct device *dev) > > +{ > > + struct hdmi_event_base base; > > + > > + base.source = dev; > > + > > + blocking_notifier_call_chain(&hdmi_notifier, HDMI_CONNECTED, &base); > > +} > > +EXPORT_SYMBOL_GPL(hdmi_event_connect); > > + > > +void hdmi_event_disconnect(struct device *dev) > > +{ > > + struct hdmi_event_base base; > > + > > + base.source = dev; > > + > > + blocking_notifier_call_chain(&hdmi_notifier, HDMI_DISCONNECTED, &base); > > +} > > +EXPORT_SYMBOL_GPL(hdmi_event_disconnect); > > + > > +void hdmi_event_new_edid(struct device *dev, const void *edid, size_t size) > > I would prefer const u8 *edid. It is after all just a u8 array and not some > opaque data structure. In DRM, the edid is of type "struct edid" (defined in include/drm/drm_edid.h). So, making it "const u8 *" means that all DRM drivers will have to explicitly cast it - not something I'm in favour of. > > +{ > > + struct hdmi_event_new_edid new_edid; > > + > > + new_edid.base.source = dev; > > + new_edid.edid = edid; > > + new_edid.size = size; > > + > > + blocking_notifier_call_chain(&hdmi_notifier, HDMI_NEW_EDID, &new_edid); > > +} > > +EXPORT_SYMBOL_GPL(hdmi_event_new_edid); > > + > > +void hdmi_event_new_eld(struct device *dev, const void *eld) > > Stupid question: what does ELD stand for? I've no idea... > > And is void the right choice here or should it also be u8? The ELD stands for EDID-like data. See information on HDA039. It's a method of conveying the EDID data specific to audio drivers to them without having the complexities of parsing the full EDID each time. It's also exported to userland so that userland can determine the capabilities of the audio path, again, without having to have full EDID parsers and exporting the full EDID data block through audio drivers. -- 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

[alsa-devel] [PATCH 0/3] ASoC: Intel: Skylake: Refine manifest module info
by Vinod Koul 10 Aug '16

10 Aug '16

The module query uses a local structure dfw_config and then populates module skl_module_cfg. Instead we can pass skl_module_cfg as argument and get it updated in snd_skl_get_module_info() Also we can optimize runtime processing by using driver list to populate module info after init. That makes runtime query introduced earlier redundant so remove that while keeping error messages. Dharageswari R (1): ASoC: Intel: Skylake: modify snd_skl_get_module_info args Vinod Koul (2): ASoC: Intel: Skylake: Populate modules after loading ASoC: Intel: Skylake: remove module id query at runtime sound/soc/intel/skylake/skl-pcm.c | 27 +++++++++++++++++++++++++++ sound/soc/intel/skylake/skl-sst-dsp.h | 7 ++++--- sound/soc/intel/skylake/skl-sst-utils.c | 10 +++++----- sound/soc/intel/skylake/skl-topology.c | 22 ++++------------------ 4 files changed, 40 insertions(+), 26 deletions(-) -- 1.9.1

2 5

[alsa-devel] [PATCH 0/6] ASoC: simple-card: add canonicalize_cpu / clean_reference
by Kuninori Morimoto 10 Aug '16

10 Aug '16

Hi Mark These add canonicalize_cpu / clean_reference to simple utiles. These are part of simple-card cleanup Kuninori Morimoto (6): ASoC: simple-card-utils: add asoc_simple_card_init_dai() ASoC: simple-card: use asoc_simple_card_init_dai() ASoC: rsrc-card: use asoc_simple_card_init_dai() ASoC: simple-card-utils: add asoc_simple_card_canonicalize_dailink() ASoC: simple-card: use asoc_simple_card_canonicalize_dailink() ASoC: rsrc-card: use asoc_simple_card_canonicalize_dailink() include/sound/simple_card_utils.h | 5 +++++ sound/soc/generic/simple-card-utils.c | 42 ++++++++++++++++++++++++++++++++++++++++++ sound/soc/generic/simple-card.c | 47 +++++------------------------------------------ sound/soc/sh/rcar/rsrc-card.c | 32 +++++--------------------------- 4 files changed, 57 insertions(+), 69 deletions(-) -- 1.9.1

2 10

[alsa-devel] [PATCH 00/49] ASoC: add simple-card-core and standardize "simple" card
by Kuninori Morimoto 10 Aug '16

10 Aug '16

Hi Mark These are very big patch-set, but basically just cleanup for simple-card driver. Now, we have simple-card driver, but it is not simple today. I would like to cleanup this. And Renesas already have rsrc-card driver which is supporting DPCM, and it is based on simple-card. This measn rsrc-card and simple-card are very similar. Thus, I would like to share these code between rsrc-card and simple-card. This rsrc-card is only used from Renesas (actually, there is no upstream user, current user is only me, by local). But this is not Renesas special driver, I can say it is DPCM version of simple-card. I would like to open it for all of ALSA people. But, not merge simple-card <-> rsrc-card, to avoid diffcult future maintenance. Thus, rsrc-card will be simple-dpcm-audio-card, and we can maintenance both simple-card, and simple-dpcm-card. I'm not sure this is good nameing. And finally, we will need HDMI sound support which uses graph base probing. I know it needs more discussion with V4L2 people. But in my understanding, basically, we can reuse simple-card base feature/function on graph base driver somehow. I would like to standardize simple card style, and use/share it with graph driver too. It will be simple-graph-card ? I'm not sure. But I think we can share same code, and can avoid development from 0. These patch are for it. Basically, it pickups common function/feature from simple-card and rsrc-card, and standardize each feature/parse/init etc in simple-card-core. Because of this patch-set, "simple-card" become "simple" again :) I tested these (simple-card, rsrc-card) on my lager, Salvator boards. But I couldn't test some feature. I hope test it on many environment. 1) - 4) cleanup for these patch-set 5) - 19) pickuped common function/feature and put it to simple-card-core 20) - 32) use simple-card-core on simple-card 33) - 46) use simple-card-core on rsrc-card 47) - 49) rename rsrc-card to simple-dpcm-audio-card Kuninori Morimoto (49): 1) ASoC: simple-card: remove duplicate header 2) ASoC: rsrc-card: remove duplicate header 3) ASoC: rsrc-card: remove unused dai_num 4) ASoC: simple-card: platform also uses asoc_simple_card_sub_parse_of() 5) ASoC: add new simple-card-core.c 6) ASoC: simple-card-core: add asoc_simple_card_parse_tdm() 7) ASoC: simple-card-core: add asoc_simple_card_parse_dailink_name() 8) ASoC: simple-card-core: add asoc_simple_card_parse_card_name() 9) ASoC: simple-card-core: add asoc_simple_card_parse_card_prefix() 10) ASoC: simple-card-core: add asoc_simple_card_parse_card_widgets() 11) ASoC: simple-card-core: add asoc_simple_card_parse_card_widgets() 12) ASoC: simple-card-core: add asoc_simple_card_parse_clk() 13) ASoC: simple-card-core: add asoc_simple_card_parse_endpoint() 14) ASoC: simple-card-core: add asoc_simple_card_parse_dpcm() 15) ASoC: simple-card-core: add asoc_simple_card_init_jack() 16) ASoC: simple-card-core: add asoc_simple_card_init_dai() 17) ASoC: simple-card-core: add asoc_simple_card_canonicalize_dailink() 18) ASoC: simple-card-core: add asoc_simple_card_canonicalize_cpu() 19) ASoC: simple-card-core: add asoc_simple_card_clean_reference() 20) ASoC: simple-card: use asoc_simple_card_parse_daifmt() 21) ASoC: simple-card: use asoc_simple_card_parse_clk() 22) ASoC: simple-card: use asoc_simple_card_parse_endpoint() 23) ASoC: simple-card: use asoc_simple_card_parse_tdm() 24) ASoC: simple-card: use asoc_simple_card_parse_card_name() 25) ASoC: simple-card: use asoc_simple_card_parse_card_route() 26) ASoC: simple-card: use asoc_simple_card_parse_card_widgets() 27) ASoC: simple-card: use asoc_simple_card_parse_dailink_name() 28) ASoC: simple-card: use asoc_simple_card_init_jack() 29) ASoC: simple-card: use asoc_simple_card_init_dai() 30) ASoC: simple-card: use asoc_simple_card_canonicalize_dailink() 31) ASoC: simple-card: use asoc_simple_card_canonicalize_cpu() 32) ASoC: simple-card: use asoc_simple_card_clean_reference() 33) ASoC: rsrc-card: use asoc_simple_card_parse_daifmt() 34) ASoC: rsrc-card: use asoc_simple_card_parse_dailink_name() 35) ASoC: rsrc-card: use asoc_simple_dai instead of rsrc_card_dai 36) ASoC: rsrc-card: use asoc_simple_card_parse_clk() 37) ASoC: rsrc-card: use asoc_simple_card_parse_endpoint() 38) ASoC: rsrc-card: use asoc_simple_card_parse_card_name() 39) ASoC: rsrc-card: use asoc_simple_card_parse_card_prefix() 40) ASoC: rsrc-card: use asoc_simple_card_parse_dpcm() 41) ASoC: rsrc-card: use asoc_simple_card_parse_card_route() 42) ASoC: rsrc-card: use asoc_simple_card_parse_tdm() 43) ASoC: rsrc-card: use asoc_simple_card_init_dai() 44) ASoC: rsrc-card: use asoc_simple_card_canonicalize_cpu() 45) ASoC: rsrc-card: use asoc_simple_card_canonicalize_dailink() 46) ASoC: rsrc-card: use asoc_simple_card_clean_reference() 47) ASoC: rsrc-card: rename rsrc-card to simple-dpcm-card phase1 48) ASoC: rsrc-card: rename rsrc-card to simple-dpcm-card phase2 49) ASoC: rsrc-card: rename rsrc-card to simple-dpcm-card phase3 Documentation/devicetree/bindings/sound/renesas,rsrc-card.txt | 75 -------------- Documentation/devicetree/bindings/sound/simple-dpcm-card.txt | 79 +++++++++++++++ include/sound/simple_card.h | 11 +-- include/sound/simple_card_core.h | 106 ++++++++++++++++++++ sound/soc/generic/Kconfig | 10 ++ sound/soc/generic/Makefile | 4 + sound/soc/generic/simple-card-core.c | 409 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ sound/soc/generic/simple-card.c | 359 ++++++++++++------------------------------------------------------ sound/soc/generic/simple-dpcm-card.c | 330 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ sound/soc/sh/Kconfig | 5 - sound/soc/sh/rcar/Makefile | 3 - sound/soc/sh/rcar/rsrc-card.c | 529 -------------------------------------------------------------------------------------------------- 12 files changed, 999 insertions(+), 921 deletions(-)

2 72