public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH 1/2]: OMAP: SDP: Introducing 'board-sdp-flash.c' for flash init
@ 2009-12-03 14:10 Vimal Singh
  2009-12-04 22:17 ` Tony Lindgren
  0 siblings, 1 reply; 8+ messages in thread
From: Vimal Singh @ 2009-12-03 14:10 UTC (permalink / raw)
  To: linux-omap; +Cc: Tony Lindgren

>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
@@ -0,0 +1,246 @@
+/*
+ * board-sdp-flash.c
+ * Modified from mach-omap2/board-3430sdp-flash.c
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Copyright (C) 2009 Texas Instruments
+ *
+ * Vimal Singh <vimalsingh@ti.com>
+ *
+ * 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.
+ */
+
+#include <linux/kernel.h>
+#include <linux/platform_device.h>
+#include <linux/io.h>
+
+#include <asm/mach/flash.h>
+#include <plat/gpmc.h>
+#include <plat/nand.h>
+#include <plat/onenand.h>
+#include <mach/board-sdp.h>
+
+#define REG_FPGA_REV			0x10
+#define REG_FPGA_DIP_SWITCH_INPUT2	0x60
+#define MAX_SUPPORTED_GPMC_CONFIG	3
+
+#define DEBUG_BASE		0x08000000 /* debug board */
+
+#define PDC_NOR		1
+#define PDC_NAND	2
+#define PDC_ONENAND	3
+#define DBG_MPDB	4
+
+/* various memory sizes */
+#define FLASH_SIZE_SDPV1	SZ_64M	/* NOR flash (64 Meg aligned) */
+#define FLASH_SIZE_SDPV2	SZ_128M	/* NOR flash (256 Meg aligned) */
+
+/*
+ * SDP3430 V2 Board CS organization
+ * Different from SDP3430 V1. Now 4 switches used to specify CS
+ *
+ * See also the Switch S8 settings in the comments.
+ *
+ * REVISIT: Add support for 2430 SDP
+ */
+static const unsigned char chip_sel_sdp[][GPMC_CS_NUM] = {
+	{PDC_NOR, PDC_NAND, PDC_ONENAND, DBG_MPDB, 0, 0, 0, 0}, /* S8:1111 */
+	{PDC_ONENAND, PDC_NAND, PDC_NOR, DBG_MPDB, 0, 0, 0, 0}, /* S8:1110 */
+	{PDC_NAND, PDC_ONENAND, PDC_NOR, DBG_MPDB, 0, 0, 0, 0}, /* S8:1101 */
+};
+
+static struct flash_platform_data sdp_nor_data = {
+	.map_name	= "cfi_probe",
+	.width		= 2,
+};
+
+static struct resource sdp_nor_resource = {
+	.flags		= IORESOURCE_MEM,
+};
+
+static struct platform_device sdp_nor_device = {
+	.name		= "omapflash",
+	.id		= 0,
+	.dev		= {
+			.platform_data = &sdp_nor_data,
+	},
+	.num_resources	= 1,
+	.resource	= &sdp_nor_resource,
+};
+
+static void
+__init board_nor_init(struct flash_partitions sdp_nor_parts, u8 cs)
+{
+	int err;
+
+	sdp_nor_data.parts	= sdp_nor_parts.parts;
+	sdp_nor_data.nr_parts	= sdp_nor_parts.nr_parts;
+
+	/* Configure start address and size of NOR device */
+	if (omap_rev() >= OMAP3430_REV_ES1_0) {
+		err = gpmc_cs_request(cs, FLASH_SIZE_SDPV2 - 1,
+				(unsigned long *)&sdp_nor_resource.start);
+		sdp_nor_resource.end = sdp_nor_resource.start
+					+ FLASH_SIZE_SDPV2 - 1;
+	} else {
+		err = gpmc_cs_request(cs, FLASH_SIZE_SDPV1 - 1,
+				(unsigned long *)&sdp_nor_resource.start);
+		sdp_nor_resource.end = sdp_nor_resource.start
+					+ FLASH_SIZE_SDPV1 - 1;
+	}
+	if (err < 0) {
+		printk(KERN_ERR "NOR: Can't request GPMC CS\n");
+		return;
+	}
+	if (platform_device_register(&sdp_nor_device) < 0)
+		printk(KERN_ERR	"Unable to register NOR device\n");
+}
+
+#if defined(CONFIG_MTD_ONENAND_OMAP2) || \
+		defined(CONFIG_MTD_ONENAND_OMAP2_MODULE)
+static struct omap_onenand_platform_data board_onenand_data = {
+	.dma_channel	= -1,   /* disable DMA in OMAP OneNAND driver */
+};
+
+static void
+__init board_onenand_init(struct flash_partitions sdp_onenand_parts, u8 cs)
+{
+	board_onenand_data.cs		= cs;
+	board_onenand_data.parts	= sdp_onenand_parts.parts;
+	board_onenand_data.nr_parts	= sdp_onenand_parts.nr_parts;
+
+	gpmc_onenand_init(&board_onenand_data);
+}
+#else
+static void
+__init board_onenand_init(struct flash_partitions sdp_onenand_parts, u8 cs)
+{
+}
+#endif /* CONFIG_MTD_ONENAND_OMAP2 || CONFIG_MTD_ONENAND_OMAP2_MODULE */
+
+#if defined(CONFIG_MTD_NAND_OMAP2) || \
+		defined(CONFIG_MTD_NAND_OMAP2_MODULE)
+static struct omap_nand_platform_data sdp_nand_data = {
+	.nand_setup	= NULL,
+	.dma_channel	= -1,		/* disable DMA in OMAP NAND driver */
+	.dev_ready	= NULL,
+	.devsize	= 0,	/* '0' for 8-bit, '1' for 16-bit device */
+};
+
+static void
+__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);
+}
+#else
+static void
+__init board_nand_init(struct flash_partitions sdp_nand_parts, u8 cs)
+{
+}
+#endif /* CONFIG_MTD_NAND_OMAP2 || CONFIG_MTD_NAND_OMAP2_MODULE */
+
+/**
+ * get_gpmc0_type - Reads the FPGA DIP_SWITCH_INPUT_REGISTER2 to get
+ * the various cs values.
+ */
+static u8 get_gpmc0_type(void)
+{
+	u8 cs = 0;
+	void __iomem *fpga_map_addr;
+
+	fpga_map_addr = ioremap(DEBUG_BASE, 4096);
+	if (!fpga_map_addr)
+		return -ENOMEM;
+
+	if (!(__raw_readw(fpga_map_addr + REG_FPGA_REV)))
+		/* we dont have an DEBUG FPGA??? */
+		/* Depend on #defines!! default to strata boot return param */
+		goto unmap;
+
+	/* S8-DIP-OFF = 1, S8-DIP-ON = 0 */
+	cs = __raw_readw(fpga_map_addr + REG_FPGA_DIP_SWITCH_INPUT2) & 0xf;
+
+	/* ES2.0 SDP's onwards 4 dip switches are provided for CS */
+	if (omap_rev() >= OMAP3430_REV_ES1_0)
+		/* change (S8-1:4=DS-2:0) to (S8-4:1=DS-2:0) */
+		cs = ((cs & 8) >> 3) | ((cs & 4) >> 1) |
+			((cs & 2) << 1) | ((cs & 1) << 3);
+	else
+		/* change (S8-1:3=DS-2:0) to (S8-3:1=DS-2:0) */
+		cs = ((cs & 4) >> 2) | (cs & 2) | ((cs & 1) << 2);
+unmap:
+	iounmap(fpga_map_addr);
+	return cs;
+}
+
+/**
+ * sdp3430_flash_init - Identify devices connected to GPMC and register.
+ *
+ * @return - void.
+ */
+void __init sdp_flash_init(struct flash_partitions sdp_partition_info[])
+{
+	u8		cs = 0;
+	u8		norcs = GPMC_CS_NUM + 1;
+	u8		nandcs = GPMC_CS_NUM + 1;
+	u8		onenandcs = GPMC_CS_NUM + 1;
+	u8		idx;
+	unsigned char	*config_sel = NULL;
+
+	/* REVISIT: Is this return correct idx for 2430 SDP?
+	 * for which cs configuration matches for 2430 SDP?
+	 */
+	idx = get_gpmc0_type();
+	if (idx >= MAX_SUPPORTED_GPMC_CONFIG) {
+		printk(KERN_ERR "%s: Invalid chip select: %d\n", __func__, cs);
+		return;
+	}
+	config_sel = (unsigned char *)(chip_sel_sdp[idx]);
+
+	while (cs < GPMC_CS_NUM) {
+		switch (config_sel[cs]) {
+		case PDC_NOR:
+			if (norcs > GPMC_CS_NUM)
+				norcs = cs;
+			break;
+		case PDC_NAND:
+			if (nandcs > GPMC_CS_NUM)
+				nandcs = cs;
+			break;
+		case PDC_ONENAND:
+			if (onenandcs > GPMC_CS_NUM)
+				onenandcs = cs;
+			break;
+		};
+		cs++;
+	}
+
+	if (norcs > GPMC_CS_NUM)
+		printk(KERN_INFO "OneNAND: Unable to find configuration "
+				" in GPMC\n ");
+	else
+		board_nor_init(sdp_partition_info[0], norcs);
+
+	if (onenandcs > GPMC_CS_NUM)
+		printk(KERN_INFO "OneNAND: Unable to find configuration "
+				" in GPMC\n ");
+	else
+		board_onenand_init(sdp_partition_info[1], onenandcs);
+
+	if (nandcs > GPMC_CS_NUM)
+		printk(KERN_INFO "NAND: Unable to find configuration "
+				" in GPMC\n ");
+	else
+		board_nand_init(sdp_partition_info[2], nandcs);
+}
diff --git a/arch/arm/mach-omap2/include/mach/board-sdp.h
b/arch/arm/mach-omap2/include/mach/board-sdp.h
new file mode 100644
index 0000000..a2f7ba2
--- /dev/null
+++ b/arch/arm/mach-omap2/include/mach/board-sdp.h
@@ -0,0 +1,22 @@
+/*
+ *  board-sdp.h
+ *
+ *  Information structures for SDP-specific board config data
+ *
+ *  Copyright (C) 2009 Nokia Corporation
+ *  Copyright (C) 2009 Texas Instruments
+ *
+ * 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.
+ */
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/partitions.h>
+
+struct flash_partitions {
+	struct mtd_partition *parts;
+	int nr_parts;
+};
+
+extern void sdp_flash_init(struct flash_partitions []);
+
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index e081338..4090749 100644
--- 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

 #define GPMC_CONFIG1_WRAPBURST_SUPP     (1 << 31)
 #define GPMC_CONFIG1_READMULTIPLE_SUPP  (1 << 30)
-- 
1.5.5

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH 1/2]: OMAP: SDP: Introducing 'board-sdp-flash.c' for flash init
  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
  0 siblings, 1 reply; 8+ messages in thread
From: Tony Lindgren @ 2009-12-04 22:17 UTC (permalink / raw)
  To: Vimal Singh; +Cc: linux-omap

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.

> --- 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.

Tony

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 1/2]: OMAP: SDP: Introducing 'board-sdp-flash.c' for flash init
  2009-12-04 22:17 ` Tony Lindgren
