Re: [PATCH] MTD Maps driver for Sharp LH7a40x

["Thomas Gleixner" <tglx@linutronix.de>]

On Saturday 19 June 2004 02:38, Marc Singer wrote:
> > The common case can just be solved by using the physmap driver and the
> > command line partition parser. Maybe we should think about an extension
> > to physmap so the board support code can supply an appropriate
> > partitioning scheme along with the chip description.
> >
> > I was thinking about simliar support for the NAND driver too, but there
> > it turns out that the anomalities are given per design, although it
> > should not be an unsolvable problem.
>
> I've chatted with Russell King about this, too.  I think we agree that
> board-specific code would be a bad idea.  The better solution appears
> to be something on the command line.  I'm going to look into it.  For
> now, consider this PATCH discarded.

Yes, for the common case where we dont have special functions neccecary the 
commandline resp. ATAG (unfortunately only for ARM) is the right place.
This works if the only information which is neccecary is

base address, size and buswidth. 

Russell, can you please give define two ATAG numbers for this purpose ? 
ATAG_MTD_PHYSMAP and 
ATAG_MTD_PARTITION
I would be happy to provide the data structures and parsers to make this work.

BUT,

For chips which need Vpp setting for programming and erasing this is rather 
impossible. Same applies to NAND drivers, as the NAND interface can hardly be 
specified board independent on the commandline.

For general purpose boards (PCI, PC104 whatever) drivers/mtd/ is surely the 
right place. For embedded boards I'm not sure if it makes sense to have all 
this code in the mtd subsystem or if it would be better to have this in the 
board specific code in arch/xxx/boards/myboard.c which is there anyway.

Another possiblity would be to include a hardware related header file in the 
physmap driver and the to be written counterpart for NAND.

#define BOARD_SPECIFIC_MTD_FUNCTIONS
#include <asm/hardware.h>

asm/hardware.h includes board_hardware.h if available.

Inside board_hardware.h then we would have

#ifdef BOARD_SPECIFIC_MTD_FUNCTIONS
board_mtd_functionA(){}
board_mtd_functionB(){}
(nand)pyhsmap chip = {
	.address = xxxx;
	.....
	.functionA = board_mtd_functionA;
	.functionA = board_mtd_functionB;
}
#endif

Not all arch's provide a hardware.h file but this should be a solvable 
problem. For ARM this should work right out of the box.

I know it looks weird in the first place, but it could be one of the possible 
solutions to solve the board support mess. Russell uses a similar approach 
for the timer init and interrupt handler for the various subarchs of ARM 
since long.

Any thoughts ?

-- 
Thomas
_____________________________________________________________________
From slash dot org
"When customers are visiting, engineers are not allowed to wear ties. 
That way the customer can tell who is the engineer and who is the 
salesman (and therefore whom to believe.). Ties cut off blood flow 
to the brain, making it easier for the salesmen to do their jobs." 
_____________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de