December 2015 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [RFC][PATCH 00/17 v2] ALSA: oxfw: refactoring and merging scs1x module
by Takashi Sakamoto 06 Dec '15

06 Dec '15

Hi, This patchset update my previous post for merging ALSA scs1x module to oxfw module: [alsa-devel] [RFC][PATCH 0/9] ALSA: oxfw: merge scs1x module http://mailman.alsa-project.org/pipermail/alsa-devel/2015-November/100534.h… This patchset consists of three parts: * 01-05: code refactoring for OXFW module * 06-09: code refactoring for old firewire-speaker functionalities in OXFW module * 10-17: merge scs1x module Changes: * split some patches for a fine granularity * drop a small framework I proposed in previous patch * rename functions for AV/C Audio Subunit command After this patchset is applied, OXFW module is loaded instead of scs1x module. Then, some names except for rawmidi ID are changed, see patch 16. Currently, I find no advantage to keep them what they were. I'm welcome to receive your oppositions about it. Takashi Sakamoto (17): ALSA: oxfw: rename a file for control elements so that it's for model-specific ALSA: oxfw: rename local functions for control elements so that they represent as local ALSA: oxfw: change function prototype for AV/C Audio Subunit command ALSA: oxfw: reuse driver entry to detect quirk ALSA: oxfw: gather model-dependent conditions to a function ALSA: oxfw: add memory allocation for model-specific structure ALSA: oxfw: move model-specific members from common structure ALSA: oxfw: move model-specific parameters from common structure ALSA: oxfw: rename a structure so that it means backward compatibility to old drivers ALSA: oxfw: add scs1x layer ALSA: oxfw: allocate own address region for SCS.1 series ALSA: oxfw: copy handlers of asynchronous transaction for MIDI capture ALSA: oxfw: add MIDI capture port for SCS.1 models ALSA: oxfw: copy handlers of asynchronous transaction for MIDI playback ALSA: oxfw: add MIDI playback port for SCS.1 models ALSA: oxfw: obsolete scs1x module ALSA: oxfw: add stream format quirk for SCS.1 models sound/firewire/Kconfig | 12 +- sound/firewire/Makefile | 2 - sound/firewire/oxfw/Makefile | 4 +- sound/firewire/oxfw/oxfw-scs1x.c | 409 +++++++++++++++++++++ .../firewire/oxfw/{oxfw-control.c => oxfw-spkr.c} | 142 ++++--- sound/firewire/oxfw/oxfw.c | 110 ++++-- sound/firewire/oxfw/oxfw.h | 23 +- 7 files changed, 586 insertions(+), 116 deletions(-) create mode 100644 sound/firewire/oxfw/oxfw-scs1x.c rename sound/firewire/oxfw/{oxfw-control.c => oxfw-spkr.c} (55%) -- 2.5.0

1 17

Re: [alsa-devel] [sound:for-linus 29/29] sound/pci/rme96.c:1035:1-7: preceding lock on line 991
by Julia Lawall 04 Dec '15

04 Dec '15

