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

[alsa-devel] [PATCH] ASoC: Intel: Fixed kbuild warnings
by yang.a.fang＠intel.com 05 May '15

05 May '15

From: "Fang, Yang A" <yang.a.fang(a)intel.com> fix following sparse warnings: (new ones prefixed by >>) >> sound/soc/intel/boards/cht_bsw_max98090_ti.c:168:37: sparse: >> incorrect type in argument 2 (different base types) sound/soc/intel/boards/cht_bsw_max98090_ti.c:168:37: expected unsigned int [unsigned] val sound/soc/intel/boards/cht_bsw_max98090_ti.c:168:37: got restricted snd_pcm_format_t [usertype] <noident> Signed-off-by: Fang, Yang A <yang.a.fang(a)intel.com> --- sound/soc/intel/boards/cht_bsw_max98090_ti.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/sound/soc/intel/boards/cht_bsw_max98090_ti.c b/sound/soc/intel/boards/cht_bsw_max98090_ti.c index 3c518b1..1be0794 100644 --- a/sound/soc/intel/boards/cht_bsw_max98090_ti.c +++ b/sound/soc/intel/boards/cht_bsw_max98090_ti.c @@ -163,9 +163,7 @@ static int cht_codec_fixup(struct snd_soc_pcm_runtime *rtd, channels->min = channels->max = 2; /* set SSP2 to 24-bit */ - snd_mask_set(&params->masks[SNDRV_PCM_HW_PARAM_FORMAT - - SNDRV_PCM_HW_PARAM_FIRST_MASK], - SNDRV_PCM_FORMAT_S24_LE); + params_set_format(params, SNDRV_PCM_FORMAT_S24_LE); return 0; } -- 1.7.9.5

2 1

[alsa-devel] [PATCH 1/6] ASoC: rt5645: remove RT5645_I2S_BCLK_MS1 control
by Bard Liao 05 May '15

05 May '15

RT5645_I2S_BCLK_MS1 (reg 0x73 [5]) is reserverd in rt5645 and rt5650. This function is move to TDM control. We can configure it by snd_soc_dai_set_tdm_slot's slot_width parameter. Signed-off-by: Bard Liao <bardliao(a)realtek.com> --- sound/soc/codecs/rt5645.c | 5 ++--- sound/soc/codecs/rt5645.h | 4 ---- 2 files changed, 2 insertions(+), 7 deletions(-) diff --git a/sound/soc/codecs/rt5645.c b/sound/soc/codecs/rt5645.c index 8bad9fe..33ebe88 100644 --- a/sound/soc/codecs/rt5645.c +++ b/sound/soc/codecs/rt5645.c @@ -2104,9 +2104,8 @@ static int rt5645_hw_params(struct snd_pcm_substream *substream, switch (dai->id) { case RT5645_AIF1: - mask_clk = RT5645_I2S_BCLK_MS1_MASK | RT5645_I2S_PD1_MASK; - val_clk = bclk_ms << RT5645_I2S_BCLK_MS1_SFT | - pre_div << RT5645_I2S_PD1_SFT; + mask_clk = RT5645_I2S_PD1_MASK; + val_clk = pre_div << RT5645_I2S_PD1_SFT; snd_soc_update_bits(codec, RT5645_I2S1_SDP, (0x3 << dl_sft), (val_len << dl_sft)); snd_soc_update_bits(codec, RT5645_ADDA_CLK1, mask_clk, val_clk); diff --git a/sound/soc/codecs/rt5645.h b/sound/soc/codecs/rt5645.h index 4473636..fa5c560 100644 --- a/sound/soc/codecs/rt5645.h +++ b/sound/soc/codecs/rt5645.h @@ -942,10 +942,6 @@ #define RT5645_I2S2_SDI_I2S2 (0x1 << 6) /* ADC/DAC Clock Control 1 (0x73) */ -#define RT5645_I2S_BCLK_MS1_MASK (0x1 << 15) -#define RT5645_I2S_BCLK_MS1_SFT 15 -#define RT5645_I2S_BCLK_MS1_32 (0x0 << 15) -#define RT5645_I2S_BCLK_MS1_64 (0x1 << 15) #define RT5645_I2S_PD1_MASK (0x7 << 12) #define RT5645_I2S_PD1_SFT 12 #define RT5645_I2S_PD1_1 (0x0 << 12) -- 1.8.1.1.439.g50a6b54

2 11

[alsa-devel] need information about dapm events, bias and mute management
by gpe 05 May '15

05 May '15

