From: ryan@bluewatersys.com (Ryan Mallon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ep93xx: Add support for Snapper CL15 module
Date: Tue, 09 Feb 2010 14:54:35 +1300 [thread overview]
Message-ID: <4B70C05B.5060404@bluewatersys.com> (raw)
In-Reply-To: <BD79186B4FD85F4B8E60E381CAEE190902152ED3@mi8nycmail19.Mi8.com>
H Hartley Sweeten wrote:
> On Monday, February 08, 2010 1:27 PM, H Hartley Sweeten wrote:
>> +#define SNAPPERCL15_NAND_BASE (EP93XX_CS7_PHYS_BASE + SZ_16M)
>> +
>> +#define SNAPPERCL15_NAND_WPN (1 << 8) /* Write protect (active low) */
>> +#define SNAPPERCL15_NAND_ALE (1 << 9) /* Address latch */
>> +#define SNAPPERCL15_NAND_CLE (1 << 10) /* Command latch */
>> +#define SNAPPERCL15_NAND_CEN (1 << 11) /* Chip enable (active low) */
>> +#define SNAPPERCL15_NAND_RDY (1 << 14) /* Device ready */
>> +
>> +#define NAND_CTRL_ADDR(chip) (chip->IO_ADDR_W + 0x40)
>> +
>> +static unsigned long nand_state;
>> +
>> +static void snappercl15_nand_cmd_ctrl(struct mtd_info *mtd, int cmd,
>> + unsigned int ctrl)
>> +{
>> + struct nand_chip *chip = mtd->priv;
>> + unsigned set;
>> +
>> + if (ctrl & NAND_CTRL_CHANGE) {
>> + set = SNAPPERCL15_NAND_CEN | SNAPPERCL15_NAND_WPN;
>> +
>> + if (ctrl & NAND_NCE)
>> + set &= ~SNAPPERCL15_NAND_CEN;
>> + if (ctrl & NAND_CLE)
>> + set |= SNAPPERCL15_NAND_CLE;
>> + if (ctrl & NAND_ALE)
>> + set |= SNAPPERCL15_NAND_ALE;
>> +
>> + nand_state &= ~(SNAPPERCL15_NAND_CEN |
>> + SNAPPERCL15_NAND_CLE |
>> + SNAPPERCL15_NAND_ALE);
>> + nand_state |= set;
>> + __raw_writew(nand_state, NAND_CTRL_ADDR(chip));
>> + }
>> +
>> + if (cmd != NAND_CMD_NONE)
>> + __raw_writew((cmd & 0xff) | nand_state, chip->IO_ADDR_W);
>> +}
>>
>> It's possible (though unlikely) for 'nand_state' to start off with an
>> unknown value. The upper layers could call the function without
>> NAND_CTRL_CHANGE set the first time.
I think the NAND sub-system guarantees this wont' happen.
>> You can use the gen_nand .probe callback to set the initial value.
>> This keeps you from having to keep the static 'first' variable that
>> used to be in the patch.
I could just change the initialisation of nand_state to:
static unsigned long nand_state = SNAPPERCL15_NAND_WPN;
Rather than having a probe function. However, I don't think even this is
necessary.
> Actually, do you even need to save a cached value for 'nand_state'?
>
> 1) The write to NAND_CTRL_ADDR sets all the control lines.
> 2) The write to IO_ADDR_W 'writes' the command to the chip.
I'm working based on a driver written for our 2.6.20 kernel (not by me),
and it uses the cached value there too. I tried making nand_state local
to the cmd_ctrl function but it doesn't work correctly. It correctly
identifies the chip, but then marks every block on the NAND as bad.
> Do you really need to OR nand_state with the cmd?
It appears so. Removing nand_state, or even replacing with just
SNAPPERCL15_NAND_WPN does not work.
~Ryan
--
Bluewater Systems Ltd - ARM Technology Solution Centre
Ryan Mallon 5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com New Zealand
Phone: +64 3 3779127 Freecall: Australia 1800 148 751
Fax: +64 3 3779135 USA 1800 261 2934
next prev parent reply other threads:[~2010-02-09 1:54 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-04 20:57 [PATCH] ep93xx: Add support for Snapper CL15 module Ryan Mallon
2010-02-04 21:35 ` H Hartley Sweeten
2010-02-04 21:52 ` Ryan Mallon
2010-02-07 20:02 ` Ryan Mallon
2010-02-08 17:11 ` H Hartley Sweeten
[not found] ` <BD79186B4FD85F4B8E60E381CAEE190902152E91@mi8nycmail19.Mi8.com>
2010-02-08 20:12 ` Ryan Mallon
2010-02-08 20:27 ` H Hartley Sweeten
2010-02-08 20:52 ` H Hartley Sweeten
2010-02-09 1:54 ` Ryan Mallon [this message]
2010-02-09 19:41 ` Ryan Mallon
2010-02-10 2:54 ` Ryan Mallon
2010-02-10 3:07 ` H Hartley Sweeten
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=4B70C05B.5060404@bluewatersys.com \
--to=ryan@bluewatersys.com \
--cc=linux-arm-kernel@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