Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1231098 > unrolled thread

Re: [alsa-devel] [PATCH] mfd: arizona: Call the runtime PM function if the state is runtime resumed

Started byInha Song <ideal.song@samsung.com>
First post2015-09-23 04:10 +0200
Last post2015-09-27 18:40 +0200
Articles 6 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [alsa-devel] [PATCH] mfd: arizona: Call the runtime PM function if  the state is runtime resumed Inha Song <ideal.song@samsung.com> - 2015-09-23 04:10 +0200
    Re: [alsa-devel] [PATCH] mfd: arizona: Call the runtime PM  function if the state is runtime resumed Charles Keepax <ckeepax@opensource.wolfsonmicro.com> - 2015-09-23 17:10 +0200
      Re: [alsa-devel] [PATCH] mfd: arizona: Call the runtime PM function if  the state is runtime resumed Inha Song <ideal.song@samsung.com> - 2015-09-24 03:40 +0200
        Re: [alsa-devel] [PATCH] mfd: arizona: Call the runtime PM  function if the state is runtime resumed Charles Keepax <ckeepax@opensource.wolfsonmicro.com> - 2015-09-24 10:10 +0200
          Re: [alsa-devel] [PATCH] mfd: arizona: Call the runtime PM function if  the state is runtime resumed Inha Song <ideal.song@samsung.com> - 2015-09-25 10:00 +0200
            Re: [alsa-devel] [PATCH] mfd: arizona: Call the runtime PM  function if the state is runtime resumed Charles Keepax <ckeepax@opensource.wolfsonmicro.com> - 2015-09-27 18:40 +0200

#1231098 — Re: [alsa-devel] [PATCH] mfd: arizona: Call the runtime PM function if the state is runtime resumed

FromInha Song <ideal.song@samsung.com>
Date2015-09-23 04:10 +0200
SubjectRe: [alsa-devel] [PATCH] mfd: arizona: Call the runtime PM function if the state is runtime resumed
Message-ID<qbHFo-6V2-5@gated-at.bofh.it>
 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@localhost:~# aplay test.wav 
