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

[alsa-devel] [PATCH v2 0/3] Support more sample rates, let the rates normal work
by Caesar Wang 06 Nov '15

06 Nov '15

That's seem the moment rockchip-codec driver other than 44100 and 48000 do not work. Says the (max98090, rt5640). ---- As the chromeos reported issue:(https://chromium.googlesource.com/chromiumos/third_party/kernel/+/v3… For detail: In that bug we want to add 32000 to sound/soc/rockchip/rockchip_max98090.c rk_aif1_hw_params. However that does not work. Previously, in https://chromium-review.googlesource.com/#/c/268398/ , rate 8000, 1600, 96000 were added. However, those rates do not work. I got the same audio as 48000 when I run aplay -D hw:0,0 /usr/local/autotest/cros/audio/fix_440_16_half.raw --rate 8000 -f S16_LE -c2 aplay -D hw:0,0 /usr/local/autotest/cros/audio/fix_440_16_half.raw --rate 16000 -f S16_LE -c2 aplay -D hw:0,0 /usr/local/autotest/cros/audio/fix_440_16_half.raw --rate 96000 -f S16_LE -c2 They all sound identical to aplay -D hw:0,0 /usr/local/autotest/cros/audio/fix_440_16_half.raw --rate 48000 -f S16_LE -c2 Also, recording using aplay -D hw:0,0 /usr/local/test.raw --rate 96000 -f S16_LE -c2 and examine the output we see it was recording using 48000. Okay, let's add this series patchs to fix this issue. arecord -D hw:0 -f S16_LE -c 2 --rate [8000-96000] -d 5 foobar.wav and aplay -D hw:0 foobar.wav Tested on veyron devices. Changes in v2: - move the set clock divider into rockchip i2s. - add the 64000 sample rates for max98090. - add the 64000 sample rate for rt5645. Caesar Wang (3): ASoC: rockchip: i2s: change bclk and lrck according to sample rates ASoC: rockchip-max98090: Allow more sample rates ASoC: rockchip-rt5645: Allow more sample rates sound/soc/rockchip/rockchip_i2s.c | 23 +++++++++++++++++++++++ sound/soc/rockchip/rockchip_max98090.c | 6 ++++++ sound/soc/rockchip/rockchip_rt5645.c | 6 ++++++ 3 files changed, 35 insertions(+) -- 1.9.1

2 5

[alsa-devel] [PATCH] ASoC: rsnd: fixup SCU_SYS_INT_EN1 address
by Kuninori Morimoto 06 Nov '15

06 Nov '15

From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> cfcefe0126 ("ASoC: rsnd: add recovery support for under/over flow error on SRC") added SCU_SYS_INT_EN1 address, but it should be 0x1d4, not 0x1c4. This patch fixup it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> --- sound/soc/sh/rcar/gen.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/sh/rcar/gen.c b/sound/soc/sh/rcar/gen.c index 84f8bb2..988c5d0 100644 --- a/sound/soc/sh/rcar/gen.c +++ b/sound/soc/sh/rcar/gen.c @@ -234,7 +234,7 @@ static int rsnd_gen2_probe(struct rsnd_priv *priv) RSND_GEN_S_REG(SCU_SYS_STATUS0, 0x1c8), RSND_GEN_S_REG(SCU_SYS_INT_EN0, 0x1cc), RSND_GEN_S_REG(SCU_SYS_STATUS1, 0x1d0), - RSND_GEN_S_REG(SCU_SYS_INT_EN1, 0x1c4), + RSND_GEN_S_REG(SCU_SYS_INT_EN1, 0x1d4), RSND_GEN_M_REG(SRC_SWRSR, 0x200, 0x40), RSND_GEN_M_REG(SRC_SRCIR, 0x204, 0x40), RSND_GEN_M_REG(SRC_ADINR, 0x214, 0x40), -- 1.9.1

2 1

[alsa-devel] [PATCH 0/2] ASoC: Add support for DA7217 and DA7218 audio codecs
by Adam Thomson 06 Nov '15

