From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Subject: Re: suspend.c vs driver-model.txt Date: Tue, 30 Jul 2002 10:04:17 +0200 Sender: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Message-ID: <20020730080418.11907@192.168.4.1> References: <20020729190219.GD13729@elf.ucw.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20020729190219.GD13729-I/5MKhXcvmPrBKCeMvbIDA@public.gmane.org> Errors-To: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: To: Pavel Machek Cc: Patrick Mochel , acpi-devel-pyega4qmqnRoyOMFzWx49A@public.gmane.org List-Id: linux-acpi@vger.kernel.org > >There's power cycle and whole kernel bootup. Device state is >completely lost during suspend to disk. As it is during suspend-to-ram in most cases (most devices except a couple of them are actually powered down and the drivers have to bring them back up, at least on pmac, though on x86, the APM BIOS helps you a bit there). So basically, drivers are responsible to bring back the device in whatever state it was at the save_state step of the suspend, in the same way for but suspend to disk and to RAM. What I want to make sure is that the driver-side semantics remain the same for swsusp and suspend-to-RAM. That includes the fact that save state will actually block IOs, and that is necessary to have a coherent state among devices. Note that you don't need to run the last step of driver notification though (the actual "suspend" state), this will save you the disk powercycle effect on suspend. Ben. ------------------------------------------------------- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31