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

[alsa-devel] [REANNOUNCE] Audio Mini Summit 2015, 8th October, Dublin
by Mark Brown 05 Oct '15

05 Oct '15

Like previous years, we're going to hold a meeting to discuss lowlevel audio on Linux. This will be held the day after ELC Europe on 8th October at CCD (The Convention Centre) in Dublin. If you're interested please sign up in the attendee list: https://docs.google.com/spreadsheets/d/1bi-8GHsqlzt41FR20WiMuWILe_cZowFireV… and please follow up to this mail with any topics you'd like to see raised so we can start collecting them (probably another Google doc will be forthcoming for them). Previously suggested topics include: - Reducing kernel size for IoT applications - ACPI simple-card - Testing tools Thanks, Mark

9 25

[alsa-devel] [PATCH 0/8] Add support for Wolfson WM8998 and WM1814 codecs
by Richard Fitzgerald 02 Oct '15

02 Oct '15

This set of patches adds support for the Wolfson Microelectronics WM8998 and WM1814 codecs. Richard Fitzgerald (8): mfd: arizona: Split INx_MODE into two fields ASoC: arizona: add defines for single-input gain control mfd: arizona: Add support for WM8998 and WM1814 gpio: arizona: add support for WM8998 and WM1814 regulator: arizona: add support for WM8998 and WM1814 extcon: arizona: Add support for WM8998 and WM1814 ASoC: wm8998: Initial WM8998 codec driver Documentation: Add WM8998/WM1814 device tree bindings Documentation/devicetree/bindings/mfd/arizona.txt | 3 + drivers/extcon/extcon-arizona.c | 33 +- drivers/gpio/gpio-arizona.c | 2 + drivers/mfd/Kconfig | 6 + drivers/mfd/Makefile | 3 + drivers/mfd/arizona-core.c | 106 ++- drivers/mfd/arizona-i2c.c | 8 + drivers/mfd/arizona-irq.c | 9 + drivers/mfd/arizona.h | 5 + drivers/mfd/wm8998-tables.c | 1592 +++++++++++++++++++++ drivers/regulator/arizona-ldo1.c | 2 + include/linux/mfd/arizona/core.h | 3 + include/linux/mfd/arizona/pdata.h | 5 +- include/linux/mfd/arizona/registers.h | 247 +++- sound/soc/codecs/Kconfig | 6 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/arizona.c | 7 + sound/soc/codecs/arizona.h | 7 +- sound/soc/codecs/wm8998.c | 1392 ++++++++++++++++++ sound/soc/codecs/wm8998.h | 23 + 20 files changed, 3432 insertions(+), 29 deletions(-) create mode 100644 drivers/mfd/wm8998-tables.c create mode 100644 sound/soc/codecs/wm8998.c create mode 100644 sound/soc/codecs/wm8998.h -- 1.7.2.5

6 22

[alsa-devel] [PATCH 0/2] CONFIG_OF vs DMA_OF
by Kuninori Morimoto 02 Oct '15

02 Oct '15

Hi Vinod, Mark Current OF base DMAEngine API will be compiled if .config has CONFIG_DMA_OF. but of-dma.h based on CONFIG_OF instead of CONFIG_DMA_OF. These patches tidyup this issue. Please check 1) patch carefully, since DMAEngine API has many dependency to other drivers. > Mark I think 2) patch is based on 1). Please check it Kuninori Morimoto (2): 1) dmaengine: OF DMAEngine API based on CONFIG_DMA_OF instead of CONFIG_OF 2) ASoC: rsnd: SND_SOC_RCAR doesn't depend on DMA_OF include/linux/of_dma.h | 2 +- sound/soc/sh/Kconfig | 1 - 2 files changed, 1 insertion(+), 2 deletions(-) Best regards --- Kuninori Morimoto

2 9

[alsa-devel] [PATCH] ASoC: Document DAI signal polarity
by Anatol Pomozov 01 Oct '15

01 Oct '15