06 Nov '15

This patch set adds DT and ASoC codec driver support for DA7217 and DA7218. Changes are based against v4.3 kernel version. Adam Thomson (2): ASoC: da7218: Add bindings documentation for DA7218 audio codec ASoC: codecs: Add da7218 codec driver Documentation/devicetree/bindings/sound/da7218.txt | 116 + include/sound/da7218.h | 136 + sound/soc/codecs/da7218.c | 3349 ++++++++++++++++++++ sound/soc/codecs/da7218.h | 1405 ++++++++ 4 files changed, 5006 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/da7218.txt create mode 100644 include/sound/da7218.h create mode 100644 sound/soc/codecs/da7218.c create mode 100644 sound/soc/codecs/da7218.h -- 1.9.3

3 4

[alsa-devel] [PATCH v2] mfd: arizona: Add DT binding for irq-gpios property
by Sebastien Jan 06 Nov '15

06 Nov '15

Signed-off-by: Sebastien Jan <sjan(a)baylibre.com> --- Documentation/devicetree/bindings/mfd/arizona.txt | 2 ++ drivers/mfd/arizona-core.c | 5 +++++ 2 files changed, 7 insertions(+) diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt b/Documentation/devicetree/bindings/mfd/arizona.txt index a8fee60..f9405ad 100644 --- a/Documentation/devicetree/bindings/mfd/arizona.txt +++ b/Documentation/devicetree/bindings/mfd/arizona.txt @@ -46,6 +46,8 @@ Optional properties: - wlf,reset : GPIO specifier for the GPIO controlling /RESET - wlf,ldoena : GPIO specifier for the GPIO controlling LDOENA + - irq-gpios : GPIO specifier for the GPIO connected to /IRQ + - wlf,gpio-defaults : A list of GPIO configuration register values. Defines for the appropriate values can found in <dt-bindings/mfd/arizona.txt>. If absent, no configuration of these registers is performed. If any entry has diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c index 44cfdbb..2046617 100644 --- a/drivers/mfd/arizona-core.c +++ b/drivers/mfd/arizona-core.c @@ -814,6 +814,11 @@ static int arizona_of_get_core_pdata(struct arizona *arizona) count++; } + arizona->pdata.irq_gpio = of_get_named_gpio(arizona->dev->of_node, + "irq-gpios", 0); + if (arizona->pdata.irq_gpio < 0) + arizona->pdata.irq_gpio = 0; + return 0; } -- 1.9.1

4 4

Re: [alsa-devel] [PATCH v1 1/5] ASoC: rockchip: i2s: Support to set the divider clock API
by Mark Brown 06 Nov '15

06 Nov '15

On Thu, Nov 05, 2015 at 01:56:39PM +0800, Caesar Wang wrote: > 在 2015年11月04日 22:34, Mark Brown 写道: > >Same thing as your other very similar patch: why does this feature > >require set_clkdiv()? > Okay, you said " > Why is this a requirement? The clock to use as a source should normally > be specified via set_sysclk() and any internal dividers calculated > automatically by the driver. > " > I think we should divider settings for these different sample rates. Sure, the question is how these things get set. > If the codec is master mode, we are *not* need this operate. > If the codec is slave mode, we are need to divider the MCLK to setting the different sample rates. > (for example, the sample rates (8k, 48k) the clock is MCLK, the clock should be divider cpu ip ) > "dividers calculated automatically by the driver", that should be occured by codec(max98090 > ) driver, but the divider clocks (LRCK, SCLK) should need to set for cpu internal side. So the CPU knows what rates it needs to set and what clocks it's getting in, why can't it set the dividers autonomously.

2 1

Re: [alsa-devel] Intel Cherry Trail platform sound issue
by Zhihe Tu 06 Nov '15

06 Nov '15