Hi, I'm working on an asoc codec but I'm facing some problems with the DAPM events the bias and the mute management. The kernel is a 3.4.91. Globally my codec is functionnal but I've some glitch. By using DAPM events (PRE_PMU, POST_PMU) and bias management I've suppressed the glitchs at the start but I've always some glitchs at the end of a playback. I'm trying to suppress them with PRE_PMD but it not works. When I test my code I see that some power off are done before the call of the SND_SOC_DAPM_PRE_PMD event. Is it normal ? Another question is regarding the mute management (snd_soc_dai_digital_mute) which is done after all the power off ... I expected it to be done just at the end of the playback. Last question about the bias management (set_bias_level in snd_soc_codec_driver). During the start I see the bias level incrementing but during the stop there is no action on the bias level. Why ? Regards. PS: I'm a newbie on codec development so don't hit to hard on my head if my questions are stupid. I've read many docs but I don't found a doc which describes the interactions between the APIs. PS2: sorry for my bad english. -- +-------+ | gpe92 | +-------+

1 0

[alsa-devel] Software based mmap support and dmix
by Yogesh Soni 05 May '15

05 May '15

Hi all, I am trying to have dmix plugin work ( I succeeded) with the audio card that does not have hardware mmap support and uses pcm_indirect method to map software buffer for mmap feature. Most of the plugins were working quite well with mmap/pcm_indirect combo. However, dmix plugin did not work (no sound). I debugged and realized that appl_ptr in pcm_direct.h(snd_pcm_indirect_playback_transfer()) was always 0 and hence nothing got copied to slave pcm buffer. I then discovered that dmix operates in freewheeling-mode.. I have made a small workaround patch (I believe it can be cleaned up) in case of free-wheeling mode, basically using sw_ready to hold bytes that need to be copied. I used rec->sw_ready because it looked safest to use for this purpose. As a result of this patch, normally period_size bytes are copied to pcm buffer every period and sound is playing smooth. I am a noob in alsa and linux in general. So, I would like your opinion on the patch. I would much prefer if I could write a patch that is generic and clean enough, so that it could be used by others. New pcm-indirect.h attached. Thanks a lot for your help. Regards Yogesh

1 0

[alsa-devel] [PATCH 1/7] ASoC: ad1836: Replace direct snd_soc_codec dapm field access
by Lars-Peter Clausen 04 May '15

04 May '15

The dapm field of the snd_soc_codec struct is eventually going to be removed, in preparation for this replace all manual access to codec->dapm with snd_soc_codec_get_dapm(). Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> --- sound/soc/codecs/ad1836.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/ad1836.c b/sound/soc/codecs/ad1836.c index 685998d..95f0bec 100644 --- a/sound/soc/codecs/ad1836.c +++ b/sound/soc/codecs/ad1836.c @@ -251,7 +251,7 @@ static int ad1836_resume(struct snd_soc_codec *codec) static int ad1836_probe(struct snd_soc_codec *codec) { struct ad1836_priv *ad1836 = snd_soc_codec_get_drvdata(codec); - struct snd_soc_dapm_context *dapm = &codec->dapm; + struct snd_soc_dapm_context *dapm = snd_soc_codec_get_dapm(codec); int num_dacs, num_adcs; int ret = 0; int i; -- 1.8.0

2 7

[alsa-devel] [PATCH V3 0/4] tas571x amplifier driver
by Kevin Cernekee 04 May '15

04 May '15

V2->V3: Revert earlier changes to the regcache APIs. Change regcache_sync() so that regcache_mark_dirty() is used to indicate that the HW was reset. This allows tas571x (which does NOT call regcache_mark_dirty()) to use regcache_sync() to write back any register changes that occurred while in cache_only (tas571x pdn) mode. One assumption here is that regcache_sync() will be called once on resume, before any other writes. If it fails, the no_sync_defaults flag will be cleared and the next sync attempt, if any, will try to write out all contents of the cache. Kevin Cernekee (4): regmap: Use regcache_mark_dirty() to indicate power loss or reset ASoC: tas571x: Add DT binding document ASoC: tas571x: New driver for TI TAS571x power amplifiers MAINTAINERS: Add entry for tas571x ASoC codec driver .../devicetree/bindings/sound/tas571x.txt | 41 ++ MAINTAINERS | 6 + drivers/base/regmap/internal.h | 3 + drivers/base/regmap/regcache.c | 61 ++- sound/soc/codecs/Kconfig | 5 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/tas571x.c | 520 +++++++++++++++++++++ sound/soc/codecs/tas571x.h | 33 ++ 8 files changed, 651 insertions(+), 20 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/tas571x.txt create mode 100644 sound/soc/codecs/tas571x.c create mode 100644 sound/soc/codecs/tas571x.h -- 2.2.0.rc0.207.ga3a616c

3 10

[alsa-devel] [PATCH 1/4] ASoC: Intel: Add support max98090 in sst driver
by yang.a.fang＠intel.com 04 May '15

04 May '15

From: "Fang, Yang A" <yang.a.fang(a)intel.com> Added entry in sst driver to support max98090 codec for intel Braswell platform. Signed-off-by: Fang, Yang A <yang.a.fang(a)intel.com> --- sound/soc/intel/atom/sst/sst_acpi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/soc/intel/atom/sst/sst_acpi.c b/sound/soc/intel/atom/sst/sst_acpi.c index fc02a48..bb19b58 100644 --- a/sound/soc/intel/atom/sst/sst_acpi.c +++ b/sound/soc/intel/atom/sst/sst_acpi.c @@ -356,6 +356,8 @@ static struct sst_machines sst_acpi_chv[] = { &chv_platform_data }, {"10EC5650", "cht-bsw", "cht-bsw-rt5645", NULL, "intel/fw_sst_22a8.bin", &chv_platform_data }, + {"193C9890", "cht-bsw", "cht-bsw-max98090", NULL, + "intel/fw_sst_22a8.bin", &chv_platform_data }, {}, }; -- 1.7.9.5