Per discussion at [1] currently there is no clear definition of what is FSYNC polarity. Different drivers use its own definition of what is "normal" and what is "inverted" fsync in different modes. This leads to compatibility problems between drivers. Explicitly specify meaning of BCLK/FSYNC polarity. [1] http://mailman.alsa-project.org/pipermail/alsa-devel/2015-August/097121.html Signed-off-by: Anatol Pomozov <anatol.pomozov(a)gmail.com> --- include/sound/soc-dai.h | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/include/sound/soc-dai.h b/include/sound/soc-dai.h index 2df96b1..c8170c4 100644 --- a/include/sound/soc-dai.h +++ b/include/sound/soc-dai.h @@ -48,10 +48,15 @@ struct snd_compr_stream; #define SND_SOC_DAIFMT_GATED (0 << 4) /* clock is gated */ /* - * DAI hardware signal inversions. + * DAI hardware signal polarity. * - * Specifies whether the DAI can also support inverted clocks for the specified - * format. + * For BCLK: + * - "normal" polarity means signal sensing happens at rising edge of BCLK + * - "inverted" polarity means signal sensing happens at falling edge of BCLK + * + * For FSYNC: + * - "normal" polarity means frame starts at rising edge of FSYNC + * - "inverted" polarity means frame starts at falling edge of FSYNC */ #define SND_SOC_DAIFMT_NB_NF (0 << 8) /* normal bit clock + frame */ #define SND_SOC_DAIFMT_NB_IF (2 << 8) /* normal BCLK + inv FRM */ -- 2.5.0.457.gab17608

6 10

[alsa-devel] SoC/Codecs/SGTL5000 - Non working MIC_BIAS Voltage settings
by gianluca 30 Sep '15

30 Sep '15

Hello, in attachment there is a small patch to ensure the correct register value for MIC BIAS Voltage. Best regards -- Eurek s.r.l. | Electronic Engineering | http://www.eurek.it via Celletta 8/B, 40026 Imola, Italy | Phone: +39-(0)542-609120 p.iva 00690621206 - c.f. 04020030377 | Fax: +39-(0)542-609212

4 5

[alsa-devel] No stream timing info with alsa pulse plugin?
by sqweek 24 Sep '15

24 Sep '15

Hi guys, I discovered on my machine that alsa_snd_pcm_status_get_tstamp (and also get_htstamp) stop working when my asoundrc invokes the pulse plugin. That is, normally they work fine but once the sound is going via pulse the returned time stamp is always zero. I'm trying to understand why that is. I couldn't really find any discussion of the pulse plugin on the archives so I'm not entirely sure I've found the right list; I was directed here via the pulseaudio bugzilla[1]. [1] https://bugs.freedesktop.org/show_bug.cgi?id=88503 Thanks for any assistance! -sqweek

4 3

[alsa-devel] [PATCH v2 0/9] Add DSP topology management for SKL
by Vinod Koul 21 Sep '15

21 Sep '15

The SKL driver does not code DSP topology in driver. With this series the ASoC topology framework is used to parse the topology information to create widgets, controls and route map for the FW topology. It adds routines for SKL DSP module configuration, compute resources for modules, initialize and bind the pipe modules. It uses the SKL IPC library added earlier to send IPC for initialize the module, bind/unbind modules. Last patch in this series removes the unused dais. changes in v2: - add more explanation in changelog and code - add explanation of MCPS - fix whitespace issues - remove skl widget check on event handler as it is redundant - add switch for depth - add else for direction based code - remove cast for NHLT blob query - make debug prints to error - remove dump info - clean some debug prints Jeeja KP (9): ASoC: Intel: Skylake: Add pipe and modules handlers ASoC: Intel: Skylake: Add module configuration helpers ASoC: Intel: Skylake: add DSP platform widget event handlers ASoC: Intel: Skylake: Add FE and BE hw_params handling ASoC: Intel: Skylake: Add topology core init and handlers ASoC: Intel: Skylake: Initialize and load DSP controls ASoC: Intel: Skylake: Add DSP support and enable it ASoC: Intel: Skylake: Initialize NHLT table ASoC: Intel: Skylake: Remove unused CPU dai's sound/soc/intel/skylake/Makefile | 3 +- sound/soc/intel/skylake/skl-pcm.c | 171 ++-- sound/soc/intel/skylake/skl-topology.c | 1262 ++++++++++++++++++++++++++ sound/soc/intel/skylake/skl-topology.h | 21 + sound/soc/intel/skylake/skl-tplg-interface.h | 78 ++ sound/soc/intel/skylake/skl.c | 29 +- sound/soc/intel/skylake/skl.h | 11 + 7 files changed, 1507 insertions(+), 68 deletions(-) create mode 100644 sound/soc/intel/skylake/skl-topology.c -- 1.9.1

3 34

[alsa-devel] Intel SST on a Bay Trail tablet
by Michele Curti 21 Sep '15

