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
next 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