December 2017 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH 0/4] ARM: sun8i: a83t: Add support for I2S and I2C
by Chen-Yu Tsai 12 Dec '17

12 Dec '17

Hi everyone, This series adds support for I2S and I2C on the Allwinner A83T SoC. The I2S controllers are similar to the ones found on the A31. However the TX FIFO and interrupt status registers were swapped around. This seems to be a recurring theme for the audio related hardware blocks. Patch 1 adds support for the A83T variant with a compatible string and associated quirks structure. Patch 2 adds device nodes and default pinmux settings for the I2S controllers. Patch 3 adds device nodes and default pinmux settings for the I2C controllers. Patch 4 is an example of a PCM5122 codec tied to I2C2 and I2S1 over the GPIO header of the Banana Pi M3. This patch should not be merged. Please have a look. Regards ChenYu Chen-Yu Tsai (4): ASoC: sun4i-i2s: Add support for A83T ARM: dts: sun8i: a83t: Add I2S controller device nodes ARM: dts: sun8i: a83t: Add I2C device nodes and pinmux settings [DO NOT MERGE] ARM: dts: sun8i: a83t: bpi-m3: Enable PCM5122 codec with I2S1 .../devicetree/bindings/sound/sun4i-i2s.txt | 2 + arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 33 ++++++++ arch/arm/boot/dts/sun8i-a83t.dtsi | 99 ++++++++++++++++++++++ sound/soc/sunxi/sun4i-i2s.c | 21 +++++ 4 files changed, 155 insertions(+) -- 2.15.0

3 9

[alsa-devel] [PATCH] ASoC: sun4i-codec: fix to enable 12Khz and 24Khz audio playback and capture sample rates
by Andrea Bondavalli 12 Dec '17

12 Dec '17

H3 ASoC supports 12Khz and 24Khz audio sample rates but the current drivers doesn't advertise these rates properly and they cannot be used. For example attempt to capture at 12Khz uses 11Khz (same applies to audio playback): # arecord -f S16_LE -c 2 -r 12000 -D hw:0,0 -t raw /tmp/testS16_LE.raw Recording raw data '/tmp/testS16_LE.raw' : Signed 16 bit Little Endian, Rate 12000 Hz, Stereo Warning: rate is not accurate (requested = 12000Hz, got = 11025Hz) This patch fixes the audio sample rates declared and supported by the driver according to the H3 data sheet. Specifically for audio playback: 8000, 11050, 12000, 16000, 22050, 24000, 32000, 44100, 48000, 96000, 192000 and for audio capture: 8000, 11050, 12000, 16000, 22050, 24000, 32000, 44100, 48000 Signed-off-by: Andrea Bondavalli <andrea.bondavalli74(a)gmail.com> --- sound/soc/sunxi/sun4i-codec.c | 29 ++++++++++++++++++++--------- 1 file changed, 20 insertions(+), 9 deletions(-) diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c index 5da4efe..c79e8a4 100644 --- a/sound/soc/sunxi/sun4i-codec.c +++ b/sound/soc/sunxi/sun4i-codec.c @@ -590,12 +590,28 @@ static int sun4i_codec_hw_params(struct snd_pcm_substream *substream, hwrate); } + +static unsigned int sun4i_codec_src_rates[] = { + 8000, 11025, 12000, 16000, 22050, 24000, 32000, + 44100, 48000, 96000, 192000 +}; + + +static struct snd_pcm_hw_constraint_list sun4i_codec_constraints = { + .count = ARRAY_SIZE(sun4i_codec_src_rates), + .list = sun4i_codec_src_rates, +}; + + static int sun4i_codec_startup(struct snd_pcm_substream *substream, struct snd_soc_dai *dai) { struct snd_soc_pcm_runtime *rtd = substream->private_data; struct sun4i_codec *scodec = snd_soc_card_get_drvdata(rtd->card); + snd_pcm_hw_constraint_list(substream->runtime, 0, + SNDRV_PCM_HW_PARAM_RATE, &sun4i_codec_constraints); + /* * Stop issuing DRQ when we have room for less than 16 samples * in our TX FIFO @@ -633,9 +649,7 @@ static struct snd_soc_dai_driver sun4i_codec_dai = { .channels_max = 2, .rate_min = 8000, .rate_max = 192000, - .rates = SNDRV_PCM_RATE_8000_48000 | - SNDRV_PCM_RATE_96000 | - SNDRV_PCM_RATE_192000, + .rates = SNDRV_PCM_RATE_CONTINUOUS, .formats = SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S32_LE, .sig_bits = 24, @@ -645,11 +659,8 @@ static struct snd_soc_dai_driver sun4i_codec_dai = { .channels_min = 1, .channels_max = 2, .rate_min = 8000, - .rate_max = 192000, - .rates = SNDRV_PCM_RATE_8000_48000 | - SNDRV_PCM_RATE_96000 | - SNDRV_PCM_RATE_192000 | - SNDRV_PCM_RATE_KNOT, + .rate_max = 48000, + .rates = SNDRV_PCM_RATE_CONTINUOUS, .formats = SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S32_LE, .sig_bits = 24, @@ -1128,7 +1139,7 @@ static const struct snd_soc_component_driver sun4i_codec_component = { .name = "sun4i-codec", }; -#define SUN4I_CODEC_RATES SNDRV_PCM_RATE_8000_192000 +#define SUN4I_CODEC_RATES SNDRV_PCM_RATE_CONTINUOUS #define SUN4I_CODEC_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | \ SNDRV_PCM_FMTBIT_S32_LE) -- 2.7.4

