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

[alsa-devel] [PATCH] ASOC: wm8960: Add multiple MCLK frequency support
by Chen.Liu 12 Dec '17

12 Dec '17

From: "Chen.Liu" <chen.liu.opensource(a)gmail.com> Issue: MCLK=24MHZ,SYSCLOCK=12.288MHZ. When the 'wm8960_set_dai_pll' function is called,the driver will prompted "WM8960 PLL: unsupported N = 4" error message. However,the value of PLLN should be 8 based on the table45( PLL Frequency Examples) of the wm8960 chip manuanl. Reason: The intergrated PLL can be used to generate SYSCLK for the wm8960. The pll_factors function in the wm8974.c file is mainly responsible for setting the divider factor of the PLL divider with reference to MCLK clock frequency to obtain the required SYSCLK clock frequency. The configure diagram for this function can be seen below. MCLK-->[f/2]-->[R=f2/f1]-->[f/4]-->[f/N](1)-->SYSCLOCK The configuration of the PLL divider in above diagram is applicable to MCLK clock frequency is less than or equal to 14.4MHZ. examples: (1)MCLK=12MHz, required clock = 12.288MHz. R should be chosen to ensure 5 < PLLN < 13. There is a fixed divide by 4 in the PLL and a selectable divide by N after the PLL which should be set to divide by 1 to meet this requirement. Enabling the divide by 1 sets the required f2 = 4 x 1 x 12.288MHz = 49.152MHz. R = 49.152 / (12 / 2) = 8.192 PLLN = int R = 8 (2)MCLK=24MHz, required clock = 12.288MHz. Enabling the divide by 1 sets the required f2 = 4 x 1 x 12.288MHZ = 49.152MHZ. R = 49.152 / (24 / 2) = 4.096 PLLN = int R = 4 And if the [f/N] reg is set to 2,then the required f2 = 4x2x12.288MHZ = 98.304MHZ. R = 98.304 / (24 / 2) = 8.192 PLLN = int R = 8 Because the [f/N] reg is fixed divide by 1,that's why driver prompted error message. Solution: The purpose of this patch is when the conditions(5 < PLLN < 13) is false, set the register[f/N] to be 2, and the recalculate the divide factor of the PLL divider. MCLK-->[f/2]-->[R=f2/f1]-->[f/4]-->[f/N](2)-->SYSCLOCK Signed-off-by: Chen.Liu <chen.liu.opensource(a)gmail.com> --- sound/soc/codecs/wm8960.c | 25 +++++++++++++++++++++---- 1 file changed, 21 insertions(+), 4 deletions(-) diff --git a/sound/soc/codecs/wm8960.c b/sound/soc/codecs/wm8960.c index 997c446..49a27b1 100644 --- a/sound/soc/codecs/wm8960.c +++ b/sound/soc/codecs/wm8960.c @@ -1036,17 +1036,25 @@ static bool is_pll_freq_available(unsigned int source, unsigned int target) * to allow rounding later */ #define FIXED_PLL_SIZE ((1 << 24) * 10) -static int pll_factors(unsigned int source, unsigned int target, +static int pll_factors(struct snd_soc_codec *codec, + unsigned int source, unsigned int target, struct _pll_div *pll_div) { unsigned long long Kpart; unsigned int K, Ndiv, Nmod; + int unsupport = 0; + u16 reg; pr_debug("WM8960 PLL: setting %dHz->%dHz\n", source, target); /* Scale up target to PLL operating frequency */ target *= 4; +retry: + if (unsupport) { + target *= 2; + unsupport += 1; + } Ndiv = target / source; if (Ndiv < 6) { source >>= 1; @@ -1056,8 +1064,12 @@ static int pll_factors(unsigned int source, unsigned int target, pll_div->pre_div = 0; if ((Ndiv < 6) || (Ndiv > 12)) { - pr_err("WM8960 PLL: Unsupported N=%d\n", Ndiv); - return -EINVAL; + if (unsupport == 2) { + pr_err("WM8960 PLL: Unsupported N=%d\n", Ndiv); + return -EINVAL; + } + unsupport = 1; + goto retry; } pll_div->n = Ndiv; @@ -1077,6 +1089,11 @@ static int pll_factors(unsigned int source, unsigned int target, pll_div->k = K; + if (unsupport) { + reg = snd_soc_read(codec, WM8960_CLOCK1) | WM8960_SYSCLK_DIV_2; + snd_soc_write(codec, WM8960_CLOCK1, reg); + } + pr_debug("WM8960 PLL: N=%x K=%x pre_div=%d\n", pll_div->n, pll_div->k, pll_div->pre_div); @@ -1091,7 +1108,7 @@ static int wm8960_set_pll(struct snd_soc_codec *codec, int ret; if (freq_in && freq_out) { - ret = pll_factors(freq_in, freq_out, &pll_div); + ret = pll_factors(codec, freq_in, freq_out, &pll_div); if (ret != 0) return ret; } -- 1.8.3.1

3 3

[alsa-devel] [BUG] soc/sti: a possible sleep-in-atomic bug in uni_player_ctl_iec958_put
by Jia-Ju Bai 12 Dec '17

12 Dec '17

According to sound/soc/sti/uniperif_player.c, the driver may sleep under a spinlock. The function call path is: uni_player_ctl_iec958_put (acquire the spinlock) uni_player_set_channel_status mutex_lock --> 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

2 1

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

12 Dec '17

According to sound/soc/intel/haswell/sst-haswell-ipc.c, the driver may sleep under a spinlock. The function call path is: hsw_irq_thread (acquire the spinlock) hsw_process_notification hsw_log_message mutex_lock --> 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 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