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

[alsa-devel] [PATCH 1/2] ASoC: tegra: add Tegra114 support to the AHUB driver
by Stephen Warren 25 Mar '13

25 Mar '13

From: Stephen Warren <swarren(a)nvidia.com> Tegra114's AHUB shares a design with Tegra30, with the followin changes: * Supports more (10 vs. 4) bi-directional FIFO channels into RAM. * Requires a separate block of registers to support the above. * Supports more attached clients, i.e. new audio multiplexing and de-multiplexing modules. * Is affected by more clocks due to the above. This change fully defines the device tree binding changes required to represent these changes, and minimally extends the driver to support the new hardware, without exposing any of the new FIFO channels. Signed-off-by: Stephen Warren <swarren(a)nvidia.com> --- .../bindings/sound/nvidia,tegra30-ahub.txt | 26 ++++++-- sound/soc/tegra/tegra30_ahub.c | 64 ++++++++++++++------ sound/soc/tegra/tegra30_ahub.h | 16 +++++ 3 files changed, 84 insertions(+), 22 deletions(-) diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.txt index 1ac7b16..0e5c12c 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.txt +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.txt @@ -1,12 +1,22 @@ NVIDIA Tegra30 AHUB (Audio Hub) Required properties: -- compatible : "nvidia,tegra30-ahub" +- compatible : "nvidia,tegra30-ahub", "nvidia,tegra114-ahub", etc. - reg : Should contain the register physical address and length for each of - the AHUB's APBIF registers and the AHUB's own registers. + the AHUB's register blocks. + - Tegra30 requires 2 entries, for the APBIF and AHUB/AUDIO register blocks. + - Tegra114 requires an additional entry, for the APBIF2 register block. - interrupts : Should contain AHUB interrupt -- nvidia,dma-request-selector : The Tegra DMA controller's phandle and - request selector for the first APBIF channel. +- nvidia,dma-request-selector : A list of the DMA channel specifiers. Each + entry contains the Tegra DMA controller's phandle and request selector. + If a single entry is present, the request selectors for the channels are + assumed to be contiguous, and increment from this value. + If multiple values are given, one value must be given per channel. +- clocks : Must contain an entry for each required entry in clock-names. +- clock-names : Must include the following entries: + - Tegra30: Requires d_audio, apbif, i2s0, i2s1, i2s2, i2s3, i2s4, dam0, + dam1, dam2, spdif_in. + - Tegra114: Additionally requires amx, adx. - ranges : The bus address mapping for the configlink register bus. Can be empty since the mapping is 1:1. - #address-cells : For the configlink bus. Should be <1>; @@ -25,7 +35,13 @@ ahub@70080000 { reg = <0x70080000 0x200 0x70080200 0x100>; interrupts = < 0 103 0x04 >; nvidia,dma-request-selector = <&apbdma 1>; - + clocks = <&tegra_car 106>, <&tegra_car 107>, <&tegra_car 30>, + <&tegra_car 11>, <&tegra_car 18>, <&tegra_car 101>, + <&tegra_car 102>, <&tegra_car 108>, <&tegra_car 109>, + <&tegra_car 110>, <&tegra_car 162>; + clock-names = "d_audio", "apbif", "i2s0", "i2s1", "i2s2", + "i2s3", "i2s4", "dam0", "dam1", "dam2", + "spdif_in"; ranges; #address-cells = <1>; #size-cells = <1>; diff --git a/sound/soc/tegra/tegra30_ahub.c b/sound/soc/tegra/tegra30_ahub.c index e5cfb4a..4405c3a 100644 --- a/sound/soc/tegra/tegra30_ahub.c +++ b/sound/soc/tegra/tegra30_ahub.c @@ -287,16 +287,27 @@ int tegra30_ahub_unset_rx_cif_source(enum tegra30_ahub_rxcif rxcif) } EXPORT_SYMBOL_GPL(tegra30_ahub_unset_rx_cif_source); -static const char * const configlink_clocks[] = { - "i2s0", - "i2s1", - "i2s2", - "i2s3", - "i2s4", - "dam0", - "dam1", - "dam2", - "spdif_in", +#define CLK_LIST_MASK_TEGRA30 BIT(0) +#define CLK_LIST_MASK_TEGRA114 BIT(1) + +#define CLK_LIST_MASK_TEGRA30_OR_LATER \ + (CLK_LIST_MASK_TEGRA30 | CLK_LIST_MASK_TEGRA114) + +static const struct { + const char *clk_name; + u32 clk_list_mask; +} configlink_clocks[] = { + { "i2s0", CLK_LIST_MASK_TEGRA30_OR_LATER }, + { "i2s1", CLK_LIST_MASK_TEGRA30_OR_LATER }, + { "i2s2", CLK_LIST_MASK_TEGRA30_OR_LATER }, + { "i2s3", CLK_LIST_MASK_TEGRA30_OR_LATER }, + { "i2s4", CLK_LIST_MASK_TEGRA30_OR_LATER }, + { "dam0", CLK_LIST_MASK_TEGRA30_OR_LATER }, + { "dam1", CLK_LIST_MASK_TEGRA30_OR_LATER }, + { "dam2", CLK_LIST_MASK_TEGRA30_OR_LATER }, + { "spdif_in", CLK_LIST_MASK_TEGRA30_OR_LATER }, + { "amx", CLK_LIST_MASK_TEGRA114 }, + { "adx", CLK_LIST_MASK_TEGRA114 }, }; #define LAST_REG(name) \ @@ -424,8 +435,24 @@ static const struct regmap_config tegra30_ahub_ahub_regmap_config = { .cache_type = REGCACHE_RBTREE, }; +static struct tegra30_ahub_soc_data soc_data_tegra30 = { + .clk_list_mask = CLK_LIST_MASK_TEGRA30, +}; + +static struct tegra30_ahub_soc_data soc_data_tegra114 = { + .clk_list_mask = CLK_LIST_MASK_TEGRA114, +}; + +static const struct of_device_id tegra30_ahub_of_match[] = { + { .compatible = "nvidia,tegra114-ahub", .data = &soc_data_tegra114 }, + { .compatible = "nvidia,tegra30-ahub", .data = &soc_data_tegra30 }, + {}, +}; + static int tegra30_ahub_probe(struct platform_device *pdev) { + const struct of_device_id *match; + const struct tegra30_ahub_soc_data *soc_data; struct clk *clk; int i; struct resource *res0, *res1, *region; @@ -436,16 +463,24 @@ static int tegra30_ahub_probe(struct platform_device *pdev) if (ahub) return -ENODEV; + match = of_match_device(tegra30_ahub_of_match, &pdev->dev); + if (!match) + return -EINVAL; + soc_data = match->data; + /* * The AHUB hosts a register bus: the "configlink". For this to * operate correctly, all devices on this bus must be out of reset. * Ensure that here. */ for (i = 0; i < ARRAY_SIZE(configlink_clocks); i++) { - clk = clk_get(&pdev->dev, configlink_clocks[i]); + if (!(configlink_clocks[i].clk_list_mask & + soc_data->clk_list_mask)) + continue; + clk = clk_get(&pdev->dev, configlink_clocks[i].clk_name); if (IS_ERR(clk)) { dev_err(&pdev->dev, "Can't get clock %s\n", - configlink_clocks[i]); + configlink_clocks[i].clk_name); ret = PTR_ERR(clk); goto err; } @@ -592,11 +627,6 @@ static int tegra30_ahub_remove(struct platform_device *pdev) return 0; } -static const struct of_device_id tegra30_ahub_of_match[] = { - { .compatible = "nvidia,tegra30-ahub", }, - {}, -}; - static const struct dev_pm_ops tegra30_ahub_pm_ops = { SET_RUNTIME_PM_OPS(tegra30_ahub_runtime_suspend, tegra30_ahub_runtime_resume, NULL) diff --git a/sound/soc/tegra/tegra30_ahub.h b/sound/soc/tegra/tegra30_ahub.h index e690e2e..7189be9 100644 --- a/sound/soc/tegra/tegra30_ahub.h +++ b/sound/soc/tegra/tegra30_ahub.h @@ -468,7 +468,23 @@ extern int tegra30_ahub_set_rx_cif_source(enum tegra30_ahub_rxcif rxcif, enum tegra30_ahub_txcif txcif); extern int tegra30_ahub_unset_rx_cif_source(enum tegra30_ahub_rxcif rxcif); +struct tegra30_ahub_soc_data { + u32 clk_list_mask; + /* + * FIXME: There are many more differences in HW, such as: + * - More APBIF channels. + * - Extra separate chunks of register address space to represent + * the extra APBIF channels. + * - More units connected to the AHUB, so that tegra30_ahub_[rt]xcif + * need expansion, coupled with there being more defined bits in + * the AHUB routing registers. + * However, the driver doesn't support those new features yet, so we + * don't represent them here yet. + */ +}; + struct tegra30_ahub { + const struct tegra30_ahub_soc_data *soc_data; struct device *dev; struct clk *clk_d_audio; struct clk *clk_apbif; -- 1.7.10.4

