January 2018 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH] ASoC: codecs: dmic: Make number of channels configurable
by Matthias Kaehlcke 09 Jan '18

09 Jan '18

The DMIC DAI driver specifies a number of 1 to 8 channels for each DAI. The actual number of mics can currently not be configured in the device tree or audio glue, but is derived from the min/max channels of the CPU and codec DAI. A typical CPU DAI has two or more channels, in consequence a single mic is treated as a stereo/multi channel device, even though only one channel carries audio data. This change adds the option to specify the number of used DMIC channels in the device tree. When specified this value overwrites the default channels_max value of 8 in the snd_soc_dai_driver struct of the codec. Signed-off-by: Matthias Kaehlcke <mka(a)chromium.org> --- Documentation/devicetree/bindings/sound/dmic.txt | 2 ++ sound/soc/codecs/dmic.c | 24 +++++++++++++++++++++++- 2 files changed, 25 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/sound/dmic.txt b/Documentation/devicetree/bindings/sound/dmic.txt index 54c8ef6498a8..f7bf65611453 100644 --- a/Documentation/devicetree/bindings/sound/dmic.txt +++ b/Documentation/devicetree/bindings/sound/dmic.txt @@ -7,10 +7,12 @@ Required properties: Optional properties: - dmicen-gpios: GPIO specifier for dmic to control start and stop + - num-channels: Number of microphones on this DAI Example node: dmic_codec: dmic@0 { compatible = "dmic-codec"; dmicen-gpios = <&gpio4 3 GPIO_ACTIVE_HIGH>; + num-channels = <1>; }; diff --git a/sound/soc/codecs/dmic.c b/sound/soc/codecs/dmic.c index b88a1ee66f80..c88f974ebe3e 100644 --- a/sound/soc/codecs/dmic.c +++ b/sound/soc/codecs/dmic.c @@ -107,8 +107,30 @@ static const struct snd_soc_codec_driver soc_dmic = { static int dmic_dev_probe(struct platform_device *pdev) { + int err; + u32 chans; + struct snd_soc_dai_driver *dai_drv = &dmic_dai; + + if (pdev->dev.of_node) { + err = of_property_read_u32(pdev->dev.of_node, "num-channels", &chans); + if (err && (err != -ENOENT)) + return err; + + if (!err) { + if (chans < 1 || chans > 8) + return -EINVAL; + + dai_drv = devm_kzalloc(&pdev->dev, sizeof(*dai_drv), GFP_KERNEL); + if (!dai_drv) + return -ENOMEM; + + memcpy(dai_drv, &dmic_dai, sizeof(*dai_drv)); + dai_drv->capture.channels_max = chans; + } + } + return snd_soc_register_codec(&pdev->dev, - &soc_dmic, &dmic_dai, 1); + &soc_dmic, dai_drv, 1); } static int dmic_dev_remove(struct platform_device *pdev) -- 2.16.0.rc0.223.g4a4ac83678-goog

4 3

[alsa-devel] [PATCH v1] ASoC: TSCS42xx: Fix control names
by Steven Eckhoff 09 Jan '18

09 Jan '18

The tscs42xx CODEC driver can confuse userspace with non-standard control names. Remove "Switch" from enum control type names. Add "Switch" to on/off control type names. Signed-off-by: Steven Eckhoff <steven.eckhoff.opensource(a)gmail.com> --- sound/soc/codecs/tscs42xx.c | 42 +++++++++++++++++++++--------------------- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/sound/soc/codecs/tscs42xx.c b/sound/soc/codecs/tscs42xx.c index eedd600875e5..4a5b32a717f2 100644 --- a/sound/soc/codecs/tscs42xx.c +++ b/sound/soc/codecs/tscs42xx.c @@ -631,7 +631,7 @@ static const struct snd_kcontrol_new tscs42xx_snd_controls[] = { 0, mic_boost_scale), /* Input Channel Map */ - SOC_ENUM("Input Channel Map Switch", ch_map_select_enum), + SOC_ENUM("Input Channel Map", ch_map_select_enum), /* Coefficient Ram */ COEFF_RAM_CTL("Cascade1L BiQuad1", BIQUAD_SIZE, 0x00), @@ -708,13 +708,13 @@ static const struct snd_kcontrol_new tscs42xx_snd_controls[] = { /* EQ */ SOC_SINGLE("EQ1 Switch", R_CONFIG1, FB_CONFIG1_EQ1_EN, 1, 0), SOC_SINGLE("EQ2 Switch", R_CONFIG1, FB_CONFIG1_EQ2_EN, 1, 0), - SOC_ENUM("EQ1 Band Enable Switch", eq1_band_enable_enum), - SOC_ENUM("EQ2 Band Enable Switch", eq2_band_enable_enum), + SOC_ENUM("EQ1 Band Enable", eq1_band_enable_enum), + SOC_ENUM("EQ2 Band Enable", eq2_band_enable_enum), /* CLE */ - SOC_ENUM("CLE Level Detect Switch", + SOC_ENUM("CLE Level Detect", cle_level_detection_enum), - SOC_ENUM("CLE Level Detect Win Switch", + SOC_ENUM("CLE Level Detect Win", cle_level_detection_window_enum), SOC_SINGLE("Expander Switch", R_CLECTL, FB_CLECTL_EXP_EN, 1, 0), @@ -726,7 +726,7 @@ static const struct snd_kcontrol_new tscs42xx_snd_controls[] = { R_MUGAIN, FB_MUGAIN_CLEMUG, 0x1f, 0, mugain_scale), SOC_SINGLE_TLV("Comp Thresh Playback Volume", R_COMPTH, FB_COMPTH, 0xff, 0, compth_scale), - SOC_ENUM("Comp Ratio Switch", compressor_ratio_enum), + SOC_ENUM("Comp Ratio", compressor_ratio_enum), SND_SOC_BYTES("Comp Atk Time", R_CATKTCL, 2), /* Effects */ @@ -740,50 +740,50 @@ static const struct snd_kcontrol_new tscs42xx_snd_controls[] = { SOC_SINGLE("MBC Band1 Switch", R_DACMBCEN, FB_DACMBCEN_MBCEN1, 1, 0), SOC_SINGLE("MBC Band2 Switch", R_DACMBCEN, FB_DACMBCEN_MBCEN2, 1, 0), SOC_SINGLE("MBC Band3 Switch", R_DACMBCEN, FB_DACMBCEN_MBCEN3, 1, 0), - SOC_ENUM("MBC Band1 Level Detect Switch", + SOC_ENUM("MBC Band1 Level Detect", mbc_level_detection_enums[0]), - SOC_ENUM("MBC Band2 Level Detect Switch", + SOC_ENUM("MBC Band2 Level Detect", mbc_level_detection_enums[1]), - SOC_ENUM("MBC Band3 Level Detect Switch", + SOC_ENUM("MBC Band3 Level Detect", mbc_level_detection_enums[2]), - SOC_ENUM("MBC Band1 Level Detect Win Switch", + SOC_ENUM("MBC Band1 Level Detect Win", mbc_level_detection_window_enums[0]), - SOC_ENUM("MBC Band2 Level Detect Win Switch", + SOC_ENUM("MBC Band2 Level Detect Win", mbc_level_detection_window_enums[1]), - SOC_ENUM("MBC Band3 Level Detect Win Switch", + SOC_ENUM("MBC Band3 Level Detect Win", mbc_level_detection_window_enums[2]), - SOC_SINGLE("MBC1 Phase Invert", R_DACMBCMUG1, FB_DACMBCMUG1_PHASE, - 1, 0), + SOC_SINGLE("MBC1 Phase Invert Switch", + R_DACMBCMUG1, FB_DACMBCMUG1_PHASE, 1, 0), SOC_SINGLE_TLV("DAC MBC1 Make-Up Gain Playback Volume", R_DACMBCMUG1, FB_DACMBCMUG1_MUGAIN, 0x1f, 0, mugain_scale), SOC_SINGLE_TLV("DAC MBC1 Comp Thresh Playback Volume", R_DACMBCTHR1, FB_DACMBCTHR1_THRESH, 0xff, 0, compth_scale), - SOC_ENUM("DAC MBC1 Comp Ratio Switch", + SOC_ENUM("DAC MBC1 Comp Ratio", dac_mbc1_compressor_ratio_enum), SND_SOC_BYTES("DAC MBC1 Comp Atk Time", R_DACMBCATK1L, 2), SND_SOC_BYTES("DAC MBC1 Comp Rel Time Const", R_DACMBCREL1L, 2), - SOC_SINGLE("MBC2 Phase Invert", R_DACMBCMUG2, FB_DACMBCMUG2_PHASE, - 1, 0), + SOC_SINGLE("MBC2 Phase Invert Switch", + R_DACMBCMUG2, FB_DACMBCMUG2_PHASE, 1, 0), SOC_SINGLE_TLV("DAC MBC2 Make-Up Gain Playback Volume", R_DACMBCMUG2, FB_DACMBCMUG2_MUGAIN, 0x1f, 0, mugain_scale), SOC_SINGLE_TLV("DAC MBC2 Comp Thresh Playback Volume", R_DACMBCTHR2, FB_DACMBCTHR2_THRESH, 0xff, 0, compth_scale), - SOC_ENUM("DAC MBC2 Comp Ratio Switch", + SOC_ENUM("DAC MBC2 Comp Ratio", dac_mbc2_compressor_ratio_enum), SND_SOC_BYTES("DAC MBC2 Comp Atk Time", R_DACMBCATK2L, 2), SND_SOC_BYTES("DAC MBC2 Comp Rel Time Const", R_DACMBCREL2L, 2), - SOC_SINGLE("MBC3 Phase Invert", R_DACMBCMUG3, FB_DACMBCMUG3_PHASE, - 1, 0), + SOC_SINGLE("MBC3 Phase Invert Switch", + R_DACMBCMUG3, FB_DACMBCMUG3_PHASE, 1, 0), SOC_SINGLE_TLV("DAC MBC3 Make-Up Gain Playback Volume", R_DACMBCMUG3, FB_DACMBCMUG3_MUGAIN, 0x1f, 0, mugain_scale), SOC_SINGLE_TLV("DAC MBC3 Comp Thresh Playback Volume", R_DACMBCTHR3, FB_DACMBCTHR3_THRESH, 0xff, 0, compth_scale), - SOC_ENUM("DAC MBC3 Comp Ratio Switch", + SOC_ENUM("DAC MBC3 Comp Ratio", dac_mbc3_compressor_ratio_enum), SND_SOC_BYTES("DAC MBC3 Comp Atk Time", R_DACMBCATK3L, 2), SND_SOC_BYTES("DAC MBC3 Comp Rel Time Const", -- 2.11.0

2 1

[alsa-devel] [PATCH][next] ASoC: TSCS42xx: make functions pll_event and dac_event static
by Colin King 09 Jan '18

09 Jan '18

From: Colin Ian King <colin.king(a)canonical.com> The functions pll_event and dac_event are local to the source and do not need to be in global scope, so make them static. Cleans up sparse warnings: symbol 'pll_event' was not declared. Should it be static? symbol 'dac_event' was not declared. Should it be static? Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- sound/soc/codecs/tscs42xx.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/sound/soc/codecs/tscs42xx.c b/sound/soc/codecs/tscs42xx.c index eedd600875e5..9e8155766ea9 100644 --- a/sound/soc/codecs/tscs42xx.c +++ b/sound/soc/codecs/tscs42xx.c @@ -355,8 +355,8 @@ static int dapm_micb_event(struct snd_soc_dapm_widget *w, return 0; } -int pll_event(struct snd_soc_dapm_widget *w, - struct snd_kcontrol *kcontrol, int event) +static int pll_event(struct snd_soc_dapm_widget *w, + struct snd_kcontrol *kcontrol, int event) { struct snd_soc_codec *codec = snd_soc_dapm_to_codec(w->dapm); int ret; @@ -369,8 +369,8 @@ int pll_event(struct snd_soc_dapm_widget *w, return ret; } -int dac_event(struct snd_soc_dapm_widget *w, - struct snd_kcontrol *kcontrol, int event) +static int dac_event(struct snd_soc_dapm_widget *w, + struct snd_kcontrol *kcontrol, int event) { struct snd_soc_codec *codec = snd_soc_dapm_to_codec(w->dapm); struct tscs42xx *tscs42xx = snd_soc_codec_get_drvdata(codec); -- 2.15.1

3 2

[alsa-devel] 4.16 merge window: please send earlier
by Takashi Iwai 09 Jan '18

09 Jan '18

Hi, currently 4.16 merge window is planned to be opened in two weeks, around Jan 21. At this time, there will be a conflict with my private schedule: I'll be traveling from Jan 20 for a couple of weeks. I'll be with a laptop and the net should work, so I likely can still keep merging but it'll be quite much reduced. So, at this time, I'd like to set the merge deadline earlier. If anyone has some material to be merged for 4.16, please submit ASAP, preferably in this week, or in the beginning of the next week. Luckily Mark already sent a pull request for the major changes, so the big changes have been already there. If any, Mark, send the further fixes earlier than usual, please. thanks, Takashi

1 0

[alsa-devel] Set multiple mixer channel values at once
by Petr Kulhavy 09 Jan '18

09 Jan '18

Hi, does the ALSA library provide a method to set multiple channel values of a multi-channel mixer element at once? There are the snd_mixer_selem_set_XXXXX_all() methods, which set all channels to the same value. I would like to write a different value to each channel, is there such a method? My motivation is the following. I have a HW with DSP/equaliser function, which uses a 5-channel mixer element (volume type element) to store biquad coefficients. To avoid invalid values in the transfer function the coefficients have to be sent to the HW over I2C all together in one transfer. Though the low level driver does that, the snd_mixer_selem_set_playback_volume() API method I'm using sets only one coef at a time. This results in partial updates of the biquad coefficients and temporary errors in the transfer function. Thanks Petr

2 3

[alsa-devel] [PATCH] ASoC: rockchip: i2s: Support mono capture
by Matthias Kaehlcke 09 Jan '18

09 Jan '18

The Rockchip I2S controller only allows to configure even numbers of capture channels. It is still possible to capture monophonic audio by using dual-channel mode and ignoring the 'data' from the second channel. Signed-off-by: Matthias Kaehlcke <mka(a)chromium.org> --- sound/soc/rockchip/rockchip_i2s.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/sound/soc/rockchip/rockchip_i2s.c b/sound/soc/rockchip/rockchip_i2s.c index 908211e1d6fc..cc22ab3d10dd 100644 --- a/sound/soc/rockchip/rockchip_i2s.c +++ b/sound/soc/rockchip/rockchip_i2s.c @@ -328,6 +328,7 @@ static int rockchip_i2s_hw_params(struct snd_pcm_substream *substream, val |= I2S_CHN_4; break; case 2: + case 1: val |= I2S_CHN_2; break; default: @@ -460,7 +461,7 @@ static struct snd_soc_dai_driver rockchip_i2s_dai = { }, .capture = { .stream_name = "Capture", - .channels_min = 2, + .channels_min = 1, .channels_max = 2, .rates = SNDRV_PCM_RATE_8000_192000, .formats = (SNDRV_PCM_FMTBIT_S8 | @@ -654,7 +655,7 @@ static int rockchip_i2s_probe(struct platform_device *pdev) } if (!of_property_read_u32(node, "rockchip,capture-channels", &val)) { - if (val >= 2 && val <= 8) + if (val >= 1 && val <= 8) soc_dai->capture.channels_max = val; } -- 2.16.0.rc0.223.g4a4ac83678-goog

2 3

Re: [alsa-devel] Headphone issues iMac 14.1 (A1418)
by Takashi Iwai 09 Jan '18

09 Jan '18

On Tue, 09 Jan 2018 16:40:09 +0100, Freaky wrote: > > Hi, > > the speaker is always working on this Mac, whilst the headphone is > unplugged that is, haven't gotten it to not function. That said, the > unplug/plug events switch data I/O flags and unplugging the headphones > correctly enables the speakers voiding anything I had done with hda-verb. > > I'm not sure what the parameters do btw :). I understand the last parameter > is some value being written and that it's probably a bunch of binary flags, > but have little clue on what they exactly do. > > >From flipping flags and looking at the alsa-info.sh it seems that each bit > corresponds to a data I/O channel. 0x1 being IO[0], 0x2 IO[1], 0x4 IO[2], > 0x8 IO[3]. > > When IO[3]'s data=1 there's audio on the speakers (0x8) > So we wrote > 0x0 and verified alsa-info, all data IO's are disabled. Audio is gone. > Wrote 0x8, enabling bit 4, which flipped IO[3]'s data back to 1 and we have > audio on speaker. I presume that makes it safe to assume IO[3] is the Amp > for speaker. > > Plugged the headphone and looked at alsa-info. > Now IO[1]'s data is enabled and that seems to be where it goes wrong. wrote > 0x0 ensuring all IO's data are disabled (checked headphones - no sound > obviously) and then 0x4 which enabled only IO[2]'s data and there's audio > again. I presume IO[2] is the Amp for the headphones thus. > > Using only 0x4 works as well thus. I have no clue if there are any Amps > behind IO[0] and IO[1] and if so where they would be heading I'm afraid. > The driver enables IO[1]'s data upon plugging the headphone, which should > be IO[2]'s data on this system and unplugging enabled IO[3]'s data. That > might also be why I never have seen it as broken as I need to unplug the > headphone first, which switches flags correctly for the speaker output. > > Plugging / unplugging doesn't seem to have any effect on the other flags > required (direction and enabled). However, they do need to be set initially > and in an earlier test, when booted with the headphone already plugged and > then enabling them before any audio was played audio still didn't work. > Needed to enable them again. Perhaps pulse did something with the flags > then though (restoring the state at first audio playback or something). I > can test this if desired. Plugging/unplugging the headphones doesn't seem > to affect any of the IO's direction nor enabled flags, they remain the same > as they were. OK, so this looks like the gpio 2/3 case, and it corresponds to imac27_122 model. Could you try to add the model option like below? Create a module config file, e.g. /etc/modprobe.d/50-hda.conf containing: options snd-hda-intel model=,imac27_122 (Note the comma before imac27_122, it's no typo, but indicates to specify the second device -- where Haswell gives the HDMI/DP controller for the first PCI device while the second one is the analog I/O). If this works, the patch like below should work without the model option above. Takashi --- diff --git a/sound/pci/hda/patch_cirrus.c b/sound/pci/hda/patch_cirrus.c index 80bbadc83721..17660d03a314 100644 --- a/sound/pci/hda/patch_cirrus.c +++ b/sound/pci/hda/patch_cirrus.c @@ -408,6 +408,7 @@ static const struct snd_pci_quirk cs420x_fixup_tbl[] = { /*SND_PCI_QUIRK(0x8086, 0x7270, "IMac 27 Inch", CS420X_IMAC27),*/ /* codec SSID */ + SND_PCI_QUIRK(0x106b, 0x0600, "iMac 14,1", CS420X_IMAC27_122), SND_PCI_QUIRK(0x106b, 0x1c00, "MacBookPro 8,1", CS420X_MBP81), SND_PCI_QUIRK(0x106b, 0x2000, "iMac 12,2", CS420X_IMAC27_122), SND_PCI_QUIRK(0x106b, 0x2800, "MacBookPro 10,1", CS420X_MBP101),

1 0

Re: [alsa-devel] Headphone issues iMac 14.1 (A1418)
by Takashi Iwai 09 Jan '18

09 Jan '18

On Tue, 09 Jan 2018 15:16:38 +0100, Freaky wrote: > > Hi Takashi, > > what exactly do you need us to test? > > Running just: > hda-verb /dev/snd/hwC1D0 0x01 SET_GPIO_DATA 0x06 > doesn't produce sound on the headphones. > > After running > hda-verb /dev/snd/hwC1D0 0x01 SET_GPIO_MASK 0x0e > hda-verb /dev/snd/hwC1D0 0x01 SET_GPIO_DIRECTION 0x0e > > It starts producing sound. > > After replugging sound is gone. Only have to run the first one again to > have sound again, the other 2 are no longer required then. > > Tried, after executing all 3 commands, to replug and then use > hda-verb /dev/snd/hwC1D0 0x01 SET_GPIO_DATA XX > > where XX > 0x00 doesn't work > 0x01 doesn't work > 0x02 doesn't work > 0x04 works > 0x06 works > 0x08 doesn't work > > What's also somewhat odd, we run X as a user (auto logon). If I switch to > console before there was any audio playing and execute: > hda-verb /dev/snd/hwC1D0 0x01 SET_GPIO_DATA 0x06 > hda-verb /dev/snd/hwC1D0 0x01 SET_GPIO_MASK 0x0e > hda-verb /dev/snd/hwC1D0 0x01 SET_GPIO_DIRECTION 0x0e Both headphone and speaker outputs are controlled with different amps, so test them individually. And, does GPIO mask and direction need to be 0x0e, not 0x06? So, try at first: hda-verb /dev/snd/hwC1D0 0x01 SET_GPIO_MASK 0x06 hda-verb /dev/snd/hwC1D0 0x01 SET_GPIO_DIR 0x06 hda-verb /dev/snd/hwC1D0 0x01 SET_GPIO_DATA 0x06 If this makes both speaker and headphone working, go to the next step. Keep the following but change the data bits either 0x02 or 0x04: hda-verb /dev/snd/hwC1D0 0x01 SET_GPIO_MASK 0x06 hda-verb /dev/snd/hwC1D0 0x01 SET_GPIO_DIR 0x06 hda-verb /dev/snd/hwC1D0 0x01 SET_GPIO_DATA 0x02 and test whether the headphone and/or the speaker works. Again with 0x04, hda-verb /dev/snd/hwC1D0 0x01 SET_GPIO_DATA 0x04 test whether the headphone and/or the speaker works. You might need to adjust the whole GPIO setup at each time you plug/unplug the jack. Check /proc/asound/card0/codec#0 output whether the GPIO values are kept as expected before testing. If it's confirmed that both the GPIO bit 0x02 and 0x04 (or vice versa) correspond to the headphone and the speaker amps, I can cook up the patch to add quirk easily. thanks, Takashi > and switch back, start playing audio, there's no sound on the headphone. > I'll need to run them again. This might be related to pulseaudio however. > Just running the first command again doesn't suffice in that case. After > audio has been on the headphones once, in all my tests so far, only the > first command does suffice to get it working again and the 0x04 value then > also works. > > Any other values, order of commands, etc. you'd like us to test? > > Thanks for the help so far :). > > Kind regards, > > On Thu, Jan 4, 2018 at 5:35 PM, Takashi Iwai <tiwai(a)suse.de> wrote: > > > On Thu, 04 Jan 2018 17:27:55 +0100, > > Freaky wrote: > > > > > > Hi Takashi, > > > > > > we need it to get the headphone output working. Upon unplugging / > > > replugging we need to check them again (they remain checked, but the > > output > > > stops working). The speaker output (onboard speakers) works fine and the > > > script we run doesn't appear to have any effect on the speaker output at > > > all. > > > > The alsa-info.sh output showed that GPIO[1] is also set, so I wonder > > how and who sets it. In anyway, could you check whether flipping any > > such gpio bits turn on / off the headphone and the speaker outputs? > > Try to toggle it while playing back, such as, > > hda-verb /dev/snd/hwC1D0 0x01 SET_GPIO_DATA xxx > > where xxx is the value to be written (0x00, 0x02, 0x04, 0x06, etc). > > > > > Currently use a python script generated by the HDA Analyzer script that > > we > > > run every 5 seconds from boot. Pasted the script below. We run it every 5 > > > seconds to ensure audio will work after replugging the headphones > > (although > > > it might incur a small delay then of course). I don't notice any hick-ups > > > in audio playback because of the script firing every 5 seconds. > > > > > > There's no acpid running from which we could detect the plug event. > > Using a > > > system based on Fedora 24. Have watched dbus-monitor (--sytem), but see > > no > > > events there upon (un)plugging the headphones which we could use as > > trigger. > > > > The headphone jack detection on HD-audio is usually done via HD-audio > > codec unsolicited events. You can check "Headphone Jack" ALSA control > > element (e.g. watch the output of "amixer contents"). > > > > > > Takashi > > > [2 <text/html; UTF-8 (quoted-printable)>] >

1 0

[alsa-devel] [PATCH 0/2] PCM OSS fixes
by Takashi Iwai 09 Jan '18

09 Jan '18

Hi, this contains two fixes for PCM OSS bugs that have been triggered by syzbot. These are simple and straightforward, and I'm going to queue for 4.15-rc8. thanks, Takashi === Takashi Iwai (2): ALSA: pcm: Abort properly at pending signal in OSS read/write loops ALSA: pcm: Allow aborting mutex lock at OSS read/write loops sound/core/oss/pcm_oss.c | 40 +++++++++++++++++++++++++++------------- 1 file changed, 27 insertions(+), 13 deletions(-) -- 2.15.1

2 14

[alsa-devel] [PATCH v2 0/4] ASoC: Intel: ACPI-related fixes
by Pierre-Louis Bossart 09 Jan '18

09 Jan '18

The first 3 patches were provided earlier on the mailing list or in Bugzilla entries, I rebased and ported them on top of the latest ACPI/KConfig fixes. The last patch is a suggestion from Andy Shevchenko to remove a hard-coded array size Changes since v1: cleaned-up quirk handling, fixed merge mistake added Andy's Reviewed-by tag on patch 2 added 4th patch to add new constant dependent on ACPI_ID_LEN Jeremy Cline (1): ASoC: Replace snd_soc_acpi_check_hid with acpi_dev_present Pierre-Louis Bossart (3): ASoC: acpi: fix machine driver selection based on quirk ASoC: Intel: bytcht_es8316: fix HID handling ASoC: acpi: remove hard-coded i2c-device name length include/sound/soc-acpi.h | 6 ++--- sound/soc/intel/boards/Kconfig | 1 + sound/soc/intel/boards/bytcht_da7213.c | 2 +- sound/soc/intel/boards/bytcht_es8316.c | 26 ++++++++++++++++++++- sound/soc/intel/boards/bytcr_rt5640.c | 2 +- sound/soc/intel/boards/bytcr_rt5651.c | 2 +- sound/soc/intel/boards/cht_bsw_rt5645.c | 4 ++-- sound/soc/intel/boards/cht_bsw_rt5672.c | 2 +- sound/soc/soc-acpi.c | 40 +++++---------------------------- 9 files changed, 40 insertions(+), 45 deletions(-) -- 2.14.1

4 13