On Fri, Jul 17, 2009 at 02:48:38PM +0400, Ilya Yanok wrote:
Scott Wood wrote:
Please look at drivers/mtd/nand/mpc5121_nfc.c, which AFAICT is very similar hardware, and see if anything can be factored out into common code, and try to keep the rest looking the same except where the hardware actually differs.
Hmm... For now we just can't spend enough effort for this...
Understood -- but I have to grumble about it regardless. :-)
+/*
- This function requests the NANDFC to perform a read of the
- NAND device status and returns the current status.
- */
+static uint16_t get_dev_status(struct mxc_nand_host *host) +{
- void __iomem *main_buf = host->regs->main_area1;
- uint32_t store;
- uint16_t ret, tmp;
- /* Issue status request to NAND device */
- /* store the main area1 first word, later do recovery */
- store = readl(main_buf);
- /*
* NANDFC buffer 1 is used for device status to prevent* corruption of read/write buffer on status requests.*/- writew(1, &host->regs->nfc_buf_addr);
But it looks like buffer 1 is used for data with large page flash.
Well, we save first word of the buffer and then recover it.
So then there's no longer any special reason to use buffer 1 for status, and that comment is misleading...
Other drivers don't seem to have any problem with status reads clobbering the buffer...
What's different about this hardware in that regard? I'm wondering if you're being more tolerant than you need to be of status requests coming in at odd times.
According to Magnus Lilja, "the nand flash controller can only handle 32 bit read/write operations, any other size will cause an abort (or something like that)". But now we're accessing it as 16-bit?
16-bit accesses work quite well. Problem was with 8-bit accesses.
OK. But in that case I'd think it would have been simpler to use 16-bit accesses rather than 32-bit when emulating byte accesses in read_buf()/write_buf().
col should never be odd if you're reading words.
It can be odd if previously we've read a byte.
I don't think that accesses will ever be mixed in that way -- correct me if I'm wrong.
In fact, I only see one use of read_word, which is to read the bad block marker.
- host->pagesize_2k = 0;
So large page is currently unsupported?
Linux driver was fixed recently and now it claims to support 2K page size... I've added all needed fixes but I can understand how this driver should detect the pagesize... Linux driver calls nand_scan_ident() itself for this... Do you think I can calls nand_scan_ident() from my board_nand_init() function?
No, at the moment you should probably just hard code it in the board config file. I need to find some time to rework the NAND init mechanism to be driven more from platform code so that it can split up nand_scan_ident() and nand_scan_tail().
-Scott