2 4

[alsa-devel] [PATCH] ASoC: imx-sgtl5000: use of_node to match cpu dai
by Shawn Guo 25 Mar '13

25 Mar '13

Since imx-sgtl5000 is only used on DT platform, it makes more sense to use cpu_of_node rather than cpu_dai_name to match cpu dai. Signed-off-by: Shawn Guo <shawn.guo(a)linaro.org> --- sound/soc/fsl/imx-sgtl5000.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/fsl/imx-sgtl5000.c b/sound/soc/fsl/imx-sgtl5000.c index 424347e..9584e78 100644 --- a/sound/soc/fsl/imx-sgtl5000.c +++ b/sound/soc/fsl/imx-sgtl5000.c @@ -148,7 +148,7 @@ static int imx_sgtl5000_probe(struct platform_device *pdev) data->dai.stream_name = "HiFi"; data->dai.codec_dai_name = "sgtl5000"; data->dai.codec_of_node = codec_np; - data->dai.cpu_dai_name = dev_name(&ssi_pdev->dev); + data->dai.cpu_of_node = ssi_np; data->dai.platform_name = "imx-pcm-audio"; data->dai.init = &imx_sgtl5000_dai_init; data->dai.dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF | -- 1.7.9.5

2 1

Re: [alsa-devel] [Alsa-user] Audio-gd NFB-17.32 (VIA VT1731)
by Torstein Hegge 25 Mar '13

