power management routines for NAND driver

Thomas Gleixner tglx at linutronix.de
Thu Aug 11 11:09:19 EDT 2005


On Thu, 2005-08-11 at 18:19 +0400, Vitaly Wool wrote:
> Hello all,

> I've looked through mtd code and found mtd_pm_callback that should be 
> called to handle PM events. This callback should in turn call 
> mtd->suspend/mtd->resume functions, if any. Therefore one evident way of 
> PM stuff implementation for this NAND flash is to provide suspend/resume 
> functions. However, pm_send (that calls mtd_pm_callback) is never called
> on ARM targets. So I doubt if it's appropriate to implement PM for the 
> driver this way since it's looking somehow obsolete.

I have no idea whats the state of those PM functions and why ARM is not
using them.

> So, unfortunately, both methods don't provide the level of integrity I'd 
> like to have. The problem is that nand core has no state machine in its 
> internals so the driver can't track the flash being in suspended state.

As far as I know the nand driver code, there is a member "state" in the
nand_chip private data structure, which is exactly tracking the state of
the device. 

FL_READY, FL_READING, FL_WRITING, FL_ERASING, FL_SYNCING, FL_CACHEDPRG,
are the currently implemented states. Adding FL_SUSPEND is not a big
problem.

All functions which access the FLASH device are serialized by
nand_get_device(), where the state variable is modified. So adding a
suspend/resume function is simple enough.

suspend justs sets the state to FL_SUSPEND and resume releases the
device by calling nand_release_device() which sets the state back to
FL_READY and wakes up the tasks on the wait_queue.

It's discussable, whether suspend is supposed to fail, when a flash
operation is in progress or just waits until the operation is finished,
which is usually only a matter of a couple of ms.

Of course we need an additional board function pointer in struct
nand_chip to have a board specific callback for suspend/resume
operations.

> Could you point me how can I synchronize access requests to the flash 
> with suspend/resume calls (e.g., fail requests when flash is in suspend 
> state) ? 

Fail requests in suspend state needs more modifications. 

The current serialization in nand_get_device would stall the calling
task and add it to the wait_queue and woken up again in the resume /
nand_release_device() path.

>From my POV this is not a bad way to go.

> Isn't it appropriate to implement a state machine here similar 
> to NOR CFI's one?

See above. :)

tglx






More information about the linux-mtd mailing list