> > + * Board support header for OMAP4430 SDP. > > + * > > + * Copyright (C) 2009 Texas Instruments > > + * > > + * Author: Santosh Shilimkar <santosh.shilimkar@xxxxxx> > > + * > > + * Based on arch/arm/plat-omap/include/mach/board-3430sdp.h > > + * > > + * This program is free software; you can redistribute it > and/or modify > > + * it under the terms of the GNU General Public License > version 2 as > > + * published by the Free Software Foundation. > > + */ > > +#ifndef __ARCH_ARM_MACH_OMAP4_BOARD_4430SDP_H > > +#define __ARCH_ARM_MACH_OMAP4_BOARD_4430SDP_H > > + > > +extern void sdp4430_flash_init(void); > > + > > +/* NAND */ > > +#define DEBUG_BASE 0x08000000 /* debug board */ > > +#define NAND_BASE 0x0C000000 /* NAND flash */ > > +#define ONENAND_MAP 0x20000000 /* OneNand flash */ > > + > > +/* various memory sizes */ > > +#define FLASH_SIZE_SDPV1 SZ_64M > > +#define FLASH_SIZE_SDPV2 SZ_128M > > +#endif > > + > > Let's leave out the board-4430sdp.h and move the defines to > the board-4430sdp.c. > > Also it sounds like the NAND defines are not yet needed. I'm thinking > that we should have just a generic gpmc-onenand.c file based on the > board-n800-flash.c that works for all boards with onenand connected > to the GPMC. Yes. This was added as a place holder since next NAND driver patches would need that. Sounds ok to me but may be Nand driver owner might have some comments on the same. We can take this up later when adding NAND support. For now I agree with you point. > b/arch/arm/plat-omap/include/mach/omap44xx.h > IO_ADDRESS(OMAP44XX_SCU_BASE) > > +#define OMAP44XX_LOCAL_TWD_BASE 0x48240600 > > +#define OMAP44XX_VA_LOCAL_TWD_BASE > IO_ADDRESS(OMAP44XX_LOCAL_TWD_BASE) > > +#define OMAP44XX_LOCAL_TWD_SIZE 0x00000100 > > +#define OMAP44XX_WKUPGEN_BASE 0x48281000 > > +#define OMAP44XX_VA_WKUPGEN_BASE > IO_ADDRESS(OMAP44XX_WKUPGEN_BASE) > > Could these defines have just OMAP4_ prefix? If some later omap4 > changes these, we can define them separately with the correct > prefix. I have kept this just to keep uniformity. Also generally we will have derivatives of ICs and this defines would Help there. Instead of modifying later we can keep this way. Regards Santosh-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
