Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 8BIT
Subject: RE: suspend/resume support for driver requires an external firmware
Date: Tue, 28 Sep 2004 13:31:47 +0800
Message-ID: <3ACA40606221794F80A5670F0AF15F8403BD57A0@pdsmsx403>
Thread-Topic: suspend/resume support for driver requires an external firmware
Thread-Index: AcSlF2gzCUz8dVg/RZOC3ST15GHeWAAApEnw
From: "Zhu, Yi" <yi.zhu@intel.com>
To: "Patrick Mochel" <mochel@digitalimplant.org>
Cc: "Dmitry Torokhov" <dtor_core@ameritech.net>,
       <linux-kernel@vger.kernel.org>,
       "Denis Vlasenko" <vda@port.imtp.ilyichevsk.odessa.ua>,
       "Oliver Neukum" <oliver@neukum.org>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1178
Lines: 28

Patrick Mochel wrote:
> I presume you're not talking about doing swsusp over NFS. If
> so, there's a lot more work to be done to teach the driver
> model and power management infrastructure about the
> dependencies involved to make that a possibility.
> It's safe to say that we don't support that, and won't
> support that at least for some time.

Then let's talk about S3 (suspend to ram), I think it should be
OK with a mounted NFS root, but the firmware issue is still there.

> As far as the firmware goes, there are two choices - reload
> it from userspace once we return or save it memory during
> suspend. I assume that these devices provide some means for
> reading the firmware from them, so you can just allocate a
> buffer and read it into that during the transition.

Agreed. I think now we need a clean interface that makes
drivers, swsusp or even the end user to work together to
finally achieve the goal.

Thanks,
-yi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/