Can anyone give some suggestions? Thanks Tu 发件人: 涂治河 [mailto:tuzhihe@pcasl.com] 发送时间: 2015年11月5日 19:37 收件人: 'alsa-devel(a)alsa-project.org' 主题: Intel Cherry Trail platform sound issue Hi All, I get cherry trail tablet, and install ubuntu14.04.3, Kernel verison is 3.19. The table using rt5672 codec with no sound output in ubuntu, but it works in win8. I get intel sst firmware fw_sst_22a8.bin from https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tr… The driver load the firmware successfully and I change some alsa mixer items: amixer -c0 sset 'codec_out0 mix 0 pcm0_in' on amixer -c0 sset 'media0_out mix 0 media1_in' on amixer -c0 sset 'media1_in Gain 0' 80% amixer -c0 sset 'media1_in Gain 0 Ramp Delay' 50 amixer -c0 sset 'media1_in Gain 0' off amixer -c0 sset 'pcm0_in Gain 0' 80% amixer -c0 sset 'pcm0_in Gain 0 Ramp Delay' 50 amixer -c0 sset 'pcm0_in Gain 0' off amixer -c0 sset 'codec_out0 Gain 0' 80% amixer -c0 sset 'codec_out0 Gain 0 Ramp Delay' 50 amixer -c0 sset 'codec_out0 Gain 0' off But there are some errors with dmesg: [ 16.359646] Audio Port: ASoC: no backend DAIs enabled for Audio Port … [ 16.382156] sst-mfld-platform sst-mfld-platform: Enter: enable=0 port_name=ssp2-port [ 16.383984] sst-mfld-platform sst-mfld-platform: Enter: enable=1 port_name=ssp2-port [ 16.541809] intel_sst_acpi 808622A8:00: Alloc for str 1 pipe 0x90 [ 17.545512] intel_sst_acpi 808622A8:00: Wait timed-out condition:0x0, msg_id:0x1 fw_state 0x2 [ 17.555207] intel_sst_acpi 808622A8:00: fw returned err -16 [ 18.605859] intel_sst_acpi 808622A8:00: Wait timed-out condition:0x0, msg_id:0x1 fw_state 0x3 [ 18.615908] intel_sst_acpi 808622A8:00: fw returned err -16 [ 19.621943] intel_sst_acpi 808622A8:00: Wait timed-out condition:0x0, msg_id:0x2 fw_state 0x3 [ 19.631499] intel_sst_acpi 808622A8:00: fw returned err -16 [ 20.637527] intel_sst_acpi 808622A8:00: Wait timed-out condition:0x0, msg_id:0x2 fw_state 0x3 [ 20.647083] intel_sst_acpi 808622A8:00: fw returned err -16 [ 20.682979] sst-mfld-platform sst-mfld-platform: Enter: enable=0 port_name=ssp2-port [ 21.681280] intel_sst_acpi 808622A8:00: Wait timed-out condition:0x0, msg_id:0x2 fw_state 0x3 [ 21.690836] intel_sst_acpi 808622A8:00: fw returned err -16 [ 21.697087] intel_sst_acpi 808622A8:00: free stream returned err -19 [ 22.757082] intel_sst_acpi 808622A8:00: Wait timed-out condition:0x0, msg_id:0x1 fw_state 0x3 [ 22.766640] intel_sst_acpi 808622A8:00: fw returned err -16 [ 23.772867] intel_sst_acpi 808622A8:00: Wait timed-out condition:0x0, msg_id:0x1 fw_state 0x3 [ 23.782432] intel_sst_acpi 808622A8:00: fw returned err -16 [ 23.857938] sst-mfld-platform sst-mfld-platform: Enter: enable=1 port_name=ssp2-port [ 23.989254] intel_sst_acpi 808622A8:00: Alloc for str 1 pipe 0x90 [ 23.989491] intel_sst_acpi 808622A8:00: FW sent error response 0x40034 [ 23.996864] intel_sst_acpi 808622A8:00: FW alloc failed ret -4 [ 24.003399] intel_sst_acpi 808622A8:00: sst_get_stream returned err -5 [ 24.010737] sst-mfld-platform sst-mfld-platform: ASoC: DAI prepare error: -5 [ 24.018652] Audio Port: ASoC: prepare FE Audio Port failed [ 25.024622] intel_sst_acpi 808622A8:00: Wait timed-out condition:0x0, msg_id:0x1 fw_state 0x3 [ 25.034180] intel_sst_acpi 808622A8:00: fw returned err -16 [ 26.040399] intel_sst_acpi 808622A8:00: Wait timed-out condition:0x0, msg_id:0x1 fw_state 0x3 [ 26.049955] intel_sst_acpi 808622A8:00: fw returned err -16 [ 27.056333] intel_sst_acpi 808622A8:00: Wait timed-out condition:0x0, msg_id:0x2 fw_state 0x3 [ 27.065890] intel_sst_acpi 808622A8:00: fw returned err -16 [ 28.072032] intel_sst_acpi 808622A8:00: Wait timed-out condition:0x0, msg_id:0x2 fw_state 0x3 [ 28.081591] intel_sst_acpi 808622A8:00: fw returned err -16 [ 28.117427] Audio Port: sst: error code = -22 [ 28.122401] snd_pcm_update_hw_ptr0: 120 callbacks suppressed [ 28.122409] cht-bsw-rt5672 cht-bsw-rt5672: BUG: , pos = -22, buffer size = 96000, period size = 48000 [ 28.132784] Audio Port: sst: error code = -22 [ 28.137749] cht-bsw-rt5672 cht-bsw-rt5672: BUG: , pos = -22, buffer size = 96000, period size = 48000 [ 28.372967] Audio Port: sst: error code = -22 [ 28.377946] cht-bsw-rt5672 cht-bsw-rt5672: BUG: , pos = -22, buffer size = 96000, period size = 48000 [ 28.388317] Audio Port: sst: error code = -22 [ 28.393289] cht-bsw-rt5672 cht-bsw-rt5672: BUG: , pos = -22, buffer size = 96000, period size = 48000 [ 28.403687] Audio Port: sst: error code = -22 lsmod info: snd_soc_sst_cht_bsw_rt5672 16384 0 snd_intel_sst_acpi 16384 1 snd_intel_sst_core 73728 1 snd_intel_sst_acpi snd_soc_sst_mfld_platform 77824 3 snd_intel_sst_core snd_soc_rt5670 106496 1 snd_soc_rl6231 16384 1 snd_soc_rt5670 snd_soc_core 196608 4 snd_soc_rt5670,snd_soc_sst_cht_bsw_rt5672,snd_soc_sst_mfld_platform snd_seq_midi 16384 0 snd_seq_midi_event 16384 1 snd_seq_midi snd_compress 20480 1 snd_soc_core snd_pcm_dmaengine 16384 1 snd_soc_core snd_rawmidi 32768 1 snd_seq_midi snd_pcm 106496 5 snd_soc_rt5670,snd_soc_core,snd_soc_sst_cht_bsw_rt5672,snd_soc_sst_mfld_platform,snd_pcm_dmaengine snd_seq 65536 2 snd_seq_midi_event,snd_seq_midi snd_seq_device 16384 3 snd_seq,snd_rawmidi,snd_seq_midi snd_timer 32768 2 snd_pcm,snd_seq snd 86016 10 snd_soc_core,snd_timer,snd_pcm,snd_seq,snd_rawmidi,snd_soc_sst_mfld_platform,snd_seq_device,snd_compress soundcore 16384 1 snd I have no idea with the next step, so can anyone give a look? Thanks Tu __________ Information from ESET Smart Security, version of virus signature database 4468 (20090929) __________ The message was checked by ESET Smart Security. http://www.eset.com __________ Information from ESET Smart Security, version of virus signature database 4468 (20090929) __________ The message was checked by ESET Smart Security. http://www.eset.com

1 0

[alsa-devel] Question on USB Audio delay calculations
by Ughreja, Rakesh A 06 Nov '15

06 Nov '15

Hi Takashi, I have a question regarding reporting of the "delay" in the USB audio driver. While starting the endpoint from "prepare" (snd_usb_endpoint_start) for playback operation, it submits empty URBs but it doesn't take them into account for "delay". When the start comes from user, the new URB won't get submitted until the previous one completes, so shouldn't we increment the delay when we submit the empty URBs before the actual start has come, because it does contribute to "delay". I can submit the patch, if my understanding is right. Regards, Rakesh

1 0

Re: [alsa-devel] fsl_ssi.c: Roberto's problem: ssi hangs after some number of samples
by Caleb Crome 06 Nov '15

06 Nov '15

On Thu, Nov 5, 2015 at 3:48 AM, Roberto Fichera <kernel(a)tekno-soft.it> wrote: > On 11/05/2015 12:30 PM, Fabio Estevam wrote: >> On Thu, Nov 5, 2015 at 8:03 AM, Roberto Fichera <kernel(a)tekno-soft.it> wrote: >> >>> Following your suggestion, I've increased the buffer size to 2K and set the period to fifo_length - 2 (13), >>> with that I'm now running substantially smooth except 3 EVTERR on RX DMA over 4 million of interrupts. >>> >>> Thanks Nicolin! I'm quite happy now! >> That's good progress, Roberto. >> >> It would be nice if you and Caleb could post the patches to the mailing list. >> Yes, when I get something quite solid, I'd like to submit it all to the list, and hope to get it into the kernel so nobody else has to go through this pain again. > > Indeed! Now the TDM is stable, I've also found the reason of the EVTERRs, which was related to some stale > code I've used to enable and disable both RDMAE and TDMAE bits to try to reset the transfers. > Once removed that code everything is looks ok now. > > Regarding patches, well, from my side there isn't nothing special compared to the original fsl_ssi.c code. > I'm basically running against a very skinny fsl_ssi.c version, I've just setup a bit larger DMA buffer, from > 16bytes to 2K, and now reduced the DMA period to 8 because I'm mostly comfortable with that size to simplify > sampling exchange against DAHDI subsystem within my DMA callbacks. > > In a few words, my problem was related due to a DMA buffer too small. > > What eventually might be interesting to have is the INTRMASK and EVTERR DMA setting to trigger DMA > related errors, but I guess this need to be discussed elsewhere. I have implemented roberto's patch on the 4.2 kernel, and I get a huge number of EVTERR interrupts. Something like 7200/second at 16kHz sample rate. But strangely, the audio seems to be correct. My patch is slightly different in that it just enables EVTERR for all channels, not just for the SSI. Might as well see if there are any other problems. And it puts the stats file at /sys/kernel/debug/20ec000.sdma/stats When I aplay a file for 10 seconds I get ~366 EVTERR interrupts. When I arecord for 10 seconds, I get 1 EVTERR interrupt When I run my application for 10 seconds, which does full duplex, I get 72703 EVTERR interrupts, but the data integrity checks out okay. Interstingly, when I enable dual fifo, it goes from about 7200 EVTERR's/sec to about 18 EVTERRs/sec. Much better, but still a long way from working perfectly. When I get a 'hang' from my application (no more portaudio callbacks), I'm actually getting repeated calls to sdma_prep_dma_cyclic, though I don't know how that call gets triggered. But once that starts happening, no more audio data gets through. Here is my version of Roberto's patch for reporting the EVTERR on a 4.2 kernel. It includes Dual fifo. The /sys/kernel/debug/20ec000.sdma/stats file is cleared by reading, so it's easy to check how many EVTERRs since the last read of the file. Thanks again for looking at this. -Caleb ---------- Forwarded message ---------- From: Caleb Crome <caleb(a)crome.org> Date: Thu, Nov 5, 2015 at 1:16 PM Subject: [PATCH] DMA: imx-sdma: add reporting of EVTERR DMA errors to fsl dma. To: ccrome(a)gmail.com Cc: Caleb Crome <caleb(a)crome.org> Add roberto's patch to the 4.x kernel for report EVTERR DMA errors in SSI transfers. From userspace, you can see errors in the /sys/kernel/debug/20ec000.sdma/stats file. --- drivers/dma/imx-sdma.c | 113 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 113 insertions(+) diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c index 9d375bc..a3a2317 100644 --- a/drivers/dma/imx-sdma.c +++ b/drivers/dma/imx-sdma.c @@ -38,6 +38,8 @@ #include <linux/of_address.h> #include <linux/of_device.h> #include <linux/of_dma.h> +#include <linux/debugfs.h> +#include <linux/seq_file.h> #include <asm/irq.h> #include <linux/platform_data/dma-imx-sdma.h> @@ -50,6 +52,8 @@ /* SDMA registers */ #define SDMA_H_C0PTR 0x000 +#define SDMACORE_EVENTS 0x005 +#define SDMACORE_EVENTS2 0x01f #define SDMA_H_INTR 0x004 #define SDMA_H_STATSTOP 0x008 #define SDMA_H_START 0x00c @@ -385,6 +389,9 @@ struct sdma_engine { const struct sdma_driver_data *drvdata; u32 spba_start_addr; u32 spba_end_addr; + u32 evterrchannel[MAX_DMA_CHANNELS]; + struct dentry *dbg_dir; + struct dentry *dbg_stats; }; static struct sdma_driver_data sdma_imx31 = { @@ -562,7 +569,19 @@ static int sdma_config_ownership(struct sdma_channel *sdmac, static void sdma_enable_channel(struct sdma_engine *sdma, int channel) { + struct sdma_channel *sdmac = &sdma->channel[channel]; + u32 msk; + writel(BIT(channel), sdma->regs + SDMA_H_START); + /* + * enable EVTERR interrupts on this channel + */ + if ((sdmac->peripheral_type == IMX_DMATYPE_SSI_SP) || + (sdmac->peripheral_type == IMX_DMATYPE_SSI_DUAL)) { + msk = readl(sdma->regs + SDMA_H_INTRMSK); + writel(msk | BIT(channel), sdma->regs + SDMA_H_INTRMSK); + printk(KERN_INFO "%s: enabling EVTERR for channel %d\n", __func__, channel); + } } /* @@ -726,11 +745,25 @@ static irqreturn_t sdma_int_handler(int irq, void *dev_id) struct sdma_engine *sdma = dev_id; unsigned long stat; + long unsigned int evterr; + + /* read the EVTERR register */ + evterr = readl_relaxed(sdma->regs + SDMA_H_EVTERR); + if ( evterr ) + { + int bitnr; + for_each_set_bit(bitnr, &evterr, sizeof(u32) * BITS_PER_BYTE) + sdma->evterrchannel[bitnr]++; + } + stat = readl_relaxed(sdma->regs + SDMA_H_INTR); /* not interested in channel 0 interrupts */ stat &= ~1; writel_relaxed(stat, sdma->regs + SDMA_H_INTR); + /* we are interested only to channels not in error status */ + stat &= ~evterr; + while (stat) { int channel = fls(stat) - 1; struct sdma_channel *sdmac = &sdma->channel[channel]; @@ -904,10 +937,17 @@ static int sdma_disable_channel(struct dma_chan *chan) struct sdma_channel *sdmac = to_sdma_chan(chan); struct sdma_engine *sdma = sdmac->sdma; int channel = sdmac->channel; + u32 msk; writel_relaxed(BIT(channel), sdma->regs + SDMA_H_STATSTOP); sdmac->status = DMA_ERROR; + if ((sdmac->peripheral_type == IMX_DMATYPE_SSI_SP) || + (sdmac->peripheral_type == IMX_DMATYPE_SSI_DUAL)) { + msk = readl(sdma->regs + SDMA_H_INTRMSK); + writel(msk & ~(BIT(channel)), sdma->regs + SDMA_H_INTRMSK); + } + return 0; } @@ -1166,6 +1206,8 @@ static struct dma_async_tx_descriptor *sdma_prep_slave_sg( dev_dbg(sdma->dev, "setting up %d entries for channel %d.\n", sg_len, channel); + printk(KERN_INFO "setting up %d entries for channel %d.\n", + sg_len, channel); sdmac->direction = direction; ret = sdma_load_context(sdmac); @@ -1259,6 +1301,8 @@ static struct dma_async_tx_descriptor *sdma_prep_dma_cyclic( dev_dbg(sdma->dev, "%s channel: %d\n", __func__, channel); + printk(KERN_INFO "%s channel: %d, periods = %d\n", __func__, channel, num_periods); + printk(KERN_INFO "buf_len = %d, period_len = %d\n", buf_len, period_len); if (sdmac->status == DMA_IN_PROGRESS) return NULL; @@ -1650,6 +1694,71 @@ static struct dma_chan *sdma_xlate(struct of_phandle_args *dma_spec, return dma_request_channel(mask, sdma_filter_fn, &data); } +#define SDMA_SHOW_REG(reg) \ + do { \ + u32 _val = readl(sdma->regs + reg); \ + seq_printf(s, "\t" #reg "=0x%08x\n", _val); \ + } while (0) + +static int sdma_show_chan_status(struct seq_file *s, void *unused) +{ + struct sdma_engine *sdma = s->private; + // struct dma_chan *chan = (struct dma_chan *)priv; + //struct sdma_channel *sdmac = to_sdma_chan(chan); + //struct sdma_engine *sdma = sdmac->sdma; + int i; + + //seq_printf(s, "SDMA channel %d status\n", sdmac->channel); + SDMA_SHOW_REG(SDMA_H_STATSTOP); + SDMA_SHOW_REG(SDMA_H_START); + SDMA_SHOW_REG(SDMA_H_EVTOVR); + SDMA_SHOW_REG(SDMA_H_EVTPEND); + SDMA_SHOW_REG(SDMA_H_EVTERR); + SDMA_SHOW_REG(SDMA_H_DSPOVR); + SDMA_SHOW_REG(SDMA_H_HOSTOVR); + SDMA_SHOW_REG(SDMA_H_INTR); + SDMA_SHOW_REG(SDMA_H_INTRMSK); + SDMA_SHOW_REG(SDMACORE_EVENTS); + SDMA_SHOW_REG(SDMACORE_EVENTS2); + + seq_printf(s, "\nSDMA EVTERR channel counters:\n"); + for(i=0; i < MAX_DMA_CHANNELS; i++) + if (sdma->evterrchannel[i]) { + seq_printf(s, "\t%03d = %u\n", i, sdma->evterrchannel[i]); + sdma->evterrchannel[i] = 0; + } + + return 0; +} + +static int fsl_sdma_stats_open(struct inode *inode, struct file *file) +{ + return single_open(file, sdma_show_chan_status, inode->i_private); +} + +static const struct file_operations fsl_sdma_stats_ops = { + .open = fsl_sdma_stats_open, + .read = seq_read, + .llseek = seq_lseek, + .release = single_release, +}; + +int fsl_sdma_debugfs_create(struct sdma_engine *sdma, struct device *dev) +{ + sdma->dbg_dir = debugfs_create_dir(dev_name(dev), NULL); + if (!sdma->dbg_dir) + return -ENOMEM; + + sdma->dbg_stats = debugfs_create_file("stats", S_IRUGO, + sdma->dbg_dir, sdma, &fsl_sdma_stats_ops); + if (!sdma->dbg_stats) { + debugfs_remove(sdma->dbg_dir); + return -ENOMEM; + } + return 0; +} + + static int sdma_probe(struct platform_device *pdev) { const struct of_device_id *of_id = @@ -1785,6 +1894,10 @@ static int sdma_probe(struct platform_device *pdev) } } + ret = fsl_sdma_debugfs_create(sdma, &pdev->dev); + if (ret) + goto err_init; + sdma->dma_device.dev = &pdev->dev; sdma->dma_device.device_alloc_chan_resources = sdma_alloc_chan_resources; -- 2.1.4