Looks suspicious. Please check. julia On Sat, 5 Dec 2015, kbuild test robot wrote: > CC: kbuild-all(a)01.org > CC: alsa-devel(a)alsa-project.org > TO: Takashi Iwai <tiwai(a)suse.de> > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git for-linus > head: ec20c9c7a63f7b8676eb574406a8bc8f32b7ba7e > commit: ec20c9c7a63f7b8676eb574406a8bc8f32b7ba7e [29/29] ALSA: rme96: Fix unexpected volume reset after rate changes > :::::: branch date: 2 hours ago > :::::: commit date: 2 hours ago > > >> sound/pci/rme96.c:1035:1-7: preceding lock on line 991 > > git remote add sound https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git > git remote update sound > git checkout ec20c9c7a63f7b8676eb574406a8bc8f32b7ba7e > vim +1035 sound/pci/rme96.c > > ^1da177e Linus Torvalds 2005-04-16 985 > 4d23359b Clemens Ladisch 2005-09-05 986 runtime->dma_area = (void __force *)(rme96->iobase + > 4d23359b Clemens Ladisch 2005-09-05 987 RME96_IO_PLAY_BUFFER); > ^1da177e Linus Torvalds 2005-04-16 988 runtime->dma_addr = rme96->port + RME96_IO_PLAY_BUFFER; > ^1da177e Linus Torvalds 2005-04-16 989 runtime->dma_bytes = RME96_BUFFER_SIZE; > ^1da177e Linus Torvalds 2005-04-16 990 > ^1da177e Linus Torvalds 2005-04-16 @991 spin_lock_irq(&rme96->lock); > ^1da177e Linus Torvalds 2005-04-16 992 if (!(rme96->wcreg & RME96_WCR_MASTER) && > ^1da177e Linus Torvalds 2005-04-16 993 snd_rme96_getinputtype(rme96) != RME96_INPUT_ANALOG && > ^1da177e Linus Torvalds 2005-04-16 994 (rate = snd_rme96_capture_getrate(rme96, &dummy)) > 0) > ^1da177e Linus Torvalds 2005-04-16 995 { > ^1da177e Linus Torvalds 2005-04-16 996 /* slave clock */ > ^1da177e Linus Torvalds 2005-04-16 997 if ((int)params_rate(params) != rate) { > ec20c9c7 Takashi Iwai 2015-12-04 998 err = -EIO; > ec20c9c7 Takashi Iwai 2015-12-04 999 goto error; > ^1da177e Linus Torvalds 2005-04-16 1000 } > ec20c9c7 Takashi Iwai 2015-12-04 1001 } else { > ec20c9c7 Takashi Iwai 2015-12-04 1002 err = snd_rme96_playback_setrate(rme96, params_rate(params)); > ec20c9c7 Takashi Iwai 2015-12-04 1003 if (err < 0) > ec20c9c7 Takashi Iwai 2015-12-04 1004 goto error; > ec20c9c7 Takashi Iwai 2015-12-04 1005 apply_dac_volume = err > 0; /* need to restore volume later? */ > ^1da177e Linus Torvalds 2005-04-16 1006 } > ec20c9c7 Takashi Iwai 2015-12-04 1007 if ((err = snd_rme96_playback_setformat(rme96, params_format(params))) < 0) > ec20c9c7 Takashi Iwai 2015-12-04 1008 goto error; > ^1da177e Linus Torvalds 2005-04-16 1009 snd_rme96_setframelog(rme96, params_channels(params), 1); > ^1da177e Linus Torvalds 2005-04-16 1010 if (rme96->capture_periodsize != 0) { > ^1da177e Linus Torvalds 2005-04-16 1011 if (params_period_size(params) << rme96->playback_frlog != > ^1da177e Linus Torvalds 2005-04-16 1012 rme96->capture_periodsize) > ^1da177e Linus Torvalds 2005-04-16 1013 { > ec20c9c7 Takashi Iwai 2015-12-04 1014 err = -EBUSY; > ec20c9c7 Takashi Iwai 2015-12-04 1015 goto error; > ^1da177e Linus Torvalds 2005-04-16 1016 } > ^1da177e Linus Torvalds 2005-04-16 1017 } > ^1da177e Linus Torvalds 2005-04-16 1018 rme96->playback_periodsize = > ^1da177e Linus Torvalds 2005-04-16 1019 params_period_size(params) << rme96->playback_frlog; > ^1da177e Linus Torvalds 2005-04-16 1020 snd_rme96_set_period_properties(rme96, rme96->playback_periodsize); > ^1da177e Linus Torvalds 2005-04-16 1021 /* S/PDIF setup */ > ^1da177e Linus Torvalds 2005-04-16 1022 if ((rme96->wcreg & RME96_WCR_ADAT) == 0) { > ^1da177e Linus Torvalds 2005-04-16 1023 rme96->wcreg &= ~(RME96_WCR_PRO | RME96_WCR_DOLBY | RME96_WCR_EMP); > ^1da177e Linus Torvalds 2005-04-16 1024 writel(rme96->wcreg |= rme96->wcreg_spdif_stream, rme96->iobase + RME96_IO_CONTROL_REGISTER); > ^1da177e Linus Torvalds 2005-04-16 1025 } > ^1da177e Linus Torvalds 2005-04-16 1026 spin_unlock_irq(&rme96->lock); > ec20c9c7 Takashi Iwai 2015-12-04 1027 err = 0; > ^1da177e Linus Torvalds 2005-04-16 1028 > ec20c9c7 Takashi Iwai 2015-12-04 1029 error: > ec20c9c7 Takashi Iwai 2015-12-04 1030 if (apply_dac_volume) { > ec20c9c7 Takashi Iwai 2015-12-04 1031 usleep_range(3000, 10000); > ec20c9c7 Takashi Iwai 2015-12-04 1032 snd_rme96_apply_dac_volume(rme96); > ec20c9c7 Takashi Iwai 2015-12-04 1033 } > ec20c9c7 Takashi Iwai 2015-12-04 1034 > ec20c9c7 Takashi Iwai 2015-12-04 @1035 return err; > ^1da177e Linus Torvalds 2005-04-16 1036 } > ^1da177e Linus Torvalds 2005-04-16 1037 > ^1da177e Linus Torvalds 2005-04-16 1038 static int > > --- > 0-DAY kernel test infrastructure Open Source Technology Center > https://lists.01.org/pipermail/kbuild-all Intel Corporation >

2 1

Re: [alsa-devel] [bug] Volume at maximum when track with different frequency is played with my RME sound card
by Maeda 04 Dec '15

04 Dec '15

Hi ! Someone's here ? Thanks. Le 23/10/2015 18:30, Maeda a écrit : > Hi all ! > > I don't know if the bug is known from your team, but some people > advice me to send an email to the Alsa devel list if nobody answer in > the kernel's bugtracking. > > Here is the bug I have : > https://bugzilla.kernel.org/show_bug.cgi?id=105771 > > What do you think about it ? > > If I was wrong sending this mail to this list, I'm sorry :) > > Thanks. > Have a nice day.

2 20

[alsa-devel] [PATCH v2 0/9] Add get_eld audio component for i915/HD-audio
by Takashi Iwai 04 Dec '15

04 Dec '15

Hi, this is a revised patchset to add get_eld op to audio component for communicating more directly between i915 and HD-audio. Currently, the HDMI/DP audio status and ELD are notified and obtained via the hardware-level communication over HD-audio unsolicited event and verbs although the graphics driver holds the exactly same information. As we already have a notification via audio component, this is another step forward; the audio driver fetches directly the audio status and ELD via the new component op. The patch still doesn't follow the recent kernel doc comment changes in i915_component.h. I'll rebase once when I get the steady branch in drm tree. The current patchset is found in sound git tree test/hdmi-jack branch. Takashi === v1->v2: * Use modeset lock for get_eld lock, drop av mutex * Return the expected size from get_eld, not the copied size * Add reverse map from a port number to the encoder * Deferred invocation of get_eld from the eld_notify in HDA side * A bit more code refactoring in HDA side * Move audio component accessors to hdac_i915.c Takashi Iwai (9): drm/i915: Remove superfluous NULL check drm/i915: Add get_eld audio component drm/i915: refactoring audio component functions drm/i915: Add reverse mapping between port and intel_encoder ALSA: hda - Split ELD update code from hdmi_present_sense() ALSA: hda - Use component ops for i915 HDMI/DP audio jack handling ALSA: hda - Do zero-clear in snd_hdmi_parse_eld() itself ALSA: hda - Skip ELD notification during PM process ALSA: hda - Move audio component accesses to hdac_i915.c drivers/gpu/drm/i915/i915_drv.h | 2 + drivers/gpu/drm/i915/intel_audio.c | 59 ++++++--- drivers/gpu/drm/i915/intel_ddi.c | 1 + drivers/gpu/drm/i915/intel_dp.c | 1 + drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_hdmi.c | 2 + include/drm/i915_component.h | 6 + include/sound/hda_i915.h | 14 +++ sound/hda/hdac_i915.c | 66 +++++++++++ sound/pci/hda/hda_eld.c | 1 + sound/pci/hda/patch_hdmi.c | 237 +++++++++++++++++++++++++------------ 11 files changed, 294 insertions(+), 96 deletions(-) -- 2.6.3

