MTD PM Resume

I found some information pertinent to this question in doing searching, but not a definite resolution.

We're doing a Linux port (kernel 2.6.11) to the iPAQ hx4700, which uses a stacked StrataFlash. The hx4700 has flash that lock all blocks on reset or power down. We worked around this problem by unlocking all the pertinent blocks in the boot loader, but for reasons I won't go into, this doesn't work on resume.

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.

mtdcore.c uses pm_register() to register its callback function (mtd_pm_callback()), and this API is apparently deprecated. If it's marked deprecated, though, it should still work, so I'm wondering if anyone knows why the suspend/resume functions for MTD devices are not being called. Any other suggestions also appreciated.

In the mean while, we'll continue to investigate.
Thanks.

Todd Blumer wrote:
...

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

On Fri, Jun 03, 2005 at 06:24:34PM -0700, Todd Poynor wrote:
...

Here's an example of how it might be done via a board mapping driver, for the PXA27x Mainstone board. I'm not sure if this is the ultimate in mtd + ldm + pm integration, but it's something. Any comments appreciated.

Index: linux-2.6.12/arch/arm/mach-pxa/mainstone.c
===================================================================
@@ -189,6 +189,11 @@
 	.dev		= { .platform_data = &mst_audio_ops },
 };
 
+static struct platform_device mainstone_flash_device = {
+	.name		= "mainstone-flash",
+	.id		= -1,
+};
+
 static void mainstone_backlight_power(int on)
 {
 	if (on) {

@@ -304,6 +309,7 @@
 
 	platform_device_register(&smc91x_device);
 	platform_device_register(&mst_audio_device);
+	platform_device_register(&mainstone_flash_device);
 
 	/* reading Mainstone's "Virtual Configuration Register"
 	   might be handy to select LCD type here */