2 2

[alsa-devel] [PATCH 0/2] ASoC: tfa9879: cleanup bindings and claim maintainership
by Peter Rosin 12 Dec '17

12 Dec '17

Hi! Device tree bindings where added for the tfa9879 along with improved support for them in the driver some time ago. All behind my back. This cleans things up and properly adds me as maintainer of the new bindings. Cheers, Peter Peter Rosin (2): ASoC: tfa9879: clean up bindings ASoC: tfa9879: add DT bindings to MAINTAINERS Documentation/devicetree/bindings/sound/tfa9879.txt | 8 ++++---- MAINTAINERS | 1 + 2 files changed, 5 insertions(+), 4 deletions(-) -- 2.11.0

2 6

[alsa-devel] Verb table for group section
by Kailang 12 Dec '17

12 Dec '17

Hi Takashi, Attach file was ALC274 in our ENG test machine. 0x16 0x90170110 => speaker 0x19 0x01a1913c => headset mic 0x1a 0x01a1913d => headphone MIC 0x1b 0x04011020 => Line out 0x21 0x0421102F => Headphone How could i set verb for group and sequence that Line out and Headphone will use DAC 0x03? Node 0x1b [Pin Complex] wcaps 0x40058f: Stereo Amp-In Amp-Out Control: name="Line Out Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Amp-In vals: [0x00 0x00] Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x00013734: IN OUT EAPD Detect Vref caps: HIZ 50 GRD 80 100 EAPD 0x2: EAPD Pin Default 0x02214120: [Jack] HP Out at Ext Front Conn = 1/8, Color = Green DefAssociation = 0x2, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x40: OUT VREF_HIZ Unsolicited: tag=01, enabled=1 Power states: D0 D1 D2 D3 EPSS Power: setting=D3, actual=D3 Connection: 2 0x02* 0x03 ========> It always use 0x02. Many Thanks. Kailang

2 3

[alsa-devel] [BUG] atmel_ssc_dai: a possible sleep-in-atomic bug in atmel_ssc_shutdown
by Jia-Ju Bai 12 Dec '17

12 Dec '17

According to sound/soc/atmel/atmel_ssc_dai.c, the driver may sleep under a spinlock. The function call path is: atmel_ssc_shutdown (acquire the spinlock) free_irq --> may sleep I do not find a good way to fix it, so I only report. This possible bug is found by my static analysis tool (DSAC) and checked by my code review. Thanks, Jia-Ju Bai

1 0

[alsa-devel] [PATCH v9 00/13] Introduce framework for SLIMbus device driver
by srinivas.kandagatla＠linaro.org 12 Dec '17

12 Dec '17