25 Mar '13

On Mon, Mar 25, 2013 at 08:38:16 +0100, Clemens Ladisch wrote: > Torstein Hegge wrote: > > I think we can conclude that the VIA VT1731 has the same issue as the > > C-Media CM6631. > > > > I'll add the VT1731 as one of the devices that needs a reset after > > sample rate change in the next iteration of the sample rate workaround > > patch. > > Why not just do it for all UAC 2 devices? If new devices that needs this just keeps popping up, that might indeed be the better solution. Torstein

1 0

[alsa-devel] No dmix/dsnoop on Intel ICH4/5 by default?
by Rene Herman 24 Mar '13

24 Mar '13

Good day. I'm out of touch of with alsa -- but should dmix/dsnoop still be enabled by default on hardware that doesn't do hardware mixing? It seems it isn't on my Intel ICH4: $ cat /proc/asound/cards 0 [ICH5 ]: ICH4 - Intel ICH5 Intel ICH5 with AD1980 at irq 17 1 [SAA7134 ]: SAA7134 - SAA7134 saa7134[0] at 0xe8200000 irq 22 I believe that it should be from /usr/share/alsa/cards/ICH4.conf, but I don't get mixing on this setup when using the "default" pcm... (which I may not mind at that much, but I was looking at some other sound-related problem and this has me rather confused) This is arch linux, with alsa-lib, -plugins and -utils 1.0.26 installed, using kernel 3.6.11-1-ARCH (ie, standard). Regards, Rene

4 11

[alsa-devel] [PATCH v4] ALSA: usb: Work around CM6631 sample rate change bug
by Torstein Hegge 24 Mar '13

24 Mar '13

