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, 7 Dec 2009 10:36:01 -0800 [thread overview]
Message-ID: <20091207183600.GF24013@atomide.com> (raw)
In-Reply-To: <ce9ab5790912062240i1ca4d8eemcc46e6bc19ecb8f6@mail.gmail.com>
* 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?
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
next prev parent reply other threads:[~2009-12-07 18:35 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-03 14:10 [PATCH 1/2]: OMAP: SDP: Introducing 'board-sdp-flash.c' for flash init Vimal Singh
2009-12-04 22:17 ` Tony Lindgren
2009-12-07 6:40 ` Vimal Singh
2009-12-07 18:36 ` Tony Lindgren [this message]
2009-12-14 9:59 ` Vimal Singh
2009-12-14 19:31 ` Tony Lindgren
2009-12-22 8:51 ` Vimal Singh
2010-01-04 10:20 ` Vimal Singh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091207183600.GF24013@atomide.com \
--to=tony@atomide.com \
--cc=linux-omap@vger.kernel.org \
--cc=vimal.newwork@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.