On Tue, Dec 15, 2009 at 1:01 AM, Tony Lindgren <tony@xxxxxxxxxxx> wrote: > * Vimal Singh <vimal.newwork@xxxxxxxxx> [091214 01:58]: >> On Tue, Dec 8, 2009 at 12:06 AM, Tony Lindgren <tony@xxxxxxxxxxx> wrote: >> > * Vimal Singh <vimal.newwork@xxxxxxxxx> [091206 22:39]: >> >> On Sat, Dec 5, 2009 at 3:47 AM, Tony Lindgren <tony@xxxxxxxxxxx> wrote: >> >> > Hi, >> >> > >> >> > * Vimal Singh <vimal.newwork@xxxxxxxxx> [091203 06:09]: >> >> >> From 13d52884956a26f93826c443e2b8bd78615f74d6 Mon Sep 17 00:00:00 2001 >> >> >> From: Vimal Singh <vimalsingh@xxxxxx> >> >> >> Date: Thu, 26 Nov 2009 16:10:24 +0530 >> >> >> Subject: [PATCH] OMAP: SDP: Introducing 'board-sdp-flash.c' for flash init >> >> >> >> >> >> This patch adds 'board-sdp-flash.c', which could be utilized >> >> >> by boards similar to 3430SDP. (For ex: 2430sdp, 36030sdp). >> >> >> >> >> >> This file does initialization for all three flash devices present >> >> >> in SDP boards (NOR, NAND, OneNAND), by finding there 'cs' number >> >> >> dynamically using switch setting information (S8: 1-4). >> >> >> This also expects partition information from core board files (for >> >> >> ex: board-3430sdp.c). Which allows to choose different default >> >> >> partitions for different boards. >> >> >> >> >> >> A new structure is created for this purpose: 'flash_partitions' >> >> >> in 'mach/board-sdp.h'. This has two members: >> >> >> 1. struct mtd_partition *parts >> >> >> 2. int nr_parts >> >> >> >> >> >> A board file is expected to fill this structure and pass it to >> >> >> 'sdp-flsash-init'. Partition information should be passed in >> >> >> structure array of 'flash_partitions'. Partition information should >> >> >> be passed in below sequence in array: >> >> >> NOR >> >> >> OneNAND >> >> >> NAND >> >> >> >> >> >> Signed-off-by: Vimal Singh <vimalsingh@xxxxxx> >> >> >> --- >> >> >> arch/arm/mach-omap2/board-sdp-flash.c | 246 ++++++++++++++++++++++++++ >> >> >> arch/arm/mach-omap2/include/mach/board-sdp.h | 22 +++ >> >> >> arch/arm/plat-omap/include/plat/gpmc.h | 2 + >> >> >> 3 files changed, 270 insertions(+), 0 deletions(-) >> >> >> create mode 100644 arch/arm/mach-omap2/board-sdp-flash.c >> >> >> create mode 100644 arch/arm/mach-omap2/include/mach/board-sdp.h >> >> >> >> >> >> diff --git a/arch/arm/mach-omap2/board-sdp-flash.c >> >> >> b/arch/arm/mach-omap2/board-sdp-flash.c >> >> >> new file mode 100644 >> >> >> index 0000000..fbbcd0e >> >> >> --- /dev/null >> >> >> +++ b/arch/arm/mach-omap2/board-sdp-flash.c >> >> > >> >> > <snip> >> >> > >> >> >> +__init board_nand_init(struct flash_partitions sdp_nand_parts, u8 cs) >> >> >> +{ >> >> >> + sdp_nand_data.cs = cs; >> >> >> + sdp_nand_data.parts = sdp_nand_parts.parts; >> >> >> + sdp_nand_data.nr_parts = sdp_nand_parts.nr_parts; >> >> >> + >> >> >> + sdp_nand_data.gpmc_cs_baseaddr = (void *)(OMAP34XX_GPMC_VIRT + >> >> >> + GPMC_CS0_BASE + >> >> >> + cs * GPMC_CS_SIZE); >> >> >> + sdp_nand_data.gpmc_baseaddr = (void *) (OMAP34XX_GPMC_VIRT); >> >> >> + >> >> >> + gpmc_nand_init(&sdp_nand_data); >> >> >> +} >> >> > >> >> > This does not look right. You're supposed to use gpmc_cs_request() >> >> > for allocating the GPMC area based on the chip select and size. >> >> >> >> I guess you are getting confuse a bit here: >> >> gpmc_baseaddr: is the virtual address for GPMC_REVISION (which is also >> >> base address for GPMC). >> >> gpmc_cs_baseaddr : This is offset from above to 'GPMC_CONFIG(cs)' for >> >> specified cs number. >> >> >> >> These are needed by nand driver. >> > >> > Right.. Looks like drivers/mtd/nand/omap2.c needs to be fixed so we >> > can get rid of this. >> > >> > And looks like we already are doing it all over the place anyways :( >> > >> >> While 'gpmc_cs_request' gives physical address to the device resource. >> >> And this is done in 'nand/omap2.c'. This is done in driver itself so >> >> that we don't allocate a resource even before driver gets loaded. >> > >> > Yuk.. The nand driver should be generic. >> > >> >> >> --- a/arch/arm/plat-omap/include/plat/gpmc.h >> >> >> +++ b/arch/arm/plat-omap/include/plat/gpmc.h >> >> >> @@ -27,6 +27,8 @@ >> >> >> >> >> >> #define GPMC_CONFIG 0x50 >> >> >> #define GPMC_STATUS 0x54 >> >> >> +#define GPMC_CS0_BASE 0x60 >> >> >> +#define GPMC_CS_SIZE 0x30 >> >> > >> >> > The GPMC_CS0_BASE and GPMC_CS_SIZE seem to be values specic to >> >> > your board, not for the GPMC hardware. >> >> >> >> These are offsets and very much specific to GPMC hardware. >> >> >> >> GPMC_CS0_BASE: is offset from GPMC base to first cs GPMC_CONFIG1 register. >> >> GPMC_CS_SIZE : is offset (gap) between next cs config registers, e.i. >> >> size for cs config registers. >> > >> > Let's keep it local until drivers/mtd/nand/omap2.c is fixed. >> > >> > Care to take a look at using some generic nand driver instead >> > if we merge this for now? >> >> To me it seems ok, for now, to get this merged and later we can work >> on cleaning 'nand/omap2.c' driver. > > OK, sounds good to me. Let's plan on moving to use the gpmc-nand.c as > posted on this list. > Could you please merge these patches for now? Below patches are list as "Changes Requested" in patchwork. [1/4] : OMAP: ZOOM: Introducing 'board-zoom-flash.c' for NAND init in ZOOM boards [1/2] : OMAP: SDP: Introducing 'board-sdp-flash.c' for flash init Will you take care of them or you want me to re-post them? -- Regards, Vimal Singh -- 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