21 Sep '15

> On Thu, 25 Jun 2015 22:17:17 +0530 Vinod Koul wrote: > > > On Thu, Jun 25, 2015 at 12:21:24PM +0200, Antonio Ospite wrote: > > > On Thu, 25 Jun 2015 11:20:46 +0530 > > > Vinod Koul <vinod.koul at intel.com> wrote: > > > > > > > On Wed, Jun 24, 2015 at 03:46:13PM +0530, Vinod Koul wrote: > > > > > On Tue, Apr 14, 2015 at 05:06:27PM +0300, Jarkko Nikula wrote: > > > [...] > > > > > > > > > > > > Which makes me thinking how does those strings describe the SSP port > > > > > > setup? E.g. do they reflect what port is actually used or could it > > > > > > be possible that those are just driver strings but firmware could > > > > > > have been tuned for SSP0? If I looked at earlier right, Teclast has > > > > > > the low pin-count Baytrail without SSP2 but I'm not sure about that. > > > > > The FW doesnt provide way to changes ports from driver in this, so this > > > > > doesnt mean much. If we are sure it is not ssp2, I can provide ssp1 fw for > > > > > test > > > > I ahve pushed latest BYT version we have as well as added binary for second > > > > SSP port. Please give it a try: > > > > > > > > https://git.kernel.org/cgit/linux/kernel/git/vkoul/firmware.git/commit/?h=b… > > > > > > > > > > Thanks Vinod, but I see these are in the ELF format, and the mainline > > > driver does not support this format, at least the last time I checked it > > > didn't. > > My bad, updated the patch now with right format > > > > https://git.kernel.org/cgit/linux/kernel/git/vkoul/firmware.git/commit/?h=b… > > > > (Adding Michele to CC) > > OK, so Jarkko was right: after a quick test I confirm that with > fw_sst_0f28_ssp0.bin I get sound; this is quite an improvement, > thanks! Damn, completely missed.. Hi Vinod, if it's possible, could you please generate a fw_sst_0f28_ssp1.bin also, so I can test my driver (mine was for the Asus X205TA laptop, where the codec is on SSP1 port)? Thanks, Michele

4 9

[alsa-devel] [PATCH v2] ASoC: Handle multiple codecs with split playback / capture
by Ricard Wanderlof 20 Sep '15

20 Sep '15

