lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 5 Jul 2013 09:25:08 +0800
From:	Bo Shen <voice.shen@...el.com>
To:	Richard Genoud <richard.genoud@...il.com>
CC:	<devicetree-discuss@...ts.ozlabs.org>,
	Nicolas Ferre <nicolas.ferre@...el.com>,
	<linux-kernel@...r.kernel.org>,
	<linux-arm-kernel@...ts.infradead.org>,
	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>
Subject: Re: [RFC PATCH 01/13] misc: atmel_ssc: add device tree DMA support

Hi Richard,

On 7/4/2013 21:44, Richard Genoud wrote:
> 2013/7/4 Bo Shen <voice.shen@...el.com>:
>> Hi Richard,
>>
>>
>> On 7/3/2013 23:51, Richard Genoud wrote:
>>>>
>>>>> but there's a violent hang (kernel stops, no trace) when I try the
>>>>> record :
>>>>> arecord -v -V stereo -Dplug:default -f cd -t wav -c 2 /tmp/toto.wav
>>>>> last thing I see is :
>>>>> dma dma0chan3: atc_control (3)
>>
>>
>> I don't meet this issue. Playback and recording works well on my side on
>> at91sam9g35ek board.
>>
>>
>>>>> I'll try to trace that.
>>>
>>> I think it's DMA related.
>>> the last thing done by the kernel is:
>>>    i2c i2c-0: i2c_outb: 0x34 A
>>>    i2c i2c-0: i2c_outb: 0x0c A
>>>    i2c i2c-0: i2c_outb: 0x5a A
>>> meaning: enable power on, LINE IN, ADC, OSC, on the WM8731
>>> so, after that, data is comming from the codec to the SSC and then is
>>> handled by the DMA.
>>> there must be something nasty on the DMA bus to hang everything like
>>> that...
>>
>>
>> Will you try i2c without DMA support to test this issue?
>
> Ok, I nailed it !
>
> To be sure we are on the same base, here is what I have done:
> onto next-20130704:
> - your 5 patches:
> ASoC: atmel_ssc_dai: move set dma data to startup callback
> ASoC: atmel_ssc_dai: add error mask define
> ASoC: atmel-pcm-dma: move prepare for dma to dai prepare
> ARM: atmel-ssc: change phybase type to dma_addr_t
> ASoC: atmel-pcm: use generic dmaengine framework
> - my patches 4-8:
> ARM: at91: DTS: sam9x5: add SSC DMA parameters
> ARM: AT91: DTS: sam9x5ek: add WM8731 codec
> ARM: AT91: DTS: sam9x5ek: add sound configuration
> ARM: AT91: DTS: sam9x5ek: enable SSC
> sound: sam9x5_wm8731: machine driver for at91sam9x5 wm8731 boards
>
> To be sure that dma-I2c doesn't disturb something, I use i2c gpio bitbang:
> diff --git a/arch/arm/boot/dts/at91sam9x5ek.dtsi
> b/arch/arm/boot/dts/at91sam9x5ek.dtsi
> index 6684d4b..53a991e 100644
> --- a/arch/arm/boot/dts/at91sam9x5ek.dtsi
> +++ b/arch/arm/boot/dts/at91sam9x5ek.dtsi
> @@ -57,15 +57,6 @@
>   				status = "okay";
>   			};
>
> -			i2c0: i2c@...10000 {
> -				status = "okay";
> -
> -				wm8731: wm8731@1a {
> -					compatible = "wm8731";
> -					reg = <0x1a>;
> -				};
> -			};
> -
>   			pinctrl@...ff400 {
>   				mmc0 {
>   					pinctrl_board_mmc0: mmc0-board {
> @@ -114,6 +105,15 @@
>   		};
>   	};
>
> +	i2c@0 {
> +		status = "okay";
> +
> +		wm8731: wm8731@1a {
> +			compatible = "wm8731";
> +			reg = <0x1a>;
> +		};
> +	};
> +
>   	sound {
>   		compatible = "atmel,sam9x5-audio-wm8731";
>
> with that configuration, it hangs when I do a:
> arecord -v -V stereo -Dplug:default -f cd -t wav -c 2 /tmp/toto.wav
>
> Now, if I remove the overrun error on ssc in rx_mask:
> diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c
> index 0ecf356..c04e825 100644
> --- a/sound/soc/atmel/atmel_ssc_dai.c
> +++ b/sound/soc/atmel/atmel_ssc_dai.c
> @@ -83,7 +83,6 @@ static struct atmel_ssc_mask ssc_rx_mask = {
>   	.ssc_disable	= SSC_BIT(CR_RXDIS),
>   	.ssc_endx	= SSC_BIT(SR_ENDRX),
>   	.ssc_endbuf	= SSC_BIT(SR_RXBUFF),
> -	.ssc_error	= SSC_BIT(SR_OVRUN),
>   	.pdc_enable	= ATMEL_PDC_RXTEN,
>   	.pdc_disable	= ATMEL_PDC_RXTDIS,
>   };
>
> It doesn't hang any more doing a simple record.
> BUT it still hangs if we do record and play at the same time.
>
> Removing the overrun on tx_mask prevent the hang:
> diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c
> index 0ecf356..41e15c2 100644
> --- a/sound/soc/atmel/atmel_ssc_dai.c
> +++ b/sound/soc/atmel/atmel_ssc_dai.c
> @@ -73,7 +73,6 @@ static struct atmel_ssc_mask ssc_tx_mask = {
>   	.ssc_disable	= SSC_BIT(CR_TXDIS),
>   	.ssc_endx	= SSC_BIT(SR_ENDTX),
>   	.ssc_endbuf	= SSC_BIT(SR_TXBUFE),
> -	.ssc_error	= SSC_BIT(SR_OVRUN),
>   	.pdc_enable	= ATMEL_PDC_TXTEN,
>   	.pdc_disable	= ATMEL_PDC_TXTDIS,
>   };
>
> i.e. when I revert "ASoC: atmel_ssc_dai: add error mask define", I
> don't see any hang.
>
> Could you test and confirm that behaviour please ?

Yes, I aware this issue.
Actually the system not hang, the resource all are occupied by the 
interrupt. This because, we enable the interrupt, when once interrupt 
occur, I try many methods to clear it, however we can not clear it. So, 
it generates the interrupt all the time. It seems the system hang.

Temp solution: not enable the interrupt. use the following patch to 
disable the interrupt.
---8>---
diff --git a/sound/soc/atmel/atmel_ssc_dai.c 
b/sound/soc/atmel/atmel_ssc_dai.c
index 0ecf356..bb53dea 100644
--- a/sound/soc/atmel/atmel_ssc_dai.c
+++ b/sound/soc/atmel/atmel_ssc_dai.c
@@ -649,7 +649,7 @@ static int atmel_ssc_prepare(struct 
snd_pcm_substream *substream,
         dma_params = ssc_p->dma_params[dir];

         ssc_writel(ssc_p->ssc->regs, CR, dma_params->mask->ssc_enable);
-       ssc_writel(ssc_p->ssc->regs, IER, dma_params->mask->ssc_error);
+       ssc_writel(ssc_p->ssc->regs, IDR, dma_params->mask->ssc_error);

         pr_debug("%s enabled SSC_SR=0x%08x\n",
                         dir ? "receive" : "transmit",
---<8---

BTW, I am checking this with our IP team, if find the real solution, I 
will fix it.

> I attached a the (simple) .config I used for the tests.
>
> PS: I hope the patches won't be mangled by gmail...
>
> Best regards,
> Richard.

Best Regards,
Bo Shen

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists