February 2020 - Alsa-devel - mailman.alsa-project.org

usage of snd_rawmidi_status_get_avail()
by GitHub issues - edited 20 Feb '20

20 Feb '20

alsa-project/alsa-lib issue #26 was edited from MusicMaker: In non blocked raw MIDI, is snd_rawmidi_status_get_avail supposed to return the number of available bytes that can be read using a snd_rawmidi_read. (port is opened for read only) It seems get_avail always returns 0 even there is MIDI data when using a read. Else is there a(nother) way to find the number of unread received bytes in the buffer? snd_rawmidi_status_alloca (&status); snd_rawmidi_status(client, status); snd_rawmidi_status_get_avail(status); Issue URL : https://github.com/alsa-project/alsa-lib/issues/26 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

usage of snd_rawmidi_status_get_avail()
by GitHub issues - edited 20 Feb '20

20 Feb '20

alsa-project/alsa-lib issue #26 was edited from MusicMaker: In non blocked raw MIDI, is snd_rawmidi_status_get_avail supposed to return the number of available bytes that can be read via snd_rawmidi_read. (port is opened for read only) It seems get_avail always returns 0 even there is MIDI data when using a read. Else is there a(nother) way to find the number of unread received bytes in the buffer? snd_rawmidi_status_alloca (&status); snd_rawmidi_status(client, status); snd_rawmidi_status_get_avail(status); Issue URL : https://github.com/alsa-project/alsa-lib/issues/26 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

usage of snd_rawmidi_status_get_avail()
by GitHub issues - edited 20 Feb '20

20 Feb '20

alsa-project/alsa-lib issue #26 was edited from MusicMaker: In non blocked raw MIDI, is snd_rawmidi_status_get_avail supposed to return the number of available bytes than can read via snd_rawmidi_read. (port is opened for read only) It seems get_avail always returns 0 even there is MIDI data when using a read. Else is there a(nother) way to find the number of unread received bytes in the buffer? snd_rawmidi_status_alloca (&status); snd_rawmidi_status(client, status); snd_rawmidi_status_get_avail(status); Issue URL : https://github.com/alsa-project/alsa-lib/issues/26 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

usage of snd_rawmidi_status_get_avail()
by GitHub issues - edited 20 Feb '20

20 Feb '20

alsa-project/alsa-lib issue #26 was edited from MusicMaker: In non blocked raw MIDI, is snd_rawmidi_status_get_avail supposed to return the number of available bytes than can read via snd_rawmidi_read. (port is opened for read only) It seems always return 0 even there is MIDI data when using a read. Else is there a(nother) way to find the number of unread received bytes in the buffer? snd_rawmidi_status_alloca (&status); snd_rawmidi_status(client, status); snd_rawmidi_status_get_avail(status); Issue URL : https://github.com/alsa-project/alsa-lib/issues/26 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

usage of snd_rawmidi_status_get_avail()
by GitHub issues - opened 20 Feb '20

20 Feb '20

alsa-project/alsa-lib issue #26 was opened from MusicMaker: In non blocked raw MIDI mode, is snd_rawmidi_status_get_avail supposed to return the number of available bytes than can read via snd_rawmidi_read. (port is opened for read only) It seems always return 0 even there is MIDI data when using a read. Else is there a(nother) way to find the number of unread received bytes in the buffer? snd_rawmidi_status_alloca (&status); snd_rawmidi_status(client, status); snd_rawmidi_status_get_avail(status); Issue URL : https://github.com/alsa-project/alsa-lib/issues/26 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

sytem reboots when initializing Edirol FA-101 firewire audio interface
by Steve Morris 20 Feb '20

20 Feb '20

Hi All, I'm running Arch Linux x86_64 My system consistently reboots when I power on my FA-101 when running kernels 5.5.1-4. Downgrading to 5.4.15 allows everything to work properly. Here's the outpu of: journalctl | grep -E 'Reboot|firewire|fw|bebob|alsa|jack' This is a good init under 5.4.15: -- Reboot -- powered on interface while running 5.4.15, initialized properly Feb 18 18:35:37 hostname kernel: firewire_ohci 0000:05:00.0: enabling device (0080 -> 0083) Feb 18 18:35:37 hostname kernel: firewire_ohci 0000:05:00.0: added OHCI v1.10 device as card 0, 4 IR + 8 IT contexts, quirks 0x11 Feb 18 18:35:37 hostname kernel: firewire_core 0000:05:00.0: created device fw0: GUID 0011223333666677, S400 Feb 18 18:35:37 hostname systemd-udevd[541]: controlC0: Process '/usr/bin/alsactl restore 0' failed with exit code 99. Feb 18 18:35:37 hostname systemd-udevd[541]: controlC1: Process '/usr/bin/alsactl restore 1' failed with exit code 99. Feb 18 18:35:38 hostname kernel: amdgpu: [powerplay] smu driver if version = 0x00000033, smu fw if version = 0x00000035, smu fw version = 0x002a3200 (42.50.0) Feb 18 18:36:08 hostname kernel: firewire_ohci 0000:05:00.0: isochronous cycle inconsistent Feb 18 18:36:08 hostname kernel: firewire_core 0000:05:00.0: created device fw1: GUID 0040ab0000c20bc1, S400 Feb 18 18:36:08 hostname kernel: firewire_core 0000:05:00.0: phy config: new root=ffc1, gap_count=5 Feb 18 18:36:10 hostname kernel: firewire_core 0000:05:00.0: BM lock failed (timeout), making local node (ffc0) root Feb 18 18:36:10 hostname kernel: firewire_core 0000:05:00.0: phy config: new root=ffc0, gap_count=5 Feb 18 18:36:12 hostname systemd-udevd[1532]: controlC2: Process '/usr/bin/alsactl restore 2' failed with exit code 99. Feb 18 18:36:15 hostname kernel: snd-bebob fw1.0: transaction failed: no ack Feb 18 18:36:15 hostname kernel: snd-bebob fw1.0: fail to get an input for MSU in plug 7: -5 Feb 18 18:36:15 hostname kernel: snd-bebob fw1.0: transaction failed: no ack Feb 18 18:36:15 hostname kernel: snd-bebob fw1.0: fail to get an input for MSU in plug 7: -5 This is a bad init under 5.5.4: -- Reboot -- Powered on interface when machine was running. Feb 18 18:13:37 hostname kernel: firewire_ohci 0000:05:00.0: enabling device (0080 -> 0083) Feb 18 18:13:37 hostname kernel: firewire_ohci 0000:05:00.0: added OHCI v1.10 device as card 0, 4 IR + 8 IT contexts, quirks 0x11 Feb 18 18:13:37 hostname kernel: firewire_core 0000:05:00.0: created device fw0: GUID 0011223333666677, S400 Feb 18 18:13:37 hostname kernel: audit: type=1130 audit(1582078417.360:3): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=ufw comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Feb 18 18:13:37 hostname audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=ufw comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Feb 18 18:13:37 hostname systemd-udevd[539]: controlC0: Process '/usr/bin/alsactl restore 0' failed with exit code 99. Feb 18 18:13:37 hostname systemd-udevd[530]: controlC1: Process '/usr/bin/alsactl restore 1' failed with exit code 99. Feb 18 18:13:38 hostname kernel: amdgpu: [powerplay] smu driver if version = 0x00000033, smu fw if version = 0x00000035, smu fw version = 0x002a3200 (42.50.0) Feb 18 18:19:45 hostname kernel: firewire_core 0000:05:00.0: phy config: new root=ffc1, gap_count=5 Feb 18 18:19:48 hostname kernel: firewire_core 0000:05:00.0: phy config: new root=ffc1, gap_count=5 Feb 18 18:19:48 hostname kernel: firewire_core 0000:05:00.0: created device fw1: GUID 0040ab0000c20bc1, S400 Feb 18 18:19:52 hostname systemd-udevd[1682]: controlC2: Process '/usr/bin/alsactl restore 2' failed with exit code 99. Feb 18 18:20:08 hostname kernel: snd-bebob fw1.0: transaction failed: no ack Feb 18 18:20:08 hostname kernel: snd-bebob fw1.0: fail to get an input for MSU in plug 7: -5 Feb 18 18:20:08 hostname kernel: snd-bebob fw1.0: transaction failed: no ack Feb 18 18:20:08 hostname kernel: snd-bebob fw1.0: fail to get an input for MSU in plug 7: -5 Feb 18 18:20:12 hostname kernel: firewire_core 0000:05:00.0: phy config: new root=ffc1, gap_count=5 Feb 18 18:21:24 hostname kernel: firewire_ohci 0000:05:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0001 address=0xd5080000 flags=0x0000] Followed by 125 more O_PAGE_FAULT and then the reboot, I'll be happy to provide additional information if needed. Steve

2 1

[PATCH 0/3] ASoC: snprintf() usage fixes
by Takashi Iwai 19 Feb '20

19 Feb '20

Hi, this is a series of patches I spotted during debugging other code. Intel skl and ASoC PCM core invokes succeeding calls of snprintf() with the incorrect expectation of the return value, which may lead to a buffer overflow. The first patch is yet another bug I found during working on this, and it's rather a real bug that can be seen clearly. Takashi === Takashi Iwai (3): ASoC: intel: skl: Fix pin debug prints ASoC: intel: skl: Fix possible buffer overflow in debug outputs ASoC: pcm: Fix possible buffer overflow in dpcm state sysfs output sound/soc/intel/skylake/skl-debug.c | 32 +++++++++++++++++--------------- sound/soc/soc-pcm.c | 16 ++++++++-------- 2 files changed, 25 insertions(+), 23 deletions(-) -- 2.16.4

3 7

[PATCH v2] ASoC: MT6660 update to 1.0.8_G
by Jeff Chang 19 Feb '20

19 Feb '20

From: Jeff Chang <jeff_chang(a)richtek.com> 1. add mt6660_component_settign for Component INIT Setting Signed-off-by: Jeff Chang <jeff_chang(a)richtek.com> --- sound/soc/codecs/mt6660.c | 78 +++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 75 insertions(+), 3 deletions(-) changelogs between v2 & v1 - remove parse DT and apply function about Chip INIT SETTING. - use hard coding for MT6660 Component INIT SETTING. diff --git a/sound/soc/codecs/mt6660.c b/sound/soc/codecs/mt6660.c index a36c416..88cf228 100644 --- a/sound/soc/codecs/mt6660.c +++ b/sound/soc/codecs/mt6660.c @@ -9,7 +9,6 @@ #include <linux/i2c.h> #include <linux/pm_runtime.h> #include <linux/delay.h> -#include <linux/debugfs.h> #include <sound/soc.h> #include <sound/tlv.h> #include <sound/pcm_params.h> @@ -225,14 +224,87 @@ static int _mt6660_chip_power_on(struct mt6660_chip *chip, int on_off) 0x01, on_off ? 0x00 : 0x01); } +struct reg_table { + uint32_t addr; + uint32_t mask; + uint32_t val; +}; + +static const struct reg_table mt6660_setting_table[] = { + { 0x20, 0x80, 0x00 }, + { 0x30, 0x01, 0x00 }, + { 0x50, 0x1c, 0x04 }, + { 0xB1, 0x0c, 0x00 }, + { 0xD3, 0x03, 0x03 }, + { 0xE0, 0x01, 0x00 }, + { 0x98, 0x44, 0x04 }, + { 0xB9, 0xff, 0x82 }, + { 0xB7, 0x7777, 0x7273 }, + { 0xB6, 0x07, 0x03 }, + { 0x6B, 0xe0, 0x20 }, + { 0x07, 0xff, 0x70 }, + { 0xBB, 0xff, 0x20 }, + { 0x69, 0xff, 0x40 }, + { 0xBD, 0xffff, 0x17f8 }, + { 0x70, 0xff, 0x15 }, + { 0x7C, 0xff, 0x00 }, + { 0x46, 0xff, 0x1d }, + { 0x1A, 0xffffffff, 0x7fdb7ffe }, + { 0x1B, 0xffffffff, 0x7fdb7ffe }, + { 0x51, 0xff, 0x58 }, + { 0xA2, 0xff, 0xce }, + { 0x33, 0xffff, 0x7fff }, + { 0x4C, 0xffff, 0x0116 }, + { 0x16, 0x1800, 0x0800 }, + { 0x68, 0x1f, 0x07 }, +}; + +static int mt6660_component_setting(struct snd_soc_component *component) +{ + struct mt6660_chip *chip = snd_soc_component_get_drvdata(component); + int ret = 0; + size_t i = 0; + + ret = _mt6660_chip_power_on(chip, 1); + if (ret < 0) { + dev_err(component->dev, "%s chip power on failed\n", __func__); + return ret; + } + + for (i = 0; i < ARRAY_SIZE(mt6660_setting_table); i++) { + ret = snd_soc_component_update_bits(component, + mt6660_setting_table[i].addr, + mt6660_setting_table[i].mask, + mt6660_setting_table[i].val); + if (ret < 0) { + dev_err(component->dev, "%s update 0x%02x failed\n", + __func__, mt6660_setting_table[i].addr); + return ret; + } + } + + ret = _mt6660_chip_power_on(chip, 0); + if (ret < 0) { + dev_err(component->dev, "%s chip power off failed\n", __func__); + return ret; + } + + return 0; +} + static int mt6660_component_probe(struct snd_soc_component *component) { struct mt6660_chip *chip = snd_soc_component_get_drvdata(component); + int ret; dev_dbg(component->dev, "%s\n", __func__); snd_soc_component_init_regmap(component, chip->regmap); - return 0; + ret = mt6660_component_setting(component); + if (ret < 0) + dev_err(chip->dev, "mt6660 component setting failed\n"); + + return ret; } static void mt6660_component_remove(struct snd_soc_component *component) @@ -506,4 +578,4 @@ module_i2c_driver(mt6660_i2c_driver); MODULE_AUTHOR("Jeff Chang <jeff_chang(a)richtek.com>"); MODULE_DESCRIPTION("MT6660 SPKAMP Driver"); MODULE_LICENSE("GPL"); -MODULE_VERSION("1.0.7_G"); +MODULE_VERSION("1.0.8_G"); -- 2.7.4

2 1

[PATCH] ASoC: fix card registration regression.
by Jerome Brunet 19 Feb '20

19 Feb '20

This reverts commit b2354e4009a773c00054b964d937e1b81cb92078. This change might have been desirable to ensure the uniqueness of the component name. It would have helped to better support linux devices which register multiple components, something is which more common than initially thought. However, some card driver are directly using dev_name() to fill the component names of the dai_link which is a problem if want to change the way ASoC generates the component names. Until we figure out the appropriate way to deal with this, revert the change and keep the names as they were. There might be a couple of warning related to debugfs (which were already present before the change) but it is still better than breaking working audio cards. Cc: Marek Szyprowski <m.szyprowski(a)samsung.com> Signed-off-by: Jerome Brunet <jbrunet(a)baylibre.com> --- sound/soc/soc-core.c | 29 +---------------------------- 1 file changed, 1 insertion(+), 28 deletions(-) diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 30c17fde14ca..518b652cf872 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -2442,33 +2442,6 @@ static int snd_soc_register_dais(struct snd_soc_component *component, return ret; } -static char *snd_soc_component_unique_name(struct device *dev, - struct snd_soc_component *component) -{ - struct snd_soc_component *pos; - int count = 0; - char *name, *unique; - - name = fmt_single_name(dev, &component->id); - if (!name) - return name; - - /* Count the number of components registred by the device */ - for_each_component(pos) { - if (dev == pos->dev) - count++; - } - - /* Keep naming as it is for the 1st component */ - if (!count) - return name; - - unique = devm_kasprintf(dev, GFP_KERNEL, "%s-%d", name, count); - devm_kfree(dev, name); - - return unique; -} - static int snd_soc_component_initialize(struct snd_soc_component *component, const struct snd_soc_component_driver *driver, struct device *dev) { @@ -2477,7 +2450,7 @@ static int snd_soc_component_initialize(struct snd_soc_component *component, INIT_LIST_HEAD(&component->card_list); mutex_init(&component->io_mutex); - component->name = snd_soc_component_unique_name(dev, component); + component->name = fmt_single_name(dev, &component->id); if (!component->name) { dev_err(dev, "ASoC: Failed to allocate name\n"); return -ENOMEM; -- 2.24.1

3 2

[RFC PATCH 0/2] ASoC: mediatek: mt8183-da7219: use SND_SOC_DAPM_PINCTRL
by Tzung-Bi Shih 19 Feb '20

19 Feb '20

In previous discussion[1], Mark thinks we should have something general pinctrl integration with DAPM. SND_SOC_DAPM_PINCTRL is exactly what we want but I failed to find existing usage (maybe in topology files?). To be equivalent to mt8183-da7219's original implementation, the 1st patch selects sleep-state at the beginning. The 2nd patch attaches the DAPM widget to playback stream. When the stream is about to start, the power on sequence selects the active-state. When the stream is about to stop, the power off sequence selects the sleep-state. Note: the DAI links will connect to hdmi-codec, that's why the playback stream name is "I2S Playback". Note: this is a RFC series. If it makes sense, will also apply to mt8183-mt6358. [1]: https://patchwork.kernel.org/patch/11379735/ Tzung-Bi Shih (2): ASoC: dapm: select sleep_state when initializing PINCTRL widget ASoC: mediatek: mt8183-da7219: use SND_SOC_DAPM_PINCTRL in TDM out .../mediatek/mt8183/mt8183-da7219-max98357.c | 98 ++----------------- sound/soc/soc-dapm.c | 3 + 2 files changed, 13 insertions(+), 88 deletions(-) -- 2.25.0.265.gbab2e86ba0-goog

2 4