The C-Media CM6631 USB-to-S/PDIF receiver doesn't respond to changes in sample rate while the interface is active. Reset the interface after setting the sampling frequency on sample rate changes, to ensure that the sample rate set by snd_usb_init_sample_rate() is used. Otherwise, the device will try to use the sample rate of the previous stream, causing distorted sound on sample rate changes. The reset is performed for all current C-Media UAC V2.0 devices, including CM6610, CM6620 and CM6631, but has only been tested with CM6631. Signed-off-by: Torstein Hegge <hegge(a)resisty.net> --- Changes since v3: - Use given target rate instead of the new rate read from device when checking if a reset is needed. Some devices (at least Schiit Bifrost) doesn't report a reliable sample rate back right after setting a new rate. This appears to fix the issues with v3 of this patch with the Schiit, as reported by Chris Hermansen in http://thread.gmane.org/gmane.linux.alsa.user/36935/focus=37284 Changes since v2: - More USB ids covered. - int crate -> int cur_rate - unsigned int previous_rate -> int prev_rate sound/usb/clock.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 46 insertions(+), 4 deletions(-) diff --git a/sound/usb/clock.c b/sound/usb/clock.c index 5e634a2..60c2775 100644 --- a/sound/usb/clock.c +++ b/sound/usb/clock.c @@ -253,7 +253,7 @@ static int set_sample_rate_v2(struct snd_usb_audio *chip, int iface, { struct usb_device *dev = chip->dev; unsigned char data[4]; - int err, crate; + int err, cur_rate, prev_rate; int clock = snd_usb_clock_find_source(chip, fmt->clock); if (clock < 0) @@ -266,6 +266,18 @@ static int set_sample_rate_v2(struct snd_usb_audio *chip, int iface, return -ENXIO; } + if ((err = snd_usb_ctl_msg(dev, usb_rcvctrlpipe(dev, 0), UAC2_CS_CUR, + USB_TYPE_CLASS | USB_RECIP_INTERFACE | USB_DIR_IN, + UAC2_CS_CONTROL_SAM_FREQ << 8, + snd_usb_ctrl_intf(chip) | (clock << 8), + data, sizeof(data))) < 0) { + snd_printk(KERN_WARNING "%d:%d:%d: cannot get freq (v2)\n", + dev->devnum, iface, fmt->altsetting); + return err; + } + + prev_rate = data[0] | (data[1] << 8) | (data[2] << 16) | (data[3] << 24); + data[0] = rate; data[1] = rate >> 8; data[2] = rate >> 16; @@ -290,9 +302,39 @@ static int set_sample_rate_v2(struct snd_usb_audio *chip, int iface, return err; } - crate = data[0] | (data[1] << 8) | (data[2] << 16) | (data[3] << 24); - if (crate != rate) - snd_printd(KERN_WARNING "current rate %d is different from the runtime rate %d\n", crate, rate); + cur_rate = data[0] | (data[1] << 8) | (data[2] << 16) | (data[3] << 24); + if (cur_rate != rate) { + snd_printd(KERN_WARNING + "current rate %d is different from the runtime rate %d\n", + cur_rate, rate); + } + + /* Some devices doesn't respond to sample rate changes while the + * interface is active. */ + if (rate != prev_rate) { + switch (chip->usb_id) { + /* C-Media CM6610/CM6620/CM6631 */ + case USB_ID(0x054c, 0x06cf): /* Sony */ + case USB_ID(0x0b05, 0x17a8): /* Asus Xonar Essence One */ + case USB_ID(0x0d8c, 0x0301): + case USB_ID(0x0d8c, 0x0302): + case USB_ID(0x0d8c, 0x0304): /* CM6631 (Schiit) */ + case USB_ID(0x0d8c, 0x0305): + case USB_ID(0x0d8c, 0x0306): + case USB_ID(0x0d8c, 0x0309): /* CM6631 */ + case USB_ID(0x0d8c, 0x0310): + case USB_ID(0x0d8c, 0x0311): /* CM6610A */ + case USB_ID(0x0d8c, 0x0312): /* CM6620A */ + case USB_ID(0x0d8c, 0x0313): /* CM6630A */ + case USB_ID(0x0d8c, 0x0314): /* CM6631A */ + case USB_ID(0x0d8c, 0x0315): /* CM6632A */ + case USB_ID(0x0d8c, 0x0319): /* CM6631A */ + case USB_ID(0x200c, 0x1030): /* Reloop */ + usb_set_interface(dev, iface, 0); + usb_set_interface(dev, iface, fmt->altsetting); + break; + } + } return 0; } -- 1.7.10.4

