public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Ben Dooks <ben@fluff.org>
To: Linux-MTD Mailing List <linux-mtd@lists.infradead.org>
Subject: NAND suspending
Date: Tue, 23 Oct 2007 17:24:14 +0100	[thread overview]
Message-ID: <20071023162414.GB12390@fluff.org.uk> (raw)

i have been working on an issue with suspend/resume with
the current NAND layer, and am interested on people's thoughts
on the issue. The problem stems from the s3c2410 driver leaving
nFCE set active (ie, low) when going into suspend, causing a
failure to resume properly (another story)

The immediate fix is just to add a call to deselect the
chip in s3c24xx_nand_suspend() by calling the internal
functions s3c2410_nand_select_chip(mtd, -1) to force nFCE
to go inactive.

I had a look through the other NAND drivers, and it seems no
other driver does anything on suspend, and having added some
debug to nand_suspend in nand_base.c, it seems that is not
being called by anything in my setup.

My question is, should my driver ensure that the MTDs it is
looking after are called from the device suspend method, and
if so, what is the appropriate call to make?2~

The next question is that once NAND suspend is called, it
should really call the nand->select_chip method to deselect
the chip when going into suspend, as the datasheet for the
K9F1208 chip quotes suspend currents when nCE is high.

A further interest is whether all possible chips attached
to the controller structure should be marked as being in
suspend, as the s3c2410 can support >1 chip connected to
it (and several of our boards have support for 2-4 chips).
Does the suspend needs to suspend all chips? At the
momemnt the nand_suspend() function uses nand_get_device
which means only one chip can be suspended (and calling
nand_release_device() will mark the chip ready again).

-- 
Ben (ben@fluff.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'

                 reply	other threads:[~2007-10-23 16:27 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20071023162414.GB12390@fluff.org.uk \
    --to=ben@fluff.org \
    --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