2 10

Re: [alsa-devel] [PATCH V2] Intel device IDs Audio
by Takashi Iwai 05 Nov '15

05 Nov '15

On Thu, 05 Nov 2015 20:51:52 +0100, Alexandra Yates wrote: > > Takashi, > > On 11/05/2015 02:29 AM, Takashi Iwai wrote: > > On Thu, 05 Nov 2015 00:56:09 +0100, > > Alexandra Yates wrote: > >> > >> Adding Intel codename Lewisburg platform device IDs for audio. > >> > >> Signed-off-by: Alexandra Yates <alexandra.yates(a)linux.intel.com> > > > > Thanks. Though, I still believe the position after Wellsburg is best > > (which is the similar chip that has the same driver type and driver > > caps bits), so I rearranged it. Also the subject was aligned. > > And last but not least, Cc to stable was added. > > > > Thank you for your review and making the additional changes. I'll keep > your methodology for future reference. > > Is this mean that the patch was accepted upstream? Yes :) Takashi > > > > Takashi > > > >> --- > >> sound/pci/hda/hda_intel.c | 5 +++++ > >> 1 file changed, 5 insertions(+) > >> > >> diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c > >> index c38c68f..e8d1151 100644 > >> --- a/sound/pci/hda/hda_intel.c > >> +++ b/sound/pci/hda/hda_intel.c > >> @@ -2168,6 +2168,11 @@ static const struct pci_device_id azx_ids[] = { > >> /* ICH10 */ > >> { PCI_DEVICE(0x8086, 0x3a6e), > >> .driver_data = AZX_DRIVER_ICH | AZX_DCAPS_INTEL_ICH }, > >> + /* Lewisburg */ > >> + { PCI_DEVICE(0x8086, 0xa1f0), > >> + .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH }, > >> + { PCI_DEVICE(0x8086, 0xa270), > >> + .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH }, > >> /* Generic Intel */ > >> { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_ANY_ID), > >> .class = PCI_CLASS_MULTIMEDIA_HD_AUDIO << 8, > >> -- > >> 1.9.1 > >> > >> > > -- > Thank you, > <Alexandra> >

