[U-Boot] [PATCH 4/7] mxc_nand: add nand driver for MX2/MX3

[Scott Wood]

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