@ 2009-12-07  6:40   ` Vimal Singh
  2009-12-07 18:36     ` Tony Lindgren
  0 siblings, 1 reply; 8+ messages in thread
From: Vimal Singh @ 2009-12-07  6:40 UTC (permalink / raw)
  To: Tony Lindgren; +Cc: linux-omap

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.

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.


>
>> --- 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.

-- 
Regards,
Vimal Singh
--
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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 1/2]: OMAP: SDP: Introducing 'board-sdp-flash.c' for flash init
  2009-12-07  6:40   ` Vimal Singh
@ 2009-12-07 18:36     ` Tony Lindgren
  2009-12-14  9:59       ` Vimal Singh
  0 siblings, 1 reply; 8+ messages in thread
From: Tony Lindgren @ 2009-12-07 18:36 UTC (permalink / raw)
  To: Vimal Singh; +Cc: linux-omap

* 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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 1/2]: OMAP: SDP: Introducing 'board-sdp-flash.c' for flash init
  2009-12-07 18:36     ` Tony Lindgren
@ 2009-12-14  9:59       ` Vimal Singh
  2009-12-14 19:31         ` Tony Lindgren
  0 siblings, 1 reply; 8+ messages in thread
From: Vimal Singh @ 2009-12-14  9:59 UTC (permalink / raw)
  To: Tony Lindgren; +Cc: linux-omap

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.

