MTD PM Resume
Todd Poynor
tpoynor at mvista.com
Fri Jun 3 21:24:34 EDT 2005
Todd Blumer wrote:
...
> So, we added some code to drivers/mtd/chips/cfi_cmdset_0001.c in
> cfi_intelext_resume() to unlock the blocks of the flash chips on resume.
> However, cfi_intelext_resume() is not be run on resume. In fact, as far
> as I can tell, pm_send() is not being called in kernel/power/pm.c on
> suspend or resume.
Hi, I'm not sure what calls the APM-style deprecated interfaces anymore...
If you initiated the suspend via a call to pm_suspend() or
/sys/power/state then LDM suspend/resume driver methods will be called,
and it looks like nothing in the mtd core will automatically register
drivers or devices in LDM. There are existing examples of registering
with LDM in some map drivers, registering a driver with the platform
bus. Looks like boards that power cycle flash chips for certain sleep
states need to also register a device, and add suspend/resume callbacks
in the struct_driver that end up calling the chip driver suspend/resume
methods (even if they don't use flash that powers up locked, since the
mtd state machine needs to be reset to assume the flash chips are in
ready state). Documentation/power/devices.txt has some more info on
those interfaces.
Or if anybody has a better way to handle this I'm all ears. A class
device for generic mtd might do it, not sure.
You just reminded me I need to figure out how to do this for a couple of
boards, thanks. If there's no disagreement on the above being the
correct approach I'll float a patch soon.
--
Todd
More information about the linux-mtd
mailing list