Add the capability to use multiple codecs on the same DAI linke where one codec is used for playback and another one is used for capture. Tested on a setup using an SSM2518 for playback and an ICS43432 I2S MEMS microphone for capture. Signed-off-by: Ricard Wanderlof <ricardw(a)axis.com> --- The patch was created after a discussion on the alsa-devel mailing list as to how best to implement this functionality. (http://mailman.alsa-project.org/pipermail/alsa-devel/2015-June/093214.html). V2: Minor code change, otherwise the differences compared to V1 are solely related to comments, in particular considerations given to the potential consequences of the patch. After consideration, it seems to me that the patch as it stands augments the current framework with the functionality indicated in the commit message above, without restricting other current uses. Further functionality could be added, but IMHO that should be done as the need arises, when it can be properly tested in a real-world setup. sound/soc/soc-pcm.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 49 insertions(+) diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c index 35fe58f4..08407ba 100644 --- a/sound/soc/soc-pcm.c +++ b/sound/soc/soc-pcm.c @@ -34,6 +34,24 @@ #define DPCM_MAX_BE_USERS 8 +/* + * snd_soc_dai_stream_valid() - check if a DAI supports the given stream + * + * Returns true if the DAI supports the indicated stream type. + */ +static bool snd_soc_dai_stream_valid(struct snd_soc_dai *dai, int stream) +{ + struct snd_soc_pcm_stream *codec_stream; + + if (stream == SNDRV_PCM_STREAM_PLAYBACK) + codec_stream = &dai->driver->playback; + else + codec_stream = &dai->driver->capture; + + /* If the codec specifies any rate at all, it supports the stream. */ + return codec_stream->rates; +} + /** * snd_soc_runtime_activate() - Increment active count for PCM runtime components * @rtd: ASoC PCM runtime that is activated @@ -371,6 +389,20 @@ static void soc_pcm_init_runtime_hw(struct snd_pcm_substream *substream) /* first calculate min/max only for CODECs in the DAI link */ for (i = 0; i < rtd->num_codecs; i++) { + + /* + * Skip CODECs which don't support the current stream type. + * Otherwise, since the rate, channel, and format values will + * zero in that case, we would have no usable settings left, + * causing the resulting setup to fail. + * At least one CODEC should match, otherwise we should have + * bailed out on a higher level, since there would be no + * CODEC to support the transfer direction in that case. + */ + if (!snd_soc_dai_stream_valid(rtd->codec_dais[i], + substream->stream)) + continue; + codec_dai_drv = rtd->codec_dais[i]->driver; if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) codec_stream = &codec_dai_drv->playback; @@ -827,6 +859,23 @@ static int soc_pcm_hw_params(struct snd_pcm_substream *substream, struct snd_soc_dai *codec_dai = rtd->codec_dais[i]; struct snd_pcm_hw_params codec_params; + /* + * Skip CODECs which don't support the current stream type, + * the idea being that if a CODEC is not used for the currently + * set up transfer direction, it should not need to be + * configured, especially since the configuration used might + * not even be supported by that CODEC. There may be cases + * however where a CODEC needs to be set up although it is + * actually not being used for the transfer, e.g. if a + * capture-only CODEC is acting as an LRCLK and/or BCLK master + * for the DAI link including a playback-only CODEC. + * If this becomes necessary, we will have to augment the + * machine driver setup with information on how to act, so + * we can do the right thing here. + */ + if (!snd_soc_dai_stream_valid(codec_dai, substream->stream)) + continue; + /* copy params for each codec */ codec_params = *params; -- 1.7.10.4 -- Ricard Wolf Wanderlöf ricardw(at)axis.com Axis Communications AB, Lund, Sweden www.axis.com Phone +46 46 272 2016 Fax +46 46 13 61 30

3 8

[alsa-devel] [PATCH RFC v2 0/7] Implement generic ASoC HDMI codec
by Jyri Sarha 20 Sep '15

20 Sep '15

Only the first three patches are meant for serious review. The ASoC part should be ready for review in other respects but the EDID SADs handling is waiting for Russell King's DRM ELD helper patches. There is a copy-pasted not-to-be-merged patch with the same functionality in the patch series. The tda998x part is not complete and I do not think Jean-Francois' binding are ready as such either. At least the usage of reg property in a port node for something that is not an address or even guaranteed to be unique is not a good idea. Some documentation of how to configure AP0-AP4 pins (REG_ENA_AP?) would help in making a proper binding for the tda998x audio configuration. These patches, my tilcdc refactoring[1], and my latest BCLK fixes for davinci-mcasp driver [2], can be found in a branch that produces working HDMI audio on Beaglebone-Black here: https://github.com/jsarha/linux.git linux-master-bbb-hdmi-20150512 [1] http://lists.freedesktop.org/archives/dri-devel/2015-May/082537.html [2] http://mailman.alsa-project.org/pipermail/alsa-devel/2015-April/090974.html Jean-Francois Moine (1): drm/i2c: tda998x: Add support of a DT graph of ports DO NOT MERGE Jyri Sarha (6): ASoC: core: If component doesn't have of_node use parent's node instead ASoC: hdmi: Remove obsolete dummy HDMI codec ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders ASoC: hdmi-codec: Add ELD based audio pcm rules DO NOT MERGE drm/i2c: tda998x: Register ASoC HDMI codec for audio functionality DO NOT MERGE ARM: dts: am335x-boneblack: Add HDMI audio support DO NOT MERGE .../devicetree/bindings/drm/i2c/tda998x.txt | 51 ++ arch/arm/boot/dts/am335x-boneblack.dts | 78 ++- drivers/gpu/drm/i2c/Kconfig | 1 + drivers/gpu/drm/i2c/tda998x_drv.c | 328 +++++++++++- include/sound/hdmi-codec.h | 99 ++++ include/sound/tda998x.h | 8 + sound/soc/codecs/Kconfig | 2 +- sound/soc/codecs/Makefile | 4 +- sound/soc/codecs/hdmi-codec.c | 560 +++++++++++++++++++++ sound/soc/codecs/hdmi.c | 109 ---- sound/soc/soc-core.c | 14 +- 11 files changed, 1129 insertions(+), 125 deletions(-) create mode 100644 include/sound/hdmi-codec.h create mode 100644 include/sound/tda998x.h create mode 100644 sound/soc/codecs/hdmi-codec.c delete mode 100644 sound/soc/codecs/hdmi.c -- 1.9.1

2 12