[   40.831047] arizona spi1.0: Leaving AoD mode
[   40.834448] s3c64xx_spi_runtime_resume
[   40.834876] arizona spi1.0: d23 => 1
[   40.835029] s3c64xx_spi_runtime_suspend
[   40.846040] s3c64xx_spi_runtime_resume
[   40.846423] arizona spi1.0: d23 => 100
[   40.846557] s3c64xx_spi_runtime_suspend
[   40.846771] arizona spi1.0: d04 <= 100
[   40.846956] s3c64xx_spi_runtime_resume
[   40.852145] s3c64xx_spi_runtime_suspend
[   40.852386] s3c64xx_spi_runtime_resume
[   40.852894] s3c64xx_spi_runtime_suspend
[   40.854307] s3c64xx_spi_runtime_resume
[   40.858375] arizona spi1.0: d40 => 3
[   40.858410] s3c64xx_spi_runtime_suspend
[   40.865429] s3c64xx_spi_runtime_resume
[   40.869637] arizona spi1.0: d02 <= 2040
[   40.869671] s3c64xx_spi_runtime_suspend
[   40.876836] s3c64xx_spi_runtime_resume
[   40.880749] arizona spi1.0: Spurious HPDET IRQ
[   40.880773] arizona spi1.0: FLL1: Fref=24000000 Fout=135475200
[   40.880787] arizona spi1.0: FLL1: Fvco=90316800Hz
[   40.880793] s3c64xx_spi_runtime_suspend
[   40.880803] arizona spi1.0: FLL1: GCD=19200
[   40.880817] arizona spi1.0: FLL1: N=7 THETA=149 LAMBDA=271
[   40.880831] arizona spi1.0: FLL1: FRATIO=0(0) OUTDIV=2 REFCLK_DIV=1
[   40.880842] arizona spi1.0: FLL1: GAIN=4
[   40.880886] arizona spi1.0: 171 <= 1
[   40.880944] s3c64xx_spi_runtime_resume
[   40.881218] s3c64xx_spi_runtime_suspend
[   40.930152] s3c64xx_spi_runtime_resume
[   40.934071] arizona spi1.0: d26 => 1
[   40.934140] s3c64xx_spi_runtime_suspend
[   40.941237] arizona spi1.0: Mixer dropped sample
[   40.945901] s3c64xx_spi_runtime_resume
[   40.950067] arizona spi1.0: d40 => 3
[   40.950091] s3c64xx_spi_runtime_suspend
[   40.957025] s3c64xx_spi_runtime_resume
[   40.960971] arizona spi1.0: d04 <= 1
[   40.961006] s3c64xx_spi_runtime_suspend
[   40.968106] s3c64xx_spi_runtime_resume
[   40.971956] arizona spi1.0: FLL1: clock OK
[   40.971987] s3c64xx_spi_runtime_suspend
[   40.979751] arizona spi1.0: SYSCLK set to 135475200Hz
[   40.984742] wm5110-codec wm5110-codec: AIF1: BCLK 1411200Hz LRCLK 44100Hz
[   40.992144] arizona spi1.0: SYSCLK set to 135475200Hz
[   40.996646] arizona spi1.0: 101 <= 8644
[   41.000360] s3c64xx_spi_runtime_resume
[   41.004300] arizona spi1.0: 51a <= 1
[   41.004357] s3c64xx_spi_runtime_suspend
[   41.011499] s3c64xx_spi_runtime_resume
[   41.015689] arizona spi1.0: 400 <= 8
[   41.015692] s3c64xx_spi_runtime_suspend
[   41.022581] s3c64xx_spi_runtime_resume
[   41.026735] arizona spi1.0: d40 => 3
[   41.026737] s3c64xx_spi_runtime_suspend
[   41.033687] s3c64xx_spi_runtime_resume
[   41.037765] arizona spi1.0: d02 <= 40
[   41.037800] s3c64xx_spi_runtime_suspend
[   41.044883] s3c64xx_spi_runtime_resume
[   41.049054] arizona spi1.0: d26 => 8
[   41.049072] s3c64xx_spi_runtime_suspend
[   41.056043] arizona spi1.0: ASRC underclocked
....
[   72.308238] arizona spi1.0: Suspend, disabling IRQ
[   72.320286] arizona spi1.0: 400 <= 0
[   72.320310] s3c64xx_spi_runtime_resume
[   72.336047] arizona spi1.0: 51a <= 0
[   72.336217] arizona spi1.0: 101 <= 8604
[   72.336401] arizona spi1.0: 171 <= 3
[   72.336425] arizona spi1.0: 171 <= 2
[   72.336731] arizona spi1.0: 171 <= 0
[   72.336751] arizona spi1.0: SYSCLK cleared
[   72.338584] arizona spi1.0: SYSCLK cleared
[   72.339123] s3c64xx_spi_suspend
[   72.355866] arizona spi1.0: Late suspend, reenabling IRQ
[   72.355893] >>> noirq failed because of spi1
[   72.355948] arizona spi1.0: Early resume, disabling IRQ
[   72.416798] PM: noirq suspend of devices failed
......

Best Regards,
Inha Song.

On Tue, 22 Sep 2015 08:46:18 +0100
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> wrote:

