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

[alsa-devel] [PATCH 000/102 - chunk#2] Add const to SOC_ENUM_*_DECL() macros
by Takashi Iwai 20 Feb '14

20 Feb '14

The first patch adds the const modifier to SOC_ENUM_SINGLE_DECL() & co, and the rest are to remove superfluous const modifiers. Takashi

5 31

[alsa-devel] [GIT PULL] ASoC fixes for v3.14
by Mark Brown 20 Feb '14

20 Feb '14

The following changes since commit 6d0abeca3242a88cab8232e4acd7e2bf088f3bc2: Linux 3.14-rc3 (2014-02-16 13:30:25 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git tags/asoc-v3.14-rc3 for you to fetch changes up to 895be5b31e5175bef575008aadb4f0a27b850daa: Merge remote-tracking branch 'asoc/fix/wm8993' into asoc-linus (2014-02-19 13:13:58 +0900) ---------------------------------------------------------------- ASoC: Fixes for v3.14 A few fixes, all driver speccific ones. The DaVinci ones aren't as clear as they should be from the subject lines on the commits but they fix issues which will prevent correct operation in some use cases and only affect that particular driver so are reasonably safe. ---------------------------------------------------------------- Adam Thomson (1): ASoC: da9055: Fix device registration of PMIC and CODEC devices Alexander Shiyan (1): ASoC: txx9aclc_ac97: Fix kernel crash on probe Dylan Reid (1): ASoC: max98090: sync regcache on entering STANDBY Jarkko Nikula (1): ASoC: rt5640: Add ACPI ID for Intel Baytrail Lars-Peter Clausen (1): ASoC: blackfin: Fix machine driver Kconfig dependencies Mark Brown (2): Merge remote-tracking branches 'asoc/fix/blackfin', 'asoc/fix/da9055', 'asoc/fix/davinci', 'asoc/fix/fsl', 'asoc/fix/fsl-esai', 'asoc/fix/max98090', 'asoc/fix/rt5640', 'asoc/fix/samsung' and 'asoc/fix/txx9aclc-ac97' into asoc-linus Merge remote-tracking branch 'asoc/fix/wm8993' into asoc-linus Peter Ujfalusi (4): ASoC: davinci-mcasp: Harmonize the sub hw_params function names ASoC: davinci-mcasp: Configure xxTDM, xxFMT and xxFMCT registers synchronously ASoC: davinci-mcasp: Consolidate pm_runtime_get/put() use in the driver ASoC: davinci-evm: Add pm callbacks to platform driver Sachin Kamat (2): ASoC: samsung: Remove invalid dependencies ASoC: samsung: Fix trivial typo Shawn Guo (1): ASoC: fsl: fix pm support of machine drivers Stephen Warren (1): ASoC: max98090: make REVISION_ID readable Wei Yongjun (1): ASoC: wm8993: drop regulator_bulk_free of devm_ allocated data Xiubo Li (1): ASoC: fsl-esai: fix ESAI TDM slot setting drivers/mfd/da9055-i2c.c | 12 +++++- sound/soc/blackfin/Kconfig | 11 +++--- sound/soc/codecs/da9055.c | 11 +++++- sound/soc/codecs/max98090.c | 21 +++++----- sound/soc/codecs/rt5640.c | 1 + sound/soc/codecs/wm8993.c | 1 - sound/soc/davinci/davinci-evm.c | 1 + sound/soc/davinci/davinci-mcasp.c | 83 ++++++++++++++++++--------------------- sound/soc/fsl/fsl_esai.c | 4 +- sound/soc/fsl/fsl_esai.h | 2 +- sound/soc/fsl/imx-mc13783.c | 1 - sound/soc/fsl/imx-sgtl5000.c | 10 +++-- sound/soc/fsl/imx-wm8962.c | 11 ++++-- sound/soc/samsung/Kconfig | 6 +-- sound/soc/txx9/txx9aclc-ac97.c | 8 ++-- 15 files changed, 99 insertions(+), 84 deletions(-)

2 1

[alsa-devel] Need your advice: Add a new communication inteface between HD-Audio and Gfx drivers for hotplug notification/ELD update
by Lin, Mengdong 20 Feb '14

20 Feb '14

Dear audio and gfx stakeholders, We hope to add a new interface between audio and gfx driver, for gfx driver to notify audio about HDMI/DP hot-plug and ELD update. Would you please share some comments on the proposal below? Background of this issue: On Intel Haswell/Broadwell platforms, there is a HW restriction that after the display HD-Audio controller is in D3, it cannot be waken up by HDMI/DP hot-plug. Consequently, although the gfx driver can still detect the HDMI/DP hot-plug, audio driver has no idea about this and cannot notify user space whether the external HDMI/DP monitor is available for audio playback, because the audio controller cannot wake up to D0 and receive HW unsolicited event about hot-plug from the audio codec. This limitation will affect user space to decide whether we can output audio over HDMI/DP. To solve the above limitation, Takashi suggested to add a new communication interface between audio and gfx driver: create a common object containing the ops registered by both graphics and audio drivers, then communicate through it, something like vga_switcheroo. Is it okay to create this kernel object in i915 driver? I915 can export an API like "display_register_audio_client" for audio driver to register a client and hot-plug notification ops. I915 can also call some API like "display_register_gfx_client" itself and register ops for audio driver to query monitor presence and ELD info on a specific port. It would be faster for audio driver than quering ELD by command/response over the HD-A bus, thus avoid delay in i915 mode set. This will also avoid waking up the audio devices unnecessarily if the user space does not really want to use HDMI/DP for audio playback. Whenever i195 enables/disables audio on a port in modeset, it can call some API like "display_set_audio_state()" on this kernel object and trigger notifications to the audio driver. When the audio driver is probed (in the delayed probe stage), it can request i915 API symbol to register the audio client for this communication kernel object. Since the 1st i915 mode set may happen before audio driver registers the ops, we'll let audio driver check ELD once after registering the audio client ops. And for the platforms which uses this communication interface, we can disable unsolicited event for HDMI/DP hot-plug in the audio driver. We hope to hear your feedback and start to work out more details. Thanks & Best Regards Mengdong

8 21

[alsa-devel] [PATCH 000/105] Rename soc_enum.max field
by Takashi Iwai 20 Feb '14

20 Feb '14

Hi, this is the first chunk of the whole patch serires, preliminary works for renaming the confusing field name and minor clean ups in the relevant places. After this chunk, SOC_ENUM_*_DECL() macro cleanup and the actual fixes for the wrong number of enum items will follow. Then introduce SOC_ENUM_SINGLE_CONST() & co for omitting the explicit ARRAY_SIZE() call, and apply it in the later patches. Takashi

6 11

[alsa-devel] [PATCH 000/102 - chunk#3] Actually fix wrong enum items
by Takashi Iwai 20 Feb '14

20 Feb '14

Now, this patch chunk fixes the actual bugs in various codec drivers that have either off-by-one number of items or lead to array overflow. sta32x is the latter one, and this can be picked up for 3.14, too. The other off-by-one fixes would change the driver behavior (now user will see more items), thus they are potential regression risks although the "fixes" are correct, per se. Takashi

5 28

[alsa-devel] [PATCH 1/2] ASoC: alc5623: Convert to direct regmap API usage
by Mark Brown 20 Feb '14

20 Feb '14

From: Mark Brown <broonie(a)linaro.org> Convert to directly use the regmap API, allowing us to eliminate the last user of the ASoC level I/O implementations (there are still open coded I/O implementations in drivers), avoiding duplicating code in regmap. We no longer cache the entire CODEC register map on probe since the more advanced cache infrastructure in regmap is able to fill the cache on demand. Signed-off-by: Mark Brown <broonie(a)linaro.org> --- sound/soc/codecs/alc5623.c | 87 ++++++++++++++++++++++++++-------------------- 1 file changed, 49 insertions(+), 38 deletions(-) diff --git a/sound/soc/codecs/alc5623.c b/sound/soc/codecs/alc5623.c index d303628..36cf7e8 100644 --- a/sound/soc/codecs/alc5623.c +++ b/sound/soc/codecs/alc5623.c @@ -21,6 +21,7 @@ #include <linux/delay.h> #include <linux/pm.h> #include <linux/i2c.h> +#include <linux/regmap.h> #include <linux/slab.h> #include <sound/core.h> #include <sound/pcm.h> @@ -38,26 +39,13 @@ MODULE_PARM_DESC(caps_charge, "ALC5623 cap charge time (msecs)"); /* codec private data */ struct alc5623_priv { - enum snd_soc_control_type control_type; + struct regmap *regmap; u8 id; unsigned int sysclk; - u16 reg_cache[ALC5623_VENDOR_ID2+2]; unsigned int add_ctrl; unsigned int jack_det_ctrl; }; -static void alc5623_fill_cache(struct snd_soc_codec *codec) -{ - int i, step = codec->driver->reg_cache_step; - u16 *cache = codec->reg_cache; - - /* not really efficient ... */ - codec->cache_bypass = 1; - for (i = 0 ; i < codec->driver->reg_cache_size ; i += step) - cache[i] = snd_soc_read(codec, i); - codec->cache_bypass = 0; -} - static inline int alc5623_reset(struct snd_soc_codec *codec) { return snd_soc_write(codec, ALC5623_RESET, 0); @@ -869,18 +857,28 @@ static struct snd_soc_dai_driver alc5623_dai = { static int alc5623_suspend(struct snd_soc_codec *codec) { + struct alc5623_priv *alc5623 = snd_soc_codec_get_drvdata(codec); + alc5623_set_bias_level(codec, SND_SOC_BIAS_OFF); + regcache_cache_only(alc5623->regmap, true); + return 0; } static int alc5623_resume(struct snd_soc_codec *codec) { - int i, step = codec->driver->reg_cache_step; - u16 *cache = codec->reg_cache; + struct alc5623_priv *alc5623 = snd_soc_codec_get_drvdata(codec); + int ret; /* Sync reg_cache with the hardware */ - for (i = 2 ; i < codec->driver->reg_cache_size ; i += step) - snd_soc_write(codec, i, cache[i]); + regcache_cache_only(alc5623->regmap, false); + ret = regcache_sync(alc5623->regmap); + if (ret != 0) { + dev_err(codec->dev, "Failed to sync register cache: %d\n", + ret); + regcache_cache_only(alc5623->regmap, true); + return ret; + } alc5623_set_bias_level(codec, SND_SOC_BIAS_STANDBY); @@ -900,14 +898,14 @@ static int alc5623_probe(struct snd_soc_codec *codec) struct snd_soc_dapm_context *dapm = &codec->dapm; int ret; - ret = snd_soc_codec_set_cache_io(codec, 8, 16, alc5623->control_type); + codec->control_data = alc5623->regmap; + ret = snd_soc_codec_set_cache_io(codec, 8, 16, SND_SOC_REGMAP); if (ret < 0) { dev_err(codec->dev, "Failed to set cache I/O: %d\n", ret); return ret; } alc5623_reset(codec); - alc5623_fill_cache(codec); /* power on device */ alc5623_set_bias_level(codec, SND_SOC_BIAS_STANDBY); @@ -980,9 +978,15 @@ static struct snd_soc_codec_driver soc_codec_device_alc5623 = { .suspend = alc5623_suspend, .resume = alc5623_resume, .set_bias_level = alc5623_set_bias_level, - .reg_cache_size = ALC5623_VENDOR_ID2+2, - .reg_word_size = sizeof(u16), - .reg_cache_step = 2, +}; + +static const struct regmap_config alc5623_regmap = { + .reg_bits = 8, + .val_bits = 16, + .reg_stride = 2, + + .max_register = ALC5623_VENDOR_ID2, + .cache_type = REGCACHE_RBTREE, }; /* @@ -996,19 +1000,32 @@ static int alc5623_i2c_probe(struct i2c_client *client, { struct alc5623_platform_data *pdata; struct alc5623_priv *alc5623; - int ret, vid1, vid2; + unsigned int vid1, vid2; + int ret; - vid1 = i2c_smbus_read_word_data(client, ALC5623_VENDOR_ID1); - if (vid1 < 0) { - dev_err(&client->dev, "failed to read I2C\n"); - return -EIO; + alc5623 = devm_kzalloc(&client->dev, sizeof(struct alc5623_priv), + GFP_KERNEL); + if (alc5623 == NULL) + return -ENOMEM; + + alc5623->regmap = devm_regmap_init_i2c(client, &alc5623_regmap); + if (IS_ERR(alc5623->regmap)) { + ret = PTR_ERR(alc5623->regmap); + dev_err(&client->dev, "Failed to initialise I/O: %d\n", ret); + return ret; + } + + ret = regmap_read(alc5623->regmap, ALC5623_VENDOR_ID1, &vid1); + if (ret < 0) { + dev_err(&client->dev, "failed to read vendor ID1: %d\n", ret); + return ret; } vid1 = ((vid1 & 0xff) << 8) | (vid1 >> 8); - vid2 = i2c_smbus_read_byte_data(client, ALC5623_VENDOR_ID2); - if (vid2 < 0) { - dev_err(&client->dev, "failed to read I2C\n"); - return -EIO; + ret = regmap_read(alc5623->regmap, ALC5623_VENDOR_ID2, &vid2); + if (ret < 0) { + dev_err(&client->dev, "failed to read vendor ID2: %d\n", ret); + return ret; } if ((vid1 != 0x10ec) || (vid2 != id->driver_data)) { @@ -1021,11 +1038,6 @@ static int alc5623_i2c_probe(struct i2c_client *client, dev_dbg(&client->dev, "Found codec id : alc56%02x\n", vid2); - alc5623 = devm_kzalloc(&client->dev, sizeof(struct alc5623_priv), - GFP_KERNEL); - if (alc5623 == NULL) - return -ENOMEM; - pdata = client->dev.platform_data; if (pdata) { alc5623->add_ctrl = pdata->add_ctrl; @@ -1048,7 +1060,6 @@ static int alc5623_i2c_probe(struct i2c_client *client, } i2c_set_clientdata(client, alc5623); - alc5623->control_type = SND_SOC_I2C; ret = snd_soc_register_codec(&client->dev, &soc_codec_device_alc5623, &alc5623_dai, 1); -- 1.9.0.rc3

1 1

[alsa-devel] About 'SNDRV_PCM_CLASS_MULTI' for devices with multi-channels
by Takashi Sakamoto 19 Feb '14

19 Feb '14

Hi all, I have two questions about the usage of this macro. Should I use this macro for new drivers which I'm working for?' http://mailman.alsa-project.org/pipermail/alsa-devel/2014-January/071820.ht… My drivers support some firewire devices, which is desinged for studio-use and have many channels. Its combination of channels are not designed for surround sound like 5.1ch. Just judging from its name, 'SNDRV_PCM_CLASS_MULTI', I should use this. But there are no drivers which use this macro in current tree, against my expectation that some drivers (ICE1712-pro, RME9652, 6fire usb and so on) should use this macro. Are there any reasons? Regards Takashi Sakamoto o-takashi(a)sakamocchi.jp

1 0

[alsa-devel] About 'SNDRV_PCM_CLASS_MULTI' for devices with multi-channels
by Takashi Sakamoto 19 Feb '14

19 Feb '14

Hi all, I have two questions about the usage of this macro. Should I use this macro for new drivers which I'm working for?' http://mailman.alsa-project.org/pipermail/alsa-devel/2014-January/071820.ht… My drivers support some firewire devices, which is desinged for studio-use and have many channels. Its combination of channels are not designed for surround sound like 5.1ch. Just judging from its name, 'SNDRV_PCM_CLASS_MULTI', I should use this. But there are no drivers which use this macro in current tree, against my expectation that some drivers (ICE1712-pro, RME9652, 6fire usb and so on) should use this macro. Are there any reasons? Regards Takashi Sakamoto o-takashi(a)sakamocchi.jp

1 0

[alsa-devel] [PATCHv2] ASoC: Intel: Fix build for sst-dsp.c on PPC architecture
by Liam Girdwood 19 Feb '14

19 Feb '14

Disable build on non X86 architectures except for compile testing. This fixes the following build errors on PPC and adds an option for testing the build on other architectures as suggested by Mark Brown :- sound/soc/intel/sst-dsp.c: In function 'sst_dsp_outbox_write': sound/soc/intel/sst-dsp.c:218:2: error: implicit declaration of function 'memcpy_toio' [-Werror=implicit-function-declaration] memcpy_toio(sst->mailbox.out_base, message, bytes); ^ sound/soc/intel/sst-dsp.c: In function 'sst_dsp_outbox_read': sound/soc/intel/sst-dsp.c:231:2: error: implicit declaration of function 'memcpy_fromio' [-Werror=implicit-function-declaration] memcpy_fromio(message, sst->mailbox.out_base, bytes); ^ Signed-off-by: Liam Girdwood <liam.r.girdwood(a)linux.intel.com> --- sound/soc/intel/Kconfig | 1 + sound/soc/intel/sst-dsp.c | 1 + 2 files changed, 2 insertions(+) diff --git a/sound/soc/intel/Kconfig b/sound/soc/intel/Kconfig index c962432..4bb802b 100644 --- a/sound/soc/intel/Kconfig +++ b/sound/soc/intel/Kconfig @@ -15,6 +15,7 @@ config SND_SST_MFLD_PLATFORM config SND_SOC_INTEL_SST tristate "ASoC support for Intel(R) Smart Sound Technology" select SND_SOC_INTEL_SST_ACPI if ACPI + depends on (X86 || COMPILE_TEST) help This adds support for Intel(R) Smart Sound Technology (SST). Say Y if you have such a device diff --git a/sound/soc/intel/sst-dsp.c b/sound/soc/intel/sst-dsp.c index e0ad2e5..6e22c12 100644 --- a/sound/soc/intel/sst-dsp.c +++ b/sound/soc/intel/sst-dsp.c @@ -19,6 +19,7 @@ #include <linux/interrupt.h> #include <linux/module.h> #include <linux/platform_device.h> +#include <linux/io.h> #include "sst-dsp.h" #include "sst-dsp-priv.h" -- 1.8.3.2

2 1

[alsa-devel] About 'SNDRV_PCM_CLASS_MULTI' for devices with multi-channels
by Takashi Sakamoto 19 Feb '14

19 Feb '14

Hi all, I have two questions about the usage of this macro. Should I use this macro for new drivers which I'm working for?' http://mailman.alsa-project.org/pipermail/alsa-devel/2014-January/071820.ht… My drivers support some firewire devices, which is desinged for studio-use and have many channels. Its combination of channels are not designed for surround sound like 5.1ch. Just judging from its name, 'SNDRV_PCM_CLASS_MULTI', I should use this. But there are no drivers which use this macro in current tree, against my expectation that some drivers (ICE1712-pro, RME9652, 6fire usb and so on) should use this macro. Are there any reasons? Regards Takashi Sakamoto o-takashi(a)sakamocchi.jp

1 0