[U-Boot] [PATCH] ARM DaVinci: Adding CONFIG options for NAND ALE and CLE

[David Brownell]

Hi Sandeep,

On Tuesday 28 April 2009, Paulraj, Sandeep wrote:
> > 
> > I had been thinking that the davinci_nand driver should
> > probably change to let board_nand_init() really become a
> > board-specific function...
> > 
> > It would call a driver routine to init the callback functions
> > and set up private data so that for example the 2GByte NAND
> > could be properly treated as a single device with two chips,
> > instead of two separate devices.  (As Linux does; I'm just
> > assuming that mechanism works right in U-Boot.)
> 
> [Sandeep] At the U-Boot level do we really need this mechanism?

I think it will improve Linux interop.

For example, the MTDPART support in U-Boot provides a string
that can be passed on the kernel command line to ensure that
U-Boot and Linux use the same partitioning.

But ... that won't work very well if Linux sees one big device,
while U-Boot sees two smaller ones.  That "mtdpart=..." command
line string won't work for Linux.

 
> > Other private data could include CLE/ALE masks, if needed.
>
> [Sandeep] This is the way we do it in the kernel. Again does
> U-boot really need this much sophistication.

Erm, the 2.6.30 code (and davinci-git) passes the masks in
through platform_data; they're not fixed at compile time.


> > That is, the u-boot davinci_nand.c code could
> > 
> > 	#ifndef CONFIG_SYS_DAVINCI_NAND_CLE
> > 	... #define it to the default 0x10 ...
> > 	#endif
>
> [Sandeep] It is my personal opinion that we should try to
> avoid such #ifdefs in the driver. I would just define all
> these in the config.h file. Let me know your opinion.

The place to *really* avoid #ifdefs is inside C functions.
I could agree that putting such defaults into the DaVinci
"nand.h" header might be prettier.

But I'd like to keep the config.h files free of such stuff.
Especially, free of stuff that doesn't change from board
to board (except in unusual cases).


> We will need such a #ifndef for the CLE as well so I would
> just put both the values in the config.h rather than have
> 2 #ifndefs in the NAND driver

Well, "nand.h" would be better.  Especially considering
that board using a non-default values are uncommon.


> > Related: MASK_ALE should not be 0x0a by default, but 0x08;
> > right? 
>
> [Sandeep] That is what I use in the internal LSP releases
>
> >	 That's what newer docs say; I think the old stuff
> > was just a bug.  In Linux, 0x08 works just fine.
>
> [Sandeep] Yes that is correct. I was going to send an e-mail
> tomorrow to see if anyone had any objections to me changing this value 

Nah ... just fixit.  ;)

- Dave