3 34

[alsa-devel] [PATCH v2] ALSA: compress: add support for 32bit calls in a 64bit kernel
by Ravindra Lokhande 04 Dec '15

04 Dec '15

Compress offload does not support ioctl calls from a 32bit userspace in a 64 bit kernel. This patch adds support for ioctls from a 32bit userspace in a 64bit kernel Signed-off-by: Ravindra Lokhande <rlokhande(a)nvidia.com> --- v1 -> v2: use compat_ptr to convert 32 bit address to 64 bit pointer sound/core/compress_offload.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/sound/core/compress_offload.c b/sound/core/compress_offload.c index b123c42..4c156a7 100644 --- a/sound/core/compress_offload.c +++ b/sound/core/compress_offload.c @@ -847,6 +847,15 @@ static long snd_compr_ioctl(struct file *f, unsigned int cmd, unsigned long arg) return retval; } +/* support of 32bit userspace on 64bit platforms */ +#ifdef CONFIG_COMPAT +static long snd_compr_ioctl_compat(struct file *file, unsigned int cmd, + unsigned long arg) +{ + return snd_compr_ioctl(file, cmd, (unsigned long)compat_ptr(arg)); +} +#endif + static const struct file_operations snd_compr_file_ops = { .owner = THIS_MODULE, .open = snd_compr_open, @@ -854,6 +863,9 @@ static const struct file_operations snd_compr_file_ops = { .write = snd_compr_write, .read = snd_compr_read, .unlocked_ioctl = snd_compr_ioctl, +#ifdef CONFIG_COMPAT + .compat_ioctl = snd_compr_ioctl_compat, +#endif .mmap = snd_compr_mmap, .poll = snd_compr_poll, }; -- 2.1.4

2 1

[alsa-devel] [PATCH] ALSA: hda - Enable audio component for old Intel PCH devices
by Takashi Iwai 04 Dec '15

04 Dec '15