7 23

[alsa-devel] [PATCH] ASoC: uda1380: Avoid accessing i2c bus when codec is disabled
by Vasily Khoruzhick 04 May '15

04 May '15

set_dai_fmt_both() callback is called from snd_soc_runtime_set_dai_fmt() which is called from snd_soc_register_card(), but at this time codec is not powered on yet. Replace direct i2c write with regcache write. Signed-off-by: Vasily Khoruzhick <anarsoul(a)gmail.com> --- sound/soc/codecs/uda1380.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/uda1380.c b/sound/soc/codecs/uda1380.c index dc7778b..c3c33bd 100644 --- a/sound/soc/codecs/uda1380.c +++ b/sound/soc/codecs/uda1380.c @@ -437,7 +437,7 @@ static int uda1380_set_dai_fmt_both(struct snd_soc_dai *codec_dai, if ((fmt & SND_SOC_DAIFMT_MASTER_MASK) != SND_SOC_DAIFMT_CBS_CFS) return -EINVAL; - uda1380_write(codec, UDA1380_IFACE, iface); + uda1380_write_reg_cache(codec, UDA1380_IFACE, iface); return 0; } -- 2.3.5

2 1

Re: [alsa-devel] [PATCH] ASoC: simple-card: support platform in dts parse
by Mark Brown 04 May '15

04 May '15

On Wed, Apr 29, 2015 at 06:11:07PM +0800, Jun Nie wrote: > Support platform in dts parse so that dma pcm component > can be added in dts. Applied, thanks.

1 0

Re: [alsa-devel] [PATCH 2/2] ASoC: zx: Add zx296702 SPDIF support
by Mark Brown 04 May '15

04 May '15

On Mon, May 04, 2015 at 09:13:48PM +0800, Jun Nie wrote: > 2015-05-01 18:55 GMT+08:00 Mark Brown <broonie(a)kernel.org>: > > This is adding a new device with DT bindings but there is no bindings > > document. All new DT bindings must be documented. > Plan to add a separate patch to device tree. Or you prefer to add > device tree patch in this patch set and loop device tree maintainer? You *always* need to document new device tree bindings at the same time as adding new code. > There are more than one SPDIF controller on ZTE SOC. One of them > support HDMI output, while the other SPDIF controller support direct > output. So I want to separate SPDIF and HDMI and add SPDIF id 0 test So this special HDMI S/PDIF controller is directly integrated with the HDMI IP in the SoC and not usable as a generic S/PDIF controller? That seems to mirror system designs which have an external HDMI encoder which use S/PDIF or I2S to connect the audio portion to an external device. > Do you have any suggestion on what driver to look at for the interface > between audio and video? Half the problem right now is that the people working on HDMI don't appear to be talking to each other very much so everything is very inconsistent with no real code sharing. I don't really feel I've got a good enough picture of what the hardware looks like in general to be 100% clear on what the best way is forward beyond the fact that we should be sharing the EDID parsing code. I'd suggest for future versions reorganizing things so that you add the S/PDIF driver with only S/PDIF support and then have a separate patch that layers on the HDMI support.

1 0