LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <email@example.com> To: Rene Herman <firstname.lastname@example.org> Cc: Pierre Ossman <email@example.com>, Pavel Machek <firstname.lastname@example.org>, Ondrej Zary <email@example.com>, Jaroslav Kysela <firstname.lastname@example.org>, ALSA development <email@example.com>, Linux Kernel <firstname.lastname@example.org>, Bjorn Helgaas <email@example.com>, Andrew Morton <firstname.lastname@example.org>, Takashi Iwai <email@example.com>, firstname.lastname@example.org Subject: Re: [alsa-devel] PNP_DRIVER_RES_DISABLE breaks swsusp at least with snd_cs4236 Date: Sat, 12 Jan 2008 20:01:58 +0100 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <4788C323.firstname.lastname@example.org> On Saturday, 12 of January 2008, Rene Herman wrote: > On 12-01-08 12:12, Pierre Ossman wrote: > > > On Sat, 12 Jan 2008 02:23:27 +0100 > > Rene Herman <email@example.com> wrote: > > > >> Pavel, Rafael -- the attached fixes snd-cs4236 not coming back to life for > >> Ondrej after hibernation due to the PNP_DRIVER_RES_DO_NOT_CHANGE test > >> triggering in pnp_bus_resume() and keeping the card in a suspended state. > >> > > > > I'm a bit confused here. Bjorn Helgaas wanted to remove the pnp_start/stop_dev() calls completely, and you want them called all the time. :) > > Wanted where? Haven't seen a coment from Bjorn? But -- while removing them > both looks (as) sensible from a mirror-image viewpoint, this wouldn't fix > the problem. > > As fas as I understand things, "hibernation" is basically "save state, shut > down machine" where the latter step is going to disable the card inevitably. Not exactly. In the ACPI (aka platform) mode it's: - pretend we're suspending and put everything into low power states - snapshot memory - power everything up - save image - suspend (ie. enter S4, suspending devices before). > On resume, you're going to need to restore the resources (that were saved in > pnp_dev->res) that it was using to the card, which is what pnp_start_dev() > does -- it not being called is the current problem of the card not coming > back to life. First of all, the card need not be initialized at all before .resume() is called. > pnp_stop_dev() could go in this specific situation. Not much point in first > disabling the thing it seems if a subsequent shutdown is going to take care > of that anyway. However, suspend/resume isn't just called in the case of > complete hibernation I guess and I know nothing about it all -- hence my > request to the hiberhation people for how this is designed to be. .suspend()/.resume() are used during suspend to RAM too. As far as hibernation is concerned, .resume() is used for two different purposes: (a) to bring the device up after it's been put into a low power state for snapshotting memory (b) to bring the device up (or reconfigure it if brought up already) after the hibernation image has been loaded and we're restoring the previous system state. > But we certainly need the pnp_start_dev() in the current flow of things. It > not being called is the problem this fixes... Yes, pnp_start_dev() is generally needed in .resume(). Thanks, Rafael
prev parent reply other threads:[~2008-01-12 18:59 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2008-01-09 22:43 PNP_DRIVER_RES_DISABLE breaks swsusp at least with snd_cs4236 Ondrej Zary 2008-01-10 1:53 ` [alsa-devel] " Rene Herman 2008-01-10 7:58 ` Jaroslav Kysela 2008-01-11 1:19 ` Rene Herman 2008-01-11 7:01 ` Pierre Ossman 2008-01-11 14:21 ` Rene Herman 2008-01-11 18:40 ` Ondrej Zary 2008-01-12 1:23 ` Rene Herman 2008-01-12 11:12 ` Pierre Ossman 2008-01-12 13:39 ` Rene Herman 2008-01-12 15:21 ` Pierre Ossman 2008-01-12 16:46 ` Ondrej Zary 2008-01-12 17:00 ` Rene Herman 2008-01-12 19:08 ` Rafael J. Wysocki 2008-01-12 20:08 ` -mm: pnp-do-not-stop-start-devices-in-suspend-resume-path.patch breaks resuming isapnp cards Rene Herman 2008-01-13 5:50 ` Bjorn Helgaas 2008-01-13 6:13 ` Rene Herman 2008-01-14 22:26 ` Bjorn Helgaas 2008-01-14 23:46 ` Rene Herman 2008-01-15 7:51 ` Jaroslav Kysela 2008-01-16 17:46 ` Bjorn Helgaas 2008-01-16 18:03 ` Ondrej Zary 2008-01-16 18:16 ` Rene Herman 2008-01-12 19:01 ` Rafael J. Wysocki [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).