[alsa-devel] PM issue with Intel SST Atom driver

[Takashi Iwai]

On Mon, 24 Apr 2017 18:27:38 +0200,
Vinod Koul wrote:
> 
> On Mon, Apr 24, 2017 at 09:22:38AM -0500, Pierre-Louis Bossart wrote:
> > On 4/24/17 4:54 AM, Takashi Iwai wrote:
> > >On Mon, 24 Apr 2017 11:52:44 +0200,
> > >Vinod Koul wrote:
> > >>
> > >>On Mon, Apr 24, 2017 at 11:43:47AM +0200, Takashi Iwai wrote:
> > >>>On Mon, 24 Apr 2017 11:12:14 +0200,
> > >>>Vinod Koul wrote:
> > >>>>
> > >>>>On Mon, Apr 24, 2017 at 11:00:45AM +0200, Takashi Iwai wrote:
> > >>>>
> > >>>>>Removing ignore_suspend makes the PM succeeds.  But it hits some other
> > >>>>>ugly kernel bugs.
> > >>>>
> > >>>>Okay have you marked .nonatomic = true for the machine DAIs?
> > >>>
> > >>>Ah that's it.  The patch below seems fixing the PM and the nonatomic
> > >>>problems.  I'm not sure about the nonatomic flag for the compress
> > >>>stream, though.
> > >>
> > >>Well we dont have upstream decoders so it wont be used in this case.
> > >>
> > >>>Also I fiddled only with FE.  Do we need the same flags for BE?  The
> > >>>others don't look setting like that, so I left so.
> > >>
> > >>I dont remember if BE needs or not FE should suffice.
> > >
> > >OK then I leave it as is.
> > >
> > >When I submit the fix, I should put Cc to stable, and wonder which
> > >version we assure the nonatomic ops in SST driver.  Did the code base
> > >support nonatomic ops from the beginning?
> > 
> > can we take this opportunity to align all drivers?
> > The .nonatomic=true is set in all drivers for the BE, except for
> > cht_bsw_max98090_ti.c
> 
> ??
> 
> $ grep nonatomic sound/soc/intel/boards/cht_bsw_max98090_ti.c
>                 .nonatomic = true,
>                 .nonatomic = true,
> 
> > It's either needed for all or not needed for all...
> 
> For the record it is must have for all of the drivers :)
> 
> $ grep -L nonatomic sound/soc/intel/boards/*.c
> sound/soc/intel/boards/bdw-rt5677.c
> sound/soc/intel/boards/broadwell.c
> sound/soc/intel/boards/byt-max98090.c
> sound/soc/intel/boards/byt-rt5640.c
> sound/soc/intel/boards/haswell.c
> sound/soc/intel/boards/mfld_machine.c
> 
> So we should add the remaining one byt-max98090.c as Takashi fixed
> byt-rt5640.c one. I will send the patch for this one.

Or maybe we should replace these definitions with some macro to expand
to the mostly same contents?  The difference is just a few callback
functions, basically.


Takashi