2 2

Re: [alsa-devel] [PATCH 0/3] ALSA: snd-usb: Some small fixes to make Playback Design products work
by Jussi Laako 23 Mar '13

23 Mar '13

On 03/22/2013 06:05 PM, Andreas Koch wrote: > The 8-bit raw format is for 2.8MHz DSD and the 16-bit format is for > 5.6MHz DSD. In both cases the driver sets the sample rate to 352.8kHz on > the DAC, I see, this is different from how I've been dealing with it. Since I always use uint8 format, but instead vary the rate to 352.8/705.6/etc... Just because it's much more straightforward form the application's perspective -> output rate is always bit rate divided by eight (=packet rate). And switch between uint8 / uint32 sample format equals to switch between DSD <-> PCM. - Jussi

1 0

[alsa-devel] [PATCH 0/3] ALSA: snd-usb: Some small fixes to make Playback Design products work
by Daniel Mack 23 Mar '13

23 Mar '13

Thanks to Andreas, I got my hands on a Playback Design MPD-3 and hacked up some small hanges necessary to make it fully work with snd-usb. The device reports 0x80000000 in the bmFormats field of two of three of its alternate settings, which wrongly made the driver believe it's a usual PCM endpoint (actually due to a fix-up fallback). However, bit 31 of this mask in fact denotes 'raw data'. The effect of this issue is that in addition to the first altsetting with a bit depth of 24, the driver exposed 8-bit and 16-bit native audio formats on the raw data endpoints, which do not work as expected. Also, those devices need a 50ms delay after switching the USB interface. Thanks, Daniel Daniel Mack (3): ALSA: snd-usb: handle the bmFormats field as unsigned int ALSA: snd-usb: handle raw data format of UAC2 devices ALSA: snd-usb: add delay quirk for "Playback Design" products include/linux/usb/audio-v2.h | 2 ++ sound/usb/format.c | 20 ++++++++++++-------- sound/usb/format.h | 2 +- sound/usb/pcm.c | 7 +++++++ sound/usb/stream.c | 2 +- 5 files changed, 23 insertions(+), 10 deletions(-) -- 1.7.10.4

4 16

Re: [alsa-devel] Support for DSD streams
by Daniel Mack 23 Mar '13

23 Mar '13

Hi Andreas, On 23.03.2013 18:35, Andreas Koch wrote: >> Yes, understood. The thing is just that we shouldn't break exising >> solutions that already rely on this "bandaid". > > You wouldn't break any existing solution based on DoP, because that > solution is dealt with in the application on one side and the DAC on > the other side. The driver and USB transfer both think it is PCM data > that is being sent. Well, that was exactly the problem with your device. With the driver as it was, it exposed a PCM interface which is 16-bit wide, and that was picked by ALSA when playing 16-bit material (because ALSA takes whatever is offered by the hardware natively). > The applications have a preference setting to > select DoP and likewise the DAC's constantly monitor the PCM > formatted data stream and automatically switch to DSD if they find > the pattern. Hmm, but your device behaves differently here, right? At least, when normal PCM material is sent to the DSD interface, it doesn't play it or switch back or something. And I think other DACs will have similar behaviour. I need to think about all that more deeply next week :) Daniel

1 0

Re: [alsa-devel] ASoC: tegra: Does the PCM_TRIGGER_{PAUSE, RESUME} emulation really work?
by Lars-Peter Clausen 23 Mar '13

23 Mar '13

