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: Mon, 27 Sep 2004 11:43:12 +0800
Message-ID: <3ACA40606221794F80A5670F0AF15F8403BD5792@pdsmsx403>
Thread-Topic: suspend/resume support for driver requires an external firmware
Thread-Index: AcSicrNk8qlP+PYtQXexEaxDauquDgBzLrtQ
From: "Zhu, Yi" <yi.zhu@intel.com>
To: "Marcel Holtmann" <marcel@holtmann.org>
Cc: "Patrick Mochel" <mochel@digitalimplant.org>,
       "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1373
Lines: 36

Marcel Holtmann wrote:
> it consumes extra runtime memory, but why not build a simple
> firmware cache behind the request_firmware() interface. 

I think this could be another choice, but I'd rather call it as a
firmware 
suspend hook. Because when the system is running, the cache 
should be purged to save memory. swsusp (or other implementations)
is required to call the firmware hook before device_suspend. The 
firmware hook is responsible to load all the necessary firmwares into
memory before suspend so that they can be read from memory in the
next request_firmware(). And we also need a firmware resume hook to
free the memory.

But how about drivers read firmware themselves? They don't rely on
firmware_class.

> In this case it can be transparent for the driver and we won't
> have an extra workaround for suspend/resume stuff for every
> driver.

I don't think it is a workaround, drivers are supposed to know best
how to "save their states". Firmware is one example for now.

> How many firmwares do a normal system really have to
> hold in memory for suspend/resume actions?

I don't know either. ;-)

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/