1 0

[alsa-devel] [PATCH v2 0/6] ASoC: Intel: Skylake: fixes and commonize machine creation
by Vinod Koul 05 Nov '15

05 Nov '15

Hi, This is second attempt to fix the SKL machine creation. So I ended up moving the match code from common and atom driver into a common routine used by these and added SKl on top of it. Also fixed passing fw name from machine table This also contains resource cleanup fix for skl driver (1st patch) Vinod Koul (6): ASoC: Intel: Skylake: Fix resource cleanup on teardown ASoC: Intel: Move apci find machine routines ASoC: Intel: Atom: move atom driver to common acpi match ASoC: Intel: Skylake: Fix skl machine driver creation ASoC: Intel: add fw name to common dsp context ASoC: Intel: Skylake: Use the fw name from ACPI mach table sound/soc/intel/Kconfig | 1 + sound/soc/intel/atom/sst/sst_acpi.c | 67 ++++++++++----------------------- sound/soc/intel/common/Makefile | 3 +- sound/soc/intel/common/sst-acpi.c | 41 +++----------------- sound/soc/intel/common/sst-acpi.h | 33 ++++++++++++++++ sound/soc/intel/common/sst-dsp-priv.h | 2 + sound/soc/intel/common/sst-match-acpi.c | 43 +++++++++++++++++++++ sound/soc/intel/skylake/skl-messages.c | 2 +- sound/soc/intel/skylake/skl-sst-dsp.h | 3 +- sound/soc/intel/skylake/skl-sst.c | 5 ++- sound/soc/intel/skylake/skl-topology.c | 2 +- sound/soc/intel/skylake/skl.c | 56 ++++++++++++++++++++++++++- sound/soc/intel/skylake/skl.h | 3 ++ 13 files changed, 168 insertions(+), 93 deletions(-) create mode 100644 sound/soc/intel/common/sst-acpi.h create mode 100644 sound/soc/intel/common/sst-match-acpi.c -- 1.9.1

2 12