October 2013 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCHv6][ 1/4] ASoC: eukrea-tlv320: Add DT support.
by Denis Carikli 24 Oct '13

24 Oct '13

Cc: Rob Herring <rob.herring(a)calxeda.com> Cc: Pawel Moll <pawel.moll(a)arm.com> Cc: Mark Rutland <mark.rutland(a)arm.com> Cc: Stephen Warren <swarren(a)wwwdotorg.org> Cc: Ian Campbell <ijc+devicetree(a)hellion.org.uk> Cc: devicetree(a)vger.kernel.org Cc: Liam Girdwood <lgirdwood(a)gmail.com> Cc: Mark Brown <broonie(a)kernel.org> Cc: alsa-devel(a)alsa-project.org Cc: Sascha Hauer <kernel(a)pengutronix.de> Cc: linux-arm-kernel(a)lists.infradead.org Cc: Eric Bénard <eric(a)eukrea.com> Signed-off-by: Denis Carikli <denis(a)eukrea.com> --- .../devicetree/bindings/sound/eukrea-tlv320.txt | 23 ++++ sound/soc/fsl/Kconfig | 5 +- sound/soc/fsl/eukrea-tlv320.c | 135 ++++++++++++++++---- 3 files changed, 140 insertions(+), 23 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/eukrea-tlv320.txt diff --git a/Documentation/devicetree/bindings/sound/eukrea-tlv320.txt b/Documentation/devicetree/bindings/sound/eukrea-tlv320.txt new file mode 100644 index 0000000..8791037 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/eukrea-tlv320.txt @@ -0,0 +1,23 @@ +Audio complex for Eukrea boards with tlv320aic23 codec. + +Required properties: +- compatible : "eukrea,eukrea-tlv320" +- model : The user-visible name of this sound complex. +- ssi-controller : The phandle of the SSI controller. +- audio-codec : The phandle of the tlv320aic23 audio codec. +- mux-int-port : The internal port of the i.MX audio muxer (AUDMUX). +- mux-ext-port : The external port of the i.MX audio muxer. + +Note: The AUDMUX port numbering should start at 1, which is consistent with +hardware manual. + +Example: + + sound { + compatible = "eukrea,eukrea-tlv320"; + model = "imx51-eukrea-tlv320aic23"; + ssi-controller = <&ssi2>; + fsl,audio-codec = <&tlv320aic23>; + mux-int-port = <2>; + mux-ext-port = <3>; + }; diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig index b7ab71f..9c3cd64 100644 --- a/sound/soc/fsl/Kconfig +++ b/sound/soc/fsl/Kconfig @@ -161,12 +161,15 @@ config SND_SOC_EUKREA_TLV320 depends on MACH_EUKREA_MBIMX27_BASEBOARD \ || MACH_EUKREA_MBIMXSD25_BASEBOARD \ || MACH_EUKREA_MBIMXSD35_BASEBOARD \ - || MACH_EUKREA_MBIMXSD51_BASEBOARD + || MACH_EUKREA_MBIMXSD51_BASEBOARD \ + || OF depends on I2C select SND_SOC_TLV320AIC23 select SND_SOC_IMX_PCM_FIQ select SND_SOC_IMX_AUDMUX select SND_SOC_IMX_SSI + select SND_SOC_FSL_SSI + select SND_SOC_IMX_PCM_DMA help Enable I2S based access to the TLV320AIC23B codec attached to the SSI interface diff --git a/sound/soc/fsl/eukrea-tlv320.c b/sound/soc/fsl/eukrea-tlv320.c index 9a4a0ca..92710cf 100644 --- a/sound/soc/fsl/eukrea-tlv320.c +++ b/sound/soc/fsl/eukrea-tlv320.c @@ -17,6 +17,8 @@ #include <linux/module.h> #include <linux/moduleparam.h> +#include <linux/of.h> +#include <linux/of_platform.h> #include <linux/device.h> #include <linux/i2c.h> #include <sound/core.h> @@ -26,49 +28,64 @@ #include "../codecs/tlv320aic23.h" #include "imx-ssi.h" +#include "fsl_ssi.h" #include "imx-audmux.h" #define CODEC_CLOCK 12000000 +struct eukrea_tlv320 { + char of; +}; + static int eukrea_tlv320_hw_params(struct snd_pcm_substream *substream, struct snd_pcm_hw_params *params) { struct snd_soc_pcm_runtime *rtd = substream->private_data; + struct eukrea_tlv320 *priv = snd_soc_card_get_drvdata(rtd->card); struct snd_soc_dai *codec_dai = rtd->codec_dai; struct snd_soc_dai *cpu_dai = rtd->cpu_dai; int ret; - ret = snd_soc_dai_set_fmt(cpu_dai, SND_SOC_DAIFMT_I2S | - SND_SOC_DAIFMT_NB_NF | - SND_SOC_DAIFMT_CBM_CFM); - if (ret) { - pr_err("%s: failed set cpu dai format\n", __func__); - return ret; + /* fsl_ssi lacks the set_fmt ops. */ + if (!priv->of) { + ret = snd_soc_dai_set_fmt(cpu_dai, SND_SOC_DAIFMT_I2S | + SND_SOC_DAIFMT_NB_NF | + SND_SOC_DAIFMT_CBM_CFM); + if (ret) { + dev_err(cpu_dai->dev, + "Failed to set the cpu dai format\n"); + return ret; + } } ret = snd_soc_dai_set_fmt(codec_dai, SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF | SND_SOC_DAIFMT_CBM_CFM); if (ret) { - pr_err("%s: failed set codec dai format\n", __func__); + dev_err(cpu_dai->dev, + "Failed to set the codec dai format.\n"); return ret; } ret = snd_soc_dai_set_sysclk(codec_dai, 0, CODEC_CLOCK, SND_SOC_CLOCK_OUT); if (ret) { - pr_err("%s: failed setting codec sysclk\n", __func__); + dev_err(cpu_dai->dev, + "Failed to set the codec dai sysclk.\n"); return ret; } - snd_soc_dai_set_tdm_slot(cpu_dai, 0xffffffc, 0xffffffc, 2, 0); - ret = snd_soc_dai_set_sysclk(cpu_dai, IMX_SSP_SYS_CLK, 0, - SND_SOC_CLOCK_IN); - if (ret) { - pr_err("can't set CPU system clock IMX_SSP_SYS_CLK\n"); - return ret; - } + /* fsl_ssi lacks the set_sysclk ops */ + if (!priv->of) { + snd_soc_dai_set_tdm_slot(cpu_dai, 0xffffffc, 0xffffffc, 2, 0); + ret = snd_soc_dai_set_sysclk(cpu_dai, IMX_SSP_SYS_CLK, 0, + SND_SOC_CLOCK_IN); + if (ret) { + dev_err(cpu_dai->dev, "Can't set CPU system clock IMX_SSP_SYS_CLK.\n"); + return ret; + } + } return 0; } @@ -80,7 +97,6 @@ static struct snd_soc_dai_link eukrea_tlv320_dai = { .name = "tlv320aic23", .stream_name = "TLV320AIC23", .codec_dai_name = "tlv320aic23-hifi", - .platform_name = "imx-ssi.0", .codec_name = "tlv320aic23-codec.0-001a", .cpu_dai_name = "imx-ssi.0", .ops = &eukrea_tlv320_snd_ops, @@ -97,8 +113,56 @@ static int eukrea_tlv320_probe(struct platform_device *pdev) { int ret; int int_port = 0, ext_port; + struct platform_device *ssi_pdev; + struct device_node *np = pdev->dev.of_node; + struct device_node *ssi_np; + struct eukrea_tlv320 *priv; + + priv = devm_kzalloc(&pdev->dev, + sizeof(struct eukrea_tlv320), GFP_KERNEL); + if (priv == NULL) + return -ENOMEM; - if (machine_is_eukrea_cpuimx27()) { + if (np) { + ssi_np = of_parse_phandle(pdev->dev.of_node, + "ssi-controller", 0); + ssi_pdev = of_find_device_by_node(ssi_np); + if (!ssi_pdev) { + dev_err(&pdev->dev, + "ssi-controller missing or invalid.\n"); + ret = -ENODEV; + goto err; + } + + ret = of_property_read_u32(np, "mux-int-port", &int_port); + if (ret) { + dev_err(&pdev->dev, + "mux-int-port missing or invalid\n"); + return ret; + } + ret = of_property_read_u32(np, "mux-ext-port", &ext_port); + if (ret) { + dev_err(&pdev->dev, + "mux-ext-port missing or invalid\n"); + return ret; + } + + /* + * The port numbering in the hardware manual starts at 1, while + * the audmux API expects it starts at 0. + */ + int_port--; + ext_port--; + + eukrea_tlv320_dai.cpu_dai_name = dev_name(&ssi_pdev->dev); + eukrea_tlv320_dai.platform_of_node = ssi_np; + priv->of = 1; + } else { + eukrea_tlv320_dai.platform_name = "imx-ssi.0"; + } + + if (machine_is_eukrea_cpuimx27() || + of_find_compatible_node(NULL, NULL, "fsl,imx21-audmux")) { imx_audmux_v1_configure_port(MX27_AUDMUX_HPCR1_SSI0, IMX_AUDMUX_V1_PCR_SYN | IMX_AUDMUX_V1_PCR_TFSDIR | @@ -115,8 +179,12 @@ static int eukrea_tlv320_probe(struct platform_device *pdev) ); } else if (machine_is_eukrea_cpuimx25sd() || machine_is_eukrea_cpuimx35sd() || - machine_is_eukrea_cpuimx51sd()) { - ext_port = machine_is_eukrea_cpuimx25sd() ? 4 : 3; + machine_is_eukrea_cpuimx51sd() || + of_find_compatible_node(NULL, NULL, "fsl,imx31-audmux")) { + if (!np) + ext_port = machine_is_eukrea_cpuimx25sd() ? + 4 : 3; + imx_audmux_v2_configure_port(int_port, IMX_AUDMUX_V2_PTCR_SYN | IMX_AUDMUX_V2_PTCR_TFSDIR | @@ -130,14 +198,29 @@ static int eukrea_tlv320_probe(struct platform_device *pdev) IMX_AUDMUX_V2_PDCR_RXDSEL(int_port) ); } else { - /* return happy. We might run on a totally different machine */ - return 0; + if (np) { + /* The eukrea,eukrea-tlv320 driver was explicitely + * requested (through the device tree). + */ + dev_err(&pdev->dev, + "Missing audmux DT node.\n"); + return -ENODEV; + } else { + /* Return happy. + * We might run on a totally different machine. + */ + return 0; + } } eukrea_tlv320.dev = &pdev->dev; + snd_soc_card_set_drvdata(&eukrea_tlv320, priv); ret = snd_soc_register_card(&eukrea_tlv320); +err: if (ret) dev_err(&pdev->dev, "snd_soc_register_card failed (%d)\n", ret); + if (np) + of_node_put(ssi_np); return ret; } @@ -149,13 +232,21 @@ static int eukrea_tlv320_remove(struct platform_device *pdev) return 0; } +static const struct of_device_id imx_tlv320_dt_ids[] = { + { .compatible = "eukrea,eukrea-tlv320"}, + { /* sentinel */ } +}; +MODULE_DEVICE_TABLE(of, imx_tlv320_dt_ids); + static struct platform_driver eukrea_tlv320_driver = { .driver = { .name = "eukrea_tlv320", .owner = THIS_MODULE, + .of_match_table = imx_tlv320_dt_ids, }, .probe = eukrea_tlv320_probe, - .remove = eukrea_tlv320_remove,}; + .remove = eukrea_tlv320_remove, +}; module_platform_driver(eukrea_tlv320_driver); -- 1.7.9.5

2 4

[alsa-devel] [GIT PULL] [00/29] playback-only DICE driver
by Clemens Ladisch 24 Oct '13

24 Oct '13