From: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org> Thanks for everyone who reviewed v8 patchset, here is v9 with review comments addressed. SLIMbus (Serial Low Power Interchip Media Bus) is a specification developed by MIPI (Mobile Industry Processor Interface) alliance. SLIMbus is a 2-wire implementation, which is used to communicate with peripheral components like audio-codec. SLIMbus uses Time-Division-Multiplexing to accommodate multiple data channels, and control channel. Control channel has messages to do device-enumeration, messages to send/receive control-data to/from SLIMbus devices, messages for port/channel management, and messages to do bandwidth allocation. Framework is introduced to support multiple instances of the bus (1 controller per bus), and multiple slave devices per controller. SPI and I2C frameworks, and comments from last time when I submitted the patches were referred-to while working on this framework. These patchsets introduce device-management, OF helpers, and messaging APIs, controller driver for Qualcomm's SLIMbus controller, and clock-pause feature for entering/exiting low-power mode for SLIMbus. Framework patches to do channel, port and bandwidth management are work-in-progress and will be sent out once these initial patches are accepted. These patchsets were tested on IFC6410 board with Qualcomm APQ8064 processor using the controller driver, and a WCD9310 codec. v8: https://lkml.org/lkml/2017/11/30/713 Changes from v8 to v9: * Fixed Licence tags as suggested by Philippe Ombredanne and Greg KH * Fixed typos spotted by Jonathan Neuschafer in documentation * Added missing addtion in index.rst file spotted by Jonathan Neuschafer Sagar Dharia (9): Documentation: Add SLIMbus summary dt-bindings: Add SLIMbus bindings slimbus: Add SLIMbus bus type slimbus: core: Add slim controllers support slimbus: Add messaging APIs to slimbus framework slimbus: Add support for 'clock-pause' feature dt-bindings: Add qcom slimbus controller bindings slimbus: qcom: Add Qualcomm Slimbus controller driver slimbus: qcom: Add runtime-pm support using clock-pause Srinivas Kandagatla (4): slimbus: core: add support to device tree helper regmap: add SLIMbus support slimbus: core: add common defines required for controllers MAINTAINERS: Add SLIMbus maintainer Documentation/devicetree/bindings/slimbus/bus.txt | 50 ++ .../devicetree/bindings/slimbus/slim-qcom-ctrl.txt | 39 ++ Documentation/driver-api/index.rst | 1 + Documentation/driver-api/slimbus/index.rst | 15 + Documentation/driver-api/slimbus/summary.rst | 106 +++ MAINTAINERS | 8 + drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/base/regmap/Kconfig | 4 + drivers/base/regmap/Makefile | 1 + drivers/base/regmap/regmap-slimbus.c | 80 +++ drivers/slimbus/Kconfig | 23 + drivers/slimbus/Makefile | 10 + drivers/slimbus/core.c | 478 +++++++++++++ drivers/slimbus/messaging.c | 328 +++++++++ drivers/slimbus/qcom-ctrl.c | 748 +++++++++++++++++++++ drivers/slimbus/sched.c | 119 ++++ drivers/slimbus/slimbus.h | 259 +++++++ include/linux/mod_devicetable.h | 13 + include/linux/regmap.h | 18 + include/linux/slimbus.h | 162 +++++ 21 files changed, 2465 insertions(+) create mode 100644 Documentation/devicetree/bindings/slimbus/bus.txt create mode 100644 Documentation/devicetree/bindings/slimbus/slim-qcom-ctrl.txt create mode 100644 Documentation/driver-api/slimbus/index.rst create mode 100644 Documentation/driver-api/slimbus/summary.rst create mode 100644 drivers/base/regmap/regmap-slimbus.c create mode 100644 drivers/slimbus/Kconfig create mode 100644 drivers/slimbus/Makefile create mode 100644 drivers/slimbus/core.c create mode 100644 drivers/slimbus/messaging.c create mode 100644 drivers/slimbus/qcom-ctrl.c create mode 100644 drivers/slimbus/sched.c create mode 100644 drivers/slimbus/slimbus.h create mode 100644 include/linux/slimbus.h -- 2.15.0

4 18

[alsa-devel] Per board ucm files on x86?
by Hans de Goede 11 Dec '17

11 Dec '17

Hi All, This weekend I've created a modified ucm config based on: https://github.com/plbossart/UCM/tree/master/chtrt5645 For a board which has a single speaker connected to the left channel (standard mono speaker setup) and a stereo headphone jack with working jack detection. I've been unable to come up with a ucm file which allows selecting between a "Stereo Speaker + Headphone" vs "Mono Speaker + Headphone" output profile. https://github.com/plbossart/UCM/tree/master/byt-rt5640 has "Mono Speaker", "Stereo Speaker" and "Headphone" profiles but does not auto-switch between Headphone and speaker based on jack detection, I've been unable to allow selecting either stereo or mono speaker while keeping auto-switching to/from the headphones. But thinking more about this I don't think that having "Stereo Speaker + Headphone" and "Mono Speaker + Headphone" profiles is the answer. Profiles make sense on machines with a bunch of outputs where we don't no what the user is going to plug in, but in this case the stereo vs mono speaker distinction is a clear property of the device, which we should IMHO autodetect based on the device-model. So I think we need a way to have different ucm files per board, so instead of loading /usr/share/ucm/chtrt5645/*.conf on my device, alsa should try to load /usr/share/ucm/chtrt5645-<boardname>/*.conf Specifically I'm thinking about using udev + hwdb (dmi string) matching to set an ALSA_UCM_NAME udev property. If the consensus is that this is a good idea I can take a shot at writing patches for this (in my spare time mostly), the downside of this approach is it would cause a dependency on libudev for the alsa ucm code. Regards, Hans

3 7

Re: [alsa-devel] [PATCH 5/8] ASoC: uniphier: add support for UniPhier AIO driver
by Mark Brown 11 Dec '17

11 Dec '17

On Mon, Dec 11, 2017 at 06:21:58PM +0900, Katsuhiro Suzuki wrote: > But I can't find how to use/map this DAI in machine driver or Device-Tree or > something. I think that it's same as PCM DAI, am I correct? Yes, that probably makes sense from a binding point of view. > I read compress-offload.rst, but I can't find how do I test it. It seems aplay > of > alsa-util doesn't know compress audio formats. Should I use PulseAudio or > Android HAL to test compress audio APIs? IIRC tinyalsa has a compressed API test application - Vinod?

2 1

[alsa-devel] [PATCH 1/2] ASoC: nuc900: Fix platform_get_irq() error checking some more
by Dan Carpenter 11 Dec '17

11 Dec '17

The error handling doesn't work here because "nuc900_audio->irq_num" is unsigned. Also we should be checking for < 0 and not <= 0 but I believe that's harmless. The platform_get_irq() comments don't talk about the return values... Fixes: fa8cc38165c2 ("ASoC: nuc900: Fix platform_get_irq's error checking") Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> diff --git a/sound/soc/nuc900/nuc900-ac97.c b/sound/soc/nuc900/nuc900-ac97.c index 5e4fbd2d3479..71fce7c85c93 100644 --- a/sound/soc/nuc900/nuc900-ac97.c +++ b/sound/soc/nuc900/nuc900-ac97.c @@ -345,11 +345,10 @@ static int nuc900_ac97_drvprobe(struct platform_device *pdev) goto out; } - nuc900_audio->irq_num = platform_get_irq(pdev, 0); - if (nuc900_audio->irq_num <= 0) { - ret = nuc900_audio->irq_num < 0 ? nuc900_audio->irq_num : -EBUSY; + ret = platform_get_irq(pdev, 0); + if (ret < 0) goto out; - } + nuc900_audio->irq_num = ret; nuc900_ac97_data = nuc900_audio;

5 14

[alsa-devel] Getting started with new driver
by Chris Caudle 11 Dec '17

11 Dec '17

I am helping review a new network audio driver that is being developed as an ALSA virtual sound card. The developer is experienced in programming, but not much in interacting with open source development. I am out of practice in programming, but would like to help with community interaction, so need some advice on getting started submitting a new driver for review. My first assumption is that since ALSA has been part of the kernel tree for quite a while all the code should match the kernel style guide (basically K&R style). Is that correct? There is some cleanup to do there, as well as some cleanup to match some recent kernel API changes (e.g. is currently using tasklet timers, but I think those are pulled out now so will need to switch to softirq timers). Once I can help get the style and API usage cleaned up, how should a new driver be submitted for review? It is currently in a semi-private tree on bitbucket.org. A series of patches as email? One big email that contains all of the driver source? Some other way? The alsa-project.org page doesn't really have a "getting started on a new driver for newbies" page that I could find. thanks, Chris Caudle

2 1