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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