Hi Takashi, please pull this driver for FireWire DACs based on the DICE chip family. While the driver supports only PCM playback at the moment, it fills a gap left by FFADO, which supports only full- duplex devices. Thanks, Clemens ---------------------------------------------------------------- The following changes since commit 6e4664525b1db28f8c4e1130957f70a94c19213e: Linux 3.11 (2013-09-02 13:46:10 -0700) are available in the git repository at: git://git.alsa-project.org/alsa-kprivate.git dice-driver-playback-only for you to fetch changes up to b20be8de1b3972ccf9af72850b045214faa8d830: ALSA: dice: restrict the driver to playback-only devices (2013-10-20 22:07:57 +0200) ---------------------------------------------------------------- Clemens Ladisch (28): ALSA: add DICE driver ALSA: dice: optimize bus reset handling ALSA: dice: allow all sample rates ALSA: dice: reduce noisy logging ALSA: dice, firewire-lib: add blocking mode ALSA: dice: fix hang when unplugging a running device ALSA: dice: implement hwdep device ALSA: dice: clear device lock when closing hwdep device ALSA: firewire: introduce amdtp_out_stream_running() ALSA: dice: reorganize interface definitions ALSA: dice: fix device detection for other vendors ALSA: dice: support dual-wire stream format at 192 kHz ALSA: dice: optimize reading of consecutive registers ALSA: firewire: extend snd_fw_transaction() ALSA: dice: avoid superflous write at bus reset ALSA: dice: remove 10s period length limit ALSA: dice: remove superfluous field ALSA: dice: make amdtp_rates[] const ALSA: dice: get clock capabilities ALSA: dice: allow notifications during initialization ALSA: dice: get rate-dependent parameters ALSA: dice: dynamic sample rate selection ALSA: dice: check clock change timeout ALSA: dice: add a proc file to show device information ALSA: dice: document quadlet alignment ALSA: dice: dice_proc_read: remove wrong typecast ALSA: dice: fix detection of Weiss devices ALSA: dice: restrict the driver to playback-only devices Stefan Richter (1): ALSA: dice: fix locking Documentation/ioctl/ioctl-number.txt | 1 + include/uapi/sound/Kbuild | 1 + include/uapi/sound/asound.h | 3 +- include/uapi/sound/firewire.h | 51 ++ sound/firewire/Kconfig | 15 + sound/firewire/Makefile | 2 + sound/firewire/amdtp.c | 209 +++-- sound/firewire/amdtp.h | 46 +- sound/firewire/cmp.c | 50 +- sound/firewire/dice-interface.h | 371 +++++++++ sound/firewire/dice.c | 1494 ++++++++++++++++++++++++++++++++++ sound/firewire/fcp.c | 2 +- sound/firewire/isight.c | 43 +- sound/firewire/lib.c | 24 +- sound/firewire/lib.h | 7 +- sound/firewire/scs1x.c | 8 +- sound/firewire/speakers.c | 16 +- 17 files changed, 2192 insertions(+), 151 deletions(-) create mode 100644 include/uapi/sound/firewire.h create mode 100644 sound/firewire/dice-interface.h create mode 100644 sound/firewire/dice.c

2 30

[alsa-devel] [PATCH 1/2] ALSA: hda - Add support of ALC255 codecs
by Takashi Iwai 24 Oct '13

24 Oct '13

From: Kailang Yang <kailang(a)realtek.com> It's just another variant of ALC269 & co. Signed-off-by: Kailang Yang <kailang(a)realtek.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/pci/hda/patch_realtek.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 52c26d3..1c4f8c5 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -2540,6 +2540,7 @@ enum { ALC269_TYPE_ALC283, ALC269_TYPE_ALC284, ALC269_TYPE_ALC286, + ALC269_TYPE_ALC255, }; /* @@ -2565,6 +2566,7 @@ static int alc269_parse_auto_config(struct hda_codec *codec) case ALC269_TYPE_ALC282: case ALC269_TYPE_ALC283: case ALC269_TYPE_ALC286: + case ALC269_TYPE_ALC255: ssids = alc269_ssids; break; default: @@ -4102,6 +4104,9 @@ static int patch_alc269(struct hda_codec *codec) case 0x10ec0286: spec->codec_variant = ALC269_TYPE_ALC286; break; + case 0x10ec0255: + spec->codec_variant = ALC269_TYPE_ALC255; + break; } if (snd_hda_codec_read(codec, 0x51, 0, AC_VERB_PARAMETERS, 0) == 0x10ec5505) { @@ -4814,6 +4819,7 @@ static int patch_alc680(struct hda_codec *codec) static const struct hda_codec_preset snd_hda_preset_realtek[] = { { .id = 0x10ec0221, .name = "ALC221", .patch = patch_alc269 }, { .id = 0x10ec0233, .name = "ALC233", .patch = patch_alc269 }, + { .id = 0x10ec0255, .name = "ALC255", .patch = patch_alc269 }, { .id = 0x10ec0260, .name = "ALC260", .patch = patch_alc260 }, { .id = 0x10ec0262, .name = "ALC262", .patch = patch_alc262 }, { .id = 0x10ec0267, .name = "ALC267", .patch = patch_alc268 }, -- 1.8.4

1 1

[alsa-devel] [PATCH] ALSA: hda - Fix mute LED on HP laptops in runtime suspend
by Takashi Iwai 24 Oct '13

24 Oct '13

When HP laptops with mute and mic-record LEDs go to runtime suspend, these LEDs are turned on forcibly no matter whether GPIO pis are on or off. This strange behavior seems triggered by resetting the HD-audio bus link at azx_rutime_suspend(). So, just add a new hda_bus flag to avoid the link reset at runtime suspend and set it for these HP machines. Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/pci/hda/hda_codec.h | 1 + sound/pci/hda/hda_intel.c | 3 ++- sound/pci/hda/patch_sigmatel.c | 4 +++- 3 files changed, 6 insertions(+), 2 deletions(-) diff --git a/sound/pci/hda/hda_codec.h b/sound/pci/hda/hda_codec.h index 7aa9870..77db694 100644 --- a/sound/pci/hda/hda_codec.h +++ b/sound/pci/hda/hda_codec.h @@ -698,6 +698,7 @@ struct hda_bus { unsigned int in_reset:1; /* during reset operation */ unsigned int power_keep_link_on:1; /* don't power off HDA link */ unsigned int no_response_fallback:1; /* don't fallback at RIRB error */ + unsigned int avoid_link_reset:1; /* don't reset link at runtime PM */ int primary_dig_out_type; /* primary digital out PCM type */ }; diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 6e61a01..a0a06f7 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -2986,7 +2986,8 @@ static int azx_runtime_suspend(struct device *dev) STATESTS_INT_MASK); azx_stop_chip(chip); - azx_enter_link_reset(chip); + if (!chip->bus->avoid_link_reset) + azx_enter_link_reset(chip); azx_clear_irq_pending(chip); if (chip->driver_caps & AZX_DCAPS_I915_POWERWELL) hda_display_power(false); diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c index fba0cef..69a549a 100644 --- a/sound/pci/hda/patch_sigmatel.c +++ b/sound/pci/hda/patch_sigmatel.c @@ -2091,8 +2091,10 @@ static void stac92hd83xxx_fixup_hp_mic_led(struct hda_codec *codec, { struct sigmatel_spec *spec = codec->spec; - if (action == HDA_FIXUP_ACT_PRE_PROBE) + if (action == HDA_FIXUP_ACT_PRE_PROBE) { spec->mic_mute_led_gpio = 0x08; /* GPIO3 */ + codec->bus->avoid_link_reset = 1; + } } static void stac92hd83xxx_fixup_headset_jack(struct hda_codec *codec, -- 1.8.4

1 0

[alsa-devel] [PATCH 0/8] treewide: Remove OOM message after input_alloc_device
by Joe Perches 24 Oct '13

24 Oct '13

Joe Perches (8): Documentation: Remove OOM message after input_allocate_device cell: Remove OOM message after input_allocate_device hid: Remove OOM message after input_allocate_device input: Remove OOM message after input_allocate_device media: Remove OOM message after input_allocate_device platform:x86: Remove OOM message after input_allocate_device staging: Remove OOM message after input_allocate_device sound: Remove OOM message after input_allocate_device Documentation/input/input-programming.txt | 1 - arch/powerpc/platforms/cell/cbe_powerbutton.c | 1 - drivers/hid/hid-input.c | 1 - drivers/hid/hid-picolcd_core.c | 5 ++--- drivers/input/joystick/as5011.c | 2 -- drivers/input/joystick/db9.c | 1 - drivers/input/joystick/gamecon.c | 4 +--- drivers/input/joystick/turbografx.c | 1 - drivers/input/joystick/walkera0701.c | 1 - drivers/input/keyboard/amikbd.c | 4 +--- drivers/input/keyboard/davinci_keyscan.c | 1 - drivers/input/keyboard/gpio_keys.c | 1 - drivers/input/keyboard/lpc32xx-keys.c | 1 - drivers/input/keyboard/max7359_keypad.c | 1 - drivers/input/keyboard/mcs_touchkey.c | 1 - drivers/input/keyboard/mpr121_touchkey.c | 1 - drivers/input/keyboard/nomadik-ske-keypad.c | 1 - drivers/input/keyboard/opencores-kbd.c | 1 - drivers/input/keyboard/pmic8xxx-keypad.c | 1 - drivers/input/keyboard/pxa27x_keypad.c | 1 - drivers/input/keyboard/pxa930_rotary.c | 1 - drivers/input/keyboard/qt1070.c | 1 - drivers/input/keyboard/qt2160.c | 1 - drivers/input/keyboard/sh_keysc.c | 1 - drivers/input/keyboard/tc3589x-keypad.c | 1 - drivers/input/keyboard/tnetv107x-keypad.c | 1 - drivers/input/keyboard/w90p910_keypad.c | 1 - drivers/input/misc/88pm80x_onkey.c | 1 - drivers/input/misc/88pm860x_onkey.c | 1 - drivers/input/misc/arizona-haptics.c | 4 +--- drivers/input/misc/atlas_btns.c | 4 +--- drivers/input/misc/da9052_onkey.c | 1 - drivers/input/misc/da9055_onkey.c | 4 +--- drivers/input/misc/ideapad_slidebar.c | 1 - drivers/input/misc/ims-pcu.c | 7 +------ drivers/input/misc/kxtj9.c | 4 +--- drivers/input/misc/max8997_haptic.c | 1 - drivers/input/misc/mc13783-pwrbutton.c | 4 +--- drivers/input/misc/mpu3050.c | 1 - drivers/input/misc/pcf8574_keypad.c | 1 - drivers/input/misc/pm8xxx-vibrator.c | 1 - drivers/input/misc/pmic8xxx-pwrkey.c | 1 - drivers/input/misc/pwm-beeper.c | 1 - drivers/input/misc/twl4030-pwrbutton.c | 4 +--- drivers/input/misc/twl6040-vibra.c | 1 - drivers/input/mouse/appletouch.c | 4 +--- drivers/input/mouse/bcm5974.c | 4 +--- drivers/input/mouse/cyapa.c | 4 +--- drivers/input/mouse/inport.c | 1 - drivers/input/mouse/logibm.c | 1 - drivers/input/mouse/pc110pad.c | 1 - drivers/input/mouse/pxa930_trkball.c | 1 - drivers/input/tablet/aiptek.c | 5 +---- drivers/input/tablet/gtco.c | 1 - drivers/input/touchscreen/88pm860x-ts.c | 1 - drivers/input/touchscreen/atmel_mxt_ts.c | 1 - drivers/input/touchscreen/atmel_tsadcc.c | 1 - drivers/input/touchscreen/bu21013_ts.c | 1 - drivers/input/touchscreen/cyttsp4_core.c | 2 -- drivers/input/touchscreen/da9034-ts.c | 1 - drivers/input/touchscreen/edt-ft5x06.c | 1 - drivers/input/touchscreen/eeti_ts.c | 5 +---- drivers/input/touchscreen/htcpen.c | 1 - drivers/input/touchscreen/intel-mid-touch.c | 1 - drivers/input/touchscreen/lpc32xx_ts.c | 1 - drivers/input/touchscreen/mcs5000_ts.c | 1 - drivers/input/touchscreen/migor_ts.c | 1 - drivers/input/touchscreen/mk712.c | 1 - drivers/input/touchscreen/pixcir_i2c_ts.c | 1 - drivers/input/touchscreen/s3c2410_ts.c | 1 - drivers/input/touchscreen/ti_am335x_tsc.c | 1 - drivers/input/touchscreen/tnetv107x-ts.c | 1 - drivers/media/rc/imon.c | 8 ++------ drivers/media/usb/em28xx/em28xx-input.c | 4 +--- drivers/media/usb/pwc/pwc-if.c | 1 - drivers/platform/x86/asus-laptop.c | 5 ++--- drivers/platform/x86/eeepc-laptop.c | 4 +--- drivers/platform/x86/ideapad-laptop.c | 4 +--- drivers/platform/x86/intel_mid_powerbtn.c | 4 +--- drivers/platform/x86/panasonic-laptop.c | 5 +---- drivers/platform/x86/thinkpad_acpi.c | 1 - drivers/platform/x86/topstar-laptop.c | 4 +--- drivers/platform/x86/toshiba_acpi.c | 4 +--- drivers/staging/cptm1217/clearpad_tm1217.c | 2 -- drivers/staging/iio/adc/mxs-lradc.c | 4 +--- drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c | 2 -- sound/pci/hda/hda_beep.c | 4 +--- 87 files changed, 29 insertions(+), 152 deletions(-) -- 1.8.1.2.459.gbcd45b4.dirty

2 2

Re: [alsa-devel] [PATCH] ASoC: tpa6130a2: Add device tree support
by Mark Brown 24 Oct '13

24 Oct '13

On Wed, Oct 23, 2013 at 02:03:28PM +0200, Sebastian Reichel wrote: > Add device tree support to tpa6130a2 driver and document the > bindings. Applied, thanks.

1 0

[alsa-devel] [PATCH] ALSA: hda - Fix unbalanced runtime PM refcount after S3/S4
by Takashi Iwai 24 Oct '13

24 Oct '13

When a machine goes to S3/S4 after power-save is enabled, the runtime PM refcount might be incorrectly decreased because the power-down triggered soon after resume assumes that the controller was already powered up, and issues the pm_notify down. This patch fixes the incorrect pm_notify call simply by checking the current value properly. Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/pci/hda/hda_codec.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index 5b6c4e3..748c6a9 100644 --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -4864,8 +4864,8 @@ static void hda_power_work(struct work_struct *work) spin_unlock(&codec->power_lock); state = hda_call_codec_suspend(codec, true); - codec->pm_down_notified = 0; - if (!bus->power_keep_link_on && (state & AC_PWRST_CLK_STOP_OK)) { + if (!codec->pm_down_notified && + !bus->power_keep_link_on && (state & AC_PWRST_CLK_STOP_OK)) { codec->pm_down_notified = 1; hda_call_pm_notify(bus, false); } -- 1.8.4

1 0

[alsa-devel] [PATCH v2 00/11] Fix AM335x-evm analog audio support
by jsarha＠ti.com 23 Oct '13

23 Oct '13

From: Jyri Sarha <jsarha(a)ti.com> The first version of patches can been found here: http://mailman.alsa-project.org/pipermail/alsa-devel/2013-September/066178.… Changes for v2 - Dropped our "ASoC: davinci-mcasp: Add pinctrl support" since driver core is taking care of this now. - Cleanup am33xx audio build - Add regulators to tlv320aic3x DT binding document - Remove dm365-voice-codec-audio DT support as it has never been tested an probably does not work - Add output pins and Line In connector to davinci-evm-audio DT binding doc - Remove asp_chan_q and ram_chan_q properties from mcasp DT node in DT mode mcasp is hardcoded to event queue 0 (highest priority) - Add pins to tlv320aic3x DT bindings document. If I misunderstood Marks comment and this patch is not needed, then just leave it out Changes based on TI internal discussions - Move system clock rate logic away from from evm_hw_params soc-op - Remove unnecesary #if defined(CONFIG_OF) from davinci-evm.c - Make dma property DT binding document more exact - Add only "dma" reg location instead of separate "dma-tx" and "dma-rx" - Primarily look for "mpu" reg property, but fall back to index 0 if not found - Remove interrupt property from mcasp DT node as it is not used - Remove #address-cells and #size-cells mcasp properties as they are not needed This set of patches fixes the basic audio support for am335x-evm. It should also be relatively simple to add the necessary nodes to relevant dts files to get BeagleBone + AudioCape and am335x-evmsk working too. The patch set depends on following patches: [PATCH v11 4/8] ARM: dts: add AM33XX EDMA support https://lkml.org/lkml/2013/6/18/49 [PATCH v11 5/8] ARM: dts: add AM33XX SPI DMA support https://lkml.org/lkml/2013/6/18/55 [PATCH v2] ARM: EDMA: Fix clearing of unused list for DT DMA resources https://lkml.org/lkml/2013/7/22/441 I have tried my best not to break the existing support for older davinci boards, but since I do not have those boards I can not be sure. Some commit comments refer to a dmaengine based davinci audio implementation which is planned for but nothing has been done yet. Best regards, Jyri Darren Etheridge (1): ARM/dts: am335x-evm: Add audio support for am335x-evm.dts Hebbar, Gururaja (2): ASoC: davinci-evm: Add device tree binding ASoC: davinci: Add support for AM33xx SoC Audio Jyri Sarha (7): ASoC: davinci-evm: Move sysclk logic away from evm_hw_params ASoC: davinci-mcasp: Add DMA register locations to DT ASoC: davinci-mcasp: Extract DMA channels directly from DT ASoC: davinci-mcasp: Remove interrupt property from DT bindings doc ASoC: tlv320aic3x: Add regulators to DT bindings document ASoC: tlv320aic3x: Add codec pins to DT bindings document ARM/dts: am33xx: mcasp: Add new dma register location to reg-property Pantelis Antoniou (1): ARM/dts: am33xx: Add mcasp0 and mcasp1 device tree entries .../bindings/sound/davinci-evm-audio.txt | 58 ++++++ .../bindings/sound/davinci-mcasp-audio.txt | 15 +- .../devicetree/bindings/sound/tlv320aic3x.txt | 26 +++ arch/arm/boot/dts/am335x-evm.dts | 56 ++++++ arch/arm/boot/dts/am33xx.dtsi | 25 +++ include/linux/platform_data/davinci_asp.h | 2 + sound/soc/davinci/Kconfig | 18 +- sound/soc/davinci/Makefile | 1 + sound/soc/davinci/davinci-evm.c | 184 +++++++++++++++++--- sound/soc/davinci/davinci-mcasp.c | 106 +++++++---- 10 files changed, 428 insertions(+), 63 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/davinci-evm-audio.txt -- 1.7.9.5

9 121

[alsa-devel] [PATCH 1/3] ASoC: samsung: Provide helper for DMA init
by Mark Brown 23 Oct '13

23 Oct '13

From: Mark Brown <broonie(a)linaro.org> In preparation for using the dmaengine helpers in ASoC rather than the dmaengine wrappers for the Samsung API wrap the configuration of dma_data. The dmaengine code expects different data to that used by the legacy API. Signed-off-by: Mark Brown <broonie(a)linaro.org> --- sound/soc/samsung/ac97.c | 51 +++++++++++++++--------------------------------- sound/soc/samsung/dma.c | 8 ++++++++ sound/soc/samsung/dma.h | 3 +++ sound/soc/samsung/i2s.c | 2 +- sound/soc/samsung/pcm.c | 18 +++++++++-------- 5 files changed, 38 insertions(+), 44 deletions(-) diff --git a/sound/soc/samsung/ac97.c b/sound/soc/samsung/ac97.c index 2acf987..bd09410 100644 --- a/sound/soc/samsung/ac97.c +++ b/sound/soc/samsung/ac97.c @@ -221,24 +221,6 @@ static struct snd_ac97_bus_ops s3c_ac97_ops = { .reset = s3c_ac97_cold_reset, }; -static int s3c_ac97_hw_params(struct snd_pcm_substream *substream, - struct snd_pcm_hw_params *params, - struct snd_soc_dai *dai) -{ - struct snd_soc_pcm_runtime *rtd = substream->private_data; - struct snd_soc_dai *cpu_dai = rtd->cpu_dai; - struct s3c_dma_params *dma_data; - - if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) - dma_data = &s3c_ac97_pcm_out; - else - dma_data = &s3c_ac97_pcm_in; - - snd_soc_dai_set_dma_data(cpu_dai, substream, dma_data); - - return 0; -} - static int s3c_ac97_trigger(struct snd_pcm_substream *substream, int cmd, struct snd_soc_dai *dai) { @@ -279,21 +261,6 @@ static int s3c_ac97_trigger(struct snd_pcm_substream *substream, int cmd, return 0; } -static int s3c_ac97_hw_mic_params(struct snd_pcm_substream *substream, - struct snd_pcm_hw_params *params, - struct snd_soc_dai *dai) -{ - struct snd_soc_pcm_runtime *rtd = substream->private_data; - struct snd_soc_dai *cpu_dai = rtd->cpu_dai; - - if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) - return -ENODEV; - else - snd_soc_dai_set_dma_data(cpu_dai, substream, &s3c_ac97_mic_in); - - return 0; -} - static int s3c_ac97_mic_trigger(struct snd_pcm_substream *substream, int cmd, struct snd_soc_dai *dai) { @@ -329,15 +296,27 @@ static int s3c_ac97_mic_trigger(struct snd_pcm_substream *substream, } static const struct snd_soc_dai_ops s3c_ac97_dai_ops = { - .hw_params = s3c_ac97_hw_params, .trigger = s3c_ac97_trigger, }; static const struct snd_soc_dai_ops s3c_ac97_mic_dai_ops = { - .hw_params = s3c_ac97_hw_mic_params, .trigger = s3c_ac97_mic_trigger, }; +static int s3c_ac97_dai_probe(struct snd_soc_dai *dai) +{ + samsung_asoc_init_dma_data(dai, &s3c_ac97_pcm_out, &s3c_ac97_pcm_in); + + return 0; +} + +static int s3c_ac97_mic_dai_probe(struct snd_soc_dai *dai) +{ + samsung_asoc_init_dma_data(dai, NULL, &s3c_ac97_mic_in); + + return 0; +} + static struct snd_soc_dai_driver s3c_ac97_dai[] = { [S3C_AC97_DAI_PCM] = { .name = "samsung-ac97", @@ -354,6 +333,7 @@ static struct snd_soc_dai_driver s3c_ac97_dai[] = { .channels_max = 2, .rates = SNDRV_PCM_RATE_8000_48000, .formats = SNDRV_PCM_FMTBIT_S16_LE,}, + .probe = s3c_ac97_dai_probe, .ops = &s3c_ac97_dai_ops, }, [S3C_AC97_DAI_MIC] = { @@ -365,6 +345,7 @@ static struct snd_soc_dai_driver s3c_ac97_dai[] = { .channels_max = 1, .rates = SNDRV_PCM_RATE_8000_48000, .formats = SNDRV_PCM_FMTBIT_S16_LE,}, + .probe = s3c_ac97_mic_dai_probe, .ops = &s3c_ac97_mic_dai_ops, }, }; diff --git a/sound/soc/samsung/dma.c b/sound/soc/samsung/dma.c index fe2748b..ee23194 100644 --- a/sound/soc/samsung/dma.c +++ b/sound/soc/samsung/dma.c @@ -441,6 +441,14 @@ static struct snd_soc_platform_driver samsung_asoc_platform = { .pcm_free = dma_free_dma_buffers, }; +void samsung_asoc_init_dma_data(struct snd_soc_dai *dai, + struct s3c_dma_params *playback, + struct s3c_dma_params *capture) +{ + snd_soc_dai_init_dma_data(dai, playback, capture); +} +EXPORT_SYMBOL_GPL(samsung_asoc_init_dma_data); + int samsung_asoc_dma_platform_register(struct device *dev) { return snd_soc_register_platform(dev, &samsung_asoc_platform); diff --git a/sound/soc/samsung/dma.h b/sound/soc/samsung/dma.h index 0e86315..fb09a1c 100644 --- a/sound/soc/samsung/dma.h +++ b/sound/soc/samsung/dma.h @@ -22,6 +22,9 @@ struct s3c_dma_params { char *ch_name; }; +void samsung_asoc_init_dma_data(struct snd_soc_dai *dai, + struct s3c_dma_params *playback, + struct s3c_dma_params *capture); int samsung_asoc_dma_platform_register(struct device *dev); void samsung_asoc_dma_platform_unregister(struct device *dev); diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c index 2c4d250..9cd0a2a 100644 --- a/sound/soc/samsung/i2s.c +++ b/sound/soc/samsung/i2s.c @@ -963,7 +963,7 @@ static int samsung_i2s_dai_probe(struct snd_soc_dai *dai) } clk_prepare_enable(i2s->clk); - snd_soc_dai_init_dma_data(dai, &i2s->dma_playback, &i2s->dma_capture); + samsung_asoc_init_dma_data(dai, &i2s->dma_playback, &i2s->dma_capture); if (other) { other->addr = i2s->addr; diff --git a/sound/soc/samsung/pcm.c b/sound/soc/samsung/pcm.c index e54256f..6a5e4bf 100644 --- a/sound/soc/samsung/pcm.c +++ b/sound/soc/samsung/pcm.c @@ -275,7 +275,6 @@ static int s3c_pcm_hw_params(struct snd_pcm_substream *substream, { struct snd_soc_pcm_runtime *rtd = substream->private_data; struct s3c_pcm_info *pcm = snd_soc_dai_get_drvdata(rtd->cpu_dai); - struct s3c_dma_params *dma_data; void __iomem *regs = pcm->regs; struct clk *clk; int sclk_div, sync_div; @@ -284,13 +283,6 @@ static int s3c_pcm_hw_params(struct snd_pcm_substream *substream, dev_dbg(pcm->dev, "Entered %s\n", __func__); - if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) - dma_data = pcm->dma_playback; - else - dma_data = pcm->dma_capture; - - snd_soc_dai_set_dma_data(rtd->cpu_dai, substream, dma_data); - /* Strictly check for sample size */ switch (params_format(params)) { case SNDRV_PCM_FORMAT_S16_LE: @@ -461,10 +453,20 @@ static const struct snd_soc_dai_ops s3c_pcm_dai_ops = { .set_fmt = s3c_pcm_set_fmt, }; +static int s3c_pcm_dai_probe(struct snd_soc_dai *dai) +{ + struct s3c_pcm_info *pcm = snd_soc_dai_get_drvdata(dai); + + snd_soc_dai_init_dma_data(dai, pcm->dma_playback, pcm->dma_capture); + + return 0; +} + #define S3C_PCM_RATES SNDRV_PCM_RATE_8000_96000 #define S3C_PCM_DAI_DECLARE \ .symmetric_rates = 1, \ + .probe = s3c_pcm_dai_probe, \ .ops = &s3c_pcm_dai_ops, \ .playback = { \ .channels_min = 2, \ -- 1.8.4.rc3

2 5

[alsa-devel] [PATCH RESEND] ASoC: dont call dapm_sync while reporting jack always
by Vinod Koul 23 Oct '13

23 Oct '13

While reporting the jack status snd_soc_jack_report() invokes snd_soc_dapm_sync() always. This should be required when we have pins associated with jack and reporting enables or disables these. So add a check for this case Signed-off-by: Vinod Koul <vinod.koul(a)intel.com> --- Sorry previous one had some non upstream cruft sound/soc/soc-jack.c | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/sound/soc/soc-jack.c b/sound/soc/soc-jack.c index c9f7953..9fd4ed8 100644 --- a/sound/soc/soc-jack.c +++ b/sound/soc/soc-jack.c @@ -65,6 +65,7 @@ void snd_soc_jack_report(struct snd_soc_jack *jack, int status, int mask) struct snd_soc_codec *codec; struct snd_soc_dapm_context *dapm; struct snd_soc_jack_pin *pin; + unsigned int sync = 0; int enable; trace_snd_soc_jack_report(jack, mask, status); @@ -92,12 +93,16 @@ void snd_soc_jack_report(struct snd_soc_jack *jack, int status, int mask) snd_soc_dapm_enable_pin(dapm, pin->pin); else snd_soc_dapm_disable_pin(dapm, pin->pin); + + /* we need to sync for this case only */ + sync = 1; } /* Report before the DAPM sync to help users updating micbias status */ blocking_notifier_call_chain(&jack->notifier, jack->status, jack); - snd_soc_dapm_sync(dapm); + if (sync) + snd_soc_dapm_sync(dapm); snd_jack_report(jack->jack, jack->status); -- 1.7.0.4

3 4

[alsa-devel] [PATCH] ASoC: tegra: Remove redundant initialisation of compat_filter_fn
by Mark Brown 23 Oct '13

23 Oct '13

From: Mark Brown <broonie(a)linaro.org> Setting a field in a static struct to NULL has no effect so don't bother (and don't generate false positives for grep). Signed-off-by: Mark Brown <broonie(a)linaro.org> --- sound/soc/tegra/tegra_pcm.c | 1 - 1 file changed, 1 deletion(-) diff --git a/sound/soc/tegra/tegra_pcm.c b/sound/soc/tegra/tegra_pcm.c index f056f63..7b2d23b 100644 --- a/sound/soc/tegra/tegra_pcm.c +++ b/sound/soc/tegra/tegra_pcm.c @@ -56,7 +56,6 @@ static const struct snd_pcm_hardware tegra_pcm_hardware = { static const struct snd_dmaengine_pcm_config tegra_dmaengine_pcm_config = { .pcm_hardware = &tegra_pcm_hardware, .prepare_slave_config = snd_dmaengine_pcm_prepare_slave_config, - .compat_filter_fn = NULL, .prealloc_buffer_size = PAGE_SIZE * 8, }; -- 1.8.4.rc3

3 4

[alsa-devel] [PATCH v6] ALSA: Add SoC on-chip internal memory support for DMA buffer allocation
by Nicolin Chen 22 Oct '13

22 Oct '13

Now it's quite common that an SoC contains its on-chip internal memory. By using this memory space for DMA buffer during audio playback/record, we can shutdown the voltage for external memory to save power. Thus add new DEV type with iram malloc()/free() and accordingly modify current default mmap() for the iram circumstance. Signed-off-by: Nicolin Chen <b42378(a)freescale.com> --- Changelog v5->v6: * Dropped remaining OF dependency bacause no need to add them: of_node doesn't care about OF; of_get_named_gen_pool() returns NULL if !OF. v4->v5: * Minimized the OF dependency. v3->v4: * Appropriately placed '#ifdef CONFIG_OF' * Tested by adding '#undef CONFIG_OF' to modified files, and passed compiling. v2->v3: * Moved iram specific mmap procedure out of ifdef ARCH_HAS_DMA_MMAP_COHERENT v1->v2: * Added of_node check * Dropped noops and unused physical addr in snd_free_dev_iram() --- include/sound/memalloc.h | 1 + sound/core/memalloc.c | 65 ++++++++++++++++++++++++++++++++++++++++++++++++ sound/core/pcm_native.c | 6 +++++ 3 files changed, 72 insertions(+) diff --git a/include/sound/memalloc.h b/include/sound/memalloc.h index cf15b82..510aec4 100644 --- a/include/sound/memalloc.h +++ b/include/sound/memalloc.h @@ -52,6 +52,7 @@ struct snd_dma_device { #else #define SNDRV_DMA_TYPE_DEV_SG SNDRV_DMA_TYPE_DEV /* no SG-buf support */ #endif +#define SNDRV_DMA_TYPE_DEV_IRAM 4 /* generic device iram-buffer */ /* * info for buffer allocation diff --git a/sound/core/memalloc.c b/sound/core/memalloc.c index bdf826f..ee505e9 100644 --- a/sound/core/memalloc.c +++ b/sound/core/memalloc.c @@ -30,6 +30,7 @@ #include <linux/seq_file.h> #include <asm/uaccess.h> #include <linux/dma-mapping.h> +#include <linux/genalloc.h> #include <linux/moduleparam.h> #include <linux/mutex.h> #include <sound/memalloc.h> @@ -157,6 +158,59 @@ static void snd_free_dev_pages(struct device *dev, size_t size, void *ptr, dec_snd_pages(pg); dma_free_coherent(dev, PAGE_SIZE << pg, ptr, dma); } + +/** + * snd_malloc_dev_iram - allocate memory from on-chip internal memory + * @dev: DMA device pointer + * @size: number of bytes to allocate from the iram + * @dma: dma-view physical address + * + * Return cpu-view address or NULL indicating allocating failure + * + * This function requires iram phandle provided via of_node + */ +void *snd_malloc_dev_iram(struct device *dev, size_t size, dma_addr_t *dma) +{ + struct gen_pool *pool = NULL; + unsigned long vaddr; + + if (!dev->of_node) + return NULL; + + pool = of_get_named_gen_pool(dev->of_node, "iram", 0); + if (!pool) + return NULL; + + vaddr = gen_pool_alloc(pool, size); + if (!vaddr) + return NULL; + + *dma = gen_pool_virt_to_phys(pool, vaddr); + + return (void *)vaddr; +} + +/** + * snd_free_dev_iram - free allocated specific memory from on-chip internal memory + * @dev: DMA device pointer + * @size: size in bytes of memory to free + * @ptr: cpu-view address returned from snd_malloc_dev_iram + * + * This function requires iram phandle provided via of_node + */ +void snd_free_dev_iram(struct device *dev, size_t size, void *ptr) +{ + struct gen_pool *pool = NULL; + + if (!dev->of_node) + return; + + pool = of_get_named_gen_pool(dev->of_node, "iram", 0); + if (!pool) + return; + + gen_pool_free(pool, (unsigned long)ptr, size); +} #endif /* CONFIG_HAS_DMA */ /* @@ -197,6 +251,14 @@ int snd_dma_alloc_pages(int type, struct device *device, size_t size, dmab->addr = 0; break; #ifdef CONFIG_HAS_DMA + case SNDRV_DMA_TYPE_DEV_IRAM: + dmab->area = snd_malloc_dev_iram(device, size, &dmab->addr); + if (dmab->area) + break; + /* Internal memory might have limited size and no enough space, + * so if we fail to malloc, try to fetch memory traditionally. + */ + dmab->dev.type = SNDRV_DMA_TYPE_DEV; case SNDRV_DMA_TYPE_DEV: dmab->area = snd_malloc_dev_pages(device, size, &dmab->addr); break; @@ -269,6 +331,9 @@ void snd_dma_free_pages(struct snd_dma_buffer *dmab) snd_free_pages(dmab->area, dmab->bytes); break; #ifdef CONFIG_HAS_DMA + case SNDRV_DMA_TYPE_DEV_IRAM: + snd_free_dev_iram(dmab->dev.dev, dmab->bytes, dmab->area); + break; case SNDRV_DMA_TYPE_DEV: snd_free_dev_pages(dmab->dev.dev, dmab->bytes, dmab->area, dmab->addr); break; diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c index a68d4c6..513f095 100644 --- a/sound/core/pcm_native.c +++ b/sound/core/pcm_native.c @@ -3199,6 +3199,12 @@ int snd_pcm_lib_default_mmap(struct snd_pcm_substream *substream, struct vm_area_struct *area) { area->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP; + if (substream->dma_buffer.dev.type == SNDRV_DMA_TYPE_DEV_IRAM) { + area->vm_page_prot = pgprot_writecombine(area->vm_page_prot); + return remap_pfn_range(area, area->vm_start, + substream->dma_buffer.addr >> PAGE_SHIFT, + area->vm_end - area->vm_start, area->vm_page_prot); + } #ifdef ARCH_HAS_DMA_MMAP_COHERENT if (!substream->ops->page && substream->dma_buffer.dev.type == SNDRV_DMA_TYPE_DEV) -- 1.8.4

4 4

[alsa-devel] [PATCH 1/2] ASoC: cirrus: Enable compile test builds
by Mark Brown 22 Oct '13

22 Oct '13

From: Mark Brown <broonie(a)linaro.org> The core support for ep93xx (currently only the DMA driver) does not depend on the architecture at all and everything else has more strict dependencies so enable compile test builds for improved build coverage. Signed-off-by: Mark Brown <broonie(a)linaro.org> --- sound/soc/cirrus/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/cirrus/Kconfig b/sound/soc/cirrus/Kconfig index 2c20f01..06f938d 100644 --- a/sound/soc/cirrus/Kconfig +++ b/sound/soc/cirrus/Kconfig @@ -1,6 +1,6 @@ config SND_EP93XX_SOC tristate "SoC Audio support for the Cirrus Logic EP93xx series" - depends on ARCH_EP93XX && SND_SOC + depends on (ARCH_EP93XX || COMPILE_TEST) && SND_SOC select SND_SOC_GENERIC_DMAENGINE_PCM help Say Y or M if you want to add support for codecs attached to -- 1.8.4.rc3

2 4

[alsa-devel] [PATCH] ASoC: dmaengine: Use filter_data rather than dma_data for compat requests
by Mark Brown 22 Oct '13

22 Oct '13

From: Mark Brown <broonie(a)linaro.org> When using the legacy filter function channel requests we currently pass the audio specific struct snd_dmaengine_dai_dma_data which isn't likely to be helpful for actual filtering. Since there's already a field in the structure called filter_data clearly intended for use here convert the driver to use that. All existing users of plain filter functions have been converted to use an explict compat function to override this behaviour except i.MX which is working around this issue in its filter function and is updated to just use filter_data directly here. Signed-off-by: Mark Brown <broonie(a)linaro.org> --- sound/soc/fsl/imx-pcm-dma.c | 4 +--- sound/soc/soc-generic-dmaengine-pcm.c | 5 ++++- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/sound/soc/fsl/imx-pcm-dma.c b/sound/soc/fsl/imx-pcm-dma.c index 4dc1296..aee2307 100644 --- a/sound/soc/fsl/imx-pcm-dma.c +++ b/sound/soc/fsl/imx-pcm-dma.c @@ -25,12 +25,10 @@ static bool filter(struct dma_chan *chan, void *param) { - struct snd_dmaengine_dai_dma_data *dma_data = param; - if (!imx_dma_is_general_purpose(chan)) return false; - chan->private = dma_data->filter_data; + chan->private = param; return true; } diff --git a/sound/soc/soc-generic-dmaengine-pcm.c b/sound/soc/soc-generic-dmaengine-pcm.c index e29ec3c..17dd379 100644 --- a/sound/soc/soc-generic-dmaengine-pcm.c +++ b/sound/soc/soc-generic-dmaengine-pcm.c @@ -126,6 +126,9 @@ static struct dma_chan *dmaengine_pcm_compat_request_channel( struct snd_pcm_substream *substream) { struct dmaengine_pcm *pcm = soc_platform_to_pcm(rtd->platform); + struct snd_dmaengine_dai_dma_data *dma_data; + + dma_data = snd_soc_dai_get_dma_data(rtd->cpu_dai, substream); if ((pcm->flags & SND_DMAENGINE_PCM_FLAG_HALF_DUPLEX) && pcm->chan[0]) return pcm->chan[0]; @@ -134,7 +137,7 @@ static struct dma_chan *dmaengine_pcm_compat_request_channel( return pcm->config->compat_request_channel(rtd, substream); return snd_dmaengine_pcm_request_channel(pcm->config->compat_filter_fn, - snd_soc_dai_get_dma_data(rtd->cpu_dai, substream)); + dma_data->filter_data); } static int dmaengine_pcm_new(struct snd_soc_pcm_runtime *rtd) -- 1.8.4.rc3

3 2

[alsa-devel] no sound on Haswell Lenovo T440s with 3.12-rc5
by John Twideldum 22 Oct '13

22 Oct '13

Hi all... There is a shiny new Lenovo T440s on my desk, which is a Haswell generation Ultrabook. Configuration dump running 3.12-rc5: http://www.alsa-project.org/db/?f=2eec0890ae63625c1b47a7e7cbcbb1722c8c5080 Symptoms: I have console beep, but no sound. Specifically, a) it appears "Intel Haswell HDMI" on displayport appears to be picked as default output, b) alternative output 2 "HDA Intel PCH/Realtek ALC292" has no PCM control. So my wild guess would be a) PCH needs to be default and b) the PCM controls are missing due to a bug Is there a patch already queued for 3.13? If not - willing to test, but may take some time as I'm travelling... Thank you!

1 0

[alsa-devel] [PATCHv5][ 1/4] ASoC: eukrea-tlv320: Add DT support.
by Denis Carikli 21 Oct '13

21 Oct '13

Cc: Rob Herring <rob.herring(a)calxeda.com> Cc: Pawel Moll <pawel.moll(a)arm.com> Cc: Mark Rutland <mark.rutland(a)arm.com> Cc: Stephen Warren <swarren(a)wwwdotorg.org> Cc: Ian Campbell <ijc+devicetree(a)hellion.org.uk> Cc: devicetree(a)vger.kernel.org Cc: Liam Girdwood <lgirdwood(a)gmail.com> Cc: Mark Brown <broonie(a)kernel.org> Cc: alsa-devel(a)alsa-project.org Cc: Sascha Hauer <kernel(a)pengutronix.de> Cc: linux-arm-kernel(a)lists.infradead.org Cc: Eric Bénard <eric(a)eukrea.com> Signed-off-by: Denis Carikli <denis(a)eukrea.com> --- ChangeLog v4->v5: - The pr_err are now replaced with (non line wrapped) dev_err. - The place of the "};" in eukrea_tlv320_driver is now fixed. --- .../devicetree/bindings/sound/eukrea-tlv320.txt | 23 ++++ sound/soc/fsl/Kconfig | 5 +- sound/soc/fsl/eukrea-tlv320.c | 135 ++++++++++++++++---- 3 files changed, 140 insertions(+), 23 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/eukrea-tlv320.txt diff --git a/Documentation/devicetree/bindings/sound/eukrea-tlv320.txt b/Documentation/devicetree/bindings/sound/eukrea-tlv320.txt new file mode 100644 index 0000000..8791037 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/eukrea-tlv320.txt @@ -0,0 +1,23 @@ +Audio complex for Eukrea boards with tlv320aic23 codec. + +Required properties: +- compatible : "eukrea,eukrea-tlv320" +- model : The user-visible name of this sound complex. +- ssi-controller : The phandle of the SSI controller. +- audio-codec : The phandle of the tlv320aic23 audio codec. +- mux-int-port : The internal port of the i.MX audio muxer (AUDMUX). +- mux-ext-port : The external port of the i.MX audio muxer. + +Note: The AUDMUX port numbering should start at 1, which is consistent with +hardware manual. + +Example: + + sound { + compatible = "eukrea,eukrea-tlv320"; + model = "imx51-eukrea-tlv320aic23"; + ssi-controller = <&ssi2>; + fsl,audio-codec = <&tlv320aic23>; + mux-int-port = <2>; + mux-ext-port = <3>; + }; diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig index b7ab71f..9c3cd64 100644 --- a/sound/soc/fsl/Kconfig +++ b/sound/soc/fsl/Kconfig @@ -161,12 +161,15 @@ config SND_SOC_EUKREA_TLV320 depends on MACH_EUKREA_MBIMX27_BASEBOARD \ || MACH_EUKREA_MBIMXSD25_BASEBOARD \ || MACH_EUKREA_MBIMXSD35_BASEBOARD \ - || MACH_EUKREA_MBIMXSD51_BASEBOARD + || MACH_EUKREA_MBIMXSD51_BASEBOARD \ + || OF depends on I2C select SND_SOC_TLV320AIC23 select SND_SOC_IMX_PCM_FIQ select SND_SOC_IMX_AUDMUX select SND_SOC_IMX_SSI + select SND_SOC_FSL_SSI + select SND_SOC_IMX_PCM_DMA help Enable I2S based access to the TLV320AIC23B codec attached to the SSI interface diff --git a/sound/soc/fsl/eukrea-tlv320.c b/sound/soc/fsl/eukrea-tlv320.c index 9a4a0ca..92710cf 100644 --- a/sound/soc/fsl/eukrea-tlv320.c +++ b/sound/soc/fsl/eukrea-tlv320.c @@ -17,6 +17,8 @@ #include <linux/module.h> #include <linux/moduleparam.h> +#include <linux/of.h> +#include <linux/of_platform.h> #include <linux/device.h> #include <linux/i2c.h> #include <sound/core.h> @@ -26,49 +28,64 @@ #include "../codecs/tlv320aic23.h" #include "imx-ssi.h" +#include "fsl_ssi.h" #include "imx-audmux.h" #define CODEC_CLOCK 12000000 +struct eukrea_tlv320 { + char of; +}; + static int eukrea_tlv320_hw_params(struct snd_pcm_substream *substream, struct snd_pcm_hw_params *params) { struct snd_soc_pcm_runtime *rtd = substream->private_data; + struct eukrea_tlv320 *priv = snd_soc_card_get_drvdata(rtd->card); struct snd_soc_dai *codec_dai = rtd->codec_dai; struct snd_soc_dai *cpu_dai = rtd->cpu_dai; int ret; - ret = snd_soc_dai_set_fmt(cpu_dai, SND_SOC_DAIFMT_I2S | - SND_SOC_DAIFMT_NB_NF | - SND_SOC_DAIFMT_CBM_CFM); - if (ret) { - pr_err("%s: failed set cpu dai format\n", __func__); - return ret; + /* fsl_ssi lacks the set_fmt ops. */ + if (!priv->of) { + ret = snd_soc_dai_set_fmt(cpu_dai, SND_SOC_DAIFMT_I2S | + SND_SOC_DAIFMT_NB_NF | + SND_SOC_DAIFMT_CBM_CFM); + if (ret) { + dev_err(cpu_dai->dev, + "Failed to set the cpu dai format\n"); + return ret; + } } ret = snd_soc_dai_set_fmt(codec_dai, SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF | SND_SOC_DAIFMT_CBM_CFM); if (ret) { - pr_err("%s: failed set codec dai format\n", __func__); + dev_err(cpu_dai->dev, + "Failed to set the codec dai format.\n"); return ret; } ret = snd_soc_dai_set_sysclk(codec_dai, 0, CODEC_CLOCK, SND_SOC_CLOCK_OUT); if (ret) { - pr_err("%s: failed setting codec sysclk\n", __func__); + dev_err(cpu_dai->dev, + "Failed to set the codec dai sysclk.\n"); return ret; } - snd_soc_dai_set_tdm_slot(cpu_dai, 0xffffffc, 0xffffffc, 2, 0); - ret = snd_soc_dai_set_sysclk(cpu_dai, IMX_SSP_SYS_CLK, 0, - SND_SOC_CLOCK_IN); - if (ret) { - pr_err("can't set CPU system clock IMX_SSP_SYS_CLK\n"); - return ret; - } + /* fsl_ssi lacks the set_sysclk ops */ + if (!priv->of) { + snd_soc_dai_set_tdm_slot(cpu_dai, 0xffffffc, 0xffffffc, 2, 0); + ret = snd_soc_dai_set_sysclk(cpu_dai, IMX_SSP_SYS_CLK, 0, + SND_SOC_CLOCK_IN); + if (ret) { + dev_err(cpu_dai->dev, "Can't set CPU system clock IMX_SSP_SYS_CLK.\n"); + return ret; + } + } return 0; } @@ -80,7 +97,6 @@ static struct snd_soc_dai_link eukrea_tlv320_dai = { .name = "tlv320aic23", .stream_name = "TLV320AIC23", .codec_dai_name = "tlv320aic23-hifi", - .platform_name = "imx-ssi.0", .codec_name = "tlv320aic23-codec.0-001a", .cpu_dai_name = "imx-ssi.0", .ops = &eukrea_tlv320_snd_ops, @@ -97,8 +113,56 @@ static int eukrea_tlv320_probe(struct platform_device *pdev) { int ret; int int_port = 0, ext_port; + struct platform_device *ssi_pdev; + struct device_node *np = pdev->dev.of_node; + struct device_node *ssi_np; + struct eukrea_tlv320 *priv; + + priv = devm_kzalloc(&pdev->dev, + sizeof(struct eukrea_tlv320), GFP_KERNEL); + if (priv == NULL) + return -ENOMEM; - if (machine_is_eukrea_cpuimx27()) { + if (np) { + ssi_np = of_parse_phandle(pdev->dev.of_node, + "ssi-controller", 0); + ssi_pdev = of_find_device_by_node(ssi_np); + if (!ssi_pdev) { + dev_err(&pdev->dev, + "ssi-controller missing or invalid.\n"); + ret = -ENODEV; + goto err; + } + + ret = of_property_read_u32(np, "mux-int-port", &int_port); + if (ret) { + dev_err(&pdev->dev, + "mux-int-port missing or invalid\n"); + return ret; + } + ret = of_property_read_u32(np, "mux-ext-port", &ext_port); + if (ret) { + dev_err(&pdev->dev, + "mux-ext-port missing or invalid\n"); + return ret; + } + + /* + * The port numbering in the hardware manual starts at 1, while + * the audmux API expects it starts at 0. + */ + int_port--; + ext_port--; + + eukrea_tlv320_dai.cpu_dai_name = dev_name(&ssi_pdev->dev); + eukrea_tlv320_dai.platform_of_node = ssi_np; + priv->of = 1; + } else { + eukrea_tlv320_dai.platform_name = "imx-ssi.0"; + } + + if (machine_is_eukrea_cpuimx27() || + of_find_compatible_node(NULL, NULL, "fsl,imx21-audmux")) { imx_audmux_v1_configure_port(MX27_AUDMUX_HPCR1_SSI0, IMX_AUDMUX_V1_PCR_SYN | IMX_AUDMUX_V1_PCR_TFSDIR | @@ -115,8 +179,12 @@ static int eukrea_tlv320_probe(struct platform_device *pdev) ); } else if (machine_is_eukrea_cpuimx25sd() || machine_is_eukrea_cpuimx35sd() || - machine_is_eukrea_cpuimx51sd()) { - ext_port = machine_is_eukrea_cpuimx25sd() ? 4 : 3; + machine_is_eukrea_cpuimx51sd() || + of_find_compatible_node(NULL, NULL, "fsl,imx31-audmux")) { + if (!np) + ext_port = machine_is_eukrea_cpuimx25sd() ? + 4 : 3; + imx_audmux_v2_configure_port(int_port, IMX_AUDMUX_V2_PTCR_SYN | IMX_AUDMUX_V2_PTCR_TFSDIR | @@ -130,14 +198,29 @@ static int eukrea_tlv320_probe(struct platform_device *pdev) IMX_AUDMUX_V2_PDCR_RXDSEL(int_port) ); } else { - /* return happy. We might run on a totally different machine */ - return 0; + if (np) { + /* The eukrea,eukrea-tlv320 driver was explicitely + * requested (through the device tree). + */ + dev_err(&pdev->dev, + "Missing audmux DT node.\n"); + return -ENODEV; + } else { + /* Return happy. + * We might run on a totally different machine. + */ + return 0; + } } eukrea_tlv320.dev = &pdev->dev; + snd_soc_card_set_drvdata(&eukrea_tlv320, priv); ret = snd_soc_register_card(&eukrea_tlv320); +err: if (ret) dev_err(&pdev->dev, "snd_soc_register_card failed (%d)\n", ret); + if (np) + of_node_put(ssi_np); return ret; } @@ -149,13 +232,21 @@ static int eukrea_tlv320_remove(struct platform_device *pdev) return 0; } +static const struct of_device_id imx_tlv320_dt_ids[] = { + { .compatible = "eukrea,eukrea-tlv320"}, + { /* sentinel */ } +}; +MODULE_DEVICE_TABLE(of, imx_tlv320_dt_ids); + static struct platform_driver eukrea_tlv320_driver = { .driver = { .name = "eukrea_tlv320", .owner = THIS_MODULE, + .of_match_table = imx_tlv320_dt_ids, }, .probe = eukrea_tlv320_probe, - .remove = eukrea_tlv320_remove,}; + .remove = eukrea_tlv320_remove, +}; module_platform_driver(eukrea_tlv320_driver); -- 1.7.9.5

1 3

[alsa-devel] Questions about virtual ALSA driver (dummy), PortAudio and full-duplex drops
by Smilen Dimitrov 21 Oct '13

21 Oct '13

Hi list(s), Apologies in advance for the longish exposition - however, I have bumped into a problem with ALSA driver development, which raised some questions that I cannot really understand at the moment. I find it especially frustrating that I cannot formulate a simple question, but instead I have to resort to test code, captures and plots, to discuss my (mis)conceptions through those - so I hope at least someone will bear with this wall of text (some 23KB plaintext), and I'll be able to get some help with this. I originally started working on a 16-bit, 44.1 kHz stereo ALSA driver for a device; and came to a point where I could achieve (what I thought was) full-duplex by running `arecord` and `aplay`, in separate shells, without any problems. However, if I tried to do the same from `audacity` - that is, have "record" running, while another track plays on the same card, with "Audacity Preferences/Recording/Overdub: Play other tracks while recording new one" enabled - then I'd experience some strange drops in the capture, which were not reported by any debug messages, even after I rebuilt and used PortAudio with debug messages on (my eventual goal is to have this experiment running in Audacity without drops). (Therefore CC to audacity-devel, since I first started looking for "audacity full duplex drops" and couldn't find much; and CC to portaudio since some of my questions depend on correct understanding of PortAudio). Anyways, I think I managed to reconstruct the drop problem I get (with my device driver and `audacity`), by using a modified command line program from the tests in the PortAudio distribution, and a modified `dummy` driver from the ALSA distribution. The complete code and test scripts are available in this directory: http://sdaaubckp.sourceforge.net/post/alsa-patest-duplex/ I ran this on Ubuntu 11.04 Natty, Linux 2.6.38 and corresponding ALSA 1.0.24.2, audacity-1.3.13, PortAudio V19 - more about my machine and environment setup is in the Readme: http://sdaaubckp.sourceforge.net/post/alsa-patest-duplex/Readme In that directory there is a script, `run-alsa-pa-tests.sh`; which compiles: the ALSA driver from `dummy-2.6.32-patest.c`; and the PortAudio program from `patest_duplex_wire.c`; with different compile-time defines - and then runs the program, obtaining verbose logs (some timestamped through `ftrace`), which end up as .csv files. The .csv files are finally plotted in the time domain using a gnuplot script, `traceLogGraph.gp`, through a batch script `batch_traceLogFile.sh`. Note you may have to change some hardcoded values in the source codes, if you want to run this collection on your machine - see the Readme for more. The file `captures01-04.tar.gz` contains complete logs from four runs of `run-alsa-pa-tests.sh` (NB: +70MB expanded), with respective `traceLogGraph.gp` gnuplot scripts that allow for reconstruction of all .png images; while the `captures_0*/` directories contain only some .pngs (those that will be referenced here). Back to the problem: once I started working with `patest_duplex_wire.c`, I realised there are actually two ways to implement "full-duplex", understood simply as "playback and record at the same time", in PortAudio: * By using two separate `PaStream*`s, with two `Pa_OpenStream`s and `Pa_StartStream`s, started one right after the other - and using their separate "record" (capture) and "play" callbacks * By using a single `PaStream*`, which correspondingly has only one callback ("wire" callback), which handles memory copying in both playback and capture directions In Audacity, as far as I could see, there is only one PortAudio callback defined (audacity-1.3.13/src/AudioIO.cpp has audacityAudioCallback;), so Audacity basically has a single "wire" callback for full-duplex. Because of that, both Audacity and `patest_duplex_wire.c` (when using a single stream/"wire" callback), can enter this section of portaudio-v19/src/hostapi/alsa/pa_linux_alsa.c: if( !xrun ) { /* Get the number of available frames for the pcms that are marked ready. * @concern FullDuplex If only one direction is marked ready (from poll), the number of frames available for * the other direction is returned. Output is normally preferred over capture however, so capture frames may be * discarded to avoid overrun unless paNeverDropInput is specified. */ int captureReady = self->capture.pcm ? self->capture.ready : 0, playbackReady = self->playback.pcm ? self->playback.ready : 0; PA_ENSURE( PaAlsaStream_GetAvailableFrames( self, captureReady, playbackReady, framesAvail, &xrun ) ); if( self->capture.pcm && self->playback.pcm ) { if( !self->playback.ready && !self->neverDropInput ) { /* Drop input, a period's worth */ PA_MDEBUG(( "%s: full-duplex (not xrun): Drop input, a period's worth - fra:%lu \n", __FUNCTION__, *framesAvail )); //added assert( self->capture.ready ); PaAlsaStreamComponent_EndProcessing( &self->capture, PA_MIN( self->capture.framesPerBuffer, *framesAvail ), &xrun ); *framesAvail = 0; self->capture.ready = 0; } } else if( self->capture.pcm ) assert( self->capture.ready ); else assert( self->playback.ready ); } ... ... which is precisely the section that seems to be causing the full-duplex capture drops I experience. I think I tried `neverDropInput` with `patest_duplex_wire.c`, and it kept segfaulting - but in any case, I don't think Audacity (at least this version) has any UI to manipulate this parameter; so I'd rather code the ALSA driver properly, so PortAudio thinks it's getting a proper full-duplex stream from it. However, this is where I get stuck - because all I can see in the code snippet are boolean conditions. Thus I cannot see what the condition is to enter this segment - in terms of variables visible from the ALSA driver (like dpcm->pcm_buf_pos, or snd_pcm_capture_avail/_hw_avail(substream->runtime)). In other words, I'd like to know what sort of rule should the ALSA driver variables observe, so the above "drop input" section is never entered when using a single PortAudio stream/"wire" callback. This is the reason why I tried adding some extra debugging statements to PortAudio (see `audacity-portaudio.patch` in the online folder), to obtain logs through `ftrace` - in hope that I'd get accurate timestamps from both user- and kernel- space, against which variable values from logs could be plotted. In brief, some of the variables on the plots are: * frabCC/frabPC = framesAvail (Capture/Playback) in bytes from CallbackThreadFunc (pa_linux_alsa.c) * frabCW/frabPW = framesAvail (Capture/Playback) in bytes from PaAlsaStream_WaitForFrames (pa_linux_alsa.c) * frgbtc/frgbtp = framesGot (Capture/Playback) in bytes total (cumulative); CallbackThreadFunc (pa_linux_alsa.c) * pav/cav/phwav/chwav = snd_pcm_playback/capture_avail/_hw_avail(substream->runtime) in bytes (dummy-2.6.32-patest.c) * aptbC/aptbP/hptbC/hptbP = (Capture/Playback) substream->runtime->control->appl_ptr/hw_ptr in bytes (dummy-2.6.32-patest.c) [ When a single PortAudio "wire" callback is used, only frabCC, frabCW and frgbtc appear (there are no separate playback variants then) - however, the driver still has separate timer functions/tasklets for each direction (playback or capture). ] The original `dummy` driver has code for both Linux kernel system timers, and for high-resolution timers; the driver builds on my system automatically with hrtimers, which is what I'm interested in. Initially, I started by working with hrtimer functions set to a period of one jiffy: since HZ in my OS is defined as 250, one jiffy is 1/HZ = 1/250 = 4 ms - and then I calculated bytes per period as total bytes per second 44100*2*2 = 176400 divided by HZ, which gives 176400/250 = 705.6 ; and then I tried to increase dpcm->pcm_buf_pos with 705 each time the hrtimer tasklet was called (those captures have folder names ending with `_jif`). That results in a behavior like this: http://sdaaubckp.sourceforge.net/post/alsa-patest-duplex/captures_02_jif/tr… That is a capture with driver debug tracing (D), fixed bytes per period in driver (F), playback+record callbacks in `patest_duplex_wire.c` (pr), with request of 512 FRAMES_PER_BUFFER (512). What I find surprising here, is that driver's `chwav` (and `cav`) stay mostly constant, "resetting" themselves in just three "hits" of the timer/tasklet after 0.12 sec; while `pav` slowly raises (and `phwav` slowly falls) - until a point after 0.12 sec, where they "reset" themselves in just one "hit" of the timer function. Furthermore, `frabPC`, `frabCC` and `frabPW` also follow the `pav` line (indicating that some frames were left 'avail', after the requested 512 frames were 'got' in PA's `CallbackThreadFunc`). For a while I thought that this slow "raise" was the cause for the drop - but it isn't, as that particular capture doesn't display a drop (and it cannot either, because it doesn't use a single "wire" callback) Then, I thought that the reason for the `pav` rising slope could be, that I'm taking too much time processing in the driver callbacks; but that can't be it, because the capture above is obtained with the "snd-dummy" driver - which does pretty much nothing in its hrtimer/takslet function, but increasing the pcm_buf_pos counters (and memsetting a couple of bytes in the capture direction); I cannot really see that as a CPU hog?! Then I thought, maybe it's a rounding problem, since I should be increasing driver pointers by 705.6 bytes per timer tick, and I'm increasing for 705 bytes instead - but then, that should result with _less_ data available for playback; while `pav` rising implies that _more_ data than needed is delivered to the PortAudio callback. Then I did another test, trying to check the delta between the kernel timestamps for capture and playback driver tasklets separately; it turns out, even if the period is specified as 4000000e-9 nsecs (4 ms) - the deltas still gr avitate around 3.99x ms; I tried also calculating cumulative bytes per second (based on deltas and bytes per period) - and for different captures, they typically tended to stabilize to some +80 Bps to some +100 Bps above the required (176400 Bps). So, if the hrtimer indeed runs a bit faster, then indeed we may feed more data than needed from the driver to userspace (PA) - but then again, the slope of `pav` is at least 668 bytes for 12.6 ms, which is >> 80 Bps; so I'm still not sure where exactly does that slope come from. Then, I noticed that the original `dummy.c` driver doesn't increase its counters by a fixed amount of bytes - but instead, by what I'd call "adaptive" amount of bytes: delta to a base time is taken; and it can be used to calculate the expected (wrapped) buffer position depending on the requested rate (although `dummy.c` does this in frames, and does it in the `_pointer` callback). So I did the same in the hrtimer tasklet - and, this seemingly does very little in respect to the `pav` slope: http://sdaaubckp.sourceforge.net/post/alsa-patest-duplex/captures_02_jif/tr… ... which is still present, with nearly the same slope as before. Unfortunately, passing "adaptive" amount of bytes/frames around is not the solution to the drops either - because here is a capture of a "drop input" (`frabDI`), with single "wire" callback requesting 512 FRAMES_PER_BUFFER - happening at approx 60 ms, even before the first correction happens (after 0.12 sec): http://sdaaubckp.sourceforge.net/post/alsa-patest-duplex/captures_02_jif/tr… The only thing I can notice here, is that when the drop happens, `phwav` briefly "crosses" below the value of `pav` (which otherwise never happens; the same goes for cav/chwav) - but I'm not sure if this is the cause, or the effect, of the drop. Also, it can be noted that for a PA single "wire" callback, the driver's playback and capture hrtimer tasklets hit very close to each other, and the corresponding variables are also very close - at the above resolution, the trace points for both nearly overlap. Another thing I suspected was FRAMES_PER_BUFFER in the PortAudio program, so the test script switches the setting in `patest_duplex_wire.c` between 512 and 0 (which is `paFramesPerBufferUnspecified`). Note that when using 0 frames per buffer: http://sdaaubckp.sourceforge.net/post/alsa-patest-duplex/captures_02_jif/tr… ... and playback+record callbacks, the is no more long slope of `pav`/`phwav`, and it self-corrects more quickly; while `cav`/`chwav` stay nearly constant - however, also note the condition where `phwav` briefly "crosses" below the value of `pav`, appears here again (but no "drop input" is detected, because we're not using a single "wire" callback). However, not even FRAMES_PER_BUFFER=0 seems to help; as it doesn't prevent the "drop input" for a single "wire" callback, in the capture below: http://sdaaubckp.sourceforge.net/post/alsa-patest-duplex/captures_02_jif/tr… Since I was also suspecting the debug traces from the driver for having an influence on the drop, the debug traces are disabled for the driver (x) in that capture - and obviously, this is not the sole cause of the drop either. Note that the original `dummy.c` kernel module calculates the period in nanoseconds, so it matches the pcm period size; in that case, one does not have to calculate if the current buffer position went over a period size - but can, instead, issue `snd_pcm_period_elapsed` directly at each call of the hrtimer tasklet. In this case, say for a pcm_period_size: 512 bytes, we might get a hrtimer period of 2902495 ns = 2.9 ms. This is controlled by the USE_JIFFY_PERIOD variable in the `dummy-2.6.32-patest.c` driver code, though not controlled by the `run-alsa-pa-tests.sh` - thus it has to be enabled manually; captures which USE_JIFFY_PERIOD have `_jif` as extension to the folder name, those that match to period size have `_psz` as extension. Again, even this doesn't prevent occurrence of the full-duplex "drop input"s - in all, these of the provided captures in the .tar.gz file feature drops: captures_01_psz/trace_patest__07_DA_w_0_drop.csv captures_03_psz/trace_patest__16_DF_w_512_drop.csv captures_01_psz/trace_patest__15_DF_w_0_drop.csv captures_04_jif/trace_patest__03_xA_w_0_drop.csv captures_02_jif/trace_patest__03_xA_w_0_drop.csv captures_04_jif/trace_patest__07_DA_w_0_drop.csv captures_02_jif/trace_patest__07_DA_w_0_drop.csv captures_04_jif/trace_patest__11_xF_w_0_drop.csv captures_02_jif/trace_patest__08_DA_w_512_drop.csv captures_04_jif/trace_patest__15_DF_w_0_drop.csv captures_02_jif/trace_patest__11_xF_w_0_drop.csv captures_04_jif/trace_patest__16_DF_w_512_drop.csv captures_03_psz/trace_patest__07_DA_w_0_drop.csv As the filenames indicate: * Regardless of whether the driver tunes its timer period to a jiffy (_jif) or to the period size (_psz); * Regardless of whether I use trace debug statement in the driver (D), or not (x); * Regardless of whether the driver "returns" adaptive (A) or fixed (F) amount of bytes; * Regardless of whether we use paFramesPerBufferUnspecified=0 or 512 frames per buffer in PortAudio; ... as long as there is a single stream/"wire callback" used from PortAudio, a "drop input" is liable to happen when running `patest_duplex_wire.c` - and this, even with a virtual `dummy` driver, which has no communication with real hardware at all, and pretty much does nothing: its role of "reading"/"writing" or "returning" bytes is merely simulated by increasing the stream buffer position counters! The mind boggles - especially since, the way I see it, one should do nothing else but properly increase these buffer counters from the driver, in order to have PortAudio "believe" a "proper" full-duplex transfer is occurring?!... and yet, what this "proper" rule (of increasing driver buffer counters) should be, completely evades me. Here I'd also like to note a few other observations - first, note that when scaling the driver hrtimer period to the period size (_psz), the `pav`/`phwav` became nearly constant, in comparison to the slopes still present upon FRAMES_PER_BUFFER=0 (which confuses me, since both: 705 bytes @ 4ms; and 2.9 bytes @ 2.9ms; should both be nearly as close to a rate of 44100 frames = 176400 bytes per second): http://sdaaubckp.sourceforge.net/post/alsa-patest-duplex/captures_03_psz/tr… ... but then, as the filenames above indicate, drops happen even then - although somewhat less often, and only when debug tracing in the driver is enabled. Could it be, that debug tracing directly from the driver can have such an effect on performance, so as to influence appearance of full-duplex "drop inputs" - even if precautions were taken, such as using `ftrace`s `trace_printk` (instead of the usual syslog `printk`), and piping the debug output directly to RAM (by using `/dev/shm`)? On a scale of a complete capture, I'd usually expect all cumulative pointers to essentially follow a single line; and usually when a capture goes well, that is how it appears - like on the image below: http://sdaaubckp.sourceforge.net/post/alsa-patest-duplex/captures_04_jif/tr… While it may be a bit difficult to follow all variables (recreate the plot in the interactive `wxt` terminal in `gnuplot`, to be able to turn off individual function plots), they all generally follow each other in the same general slope; also note that the capture ends at about 2 seconds (as programmed in `patest_duplex_wire.c`) - but playback lingers on for half a second more. However, a full-duplex drop can seemingly happen even on a line that otherwise appears straight - like on the plot below (although the reason for that could be that the drop happens early in that capture): http://sdaaubckp.sourceforge.net/post/alsa-patest-duplex/captures_02_jif/tr… ... but usually, a "drop input" resets (at least) the driver's playback `hw_ptr` (and others), like on the capture below: http://sdaaubckp.sourceforge.net/post/alsa-patest-duplex/captures_04_jif/tr… Note that when using playback/record PA callbacks (which cannot detect a "drop input"), may have similar resets of playback `hw_ptr`: http://sdaaubckp.sourceforge.net/post/alsa-patest-duplex/captures_03_psz/tr… ... but also the capture variables may reset: http://sdaaubckp.sourceforge.net/post/alsa-patest-duplex/captures_03_psz/tr… The above capture also shows `frgbtc` starting to deviate from `frgbtp`, when these "resets" occur - but piecewise, `frgbtc` still seems to keep slope parallel to `frgbtp` (and the rest of the cumulative position variables). However, this seems to be a case of proper XRUN, as the respective log for that capture includes "PaAlsaStream_HandleXrun: restarting Alsa to recover from XRUN" (while the full-duplex "drop input" is specifically _not_ an xrun). Note also, that sometimes I get some variables to be completely non-linear: http://sdaaubckp.sourceforge.net/post/alsa-patest-duplex/captures_01_psz/tr… ... however, note also that `captures_01_psz` was taken with an older version of the scripts, where I may have possibly failed to increase `ftrace` buffering - so I think those interruptions in the capture data are actually an artifact of a tracing problem. Otherwise, is it possible that ALSA could "pause" the playback/capture hrtimer tasklets for a while? Interestingly, when I tried using `patest_duplex_wire.c` with my onboard HDA Intel soundcard (naturally, without any kernel driver variable tracing, only the PA part) - a lot of the times it ended up producing similar non-linear (and diverging) cumulative variable traces - however, it never triggered a full-duplex "drop input". Finally, I suspect that these settings in the `dummy-2.6.32-patest.c` module, may also play a role in the behavior that results with full-duplex drops (they are otherwise kept the same as in the original `dummy` module): static struct snd_pcm_hardware dummy_pcm_hardware = { .info = (SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_RESUME | SNDRV_PCM_INFO_MMAP_VALID), ... .buffer_bytes_max = MAX_BUFFER_SIZE, .period_bytes_min = 64, .period_bytes_max = MAX_PERIOD_SIZE, //(64*1024) .periods_min = USE_PERIODS_MIN, //1 .periods_max = USE_PERIODS_MAX, //1024 .fifo_size = 0, ... ... and my questions in respect to them, would be this (considering the capture data should be available through address substream->runtime->dma_area in the driver): * Given that this is a virtual driver, there is no hardware with buffers whose status (how filled they are) could generate (hardware) interrupts; instead we "raise" hrtimer functions (softirq priority) directly from the kernel module - which further schedule a tasklet (with even lower priority), and where we have the opportunity to control the repetition period of the timer functions (and thus the expected transferred bytes per period, for a given audio rate). In this context, what is the meaning of `period_bytes_min` and `periods_min`? Can they be arbitrarily set - or should one set them in relation to the expected bytes per period achieved through the timer functions? * Given that `dummy` is a virtual driver, and doesn't communicate with hardware - there is no actual DMA operation performed through it, right? * If there is no actual DMA - is there actual MMAP? In other words, does the MMAP in SNDRV_PCM_INFO_MMAP refer to: memory mapping of a hardware card DMA bus address, to substream->runtime->dma_area; or to: memory mapping of kernel-space substream->runtime->dma_area, to whatever address user-space (e.g. snd_pcm_read()) uses to access it? * If there is no actual DMA - should SNDRV_PCM_INFO_MMAP_VALID be then kept? (original `dummy` driver keeps it) What would be the meaning of SNDRV_PCM_INFO_MMAP_VALID in this context (of a virtual driver with hrtimer functions/tasklets?) * What would be the meaning of SNDRV_PCM_INFO_JOINT_DUPLEX in this context? (I've seen [http://mailman.alsa-project.org/pipermail/alsa-devel/2007-December/004801.h… "[alsa-devel] How do I use SNDRV_PCM_INFO_JOINT_DUPLEX?"], but I can't really relate it to this context) Could usage of SNDRV_PCM_INFO_JOINT_DUPLEX help avoid the PortAudio full-duplex drops? And to summarize my general questions: * Given the 'telecom' definition of full-duplex as "a point-to-point system composed of two connected parties or devices that can communicate with one another in both directions, simultaneously" (wiki), is there a stricter/more specific definition of "full-duplex": ** in terms of digital audio generally? ** specifically in PortAudio (I guess yes: "when a single callback is used for both playback and capture", but there's probably more in terms of buffer positions), and in ALSA (I guess no)? * Given that none of the approaches used in the test (debug driver traces on vs. off; driver returning fixed vs. adaptive number of frames/bytes per period; driver tuning the period to pcm_period_size vs. to a jiffy; PA using fixed vs. using unspecified amount of frames per period) have explicitly prevented the appearance of single "wire" callback (full-duplex) drops; and given that the driver is a virtual one (merely updating buffer positions, which shouldn't be a CPU hog) - what could possibly be the reason for the full-duplex drops? * Is it possible at all, to use the architecture of the `dummy` driver (hrtimer + tasklet just updating buffer positions) to code an ALSA driver, that will not generate full-duplex drops when used from PortAudio with single "wire" callback? ** If so, is there a metric/conditions in terms of ALSA driver variables, that should be followed to ensure proper full-duplex operation (under PortAudio with single callback)? * Is it possible that the driver is OK - and instead I have a problem with coding of the single "wire" callback in PortAudio? (even though most of it is copied from examples) Well, that was certainly a mouthful - but I hope at least I managed to provide a reproducible example, if not a coherent explanation of the problem... Thanks in advance for any answers/pointers, Cheers!

6 15

[alsa-devel] [PATCHv4][ 1/4] ASoC: eukrea-tlv320: Add DT support.
by Denis Carikli 21 Oct '13

21 Oct '13

Cc: Rob Herring <rob.herring(a)calxeda.com> Cc: Pawel Moll <pawel.moll(a)arm.com> Cc: Mark Rutland <mark.rutland(a)arm.com> Cc: Stephen Warren <swarren(a)wwwdotorg.org> Cc: Ian Campbell <ijc+devicetree(a)hellion.org.uk> Cc: devicetree(a)vger.kernel.org Cc: Liam Girdwood <lgirdwood(a)gmail.com> Cc: Mark Brown <broonie(a)kernel.org> Cc: alsa-devel(a)alsa-project.org Cc: Sascha Hauer <kernel(a)pengutronix.de> Cc: linux-arm-kernel(a)lists.infradead.org Cc: Eric Bénard <eric(a)eukrea.com> Signed-off-by: Denis Carikli <denis(a)eukrea.com> --- ChangeLog v2->v4: - a multiline string was avoided. --- .../devicetree/bindings/sound/eukrea-tlv320.txt | 23 ++++ sound/soc/fsl/Kconfig | 5 +- sound/soc/fsl/eukrea-tlv320.c | 125 +++++++++++++++++--- 3 files changed, 133 insertions(+), 20 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/eukrea-tlv320.txt diff --git a/Documentation/devicetree/bindings/sound/eukrea-tlv320.txt b/Documentation/devicetree/bindings/sound/eukrea-tlv320.txt new file mode 100644 index 0000000..8791037 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/eukrea-tlv320.txt @@ -0,0 +1,23 @@ +Audio complex for Eukrea boards with tlv320aic23 codec. + +Required properties: +- compatible : "eukrea,eukrea-tlv320" +- model : The user-visible name of this sound complex. +- ssi-controller : The phandle of the SSI controller. +- audio-codec : The phandle of the tlv320aic23 audio codec. +- mux-int-port : The internal port of the i.MX audio muxer (AUDMUX). +- mux-ext-port : The external port of the i.MX audio muxer. + +Note: The AUDMUX port numbering should start at 1, which is consistent with +hardware manual. + +Example: + + sound { + compatible = "eukrea,eukrea-tlv320"; + model = "imx51-eukrea-tlv320aic23"; + ssi-controller = <&ssi2>; + fsl,audio-codec = <&tlv320aic23>; + mux-int-port = <2>; + mux-ext-port = <3>; + }; diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig index b7ab71f..9c3cd64 100644 --- a/sound/soc/fsl/Kconfig +++ b/sound/soc/fsl/Kconfig @@ -161,12 +161,15 @@ config SND_SOC_EUKREA_TLV320 depends on MACH_EUKREA_MBIMX27_BASEBOARD \ || MACH_EUKREA_MBIMXSD25_BASEBOARD \ || MACH_EUKREA_MBIMXSD35_BASEBOARD \ - || MACH_EUKREA_MBIMXSD51_BASEBOARD + || MACH_EUKREA_MBIMXSD51_BASEBOARD \ + || OF depends on I2C select SND_SOC_TLV320AIC23 select SND_SOC_IMX_PCM_FIQ select SND_SOC_IMX_AUDMUX select SND_SOC_IMX_SSI + select SND_SOC_FSL_SSI + select SND_SOC_IMX_PCM_DMA help Enable I2S based access to the TLV320AIC23B codec attached to the SSI interface diff --git a/sound/soc/fsl/eukrea-tlv320.c b/sound/soc/fsl/eukrea-tlv320.c index 9a4a0ca..773863d 100644 --- a/sound/soc/fsl/eukrea-tlv320.c +++ b/sound/soc/fsl/eukrea-tlv320.c @@ -17,6 +17,8 @@ #include <linux/module.h> #include <linux/moduleparam.h> +#include <linux/of.h> +#include <linux/of_platform.h> #include <linux/device.h> #include <linux/i2c.h> #include <sound/core.h> @@ -26,24 +28,33 @@ #include "../codecs/tlv320aic23.h" #include "imx-ssi.h" +#include "fsl_ssi.h" #include "imx-audmux.h" #define CODEC_CLOCK 12000000 +struct eukrea_tlv320 { + char of; +}; + static int eukrea_tlv320_hw_params(struct snd_pcm_substream *substream, struct snd_pcm_hw_params *params) { struct snd_soc_pcm_runtime *rtd = substream->private_data; + struct eukrea_tlv320 *priv = snd_soc_card_get_drvdata(rtd->card); struct snd_soc_dai *codec_dai = rtd->codec_dai; struct snd_soc_dai *cpu_dai = rtd->cpu_dai; int ret; - ret = snd_soc_dai_set_fmt(cpu_dai, SND_SOC_DAIFMT_I2S | - SND_SOC_DAIFMT_NB_NF | - SND_SOC_DAIFMT_CBM_CFM); - if (ret) { - pr_err("%s: failed set cpu dai format\n", __func__); - return ret; + /* fsl_ssi lacks the set_fmt ops. */ + if (!priv->of) { + ret = snd_soc_dai_set_fmt(cpu_dai, SND_SOC_DAIFMT_I2S | + SND_SOC_DAIFMT_NB_NF | + SND_SOC_DAIFMT_CBM_CFM); + if (ret) { + pr_err("%s: failed set cpu dai format\n", __func__); + return ret; + } } ret = snd_soc_dai_set_fmt(codec_dai, SND_SOC_DAIFMT_I2S | @@ -60,15 +71,18 @@ static int eukrea_tlv320_hw_params(struct snd_pcm_substream *substream, pr_err("%s: failed setting codec sysclk\n", __func__); return ret; } - snd_soc_dai_set_tdm_slot(cpu_dai, 0xffffffc, 0xffffffc, 2, 0); - ret = snd_soc_dai_set_sysclk(cpu_dai, IMX_SSP_SYS_CLK, 0, - SND_SOC_CLOCK_IN); - if (ret) { - pr_err("can't set CPU system clock IMX_SSP_SYS_CLK\n"); - return ret; - } + /* fsl_ssi lacks the set_sysclk ops */ + if (!priv->of) { + snd_soc_dai_set_tdm_slot(cpu_dai, 0xffffffc, 0xffffffc, 2, 0); + ret = snd_soc_dai_set_sysclk(cpu_dai, IMX_SSP_SYS_CLK, 0, + SND_SOC_CLOCK_IN); + if (ret) { + pr_err("can't set CPU system clock IMX_SSP_SYS_CLK\n"); + return ret; + } + } return 0; } @@ -80,7 +94,6 @@ static struct snd_soc_dai_link eukrea_tlv320_dai = { .name = "tlv320aic23", .stream_name = "TLV320AIC23", .codec_dai_name = "tlv320aic23-hifi", - .platform_name = "imx-ssi.0", .codec_name = "tlv320aic23-codec.0-001a", .cpu_dai_name = "imx-ssi.0", .ops = &eukrea_tlv320_snd_ops, @@ -97,8 +110,56 @@ static int eukrea_tlv320_probe(struct platform_device *pdev) { int ret; int int_port = 0, ext_port; + struct platform_device *ssi_pdev; + struct device_node *np = pdev->dev.of_node; + struct device_node *ssi_np; + struct eukrea_tlv320 *priv; + + priv = devm_kzalloc(&pdev->dev, + sizeof(struct eukrea_tlv320), GFP_KERNEL); + if (priv == NULL) + return -ENOMEM; + + if (np) { + ssi_np = of_parse_phandle(pdev->dev.of_node, + "ssi-controller", 0); + ssi_pdev = of_find_device_by_node(ssi_np); + if (!ssi_pdev) { + dev_err(&pdev->dev, + "ssi-controller missing or invalid.\n"); + ret = -ENODEV; + goto err; + } + + ret = of_property_read_u32(np, "mux-int-port", &int_port); + if (ret) { + dev_err(&pdev->dev, + "mux-int-port missing or invalid\n"); + return ret; + } + ret = of_property_read_u32(np, "mux-ext-port", &ext_port); + if (ret) { + dev_err(&pdev->dev, + "mux-ext-port missing or invalid\n"); + return ret; + } + + /* + * The port numbering in the hardware manual starts at 1, while + * the audmux API expects it starts at 0. + */ + int_port--; + ext_port--; + + eukrea_tlv320_dai.cpu_dai_name = dev_name(&ssi_pdev->dev); + eukrea_tlv320_dai.platform_of_node = ssi_np; + priv->of = 1; + } else { + eukrea_tlv320_dai.platform_name = "imx-ssi.0"; + } - if (machine_is_eukrea_cpuimx27()) { + if (machine_is_eukrea_cpuimx27() || + of_find_compatible_node(NULL, NULL, "fsl,imx21-audmux")) { imx_audmux_v1_configure_port(MX27_AUDMUX_HPCR1_SSI0, IMX_AUDMUX_V1_PCR_SYN | IMX_AUDMUX_V1_PCR_TFSDIR | @@ -115,8 +176,12 @@ static int eukrea_tlv320_probe(struct platform_device *pdev) ); } else if (machine_is_eukrea_cpuimx25sd() || machine_is_eukrea_cpuimx35sd() || - machine_is_eukrea_cpuimx51sd()) { - ext_port = machine_is_eukrea_cpuimx25sd() ? 4 : 3; + machine_is_eukrea_cpuimx51sd() || + of_find_compatible_node(NULL, NULL, "fsl,imx31-audmux")) { + if (!np) + ext_port = machine_is_eukrea_cpuimx25sd() ? + 4 : 3; + imx_audmux_v2_configure_port(int_port, IMX_AUDMUX_V2_PTCR_SYN | IMX_AUDMUX_V2_PTCR_TFSDIR | @@ -130,14 +195,29 @@ static int eukrea_tlv320_probe(struct platform_device *pdev) IMX_AUDMUX_V2_PDCR_RXDSEL(int_port) ); } else { - /* return happy. We might run on a totally different machine */ - return 0; + if (np) { + /* The eukrea,eukrea-tlv320 driver was explicitely + * requested (through the device tree). + */ + dev_err(&pdev->dev, + "Missing audmux DT node.\n"); + return -ENODEV; + } else { + /* Return happy. + * We might run on a totally different machine. + */ + return 0; + } } eukrea_tlv320.dev = &pdev->dev; + snd_soc_card_set_drvdata(&eukrea_tlv320, priv); ret = snd_soc_register_card(&eukrea_tlv320); +err: if (ret) dev_err(&pdev->dev, "snd_soc_register_card failed (%d)\n", ret); + if (np) + of_node_put(ssi_np); return ret; } @@ -149,10 +229,17 @@ static int eukrea_tlv320_remove(struct platform_device *pdev) return 0; } +static const struct of_device_id imx_tlv320_dt_ids[] = { + { .compatible = "eukrea,eukrea-tlv320"}, + { /* sentinel */ } +}; +MODULE_DEVICE_TABLE(of, imx_tlv320_dt_ids); + static struct platform_driver eukrea_tlv320_driver = { .driver = { .name = "eukrea_tlv320", .owner = THIS_MODULE, + .of_match_table = imx_tlv320_dt_ids, }, .probe = eukrea_tlv320_probe, .remove = eukrea_tlv320_remove,}; -- 1.7.9.5

1 4

[alsa-devel] [PATCH] ASoC: dont call dapm_sync while reporting jack always
by Vinod Koul 21 Oct '13

21 Oct '13

While reporting the jack status snd_soc_jack_report() invokes snd_soc_dapm_sync() always. This should be required when we have pins associated with jack and reporting enables or disables these. So add a check for this case Change-Id: I671cd444d1b6610dcb83b28f7339477556373e5c Signed-off-by: Vinod Koul <vinod.koul(a)intel.com> --- sound/soc/soc-jack.c | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/sound/soc/soc-jack.c b/sound/soc/soc-jack.c index c9f7953..9fd4ed8 100644 --- a/sound/soc/soc-jack.c +++ b/sound/soc/soc-jack.c @@ -65,6 +65,7 @@ void snd_soc_jack_report(struct snd_soc_jack *jack, int status, int mask) struct snd_soc_codec *codec; struct snd_soc_dapm_context *dapm; struct snd_soc_jack_pin *pin; + unsigned int sync = 0; int enable; trace_snd_soc_jack_report(jack, mask, status); @@ -92,12 +93,16 @@ void snd_soc_jack_report(struct snd_soc_jack *jack, int status, int mask) snd_soc_dapm_enable_pin(dapm, pin->pin); else snd_soc_dapm_disable_pin(dapm, pin->pin); + + /* we need to sync for this case only */ + sync = 1; } /* Report before the DAPM sync to help users updating micbias status */ blocking_notifier_call_chain(&jack->notifier, jack->status, jack); - snd_soc_dapm_sync(dapm); + if (sync) + snd_soc_dapm_sync(dapm); snd_jack_report(jack->jack, jack->status); -- 1.7.0.4

1 0

[alsa-devel] mxc-spdif delay: miss 1-2s at the beginning of the song
by stéphane cerveau 21 Oct '13

21 Oct '13

Dear all, I'm facing a delay during startup missing 1-2s of the song when i'm using mxc spdif with aplay. I guess its a problem with spdif synchronization. If i put a msleep(1000) at the end of the function mxc-spdif.c:mxc_spdif_playback_start, the playback is ok. Is there anyone who already faced this issue? BR. Stéphane

2 3

[alsa-devel] alsa project installation not working
by Ranjith 21 Oct '13

21 Oct '13

Hi, I am using Ubuntu 12.10. I am not able to install alsa project. When I'm giving ./configure it is throwing error as configure command not found. Thanks & Regards, Ranjith

2 1

[alsa-devel] [PATCH] ALSA: hda - add codec ID for Valleyview2 display codec
by mengdong.lin＠intel.com 21 Oct '13

21 Oct '13

From: Mengdong Lin <mengdong.lin(a)intel.com> This patch adds codec ID (0x80862882) and module alias for Valleyview2 display codec. Signed-off-by: Mengdong Lin <mengdong.lin(a)intel.com> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index 7ea0245..e332db8 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -2671,6 +2671,7 @@ static const struct hda_codec_preset snd_hda_preset_hdmi[] = { { .id = 0x80862806, .name = "PantherPoint HDMI", .patch = patch_generic_hdmi }, { .id = 0x80862807, .name = "Haswell HDMI", .patch = patch_generic_hdmi }, { .id = 0x80862880, .name = "CedarTrail HDMI", .patch = patch_generic_hdmi }, +{ .id = 0x80862882, .name = "Valleyview2 HDMI", .patch = patch_generic_hdmi }, { .id = 0x808629fb, .name = "Crestline HDMI", .patch = patch_generic_hdmi }, {} /* terminator */ }; @@ -2725,6 +2726,7 @@ MODULE_ALIAS("snd-hda-codec-id:80862805"); MODULE_ALIAS("snd-hda-codec-id:80862806"); MODULE_ALIAS("snd-hda-codec-id:80862807"); MODULE_ALIAS("snd-hda-codec-id:80862880"); +MODULE_ALIAS("snd-hda-codec-id:80862882"); MODULE_ALIAS("snd-hda-codec-id:808629fb"); MODULE_LICENSE("GPL"); -- 1.8.1.2

2 1

[alsa-devel] [PATCH] ASoC: kirkwood: cleanup the external clock probe
by Jean-Francois Moine 21 Oct '13

21 Oct '13

This patch checks the return value of the clk_prepare_enable of the external clock and removes the test about a same internal and external clock which would quite never occur and won't work in most cases it would occur. Signed-off-by: Jean-Francois Moine <moinejf(a)free.fr> --- This patch applies against broonie/sound for-next. --- sound/soc/kirkwood/kirkwood-i2s.c | 13 +++++-------- 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/sound/soc/kirkwood/kirkwood-i2s.c.old b/sound/soc/kirkwood/kirkwood-i2s.c.pat2 index d0504a2..c2433ea 100644 --- a/sound/soc/kirkwood/kirkwood-i2s.c.old +++ b/sound/soc/kirkwood/kirkwood-i2s.c.pat2 @@ -500,14 +500,11 @@ static int kirkwood_i2s_dev_probe(struct platform_device *pdev) if (PTR_ERR(priv->extclk) == -EPROBE_DEFER) return -EPROBE_DEFER; } else { - if (priv->extclk == priv->clk) { - devm_clk_put(&pdev->dev, priv->extclk); - priv->extclk = ERR_PTR(-EINVAL); - } else { - dev_info(&pdev->dev, "found external clock\n"); - clk_prepare_enable(priv->extclk); - soc_dai = &kirkwood_i2s_dai_extclk; - } + dev_info(&pdev->dev, "found external clock\n"); + ret = clk_prepare_enable(priv->extclk); + if (err < 0) + return err; + soc_dai = kirkwood_i2s_dai_extclk; } /* Some sensible defaults - this reflects the powerup values */ -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/

2 4

[alsa-devel] Fw: alsa project installation not working
by Ranjith 21 Oct '13

21 Oct '13

-------------------------------------------------- From: "Ranjith" <ranjithvs(a)iwavesystems.com> Sent: Monday, October 21, 2013 2:32 PM To: <alsa-devel(a)alsa-project.org> Subject: [alsa-devel] alsa project installation not working > Hi, > > I am using Ubuntu 12.10. I am not able to install alsa project. When I'm > giving ./configure it is throwing error as configure command not found. > > > Thanks & Regards, > > Ranjith > _______________________________________________ > Alsa-devel mailing list > Alsa-devel(a)alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

1 0

[alsa-devel] Audio Miniconference 2013 October
by Mark Brown 21 Oct '13

21 Oct '13

The room is Harris 2 upstairs on the 1st floor.

1 0