As i915 graphics driver provides the notification via audio component, not only the currently implemented HSW+ and VLV+ platforms but also all other PCH-based platforms (e.g. Cougar Point, Panther Point, etc) can use this infrastructure. It'll improve the reliability and the power consumption significantly, especially once when we implement the ELD notification via component. As a preliminary, this patch enables the usage of audio component for all PCH platforms. The HDA controller just needs to set AZX_DCAPS_I915_POWERWELL flag appropriately. The name of the flag is a bit confusing, but this actually works even on the chips without the powerwell but accesses only the other component ops. In the HDMI/DP codec driver side, we just need to register/unregister the notifier for such chips. This can be identified by checking the audio_component field in the assigned hdac_bus. One caveat is that PCH for Haswell and Broadwell must not be bound with i915 audio component, as there are dedicated HD-audio HDMI controllers on these platforms. Ditto for Poulsbo and Oaktrail as they use gma500 graphics, not i915. Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/pci/hda/hda_intel.c | 14 ++++++++++---- sound/pci/hda/patch_hdmi.c | 6 ++++-- 2 files changed, 14 insertions(+), 6 deletions(-) diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 963f82430938..ee0e316401f9 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -284,13 +284,19 @@ enum { (AZX_DCAPS_OLD_SSYNC | AZX_DCAPS_NO_ALIGN_BUFSIZE) /* quirks for Intel PCH */ -#define AZX_DCAPS_INTEL_PCH_NOPM \ +#define AZX_DCAPS_INTEL_PCH_BASE \ (AZX_DCAPS_NO_ALIGN_BUFSIZE | AZX_DCAPS_COUNT_LPIB_DELAY |\ AZX_DCAPS_REVERSE_ASSIGN | AZX_DCAPS_SNOOP_TYPE(SCH)) +/* PCH up to IVB; bound with i915 audio component for HDMI, no runtime PM */ +#define AZX_DCAPS_INTEL_PCH_NOPM \ + (AZX_DCAPS_INTEL_PCH_BASE | AZX_DCAPS_I915_POWERWELL) + +/* PCH for HSW/BDW; with runtime PM, but no i915 binding */ #define AZX_DCAPS_INTEL_PCH \ - (AZX_DCAPS_INTEL_PCH_NOPM | AZX_DCAPS_PM_RUNTIME) + (AZX_DCAPS_INTEL_PCH_BASE | AZX_DCAPS_PM_RUNTIME) +/* HSW HDMI */ #define AZX_DCAPS_INTEL_HASWELL \ (/*AZX_DCAPS_ALIGN_BUFSIZE |*/ AZX_DCAPS_COUNT_LPIB_DELAY |\ AZX_DCAPS_PM_RUNTIME | AZX_DCAPS_I915_POWERWELL |\ @@ -2146,10 +2152,10 @@ static const struct pci_device_id azx_ids[] = { .driver_data = AZX_DRIVER_SCH | AZX_DCAPS_INTEL_PCH_NOPM }, /* Poulsbo */ { PCI_DEVICE(0x8086, 0x811b), - .driver_data = AZX_DRIVER_SCH | AZX_DCAPS_INTEL_PCH_NOPM }, + .driver_data = AZX_DRIVER_SCH | AZX_DCAPS_INTEL_PCH_BASE }, /* Oaktrail */ { PCI_DEVICE(0x8086, 0x080a), - .driver_data = AZX_DRIVER_SCH | AZX_DCAPS_INTEL_PCH_NOPM }, + .driver_data = AZX_DRIVER_SCH | AZX_DCAPS_INTEL_PCH_BASE }, /* BayTrail */ { PCI_DEVICE(0x8086, 0x0f04), .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_BAYTRAIL }, diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index a918377d3e9b..85342d261043 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -152,6 +152,8 @@ struct hdmi_spec { struct i915_audio_component_audio_ops i915_audio_ops; }; +#define codec_has_acomp(codec) \ + ((codec)->bus->core.audio_component != NULL) struct hdmi_audio_infoframe { u8 type; /* 0x84 */ @@ -2218,7 +2220,7 @@ static void generic_hdmi_free(struct hda_codec *codec) struct hdmi_spec *spec = codec->spec; int pin_idx; - if (is_haswell_plus(codec) || is_valleyview_plus(codec)) + if (codec_has_acomp(codec)) snd_hdac_i915_register_notifier(NULL); for (pin_idx = 0; pin_idx < spec->num_pins; pin_idx++) { @@ -2390,7 +2392,7 @@ static int patch_generic_hdmi(struct hda_codec *codec) is_broxton(codec)) codec->core.link_power_control = 1; - if (is_haswell_plus(codec) || is_valleyview_plus(codec)) { + if (codec_has_acomp(codec)) { codec->depop_delay = 0; spec->i915_audio_ops.audio_ptr = codec; spec->i915_audio_ops.pin_eld_notify = intel_pin_eld_notify; -- 2.6.3

1 0

[alsa-devel] Clock Rate Clock Rate Adjustment API
by Chas Leichner 04 Dec '15

04 Dec '15

I would like to be able to make small adjustments the playback clock rate of a PCM device as it is playing in order to accurately synchronize music playback across several computers. Looking at the kernel source, this functionality has been previously implemented in both the aloop driver and ST's uniperif driver where the clock rate adjustment was exposed to the user space as a control element. Although the control interface can be used to communicate this information, the naming and properties of the clock adjustment controls don't appear to be standardized or documented and I don't see anything related to clock rate adjustment in Documentation/sound/alsa/ControlNames.txt. In order to make a standardized interface, do you think it makes more sense to standardize on a clock rate adjustment control or introduce a new interface other than the control interface because the control interface is only for mixer controls rather than arbitrary runtime changes to the driver? Regards, Chas