-- 
Regards,
Vimal Singh
--
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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 1/2]: OMAP: SDP: Introducing 'board-sdp-flash.c' for flash init
  2009-12-14  9:59       ` Vimal Singh
@ 2009-12-14 19:31         ` Tony Lindgren
  2009-12-22  8:51           ` Vimal Singh
  0 siblings, 1 reply; 8+ messages in thread
From: Tony Lindgren @ 2009-12-14 19:31 UTC (permalink / raw)
  To: Vimal Singh; +Cc: linux-omap

* 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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 1/2]: OMAP: SDP: Introducing 'board-sdp-flash.c' for flash init
  2009-12-14 19:31         ` Tony Lindgren
@ 2009-12-22  8:51           ` Vimal Singh
  2010-01-04 10:20             ` Vimal Singh
  0 siblings, 1 reply; 8+ messages in thread
From: Vimal Singh @ 2009-12-22  8:51 UTC (permalink / raw)
  To: Tony Lindgren; +Cc: linux-omap

On Tue, Dec 15, 2009 at 1:01 AM, Tony Lindgren <tony@atomide.com> wrote:
> * 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.
>
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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 1/2]: OMAP: SDP: Introducing 'board-sdp-flash.c' for flash init
  2009-12-22  8:51           ` Vimal Singh
@ 2010-01-04 10:20             ` Vimal Singh
  0 siblings, 0 replies; 8+ messages in thread
From: Vimal Singh @ 2010-01-04 10:20 UTC (permalink / raw)
  To: Tony Lindgren; +Cc: linux-omap

Tony,

On Tue, Dec 22, 2009 at 2:21 PM, Vimal Singh <vimal.newwork@gmail.com> wrote:
> On Tue, Dec 15, 2009 at 1:01 AM, Tony Lindgren <tony@atomide.com> wrote:
>> * 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.
>>
> 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?
>

Do you want me to re-base all patches and post them again?

> --
> Regards,
> Vimal Singh
>



-- 
Regards,
Vimal Singh
--
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

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2010-01-04 10:21 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox