On Fri, Feb 5, 2010 at 5:20 AM, Tony Lindgren <tony@xxxxxxxxxxx> wrote:
> * Vimal Singh <vimal.newwork@xxxxxxxxx> [100112 22:51]:
>> From 994785b066a9bd4fbaf7753cb6ab7317440afd36 Mon Sep 17 00:00:00 2001
>> From: Vimal Singh <vimalsingh@xxxxxx>
>> Date: Tue, 12 Jan 2010 17:22:42 +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
>
> <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);
>> +}
>
> Related to the comments for gpmc-nand.c, you can now get rid of the
> gpmc_cs_baseaddr hardcoding in the board-*.c files. The address gets
> assigned by gpmc_cs_request based on the chip select and size.
This (gpmc_cs_baseaddr) is passed to OMAP NAND driver (nand/omap2.c)
for its uses.
This is base address to GPMC Registers for CS where NAND is present.
And this will be used by functions like "omap_hwcontrol" to access
GPMC NAND COMMAND, GPMC NAND ADDRESS and GPMC NAND DATA etc CS
specific registers.
And of course, nand driver should not know at which 'cs' nand device
is connected, correct?
So, this information is passed from board.
--
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
