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