> On Mon, Sep 21, 2015 at 11:16:42AM +0900, Inha Song wrote:
> > Hi, Charles,
> > 
> > I've already tried to change.
> > If I change to that, we can't enter the suspen during the playback.
> > 
> > -
> > [   72.538263] arizona spi1.0: Suspend, disabling IRQ
> > ...
> > [   72.585823] arizona spi1.0: Late suspend, reengabling IRQ
> > [   72.585904] arizona spi1.0: Early resume, disabling IRQ
> > ...
> > [   72.646770] PM: noirq suspend of devices failed
> > 		<- because of "spi1.0" pm_wakeup_pending() in suspend_noirq()
> 
> Ok this looks more reasonable, suspend should fail because we do
> have an IRQ waiting to be handled, so we shouldn't suspend. But
> you are saying this happens every time the CODEC goes to suspend,
> thus blocking the suspend from suspending?
> 
> First step then would be to identify what IRQ is occurring, could
> you set LOG_DEVICE at the top of drivers/base/regmap/regmap.c to
> "spi1.0" and provide a log, so we can see what IRQ is being
> asserted from the CODEC.
> 
> Thanks,
> Charles
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]


#1231498 — Re: [alsa-devel] [PATCH] mfd: arizona: Call the runtime PM function if the state is runtime resumed

FromCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Date2015-09-23 17:10 +0200
SubjectRe: [alsa-devel] [PATCH] mfd: arizona: Call the runtime PM function if the state is runtime resumed
Message-ID<qbTQe-7KM-17@gated-at.bofh.it>
In reply to#1231098
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@localhost:~# aplay test.wav 
> [   41.049072] s3c64xx_spi_runtime_suspend
> [   41.056043] arizona spi1.0: ASRC underclocked
> ....
> [   72.308238] arizona spi1.0: Suspend, disabling IRQ
> [   72.320286] arizona spi1.0: 400 <= 0
> [   72.320310] s3c64xx_spi_runtime_resume
> [   72.336047] arizona spi1.0: 51a <= 0
> [   72.336217] arizona spi1.0: 101 <= 8604
> [   72.336401] arizona spi1.0: 171 <= 3
> [   72.336425] arizona spi1.0: 171 <= 2
> [   72.336731] arizona spi1.0: 171 <= 0
> [   72.336751] arizona spi1.0: SYSCLK cleared
> [   72.338584] arizona spi1.0: SYSCLK cleared

This bit looks likely related to your problem, it looks like the
FLL is being turned off. My guess here would be that you haven't
called snd_soc_dapm_ignore_suspend from your machine driver, you
need to call this for all end points that may want to stay
powered up during system suspend and also set the ignore_suspend
flag on any DAI links you want to remain active during system
suspend.

Likely what is happening here is that you are disabling the FLL
and this is causing some IRQ which is then causing a wake event
thus aborting the suspend.

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

[toc] | [prev] | [next] | [standalone]


#1231803

FromInha Song <ideal.song@samsung.com>
Date2015-09-24 03:40 +0200
Message-ID<qc3FT-57w-5@gated-at.bofh.it>
In reply to#1231498
Hi, Charles,

On Wed, 23 Sep 2015 15:43:12 +0100
Charles Keepax <ckeepax@opensource.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@localhost:~# aplay test.wav 
> > [   41.049072] s3c64xx_spi_runtime_suspend
> > [   41.056043] arizona spi1.0: ASRC underclocked
> > ....
> > [   72.308238] arizona spi1.0: Suspend, disabling IRQ
> > [   72.320286] arizona spi1.0: 400 <= 0
> > [   72.320310] s3c64xx_spi_runtime_resume
> > [   72.336047] arizona spi1.0: 51a <= 0
> > [   72.336217] arizona spi1.0: 101 <= 8604
> > [   72.336401] arizona spi1.0: 171 <= 3
> > [   72.336425] arizona spi1.0: 171 <= 2
> > [   72.336731] arizona spi1.0: 171 <= 0
> > [   72.336751] arizona spi1.0: SYSCLK cleared
> > [   72.338584] arizona spi1.0: SYSCLK cleared
> 
> This bit looks likely related to your problem, it looks like the
> FLL is being turned off. My guess here would be that you haven't
> called snd_soc_dapm_ignore_suspend from your machine driver, you
> need to call this for all end points that may want to stay
> powered up during system suspend and also set the ignore_suspend
> flag on any DAI links you want to remain active during system
> suspend.

