Not able to restart audio after hibernation

Not able to restart audio after hibernation

[Rajeev kumar]

Hello Mark,

I am testing my audio driver on spear platform with the linux kernel 
2.6.37. During testing I put my system in hibernation mode and found 
that there is no sound after resume. The steps I am using for 
hibernation are
1. Have audio player on, select some audio, (using aplay utils)
2. Hibernate machine
3. Resume from hibernate

After resume it seems that there is no data available in the buffer to 
play, as application is giving pcm_write error and  exit.

While going through the suspend/resume implementation in the alsa 
framework, get to know that feature to support hibernation is missing.
The suspend/resume implementation for audio is with dev_pm_ops which is 
present in snd-core.c . If we look into the structure, we have only 
suspend, resume and poweroff feature present in it. To support 
hibernation we need freeze,thaw and restore also.
Please correct me if I am wrong?

Just for experiment I modified the structure and added freeze, thaw and 
restore functionality, but the result is same. The new modified 
structure looks like

static const struct dev_pm_ops soc_pm_ops = {
	.suspend = soc_suspend,
	.resume = soc_resume,
	
	.freeze = soc_suspend,
	.thaw = soc_resume,
	.restore = soc_resume,

	.poweroff = soc_poweroff,
}

Just for info audio is working fine in case of suspend-to-ram.

Best Regards
~Rajeev

Re: Not able to restart audio after hibernation

[Mark Brown]

On Fri, Jan 06, 2012 at 04:17:50PM +0530, Rajeev kumar wrote:

> While going through the suspend/resume implementation in the alsa
> framework, get to know that feature to support hibernation is
> missing.

Hibernation is not supported on ARM at all.  Is SPEAR not an ARM based
platform?

> Just for experiment I modified the structure and added freeze, thaw
> and restore functionality, but the result is same. The new modified
> structure looks like

This suggests that you have a bug in your suspend and resume
implementation, possibly outside of this driver.

Re: Not able to restart audio after hibernation

[Tobin Davis]

On Fri, 2012-01-06 at 10:32 -0800, Mark Brown wrote:
> On Fri, Jan 06, 2012 at 04:17:50PM +0530, Rajeev kumar wrote:
> 
> > While going through the suspend/resume implementation in the alsa
> > framework, get to know that feature to support hibernation is
> > missing.
> 
> Hibernation is not supported on ARM at all.  Is SPEAR not an ARM based
> platform?
It isn't?  Hibernate is supported on all systems to some level.  Essentially 
the cpu is just halting all threads and saving state (cpu, memory, and device configs) to storage.

And I have a couple of arm development platforms here that would beg to
argue with this statement.


-- 
Tobin Davis 

A door is what a dog is perpetually on the wrong side of.
		-- Ogden Nash

Re: Not able to restart audio after hibernation

[Mark Brown]

On Fri, Jan 06, 2012 at 12:54:33PM -0800, Tobin Davis wrote:
> On Fri, 2012-01-06 at 10:32 -0800, Mark Brown wrote:

> > Hibernation is not supported on ARM at all.  Is SPEAR not an ARM based
> > platform?

> It isn't?  Hibernate is supported on all systems to some level.  Essentially 
> the cpu is just halting all threads and saving state (cpu, memory, and device configs) to storage.

...and then restoring it later when we power on again.  It's this bit
that had been tricky.

> And I have a couple of arm development platforms here that would beg to
> argue with this statement.

Perhaps it's been supported since I last looked, but if it has there's a
*lot* of drivers for ARM based systems which need to be updated.

Re: Not able to restart audio after hibernation

[Mark Brown]

On Mon, Jan 09, 2012 at 08:46:45AM +0530, Shiraz Hashim wrote:
> On Sat, Jan 07, 2012 at 02:32:05AM +0800, Mark Brown wrote:

> > This suggests that you have a bug in your suspend and resume
> > implementation, possibly outside of this driver.

> The driver works absolutely fine in case of suspend to ram where the
> power domains (which includes the I2S controller) is switched off.

That doesn't mean everything is OK, for example the clock tree or DMA
controller might not be preserving state properly.

> As the soc-core.c misses hibernation call backs of dev_pm_ops, we were
> wondering whether it has been tested before on some other platform.

Not to my knowledge, but I don't see any reason why anything more than
the trivial implementation should really be needed except for the
general pointlessness of resuming after hibernating.