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] [day] [month] [year] [list]
Date:	Sun, 27 Sep 2015 17:06:44 +0100
From:	Charles Keepax <ckeepax@...nsource.wolfsonmicro.com>
To:	Inha Song <ideal.song@...sung.com>
CC:	<lee.jones@...aro.org>, <broonie@...nel.org>,
	<linux-kernel@...r.kernel.org>, <alsa-devel@...a-project.org>,
	<patches@...nsource.wolfsonmicro.com>, <sameo@...ux.intel.com>,
	<cw00.choi@...sung.com>
Subject: Re: [alsa-devel] [PATCH] mfd: arizona: Call the runtime PM
 function if the state is runtime resumed

On Fri, Sep 25, 2015 at 04:51:28PM +0900, Inha Song wrote:
> Hi, Charles,
> 
> On Thu, 24 Sep 2015 08:41:07 +0100
> Charles Keepax <ckeepax@...nsource.wolfsonmicro.com> wrote:
> 
> > On Thu, Sep 24, 2015 at 10:38:09AM +0900, Inha Song wrote:
> > > Hi, Charles,
> > > 
> > > On Wed, 23 Sep 2015 15:43:12 +0100
> > > Charles Keepax <ckeepax@...nsource.wolfsonmicro.com> wrote:
> > > 
> > > > On Wed, Sep 23, 2015 at 11:04:04AM +0900, Inha Song wrote:
> > > > >  Hi, Charles,
> > > > > 
> > > > > I saw the log with LOG_DEVICE in regmap. But, I'm not sure the reason that suspend noirq failed is IRQ occuring.
> > > > > 
> > > > > Here is my log:
> > > > > --
> > > > > root@...alhost:~# aplay test.wav 
> > > > > [   41.049072] s3c64xx_spi_runtime_suspend
> But, I can't find any spi regmap log that for IRQ.
> --
> [  114.282681] arizona spi1.0: Late suspend, reenabling IRQ
> [  114.282708] >>> noirq failed because of spi1
> [  114.282760] arizona spi1.0: Early resume, disabling IRQ
> [  114.316510] PM: noirq suspend of devices failed
> [  114.333590] s3c64xx_spi_resume
> 
>      -> set the FLL in machine for playback when resume.
> [  114.334756] arizona spi1.0: FLL1: Fref=24000000 Fout=135475200
> [  114.334762] arizona spi1.0: FLL1: Fvco=90316800Hz
> [  114.334792] arizona spi1.0: FLL1: GCD=19200
> [  114.334798] arizona spi1.0: FLL1: N=7 THETA=149 LAMBDA=271
> [  114.334803] arizona spi1.0: FLL1: FRATIO=0(0) OUTDIV=2 REFCLK_DIV=1
> [  114.334807] arizona spi1.0: FLL1: GAIN=4
> [  114.334827] arizona spi1.0: 171 <= 1
> [  114.520724] arizona spi1.0: Late resume, reenabling IRQ
> [  114.521152] arizona spi1.0: d40 => 3
> [  114.521387] arizona spi1.0: d04 <= 1
> [  114.521500] arizona spi1.0: FLL1: clock OK
> [  114.521773] arizona spi1.0: SYSCLK set to 135475200Hz
> [  114.522651] arizona spi1.0: SYSCLK set to 135475200Hz
> [  114.522752] arizona spi1.0: 101 <= 8644
> [  114.522940] arizona spi1.0: 51a <= 1
> [  114.523057] arizona spi1.0: 400 <= 8
> [  114.909270] s3c64xx_spi_runtime_suspend
> [  114.909721] done.
> Suspended. Trying resume. Failed. Restarting stream. Done.
> 
>     -> retry to enter suspend Immediately.
> [  115.478349] arizona spi1.0: Suspend, disabling IRQ
> [  115.489783] arizona spi1.0: 400 <= 0
> [  115.489804] s3c64xx_spi_runtime_resume
> [  115.506127] arizona spi1.0: 51a <= 0
> [  115.506298] arizona spi1.0: 101 <= 8604
> [  115.506493] arizona spi1.0: 171 <= 3
> [  115.506515] arizona spi1.0: 171 <= 2
> [  115.506777] arizona spi1.0: 171 <= 0
> [  115.506793] arizona spi1.0: SYSCLK cleared
> [  115.507842] arizona spi1.0: SYSCLK cleared
> [  115.508373] s3c64xx_spi_suspend                                                                                                     
> 
> [  115.523095] arizona spi1.0: Late suspend, reenabling IRQ                                                                            
> [  115.523121] >>> noirq failed because of spi1                                                                                        
> [  115.523171] arizona spi1.0: Early resume, disabling IRQ
> [  115.556507] PM: noirq suspend of devices failed 
>      -> Repeats:
> 
> Do you have any idea to check which IRQ was occur? 

Hmm... yes that is odd whatever the IRQ was it appears to have
disappeared by the time we try to handle it.

Two things I would check next, is it perhaps electrical, is the
IRQ line getting pulled low for some reason other than an IRQ
being generated. For example are all the supplies being removed
from the CODEC and any pull-ups on that IRQ line? Perhaps then
when the system resumes the supplies are re-instated and the
false IRQ disappears. However this is probably unlikely as I
would expect to see an IRQ for boot done in this case.

Secondly, could you try taking the extcon driver out of the build
(CONFIG_EXTCON_ARIZONA), that should keep all the jack detect
disabled, which is probably the second most likely source of a
random IRQ from the chip.

I am attempting to reproduce your problem here, but alas
suspend/resume support on the Arndale board (our main dev system
at the moment) is pretty bad. If you know anyone your end who
might have any ideas why the SPI is totally unresponsive after
resume I would be happy to hear from them :-)

Thanks,
Charles
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