On 03/23/2013 02:28 PM, Laxman Dewangan wrote: > On Saturday 23 March 2013 06:59 PM, Lars-Peter Clausen wrote: >> On 03/23/2013 02:16 PM, Laxman Dewangan wrote: >>> On Saturday 23 March 2013 05:05 AM, Stephen Warren wrote: >>>> On 03/22/2013 10:26 AM, Lars-Peter Clausen wrote: >>>>> Hi, >>>>> >>>>> The tegra pcm driver tries to emulate SNDRV_PCM_TRIGGER_PAUSE and >>>>> SNDRV_PCM_TRIGGER_RESUME. By passing SNDRV_PCM_TRIGGER_START and >>>>> SNDRV_PCM_TRIGGER_STOP to snd_dmaengine_pcm_trigger. But does this really >>>>> work? The old non-dmaengine based driver implemented this properly. I'd >>>>> reset the dma position pointer for SNDRV_PCM_TRIGGER_START, but keep it >>>>> where it was for SNDRV_PCM_TRIGGER_RESUME. But as far as I can see with >>>>> the >>>>> dmaengine based driver the pointer always gets reset to 0 for both >>>>> SNDRV_PCM_TRIGGER_START and SNDRV_PCM_TRIGGER_RESUME. >>>> It's quite possible this hasn't been tested, or tested recently. I don't >>>> recall how to test PAUSE/RESUME. Can you enlighten me? >>>> >>>> Laxman, can you comment here? >>> The tegra20/Tegra30 does not support the pause of the channel. It was >>> through global pause. hence the pause and resume is implemented like stop >>> transfer and again restart transfer. hence you are seeing this as the reset >>> pointer as 0. >>> >> Yea, but in that case you shouldn't implement pause/resume at all. You've >> changed the semantics on pause/resume on which applications rely. If >> pause/resume are not implemented applications usually workaround it. >> >> - Lars >> > > So should we return -EINVAL in case of following? > > case SNDRV_PCM_TRIGGER_RESUME: > case SNDRV_PCM_TRIGGER_PAUSE_PUSH: > Don't set the SNDRV_PCM_INFO_PAUSE and SNDRV_PCM_INFO_RESUME bits in the pcm_hardware struct and use snd_dmaengine_pcm_trigger as your trigger callback. The ALSA core will take care of everything else. - Lars

1 0

Re: [alsa-devel] ASoC: tegra: Does the PCM_TRIGGER_{PAUSE, RESUME} emulation really work?
by Lars-Peter Clausen 23 Mar '13

23 Mar '13

On 03/23/2013 02:16 PM, Laxman Dewangan wrote: > On Saturday 23 March 2013 05:05 AM, Stephen Warren wrote: >> On 03/22/2013 10:26 AM, Lars-Peter Clausen wrote: >>> Hi, >>> >>> The tegra pcm driver tries to emulate SNDRV_PCM_TRIGGER_PAUSE and >>> SNDRV_PCM_TRIGGER_RESUME. By passing SNDRV_PCM_TRIGGER_START and >>> SNDRV_PCM_TRIGGER_STOP to snd_dmaengine_pcm_trigger. But does this really >>> work? The old non-dmaengine based driver implemented this properly. I'd >>> reset the dma position pointer for SNDRV_PCM_TRIGGER_START, but keep it >>> where it was for SNDRV_PCM_TRIGGER_RESUME. But as far as I can see with the >>> dmaengine based driver the pointer always gets reset to 0 for both >>> SNDRV_PCM_TRIGGER_START and SNDRV_PCM_TRIGGER_RESUME. >> It's quite possible this hasn't been tested, or tested recently. I don't >> recall how to test PAUSE/RESUME. Can you enlighten me? >> >> Laxman, can you comment here? > The tegra20/Tegra30 does not support the pause of the channel. It was > through global pause. hence the pause and resume is implemented like stop > transfer and again restart transfer. hence you are seeing this as the reset > pointer as 0. > Yea, but in that case you shouldn't implement pause/resume at all. You've changed the semantics on pause/resume on which applications rely. If pause/resume are not implemented applications usually workaround it. - Lars > So pause is stop and resume is the start again. > > If it is require to implement the dmaengine_pause/resume() then it can not > be done truely, it can be done atelast in resolution of one buffer transfer. > We can not stop dma in mid of buffer transfer and start from there. We can > do cancel of current buffer transfer and then start from begining of current > buffer, not from the point it was paused. > > However, tegra114 support this pause and resume truely.

1 0