But, We should call the trigger callback with SNDRV_PCM_TRIGGER_SUSPEND and *_RESUME command
for support senarios what suspend during the playback and resume.
So, I can't set the "ignore_suspend" in playback DAI.

For this reason, I would have called the runtime_suspend manually in arizona-core when suspend.

Best Reagrds,
Inha Song.

> 
> Likely what is happening here is that you are disabling the FLL
> and this is causing some IRQ which is then causing a wake event
> thus aborting the suspend.
> 
> Thanks,
> Charles
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1231930 — Re: [alsa-devel] [PATCH] mfd: arizona: Call the runtime PM function if the state is runtime resumed

FromCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Date2015-09-24 10:10 +0200
SubjectRe: [alsa-devel] [PATCH] mfd: arizona: Call the runtime PM function if the state is runtime resumed
Message-ID<qc9Lj-5Dv-1@gated-at.bofh.it>
In reply to#1231803
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@opensource.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@localhost:~# aplay test.wav 
> > > [   41.049072] s3c64xx_spi_runtime_suspend
> > > [   41.056043] arizona spi1.0: ASRC underclocked
> > > ....
> > > [   72.308238] arizona spi1.0: Suspend, disabling IRQ
> > > [   72.320286] arizona spi1.0: 400 <= 0
> > > [   72.320310] s3c64xx_spi_runtime_resume
> > > [   72.336047] arizona spi1.0: 51a <= 0
> > > [   72.336217] arizona spi1.0: 101 <= 8604
> > > [   72.336401] arizona spi1.0: 171 <= 3
> > > [   72.336425] arizona spi1.0: 171 <= 2
> > > [   72.336731] arizona spi1.0: 171 <= 0
> > > [   72.336751] arizona spi1.0: SYSCLK cleared
> > > [   72.338584] arizona spi1.0: SYSCLK cleared
> > 
> > This bit looks likely related to your problem, it looks like the
> > FLL is being turned off. My guess here would be that you haven't
> > called snd_soc_dapm_ignore_suspend from your machine driver, you
> > need to call this for all end points that may want to stay
> > powered up during system suspend and also set the ignore_suspend
> > flag on any DAI links you want to remain active during system
> > suspend.
> 
> But, We should call the trigger callback with SNDRV_PCM_TRIGGER_SUSPEND and *_RESUME command
> for support senarios what suspend during the playback and resume.
> So, I can't set the "ignore_suspend" in playback DAI.
> 
> For this reason, I would have called the runtime_suspend manually in arizona-core when suspend.
> 
> Best Reagrds,
> Inha Song.
> 

Ah ok so you want the audio to stop during suspend?

Ok in that case can we get a bit more of log, your log finished
up here:

[   72.308238] arizona spi1.0: Suspend, disabling IRQ
[   72.320286] arizona spi1.0: 400 <= 0
[   72.320310] s3c64xx_spi_runtime_resume
[   72.336047] arizona spi1.0: 51a <= 0
[   72.336217] arizona spi1.0: 101 <= 8604
[   72.336401] arizona spi1.0: 171 <= 3
[   72.336425] arizona spi1.0: 171 <= 2
[   72.336731] arizona spi1.0: 171 <= 0
[   72.336751] arizona spi1.0: SYSCLK cleared
[   72.338584] arizona spi1.0: SYSCLK cleared
[   72.339123] s3c64xx_spi_suspend
[   72.355866] arizona spi1.0: Late suspend, reenabling IRQ
[   72.355893] >>> noirq failed because of spi1
[   72.355948] arizona spi1.0: Early resume, disabling IRQ
[   72.416798] PM: noirq suspend of devices failed

Which finished too early as we can't see which IRQ it was that
triggered the wakeup.

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

[toc] | [prev] | [next] | [standalone]


#1232638

FromInha Song <ideal.song@samsung.com>
Date2015-09-25 10:00 +0200
Message-ID<qcw5b-3AI-5@gated-at.bofh.it>
In reply to#1231930
Hi, Charles,

On Thu, 24 Sep 2015 08:41:07 +0100
Charles Keepax <ckeepax@opensource.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@opensource.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@localhost:~# aplay test.wav 
> > > > [   41.049072] s3c64xx_spi_runtime_suspend
> > > > [   41.056043] arizona spi1.0: ASRC underclocked
> > > > ....
> > > > [   72.308238] arizona spi1.0: Suspend, disabling IRQ
> > > > [   72.320286] arizona spi1.0: 400 <= 0
> > > > [   72.320310] s3c64xx_spi_runtime_resume
> > > > [   72.336047] arizona spi1.0: 51a <= 0
> > > > [   72.336217] arizona spi1.0: 101 <= 8604
> > > > [   72.336401] arizona spi1.0: 171 <= 3
> > > > [   72.336425] arizona spi1.0: 171 <= 2
> > > > [   72.336731] arizona spi1.0: 171 <= 0
> > > > [   72.336751] arizona spi1.0: SYSCLK cleared
> > > > [   72.338584] arizona spi1.0: SYSCLK cleared
> > > 
> > > This bit looks likely related to your problem, it looks like the
> > > FLL is being turned off. My guess here would be that you haven't
> > > called snd_soc_dapm_ignore_suspend from your machine driver, you
> > > need to call this for all end points that may want to stay
> > > powered up during system suspend and also set the ignore_suspend
> > > flag on any DAI links you want to remain active during system
> > > suspend.
> > 
> > But, We should call the trigger callback with SNDRV_PCM_TRIGGER_SUSPEND and *_RESUME command
> > for support senarios what suspend during the playback and resume.
> > So, I can't set the "ignore_suspend" in playback DAI.
> > 
> > For this reason, I would have called the runtime_suspend manually in arizona-core when suspend.
> > 
> > Best Reagrds,
> > Inha Song.
> > 
> 
> Ah ok so you want the audio to stop during suspend?

Yes, I want to stop when suspend and continuous play when resume.

> 
> Ok in that case can we get a bit more of log, your log finished
> up here:
> 
> [   72.308238] arizona spi1.0: Suspend, disabling IRQ
> [   72.320286] arizona spi1.0: 400 <= 0
> [   72.320310] s3c64xx_spi_runtime_resume
> [   72.336047] arizona spi1.0: 51a <= 0
> [   72.336217] arizona spi1.0: 101 <= 8604
> [   72.336401] arizona spi1.0: 171 <= 3
> [   72.336425] arizona spi1.0: 171 <= 2
> [   72.336731] arizona spi1.0: 171 <= 0
> [   72.336751] arizona spi1.0: SYSCLK cleared
> [   72.338584] arizona spi1.0: SYSCLK cleared
> [   72.339123] s3c64xx_spi_suspend
> [   72.355866] arizona spi1.0: Late suspend, reenabling IRQ
> [   72.355893] >>> noirq failed because of spi1
> [   72.355948] arizona spi1.0: Early resume, disabling IRQ
> [   72.416798] PM: noirq suspend of devices failed
> 
> Which finished too early as we can't see which IRQ it was that
> triggered the wakeup.

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? 

Best Regards,
Inha Song.


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

[toc] | [prev] | [next] | [standalone]


#1233707 — Re: [alsa-devel] [PATCH] mfd: arizona: Call the runtime PM function if the state is runtime resumed

FromCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Date2015-09-27 18:40 +0200
SubjectRe: [alsa-devel] [PATCH] mfd: arizona: Call the runtime PM function if the state is runtime resumed
Message-ID<qdn9w-4ba-15@gated-at.bofh.it>
In reply to#1232638
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@opensource.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@opensource.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@localhost:~# 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web