Re: [PATCH 1/2]: OMAP: SDP: Introducing 'board-sdp-flash.c' for flash init

From: Tony Lindgren <tony@atomide.com>
To: Vimal Singh <vimal.newwork@gmail.com>
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 1/2]: OMAP: SDP: Introducing 'board-sdp-flash.c' for flash init
Date: Mon, 14 Dec 2009 11:31:49 -0800	[thread overview]
Message-ID: <20091214193149.GB4575@atomide.com> (raw)
In-Reply-To: <ce9ab5790912140159o46280d86u5ceb2ba11978e388@mail.gmail.com>

* Vimal Singh <vimal.newwork@gmail.com> [091214 01:58]:
> On Tue, Dec 8, 2009 at 12:06 AM, Tony Lindgren <tony@atomide.com> wrote:
> > * Vimal Singh <vimal.newwork@gmail.com> [091206 22:39]:
> >> On Sat, Dec 5, 2009 at 3:47 AM, Tony Lindgren <tony@atomide.com> wrote:
> >> > Hi,
> >> >
> >> > * Vimal Singh <vimal.newwork@gmail.com> [091203 06:09]:
> >> >> From 13d52884956a26f93826c443e2b8bd78615f74d6 Mon Sep 17 00:00:00 2001
> >> >> From: Vimal Singh <vimalsingh@ti.com>
> >> >> 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@ti.com>
> >> >> ---
> >> >>  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.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html