[alsa-devel] Restore state around suspend/resume
Hi,
Currently, suspending the computer via pm-suspend (as done from HAL), causes the ALSA state to be stored and restored via alsactl. Here's what the hook looks like:
http://cgit.freedesktop.org/pm-utils/tree/pm/sleep.d/65alsa
Is this still necessary on recent kernels? Is there a list of drivers which properly maintain state across suspend/resume? We're trying to cut down on the amount of work done in userspace which slows down suspend cycles.
Thanks.
-- Dan -- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
At Sat, 29 Nov 2008 12:40:02 -0800, Dan Nicholson wrote:
Hi,
Currently, suspending the computer via pm-suspend (as done from HAL), causes the ALSA state to be stored and restored via alsactl. Here's what the hook looks like:
http://cgit.freedesktop.org/pm-utils/tree/pm/sleep.d/65alsa
Is this still necessary on recent kernels? Is there a list of drivers which properly maintain state across suspend/resume? We're trying to cut down on the amount of work done in userspace which slows down suspend cycles.
The all drivers with PM support should have do store/restore the mixer states. For such drivers, calling alsactl is just a waste of time.
I don't know who introduced it, but maybe it was a workaround...
Takashi -- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Nov 30, 2008 at 1:01 AM, Takashi Iwai tiwai@suse.de wrote:
At Sat, 29 Nov 2008 12:40:02 -0800, Dan Nicholson wrote:
Hi,
Currently, suspending the computer via pm-suspend (as done from HAL), causes the ALSA state to be stored and restored via alsactl. Here's what the hook looks like:
http://cgit.freedesktop.org/pm-utils/tree/pm/sleep.d/65alsa
Is this still necessary on recent kernels? Is there a list of drivers which properly maintain state across suspend/resume? We're trying to cut down on the amount of work done in userspace which slows down suspend cycles.
The all drivers with PM support should have do store/restore the mixer states. For such drivers, calling alsactl is just a waste of time.
Thanks. Which drivers don't have PM support?
I don't know who introduced it, but maybe it was a workaround...
Yeah, I'm sure it was a workaround, but we're trying to get rid of the unnecessary ones now.
-- Dan -- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
At Sun, 30 Nov 2008 08:22:49 -0800, Dan Nicholson wrote:
On Sun, Nov 30, 2008 at 1:01 AM, Takashi Iwai tiwai@suse.de wrote:
At Sat, 29 Nov 2008 12:40:02 -0800, Dan Nicholson wrote:
Hi,
Currently, suspending the computer via pm-suspend (as done from HAL), causes the ALSA state to be stored and restored via alsactl. Here's what the hook looks like:
http://cgit.freedesktop.org/pm-utils/tree/pm/sleep.d/65alsa
Is this still necessary on recent kernels? Is there a list of drivers which properly maintain state across suspend/resume? We're trying to cut down on the amount of work done in userspace which slows down suspend cycles.
The all drivers with PM support should have do store/restore the mixer states. For such drivers, calling alsactl is just a waste of time.
Thanks. Which drivers don't have PM support?
Many. Look though the kernel tree codes under sound directory that has no suspend and resume callbacks.
I don't know who introduced it, but maybe it was a workaround...
Yeah, I'm sure it was a workaround, but we're trying to get rid of the unnecessary ones now.
Even for drivers without PM support, alsactl alone is useless. So I suggest you to remove it.
Takashi -- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Nov 30, 2008 at 9:06 AM, Takashi Iwai tiwai@suse.de wrote:
At Sun, 30 Nov 2008 08:22:49 -0800, Dan Nicholson wrote:
On Sun, Nov 30, 2008 at 1:01 AM, Takashi Iwai tiwai@suse.de wrote:
At Sat, 29 Nov 2008 12:40:02 -0800, Dan Nicholson wrote:
Hi,
Currently, suspending the computer via pm-suspend (as done from HAL), causes the ALSA state to be stored and restored via alsactl. Here's what the hook looks like:
http://cgit.freedesktop.org/pm-utils/tree/pm/sleep.d/65alsa
Is this still necessary on recent kernels? Is there a list of drivers which properly maintain state across suspend/resume? We're trying to cut down on the amount of work done in userspace which slows down suspend cycles.
The all drivers with PM support should have do store/restore the mixer states. For such drivers, calling alsactl is just a waste of time.
Thanks. Which drivers don't have PM support?
Many. Look though the kernel tree codes under sound directory that has no suspend and resume callbacks.
OK.
I don't know who introduced it, but maybe it was a workaround...
Yeah, I'm sure it was a workaround, but we're trying to get rid of the unnecessary ones now.
Even for drivers without PM support, alsactl alone is useless. So I suggest you to remove it.
I'm sorry, but why useless? It seems that it would be useful to restore state from userspace if the driver isn't doing that on its own.
-- Dan -- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
At Sun, 30 Nov 2008 09:10:32 -0800, Dan Nicholson wrote:
On Sun, Nov 30, 2008 at 9:06 AM, Takashi Iwai tiwai@suse.de wrote:
At Sun, 30 Nov 2008 08:22:49 -0800, Dan Nicholson wrote:
On Sun, Nov 30, 2008 at 1:01 AM, Takashi Iwai tiwai@suse.de wrote:
At Sat, 29 Nov 2008 12:40:02 -0800, Dan Nicholson wrote:
Hi,
Currently, suspending the computer via pm-suspend (as done from HAL), causes the ALSA state to be stored and restored via alsactl. Here's what the hook looks like:
http://cgit.freedesktop.org/pm-utils/tree/pm/sleep.d/65alsa
Is this still necessary on recent kernels? Is there a list of drivers which properly maintain state across suspend/resume? We're trying to cut down on the amount of work done in userspace which slows down suspend cycles.
The all drivers with PM support should have do store/restore the mixer states. For such drivers, calling alsactl is just a waste of time.
Thanks. Which drivers don't have PM support?
Many. Look though the kernel tree codes under sound directory that has no suspend and resume callbacks.
OK.
I don't know who introduced it, but maybe it was a workaround...
Yeah, I'm sure it was a workaround, but we're trying to get rid of the unnecessary ones now.
Even for drivers without PM support, alsactl alone is useless. So I suggest you to remove it.
I'm sorry, but why useless? It seems that it would be useful to restore state from userspace if the driver isn't doing that on its own.
Read alsactl "alone". Without the combination of module unloading and reloading, it's useless.
And, whether you need alsactl in pm script depends on the implementation. On many distros, loading the sound driver will invoke "alsactl restore" automatically, thus you don't need it in the pm side. But, for unloading the module, I guess "alsactl store" would be needed explicitly in the pm hook.
Takashi -- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Nov 30, 2008 at 9:22 AM, Takashi Iwai tiwai@suse.de wrote:
At Sun, 30 Nov 2008 09:10:32 -0800, Dan Nicholson wrote:
On Sun, Nov 30, 2008 at 9:06 AM, Takashi Iwai tiwai@suse.de wrote:
At Sun, 30 Nov 2008 08:22:49 -0800, Dan Nicholson wrote:
On Sun, Nov 30, 2008 at 1:01 AM, Takashi Iwai tiwai@suse.de wrote:
I don't know who introduced it, but maybe it was a workaround...
Yeah, I'm sure it was a workaround, but we're trying to get rid of the unnecessary ones now.
Even for drivers without PM support, alsactl alone is useless. So I suggest you to remove it.
I'm sorry, but why useless? It seems that it would be useful to restore state from userspace if the driver isn't doing that on its own.
Read alsactl "alone". Without the combination of module unloading and reloading, it's useless.
So, are you saying that all drivers will maintain their state until they are unloaded?
And, whether you need alsactl in pm script depends on the implementation. On many distros, loading the sound driver will invoke "alsactl restore" automatically, thus you don't need it in the pm side. But, for unloading the module, I guess "alsactl store" would be needed explicitly in the pm hook.
Yes, we don't want to unload the modules at suspend time unless working around problems. And then, I'd suspect a udev or modprobe rule would be more appropriate for restoring state.
-- Dan -- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
At Sun, 30 Nov 2008 09:30:37 -0800, Dan Nicholson wrote:
On Sun, Nov 30, 2008 at 9:22 AM, Takashi Iwai tiwai@suse.de wrote:
At Sun, 30 Nov 2008 09:10:32 -0800, Dan Nicholson wrote:
On Sun, Nov 30, 2008 at 9:06 AM, Takashi Iwai tiwai@suse.de wrote:
At Sun, 30 Nov 2008 08:22:49 -0800, Dan Nicholson wrote:
On Sun, Nov 30, 2008 at 1:01 AM, Takashi Iwai tiwai@suse.de wrote:
I don't know who introduced it, but maybe it was a workaround...
Yeah, I'm sure it was a workaround, but we're trying to get rid of the unnecessary ones now.
Even for drivers without PM support, alsactl alone is useless. So I suggest you to remove it.
I'm sorry, but why useless? It seems that it would be useful to restore state from userspace if the driver isn't doing that on its own.
Read alsactl "alone". Without the combination of module unloading and reloading, it's useless.
So, are you saying that all drivers will maintain their state until they are unloaded?
The drivers supporting PM do it, yes.
Takashi -- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Nov 30, 2008 at 10:28 AM, Takashi Iwai tiwai@suse.de wrote:
At Sun, 30 Nov 2008 09:30:37 -0800, Dan Nicholson wrote:
On Sun, Nov 30, 2008 at 9:22 AM, Takashi Iwai tiwai@suse.de wrote:
At Sun, 30 Nov 2008 09:10:32 -0800, Dan Nicholson wrote:
On Sun, Nov 30, 2008 at 9:06 AM, Takashi Iwai tiwai@suse.de wrote:
At Sun, 30 Nov 2008 08:22:49 -0800, Dan Nicholson wrote:
On Sun, Nov 30, 2008 at 1:01 AM, Takashi Iwai tiwai@suse.de wrote: > I don't know who introduced it, but maybe it was a workaround...
Yeah, I'm sure it was a workaround, but we're trying to get rid of the unnecessary ones now.
Even for drivers without PM support, alsactl alone is useless. So I suggest you to remove it.
I'm sorry, but why useless? It seems that it would be useful to restore state from userspace if the driver isn't doing that on its own.
Read alsactl "alone". Without the combination of module unloading and reloading, it's useless.
So, are you saying that all drivers will maintain their state until they are unloaded?
The drivers supporting PM do it, yes.
Then, for drivers that don't support PM, won't they lose their state across suspend? Shouldn't we save and restore it from userspace for those drivers?
-- Dan -- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
At Sun, 30 Nov 2008 10:38:27 -0800, Dan Nicholson wrote:
On Sun, Nov 30, 2008 at 10:28 AM, Takashi Iwai tiwai@suse.de wrote:
At Sun, 30 Nov 2008 09:30:37 -0800, Dan Nicholson wrote:
On Sun, Nov 30, 2008 at 9:22 AM, Takashi Iwai tiwai@suse.de wrote:
At Sun, 30 Nov 2008 09:10:32 -0800, Dan Nicholson wrote:
On Sun, Nov 30, 2008 at 9:06 AM, Takashi Iwai tiwai@suse.de wrote:
At Sun, 30 Nov 2008 08:22:49 -0800, Dan Nicholson wrote: > > On Sun, Nov 30, 2008 at 1:01 AM, Takashi Iwai tiwai@suse.de wrote: > > I don't know who introduced it, but maybe it was a workaround... > > Yeah, I'm sure it was a workaround, but we're trying to get rid of the > unnecessary ones now.
Even for drivers without PM support, alsactl alone is useless. So I suggest you to remove it.
I'm sorry, but why useless? It seems that it would be useful to restore state from userspace if the driver isn't doing that on its own.
Read alsactl "alone". Without the combination of module unloading and reloading, it's useless.
So, are you saying that all drivers will maintain their state until they are unloaded?
The drivers supporting PM do it, yes.
Then, for drivers that don't support PM, won't they lose their state across suspend? Shouldn't we save and restore it from userspace for those drivers?
They may lose the state. They need anyway unloading and reloading the driver at suspend/resume. That's why I wrote alsactl "alone" doesn't help. It must be always coupled with unloading/reloading if it's really needed. Putting only alsactl is thus useless and misleading.
Takashi -- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Nov 30, 2008 at 12:27 PM, Takashi Iwai tiwai@suse.de wrote:
At Sun, 30 Nov 2008 10:38:27 -0800, Dan Nicholson wrote:
On Sun, Nov 30, 2008 at 10:28 AM, Takashi Iwai tiwai@suse.de wrote:
At Sun, 30 Nov 2008 09:30:37 -0800, Dan Nicholson wrote:
On Sun, Nov 30, 2008 at 9:22 AM, Takashi Iwai tiwai@suse.de wrote:
At Sun, 30 Nov 2008 09:10:32 -0800, Dan Nicholson wrote:
On Sun, Nov 30, 2008 at 9:06 AM, Takashi Iwai tiwai@suse.de wrote: > At Sun, 30 Nov 2008 08:22:49 -0800, > Dan Nicholson wrote: >> >> On Sun, Nov 30, 2008 at 1:01 AM, Takashi Iwai tiwai@suse.de wrote: >> > I don't know who introduced it, but maybe it was a workaround... >> >> Yeah, I'm sure it was a workaround, but we're trying to get rid of the >> unnecessary ones now. > > Even for drivers without PM support, alsactl alone is useless. > So I suggest you to remove it.
I'm sorry, but why useless? It seems that it would be useful to restore state from userspace if the driver isn't doing that on its own.
Read alsactl "alone". Without the combination of module unloading and reloading, it's useless.
So, are you saying that all drivers will maintain their state until they are unloaded?
The drivers supporting PM do it, yes.
Then, for drivers that don't support PM, won't they lose their state across suspend? Shouldn't we save and restore it from userspace for those drivers?
They may lose the state. They need anyway unloading and reloading the driver at suspend/resume. That's why I wrote alsactl "alone" doesn't help. It must be always coupled with unloading/reloading if it's really needed. Putting only alsactl is thus useless and misleading.
Ah, thank you. Then we can drop the alsactl hook and suggest that anyone who has a non-PM-aware sound driver needs to add it to SUSPEND_MODULES, which unloads and reloads the driver at suspend time. Then, hopefully, udev or modprobe is setup to save/restore the state.
-- Dan -- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
At Sun, 30 Nov 2008 12:54:15 -0800, Dan Nicholson wrote:
On Sun, Nov 30, 2008 at 12:27 PM, Takashi Iwai tiwai@suse.de wrote:
At Sun, 30 Nov 2008 10:38:27 -0800, Dan Nicholson wrote:
On Sun, Nov 30, 2008 at 10:28 AM, Takashi Iwai tiwai@suse.de wrote:
At Sun, 30 Nov 2008 09:30:37 -0800, Dan Nicholson wrote:
On Sun, Nov 30, 2008 at 9:22 AM, Takashi Iwai tiwai@suse.de wrote:
At Sun, 30 Nov 2008 09:10:32 -0800, Dan Nicholson wrote: > > On Sun, Nov 30, 2008 at 9:06 AM, Takashi Iwai tiwai@suse.de wrote: > > At Sun, 30 Nov 2008 08:22:49 -0800, > > Dan Nicholson wrote: > >> > >> On Sun, Nov 30, 2008 at 1:01 AM, Takashi Iwai tiwai@suse.de wrote: > >> > I don't know who introduced it, but maybe it was a workaround... > >> > >> Yeah, I'm sure it was a workaround, but we're trying to get rid of the > >> unnecessary ones now. > > > > Even for drivers without PM support, alsactl alone is useless. > > So I suggest you to remove it. > > I'm sorry, but why useless? It seems that it would be useful to > restore state from userspace if the driver isn't doing that on its > own.
Read alsactl "alone". Without the combination of module unloading and reloading, it's useless.
So, are you saying that all drivers will maintain their state until they are unloaded?
The drivers supporting PM do it, yes.
Then, for drivers that don't support PM, won't they lose their state across suspend? Shouldn't we save and restore it from userspace for those drivers?
They may lose the state. They need anyway unloading and reloading the driver at suspend/resume. That's why I wrote alsactl "alone" doesn't help. It must be always coupled with unloading/reloading if it's really needed. Putting only alsactl is thus useless and misleading.
Ah, thank you. Then we can drop the alsactl hook and suggest that anyone who has a non-PM-aware sound driver needs to add it to SUSPEND_MODULES, which unloads and reloads the driver at suspend time. Then, hopefully, udev or modprobe is setup to save/restore the state.
Yes. Or you can comment out about it, too. Anyway, a definitely better fix is to support PM in the driver. So, please don't put such a workaround in the common pm hook in the first place, anyway...
Most reasons why PM isn't supported are the lack of test hardware (and the second place is lack of developers). If the reporter can help debugging, it'd be much better than sticking with the ugly workaround.
thanks,
Takashi -- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
participants (2)
-
Dan Nicholson -
Takashi Iwai