2 1

[alsa-devel] [PATCH 1/2] ASoC: arizona: Correct types of mixer texts and values
by Charles Keepax 03 Dec '15

03 Dec '15

The core expects "const char * const" and "unsigned int" for enum controls, various places in Arizona use "const char *" and "int". This patch corrects the type of these arrays. Signed-off-by: Charles Keepax <ckeepax(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/arizona.c | 8 ++++---- sound/soc/codecs/arizona.h | 8 ++++---- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/sound/soc/codecs/arizona.c b/sound/soc/codecs/arizona.c index a23f7d1..d2731cf 100644 --- a/sound/soc/codecs/arizona.c +++ b/sound/soc/codecs/arizona.c @@ -310,7 +310,7 @@ int arizona_init_gpio(struct snd_soc_codec *codec) } EXPORT_SYMBOL_GPL(arizona_init_gpio); -const char *arizona_mixer_texts[ARIZONA_NUM_MIXER_INPUTS] = { +const char * const arizona_mixer_texts[ARIZONA_NUM_MIXER_INPUTS] = { "None", "Tone Generator 1", "Tone Generator 2", @@ -418,7 +418,7 @@ const char *arizona_mixer_texts[ARIZONA_NUM_MIXER_INPUTS] = { }; EXPORT_SYMBOL_GPL(arizona_mixer_texts); -int arizona_mixer_values[ARIZONA_NUM_MIXER_INPUTS] = { +unsigned int arizona_mixer_values[ARIZONA_NUM_MIXER_INPUTS] = { 0x00, /* None */ 0x04, /* Tone */ 0x05, @@ -555,12 +555,12 @@ const char *arizona_sample_rate_val_to_name(unsigned int rate_val) } EXPORT_SYMBOL_GPL(arizona_sample_rate_val_to_name); -const char *arizona_rate_text[ARIZONA_RATE_ENUM_SIZE] = { +const char * const arizona_rate_text[ARIZONA_RATE_ENUM_SIZE] = { "SYNCCLK rate", "8kHz", "16kHz", "ASYNCCLK rate", }; EXPORT_SYMBOL_GPL(arizona_rate_text); -const int arizona_rate_val[ARIZONA_RATE_ENUM_SIZE] = { +const unsigned int arizona_rate_val[ARIZONA_RATE_ENUM_SIZE] = { 0, 1, 2, 8, }; EXPORT_SYMBOL_GPL(arizona_rate_val); diff --git a/sound/soc/codecs/arizona.h b/sound/soc/codecs/arizona.h index 01a367c..b4f1867 100644 --- a/sound/soc/codecs/arizona.h +++ b/sound/soc/codecs/arizona.h @@ -96,8 +96,8 @@ struct arizona_priv { #define ARIZONA_NUM_MIXER_INPUTS 104 extern const unsigned int arizona_mixer_tlv[]; -extern const char *arizona_mixer_texts[ARIZONA_NUM_MIXER_INPUTS]; -extern int arizona_mixer_values[ARIZONA_NUM_MIXER_INPUTS]; +extern const char * const arizona_mixer_texts[ARIZONA_NUM_MIXER_INPUTS]; +extern unsigned int arizona_mixer_values[ARIZONA_NUM_MIXER_INPUTS]; #define ARIZONA_GAINMUX_CONTROLS(name, base) \ SOC_SINGLE_RANGE_TLV(name " Input Volume", base + 1, \ @@ -216,8 +216,8 @@ extern int arizona_mixer_values[ARIZONA_NUM_MIXER_INPUTS]; #define ARIZONA_RATE_ENUM_SIZE 4 #define ARIZONA_SAMPLE_RATE_ENUM_SIZE 14 -extern const char *arizona_rate_text[ARIZONA_RATE_ENUM_SIZE]; -extern const int arizona_rate_val[ARIZONA_RATE_ENUM_SIZE]; +extern const char * const arizona_rate_text[ARIZONA_RATE_ENUM_SIZE]; +extern const unsigned int arizona_rate_val[ARIZONA_RATE_ENUM_SIZE]; extern const char * const arizona_sample_rate_text[ARIZONA_SAMPLE_RATE_ENUM_SIZE]; extern const unsigned int arizona_sample_rate_val[ARIZONA_SAMPLE_RATE_ENUM_SIZE]; -- 2.1.4

2 3

[alsa-devel] mx28: bad unlock balance detected
by Fabio Estevam 03 Dec '15

03 Dec '15

Hi, Running linux-next 20151126 on a mx28evk leads to the following bug: sgtl5000 0-000a: sgtl5000 revision 0x11 sgtl5000 0-000a: Using internal LDO instead of VDDD ===================================== [ BUG: bad unlock balance detected! ] 4.4.0-rc2-next-20151126-00001-g44eb6b2 #156 Not tainted ------------------------------------- kworker/u2:0/6 is trying to release lock (&rdev->mutex) at: [<c02e7858>] regulator_get_voltage+0x30/0x44 but there are no more locks to release! other info that might help us debug this: 5 locks held by kworker/u2:0/6: #0: ("%s""deferwq"){++++.+}, at: [<c002f1f8>] process_one_work+0x10c/0x49c #1: (deferred_probe_work){+.+.+.}, at: [<c002f1f8>] process_one_work+0x10c/0x49c #2: (&dev->mutex){......}, at: [<c03197bc>] __device_attach+0x20/0x108 #3: (client_mutex){+.+.+.}, at: [<c042dc34>] snd_soc_register_card+0x280/0x1108 #4: (&card->mutex){+.+.+.}, at: [<c042dc40>] snd_soc_register_card+0x28c/0x1108 stack backtrace: CPU: 0 PID: 6 Comm: kworker/u2:0 Not tainted 4.4.0-rc2-next-20151126-00001-g44eb6b2 #156 Hardware name: Freescale MXS (Device Tree) Workqueue: deferwq deferred_probe_work_func [<c000eea0>] (unwind_backtrace) from [<c000cfa0>] (show_stack+0x10/0x14) [<c000cfa0>] (show_stack) from [<c0049350>] (print_unlock_imbalance_bug+0xac/0xdc) [<c0049350>] (print_unlock_imbalance_bug) from [<c004c2f8>] (lock_release+0x2a4/0x38c) [<c004c2f8>] (lock_release) from [<c0513e70>] (__mutex_unlock_slowpath+0x7c/0x15c) [<c0513e70>] (__mutex_unlock_slowpath) from [<c02e7858>] (regulator_get_voltage+0x30/0x44) [<c02e7858>] (regulator_get_voltage) from [<c043c200>] (sgtl5000_probe+0x1c0/0x5f0) [<c043c200>] (sgtl5000_probe) from [<c0428a74>] (snd_soc_codec_drv_probe+0x14/0x18) [<c0428a74>] (snd_soc_codec_drv_probe) from [<c042cd54>] (soc_probe_component+0x200/0x330) [<c042cd54>] (soc_probe_component) from [<c042e178>] (snd_soc_register_card+0x7c4/0x1108) [<c042e178>] (snd_soc_register_card) from [<c0439cdc>] (devm_snd_soc_register_card+0x30/0x70) [<c0439cdc>] (devm_snd_soc_register_card) from [<c043d1cc>] (mxs_sgtl5000_probe+0xc8/0x138) [<c043d1cc>] (mxs_sgtl5000_probe) from [<c031b1fc>] (platform_drv_probe+0x50/0xac) [<c031b1fc>] (platform_drv_probe) from [<c0319ab0>] (driver_probe_device+0x1e4/0x2b0) [<c0319ab0>] (driver_probe_device) from [<c03180d8>] (bus_for_each_drv+0x44/0x8c) [<c03180d8>] (bus_for_each_drv) from [<c0319840>] (__device_attach+0xa4/0x108) [<c0319840>] (__device_attach) from [<c0318f84>] (bus_probe_device+0x88/0x90) [<c0318f84>] (bus_probe_device) from [<c0319370>] (deferred_probe_work_func+0x64/0x94) [<c0319370>] (deferred_probe_work_func) from [<c002f290>] (process_one_work+0x1a4/0x49c) [<c002f290>] (process_one_work) from [<c002f5e8>] (worker_thread+0x28/0x468) [<c002f5e8>] (worker_thread) from [<c0034dbc>] (kthread+0xc0/0xdc) [<c0034dbc>] (kthread) from [<c000a2ec>] (ret_from_fork+0x14/0x28) mxs-sgtl5000 sound: sgtl5000 <-> 80042000.saif mapping ok By inspecting the sgtl5000 codec driver I could not find where this "bad unlock balance" is happening. Any ideas? Thanks, Fabio Estevam

2 3

[alsa-devel] [PATCH v2] ASoC: da7218: Enable mic level detection reporting to user-space
by Adam Thomson 03 Dec '15

03 Dec '15

This patch adds support to the codec driver to handle mic level detect related IRQs, and report these to user-space using a uevent variable. The uevent variable string "EVENT=MIC_LEVEL_DETECT" is sent to user-space, if the mic level detect feature is enabled, and the audio captured at the chosen mic(s) is above a certain threshold. User-space can then handle the event accordingly (e.g. process audio capture stream). This method was chosen over ALSA control notification for a couple of reasons: 1) There's no requirement here for a control to read state from. The event is the only thing that's required and of interest. 2) tinyalsa support for control notifications does not exist so on platforms using this over alsa-lib there is a need to add code to support this event handling. Another possible option would be to use the standard Jack reporting framework but this really does not fit for this kind of event. Finally, use of the input device framework is not being encouraged, due to difficulties in enabling apps to access input devices, so this has also been avoided. Signed-off-by: Adam Thomson <Adam.Thomson.Opensource(a)diasemi.com> --- Changes in v2: - More verbose and descriptive commit message added. sound/soc/codecs/da7218.c | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/sound/soc/codecs/da7218.c b/sound/soc/codecs/da7218.c index 4fee7ae..752ed04 100644 --- a/sound/soc/codecs/da7218.c +++ b/sound/soc/codecs/da7218.c @@ -2202,6 +2202,16 @@ int da7218_hpldet(struct snd_soc_codec *codec, struct snd_soc_jack *jack) } EXPORT_SYMBOL_GPL(da7218_hpldet); +static void da7218_micldet_irq(struct snd_soc_codec *codec) +{ + char *envp[] = { + "EVENT=MIC_LEVEL_DETECT", + NULL, + }; + + kobject_uevent_env(&codec->dev->kobj, KOBJ_CHANGE, envp); +} + static void da7218_hpldet_irq(struct snd_soc_codec *codec) { struct da7218_priv *da7218 = snd_soc_codec_get_drvdata(codec); @@ -2232,6 +2242,10 @@ static irqreturn_t da7218_irq_thread(int irq, void *data) if (!status) return IRQ_NONE; + /* Mic level detect */ + if (status & DA7218_LVL_DET_EVENT_MASK) + da7218_micldet_irq(codec); + /* HP detect */ if (status & DA7218_HPLDET_JACK_EVENT_MASK) da7218_hpldet_irq(codec); @@ -2936,11 +2950,6 @@ static int da7218_probe(struct snd_soc_codec *codec) } if (da7218->irq) { - /* Mask off mic level events, currently not handled */ - snd_soc_update_bits(codec, DA7218_EVENT_MASK, - DA7218_LVL_DET_EVENT_MSK_MASK, - DA7218_LVL_DET_EVENT_MSK_MASK); - ret = devm_request_threaded_irq(codec->dev, da7218->irq, NULL, da7218_irq_thread, IRQF_TRIGGER_LOW | IRQF_ONESHOT, -- 1.9.3

1 0