public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Vitaly Wool <vwool@ru.mvista.com>
To: linux-mtd@lists.infradead.org
Subject: power management routines for NAND driver
Date: Thu, 11 Aug 2005 18:19:30 +0400	[thread overview]
Message-ID: <42FB5E72.2010402@ru.mvista.com> (raw)

Hello all,

I'd like to implement power management for NAND flash on ARMv5 platform. 
However, I haven't seen any NAND driver implementing suspend/resume 
routines so I'm not sure how to do it in an appropriate way.

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.

Another way could be define the platform_device and provide its 
suspend/resume functions, that would be called during the power state 
transition. This is basically how SA1100 NOR flash mapping driver works, 
but for Intel CFI-compliant  NOR flash there're appropriate 
suspend/resume functions implemented, and NAND base driver is not the case.

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.

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) ? Isn't it appropriate to implement a state machine here similar 
to NOR CFI's one?

TIA!

Vitaly

             reply	other threads:[~2005-08-11 14:19 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-11 14:19 Vitaly Wool [this message]
2005-08-11 15:09 ` power management routines for NAND driver Thomas Gleixner
2005-08-11 15:25   ` Vitaly Wool
2005-08-11 16:25     ` Thomas Gleixner
2005-08-12 15:11   ` Vitaly Wool
2005-08-12 15:36     ` Thomas Gleixner
2005-08-12 15:41       ` Thomas Gleixner
2005-08-12 15:55       ` Vitaly Wool
2005-08-12 16:16         ` Thomas Gleixner
2005-08-12 16:46           ` Vitaly Wool
2005-08-22 12:54             ` Vitaly Wool
2005-08-12 15:57       ` Vitaly Wool
2005-08-11 20:23 ` Todd Poynor
2005-08-11 20:31   ` Thomas Gleixner
2005-08-11 20:49     ` Vitaly Wool
2005-08-11 20:53       ` Thomas Gleixner
2005-08-11 20:55         ` Josh Boyer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=42FB5E72.2010402@ru.mvista.com \
    --to=vwool@ru.mvista.com \
    --cc=linux-mtd@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox