Re: [PATCH] omap: cleanup NAND platform data
*_nand_data)
+int __init gpmc_nand_init(struct omap_nand_platform_data *gpmc_nand_data)
{
int err = 0;
struct device *dev = gpmc_nand_device.dev;
- gpmc_nand_data = _nand_data;
- gpmc_nand_data-nand_setup = omap2_nand_gpmc_retime;
Purpose of doing this was to be able to utilise
'omap2_nand_gpmc_retime', when DVFS is ready to use it,
for changing timing parameter dynamically when a frequency change is done.
--
Regards,
Vimal Singh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Self modifying code in ARM 11 architectures
CC'ing correct ARM mailing list. On Tue, May 24, 2011 at 3:48 PM, Ashok Babu asho...@gmail.com wrote: Hi All, I am no success in booting up the ARM1176 processor with the linux-2.6.32 kernel. While googling about the ARM Harvard architecture, I came to know that we have to flush/invalidate the D-Cache and I-Cache when using the self modifying codes. So here my questions/doubts : 1) Is'nt it the kernel itself is self modifying code with lots of function pointers ? If yes, how is synchronization b/w d-cache and i-cache handled in the kernel ? 2) Can this be the reason for the kernel not booting for me ? Because If i disable the I-Cache in the config, then the kernel boots up without any issues. Any pointers on this will be of great help. Thanks Best Regards Ashok -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Regards, Vimal Singh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap : nand : fix subpage ecc issue with prefetch
On Fri, May 6, 2011 at 12:18 AM, Artem Bityutskiy dedeki...@gmail.com wrote: On Mon, 2011-05-02 at 16:40 +0530, Kishore Kadiyala wrote: For prefetch engine, read and write got broken in commit '2c01946c'. We never hit a scenario of not getting 'gpmc_prefetch_enable' call success. When reading/writing a subpage with a non divisible by 4 ecc number of bytes, the mis-aligned bytes gets handled first before enabling the Prefetch engine, then it reads/writes rest of the bytes. Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com Signed-off-by: Vimal Singh vimal.neww...@gmail.com Reported-by: Bryan DE FARIA bdefa...@adeneo-embedded.com This needs a better commit message with more explanation and analysis of the problem and how it was fixed.This commit message is not very understandable. And then it needs also: How about a commit log like this: When reading/writing a subpage (When HW ECC is not available/enable) for number of bytes not aligned to 4, the mis-aligned bytes gets handled first (by cpu copy mathod) before enabling the Prefetch engin to/from 'p' (start of buffer 'buf'). Then it reads/writes rest of the bytes with the help of Prefetch engine, if available, or again by cpu copy mathod. Currnetly, reading/writing of rest of bytes, is not done correctly. Its trying to read/write again to/from begining of buffer 'buf', overwriting the mis-aligned bytes. For prefetch engine read and write it got broken in commit '2c01946c'. And we never hit the scenario of not getting 'gpmc_prefetch_enable' call sucess. So, problem did not get caught up. This patch fixes the issue. Cc: sta...@kernel.org [2.6.36+] Right? And then we could send it upstream. Yes, sure. I think kishore can take care of adding this in 'cc' while posting next time. -- Regards, Vimal Singh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap : nand : fix subpage ecc issue with prefetch
Hi Artem,
Can you please give a look on this patch?
This patch fixes is required for anyone who wants to use this driver
without using HW ECC.
-- Vimal
On Mon, May 2, 2011 at 4:40 PM, Kishore Kadiyala
kishore.kadiy...@ti.com wrote:
For prefetch engine, read and write got broken in commit '2c01946c'.
We never hit a scenario of not getting 'gpmc_prefetch_enable'
call success.
When reading/writing a subpage with a non divisible by 4 ecc number
of bytes, the mis-aligned bytes gets handled first before enabling
the Prefetch engine, then it reads/writes rest of the bytes.
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
Signed-off-by: Vimal Singh vimal.neww...@gmail.com
Reported-by: Bryan DE FARIA bdefa...@adeneo-embedded.com
---
drivers/mtd/nand/omap2.c | 12 +---
1 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index da9a351..2c8040f 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -263,11 +263,10 @@ static void omap_read_buf_pref(struct mtd_info *mtd,
u_char *buf, int len)
if (ret) {
/* PFPW engine is busy, use cpu copy method */
if (info-nand.options NAND_BUSWIDTH_16)
- omap_read_buf16(mtd, buf, len);
+ omap_read_buf16(mtd, (u_char *)p, len);
else
- omap_read_buf8(mtd, buf, len);
+ omap_read_buf8(mtd, (u_char *)p, len);
} else {
- p = (u32 *) buf;
do {
r_count = gpmc_read_status(GPMC_PREFETCH_FIFO_CNT);
r_count = r_count 2;
@@ -293,7 +292,7 @@ static void omap_write_buf_pref(struct mtd_info *mtd,
struct omap_nand_info, mtd);
uint32_t w_count = 0;
int i = 0, ret = 0;
- u16 *p;
+ u16 *p = (u16 *)buf;
unsigned long tim, limit;
/* take care of subpage writes */
@@ -309,11 +308,10 @@ static void omap_write_buf_pref(struct mtd_info *mtd,
if (ret) {
/* PFPW engine is busy, use cpu copy method */
if (info-nand.options NAND_BUSWIDTH_16)
- omap_write_buf16(mtd, buf, len);
+ omap_write_buf16(mtd, (u_char *)p, len);
else
- omap_write_buf8(mtd, buf, len);
+ omap_write_buf8(mtd, (u_char *)p, len);
} else {
- p = (u16 *) buf;
while (len) {
w_count = gpmc_read_status(GPMC_PREFETCH_FIFO_CNT);
w_count = w_count 1;
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] omap : nand : fix omap2 module reinsertion
On Fri, Apr 29, 2011 at 4:01 PM, Bryan DE FARIA bdefa...@adeneo-embedded.com wrote: When the module is removed, a reinsertion will fail with a -16 error. Signed-off-by: Bryan DE FARIA bdefa...@adeneo-embedded.com --- drivers/mtd/nand/omap2.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c index da9a351..eab51da 100644 --- a/drivers/mtd/nand/omap2.c +++ b/drivers/mtd/nand/omap2.c @@ -1138,6 +1138,7 @@ static int omap_nand_remove(struct platform_device *pdev) /* Release NAND device, its internal structures and partitions */ nand_release(info-mtd); + release_mem_region(info-phys_base, NAND_IO_SIZE); I think using 'release_resource' would be better here. And you should better do this after below 'iounmap' is done. iounmap(info-nand.IO_ADDR_R); kfree(info-mtd); return 0; -- -- Regards, Vimal Singh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] omap : nand : fix subpage ecc issue with prefetch
On Fri, Apr 29, 2011 at 4:01 PM, Bryan DE FARIA bdefa...@adeneo-embedded.com wrote: When reading a subpage with a non dividable by 4 ecc number of byte, the prefetch function gets first the extra bytes, then reads the bytes lefting. Extra bytes are not returned in the buffer (they are overwritten), which makes the software ecc fail. Its not only read, write too is broken for the same reason. More ever, it is broken for other path too (failing to enable prefetch engine path). -- Regards, Vimal Singh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: omap2: mtd split nand_scan in ident and tail
On Mon, Apr 18, 2011 at 12:20 PM, Jan Weitzel j.weit...@phytec.de wrote: nand_scan calls nand_scan_tail and here we got a ecc.layout and calculate oobavail for this layout. After calling nand_scan, we change the layout pointer if OMAP_ECC_HAMMING_CODE_HW_ROMCODE is set. This results in not calcluated oobavail. Mountig as jffs2 is not possible. To fix that nand_scan has to split up in nand_scan_ident and nand_scan_tail setting ecc.layout between these calls. So nand_scan_tail calculates oobvail for the used layout. This is also done in serveral other platforms. v2: update commit message Move above two lines to below (as there are not part of commit log): Signed-off-by: Jan Weitzel j.weit...@phytec.de --- here. Feel free to add: Reviewed-by: Vimal Singh vimal.neww...@gmail.com Regards, Vimal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap3: nand: bch ecc support added
...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Regards, Vimal Singh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap3: nand: bch ecc support added
On Fri, Jan 21, 2011 at 9:37 AM, Ghorai, Sukumar s-gho...@ti.com wrote: -Original Message- From: Vimal Singh [mailto:vimal.neww...@gmail.com] Sent: Thursday, January 20, 2011 8:47 PM To: Ghorai, Sukumar Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org; linux-arm- ker...@lists.infradead.org; Kamat, Nishant Subject: Re: [PATCH] omap3: nand: bch ecc support added Hi Ghorai, I am the initial author of this patch. And I guess this patch still uses most of my work. [Ghorai] I know you are working on it, But I think your code was in a shape for - 1. not for up-streamble shape That's because I never posted it for up-stream. 2. non functional, No, it was a working (at least for 8-bit correction) patch on that kernel version (I do not remember the correct version now, may be .29-.30) It did not work for 4-bit, because of known reason. And I guess while posting this patch you should also have mentioned/documented about that. No? So can you check this version matching with your original code? In that case I can add your Signed-off. Yes, you should. I can see this version has got many changes, but original idea is same. And not all code is changed. Does it? Regards, Vimal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Issue : jffs2 and ecc layout
On Mon, Oct 4, 2010 at 12:59 PM, Ghorai, Sukumar s-gho...@ti.com wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Ghorai, Sukumar Sent: Tuesday, September 28, 2010 6:17 PM To: linux-...@lists.infradead.org Cc: linux-omap@vger.kernel.org Subject: Issue : jffs2 and ecc layout Hi, I was using the following ecc layout which is not working to mount the jffs2 File-system. I was in 2.6.32 kernel and working; but same layout is not working with latest 2.6 kernel. Observation is that - no read request issued to the driver (say omap2.c). # mount -t jffs2 /dev/mtdblock4 /mnt/nand [ 32.505218] cannot read OOB for EB at , requested 8 bytes, read 0 bytes, error -22 mount: Mounting /dev/mtdblock4 on /mnt/nand failed: Input/output error # dmesg 3[ 32.505218] cannot read OOB for EB at , requested 8 bytes, read 0 bytes, error -22 I do not think above issue has anything to do with the ECC layout. But as I earlier pointed (in [1]), this change [2] has messed up function 'omap_hwcontrol'. All read/write functions read/write data from/to address info-nand.IO_ADDR_(R/W), which is not set by new function 'gpmc_nand_write' (which still take care of writing address/cmd to write registers). But since above pointer is not set (hence points to address '0'), driver tries to read data from wrong location. In fact, I would even suggest to try dumping nand command registers(or use T32) and verify if commands issued were written correctly to appropriate registers. [1]: http://marc.info/?l=linux-omapm=128302624528822w=2 [2] commit: http://git.infradead.org/mtd-2.6.git/commitdiff/2c01946c6b9ebaa5a89710bc42ca224a7f52f227 -- Regards, Vimal Singh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] OMAP: NAND: Fix static declaration warning
On Wed, Oct 6, 2010 at 3:26 AM, G, Manjunath Kondaiah manj...@ti.com wrote: This patch fixes sparse warning for static declaration of variable use_dma drivers/mtd/nand/omap2.c:114:11: warning: symbol 'use_dma' was not declared. Should it be static? Signed-off-by: G, Manjunath Kondaiah manj...@ti.com Cc: linux-arm-ker...@lists.infradead.org Cc: linux-...@lists.infradead.org Cc: Tony Lindgren t...@atomide.com Cc: Nishanth Menon n...@ti.com --- Changes since v1: - no logical changes, patch seperated from series based Tony's suggestion. drivers/mtd/nand/omap2.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c index 133d515..439e80d 100644 --- a/drivers/mtd/nand/omap2.c +++ b/drivers/mtd/nand/omap2.c @@ -111,11 +111,11 @@ static int use_dma = 1; module_param(use_dma, bool, 0); MODULE_PARM_DESC(use_dma, enable/disable use of DMA); #else -const int use_dma; +static const int use_dma; #endif #else const int use_prefetch; -const int use_dma; +static const int use_dma; I did not understand, why did it not pointed same error for 'const int use_prefetch'? -- Regards, Vimal Singh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 09/10] OMAP2/3: Convert write/read functions to raw read/write
On Tue, Sep 21, 2010 at 3:31 PM, G, Manjunath Kondaiah manj...@ti.com wrote:
Following sparse warnings exists due to use of writel/w and readl/w functions.
This patch fixes the sparse warnings by converting readl/w functions usage
into
__raw_readl/__raw_readw functions.
[...]
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -481,7 +481,7 @@ static int omap_verify_buf(struct mtd_info *mtd, const
u_char * buf, int len)
len = 1;
while (len--) {
- if (*p++ != cpu_to_le16(readw(info-nand.IO_ADDR_R)))
+ if (*p++ != cpu_to_le16(__raw_readw(info-nand.IO_ADDR_R)))
There was an old comment to remove use of 'cpu_to_le16' from driver, I
just missed it. Can you rather use 'ioread16_rep' for reading data.
--
Regards,
Vimal Singh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: NAND ECC in linux-omap
Adding LO and MTD list too for more comments.
On Sat, Aug 28, 2010 at 1:40 AM, Vimal Singh vimal.neww...@gmail.com wrote:
On Sat, Aug 28, 2010 at 12:00 AM, Cliff Brake cliff.br...@gmail.com wrote:
On Fri, Aug 27, 2010 at 2:29 PM, Cliff Brake cliff.br...@gmail.com wrote:
On Fri, Aug 27, 2010 at 11:13 AM, Ghorai, Sukumar s-gho...@ti.com wrote:
-Original Message-
From: Vimal Singh [mailto:vimal.neww...@gmail.com]
Sent: Tuesday, August 24, 2010 10:41 PM
To: Cliff Brake
Cc: Ghorai, Sukumar; Linux OMAP Users; Kamat, Nishant
Subject: Re: NAND ECC in linux-omap
On Tue, Aug 24, 2010 at 8:04 PM, Cliff Brake cliff.br...@gmail.com
wrote:
flash_erasall -j /dev/mtd4
Give a try without using '-j' option... If ECC layout is the suspect..
this may help.
[Ghorai]
Cliff,
I did not able to spend much time on it to get into the problem.
But would you please try using these additional patch(4) that yet to
upstream?
https://patchwork.kernel.org/patch/116554/
https://patchwork.kernel.org/patch/116553/
https://patchwork.kernel.org/patch/116555/
https://patchwork.kernel.org/patch/116556/
And select/change the proper ECC in -
arch/arm/mach-omap2/board-flash.c: line No.148;
board_nand_data.ecc_opt = OMAP_ECC_HAMMING_CODE_HW;
Thanks for the patches. Now I get the following:
r...@ts3:~# flash_eraseall /dev/mtd1
Erasing 128 Kibyte @ 1c -- 100 % complete.
r...@ts3:~# nandwrite -p /dev/mtd1 /media/mmcblk0p1/u-boot.bin
Writing data to block 0 at offset 0x0
And the operation hangs.
Drop these patches. Please just give one more try after reverting last
2 commits in omap2.c driver:
1. omap3 nand: cleanup virtual address usages
and
2. omap3 gpmc: functionality enhancement
I suspect something wrong with patch '2'. I will look into it more.
I can see the problem in '1' patch only. In this patch, see below change:
--
static void omap_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int ctrl)
{
struct omap_nand_info *info = container_of(mtd,
struct omap_nand_info, mtd);
- switch (ctrl) {
- case NAND_CTRL_CHANGE | NAND_CTRL_CLE:
- info-nand.IO_ADDR_W = info-gpmc_cs_baseaddr +
- GPMC_CS_NAND_COMMAND;
- info-nand.IO_ADDR_R = info-gpmc_cs_baseaddr +
- GPMC_CS_NAND_DATA;
- break;
-
- case NAND_CTRL_CHANGE | NAND_CTRL_ALE:
- info-nand.IO_ADDR_W = info-gpmc_cs_baseaddr +
- GPMC_CS_NAND_ADDRESS;
- info-nand.IO_ADDR_R = info-gpmc_cs_baseaddr +
- GPMC_CS_NAND_DATA;
- break;
-
- case NAND_CTRL_CHANGE | NAND_NCE:
- info-nand.IO_ADDR_W = info-gpmc_cs_baseaddr +
- GPMC_CS_NAND_DATA;
- info-nand.IO_ADDR_R = info-gpmc_cs_baseaddr +
- GPMC_CS_NAND_DATA;
- break;
- }
- if (cmd != NAND_CMD_NONE)
- __raw_writeb(cmd, info-nand.IO_ADDR_W);
+ if (cmd != NAND_CMD_NONE) {
+ if (ctrl NAND_CLE)
+ gpmc_nand_write(info-gpmc_cs, GPMC_NAND_COMMAND, cmd);
+
+ else if (ctrl NAND_ALE)
+ gpmc_nand_write(info-gpmc_cs, GPMC_NAND_ADDRESS, cmd);
+
+ else /* NAND_NCE */
+ gpmc_nand_write(info-gpmc_cs, GPMC_NAND_DATA, cmd);
+ }
}
-
The new (changed) hwcontrol routine still can latch command and
address to correct gpmc nand registers. But it is failing to set '
info-nand.IO_ADDR_W' and 'info-nand.IO_ADDR_R'.
Which will be used by write/read routines to: write to (IO_ADDR_W) or
read from (IO_ADDR_R).
--
Regards,
Vimal Singh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: NAND ECC in linux-omap
On Tue, Aug 24, 2010 at 8:04 PM, Cliff Brake cliff.br...@gmail.com wrote: flash_erasall -j /dev/mtd4 Give a try without using '-j' option... If ECC layout is the suspect.. this may help. -- Regards, Vimal Singh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/3] omap3 nand: cleanup exiting platform related code
Reviewed-by: Vimal Singh vimal.neww...@gmail.com On Fri, Jun 4, 2010 at 1:10 PM, Sukumar Ghorai s-gho...@ti.com wrote: The following set of patches applies on top of for-next branch. http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git Patches verified on: omap3430-SDP, omap3630-sdp, zoom3 and beagle board And these are the patches required to address the following input - 1. The NAND driver needs to stop tinkering with the GPMC registers The omap General Purpose Memory Controller (GPMC) registers are omap specific, and not driver specific. Tinkering with these registers can cause issues with the other devices on the GPMC. 2. Passing hardcoded GPMC_CS0_BASE needs to go from the board files Passing hardcoded GPMC virtual addressess is sure way to mess up things. This should all become unnecessary once the NAND drivers stops messing with the GPMC registers directly. Discussion: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg27630.html Changes in this series - Unused function removed. Functions related to ecc and prefetch engine are optimized. v4: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg29458.html Few functionality was missing like - There should be some locking as only one chipselect can use the ECC or prefetch engine at a time. If you have NAND in two chipselects, bad things would happen. v3: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg28715.html Additionally, it was needed to implement more functions for the platform init code to use. v2: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg28467.html v1: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg28164.html Sukumar Ghorai (3): omap3 gpmc: functionality enhancement omap3 nand: cleanup virtual address usages omap3 nand: fix issue in board file to detect nand arch/arm/mach-omap2/board-cm-t35.c | 20 +--- arch/arm/mach-omap2/board-devkit8000.c | 25 +--- arch/arm/mach-omap2/board-omap3beagle.c | 24 +--- arch/arm/mach-omap2/board-omap3touchbook.c | 25 +--- arch/arm/mach-omap2/board-overo.c | 24 +--- arch/arm/mach-omap2/board-sdp-flash.c | 5 - arch/arm/mach-omap2/gpmc-nand.c | 39 ++ arch/arm/mach-omap2/gpmc.c | 228 +--- arch/arm/plat-omap/include/plat/gpmc.h | 36 - arch/arm/plat-omap/include/plat/nand.h | 6 +- drivers/mtd/nand/omap2.c | 229 11 files changed, 320 insertions(+), 341 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Regards, Vimal Singh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/3] omap3 gpmc: functionality enhancement
On Fri, May 28, 2010 at 12:03 PM, Ghorai, Sukumar s-gho...@ti.com wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Vimal Singh
Sent: Thursday, May 27, 2010 11:56 PM
To: Ghorai, Sukumar
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH v4 1/3] omap3 gpmc: functionality enhancement
On Thu, May 27, 2010 at 6:54 PM, Sukumar Ghorai s-gho...@ti.com wrote:
[...]
-static unsigned gpmc_cs_map;
+static unsigned int gpmc_cs_map; /* flag for cs which are
initialized */
Tab should be after 'int', not before.
[...]
@@ -456,13 +565,22 @@ EXPORT_SYMBOL(gpmc_prefetch_enable);
/**
* gpmc_prefetch_reset - disables and stops the prefetch engine
*/
-void gpmc_prefetch_reset(void)
+int gpmc_prefetch_reset(int cs)
{
+ u32 config1;
+
+ /* check if the same module/cs is trying to reset */
+ config1 = gpmc_read_reg(GPMC_PREFETCH_CONFIG1);
+ if (((config1 CS_NUM_SHIFT) 0x7) != cs)
+ return -EINVAL;
+
You really do not need this.
Prefetch has just one instance at a time and 'reset' will be call only
when driver has got access to prefetch (for either read or write
access), from the driver.
[Ghorai] Agree. And.. NAND may not be good example. But if tomorrow i/o
operation need to cancel for some other type of device and for big size of IO
on progress. So is not this API required that case?
First of all, this prefetch engine is dedicated for only NAND.
Then, if user wants to 'cancel', say a big write operation; since
there is no 'cancel' command provided by chip (nand), FS has to handle
it. And, I guess, best way will be to complete current chunck of
request (in this case writing of current page or sub-page) and then
cancel any further pending transfer.
And in that case again, prefetch 'reset' will get called for
completion of current page/sub-page operation.
--
Regards,
Vimal Singh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/3] omap3 gpmc: functionality enhancement
On Fri, May 28, 2010 at 11:50 PM, Ghorai, Sukumar s-gho...@ti.com wrote:
-Original Message-
From: Vimal Singh [mailto:vimal.neww...@gmail.com]
Sent: Friday, May 28, 2010 9:14 PM
To: Ghorai, Sukumar
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH v4 1/3] omap3 gpmc: functionality enhancement
On Fri, May 28, 2010 at 12:03 PM, Ghorai, Sukumar s-gho...@ti.com wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Vimal Singh
Sent: Thursday, May 27, 2010 11:56 PM
To: Ghorai, Sukumar
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH v4 1/3] omap3 gpmc: functionality enhancement
On Thu, May 27, 2010 at 6:54 PM, Sukumar Ghorai s-gho...@ti.com
wrote:
[...]
-static unsigned gpmc_cs_map;
+static unsigned int gpmc_cs_map; /* flag for cs which
are
initialized */
Tab should be after 'int', not before.
[...]
@@ -456,13 +565,22 @@ EXPORT_SYMBOL(gpmc_prefetch_enable);
/**
* gpmc_prefetch_reset - disables and stops the prefetch engine
*/
-void gpmc_prefetch_reset(void)
+int gpmc_prefetch_reset(int cs)
{
+ u32 config1;
+
+ /* check if the same module/cs is trying to reset */
+ config1 = gpmc_read_reg(GPMC_PREFETCH_CONFIG1);
+ if (((config1 CS_NUM_SHIFT) 0x7) != cs)
+ return -EINVAL;
+
You really do not need this.
Prefetch has just one instance at a time and 'reset' will be call only
when driver has got access to prefetch (for either read or write
access), from the driver.
[Ghorai] Agree. And.. NAND may not be good example. But if tomorrow i/o
operation need to cancel for some other type of device and for big size of
IO on progress. So is not this API required that case?
First of all, this prefetch engine is dedicated for only NAND.
[Ghorai] ok. Does not this below response is contradicting previous statement?
Then, if user wants to 'cancel', say a big write operation; since
there is no 'cancel' command provided by chip (nand), FS has to handle
it. And, I guess, best way will be to complete current chunck of
request (in this case writing of current page or sub-page) and then
cancel any further pending transfer.
And in that case again, prefetch 'reset' will get called for
completion of current page/sub-page operation.
[Ghorai]
1. In this case why we checks - prefetch engine busy or not, if we are
waiting to complete one request to be completed before another? As we reset
the prefetch-engine at the end of the io?
Since there could be other request (for read/write) from another
driver instance (in case we have more than one NAND chip on board).
2. The only possible scenario is - when two driver(say for two separate nand
chip) trying to access the prefetch-engine. In that case who accessing the
prefetch engine he should only reset the engine. And to avoid confusion and
mistake of the user of this API, it has been added 'cs' number as a function
parameter for reset and the same is used to check before reset.
In this scenario, when second driver instance fails to get prefetch,
it completes the request by cpu transfer method. And there is no
chance for prefetch reset to get called from this driver instance.
Note that we are not calling reset explicitly, but a driver (instance)
resets the prefetch only if it gets first.
--
Regards,
Vimal Singh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/3] omap3 gpmc: functionality enhancement
On Thu, May 27, 2010 at 6:54 PM, Sukumar Ghorai s-gho...@ti.com wrote:
[...]
-static unsigned gpmc_cs_map;
+static unsigned int gpmc_cs_map; /* flag for cs which are
initialized */
Tab should be after 'int', not before.
[...]
@@ -456,13 +565,22 @@ EXPORT_SYMBOL(gpmc_prefetch_enable);
/**
* gpmc_prefetch_reset - disables and stops the prefetch engine
*/
-void gpmc_prefetch_reset(void)
+int gpmc_prefetch_reset(int cs)
{
+ u32 config1;
+
+ /* check if the same module/cs is trying to reset */
+ config1 = gpmc_read_reg(GPMC_PREFETCH_CONFIG1);
+ if (((config1 CS_NUM_SHIFT) 0x7) != cs)
+ return -EINVAL;
+
You really do not need this.
Prefetch has just one instance at a time and 'reset' will be call only
when driver has got access to prefetch (for either read or write
access), from the driver.
--
Regards,
Vimal Singh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] omap3 gpmc: functionality enhancement
On Tue, May 25, 2010 at 8:07 PM, Ghorai, Sukumar s-gho...@ti.com wrote: [...] c. And how to know that ECC engine is in used other driver should not use it? Any bit to know that ecc engine is busy, as we check for prefetch? Do not really remember config registers. Perhaps there is no way. But I guess you should check into register GPMC_ECC_CONFIG at bit 1. This is the bit we are setting to enable ECC calculation, IIRC. [Ghorai] there are two functions - info-nand.ecc.calculate = omap_calculate_ecc; info-nand.ecc.hwctl = omap_enable_hwecc; And GPMC_ECC_CONFIG register.. 3:1 ECCCS Selects the CS where ECC is computed 0 ECCENABLE Enables the ECC feature Now we enable omap_enable_hwecc (with GPMC_ECC_CONFIG[ECCENABLE]=1); and its get disabled (automatically) when ecc_size data transfer over. But say still it did not read the ecc value yet (omap_calculate_ecc). So how to protect following omap_enable_hwecc() before omap_calculate_ecc() without additional flag? Any input is welcome. Oh yes, that's is a problem. Perhaps in that case you have to protect it in very much same way you already did. -- Regards, Vimal Singh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] omap3 gpmc: functionality enhancement
On Thu, May 20, 2010 at 11:08 AM, Ghorai, Sukumar s-gho...@ti.com wrote:
Vimal,
-Original Message-
From: Vimal Singh [mailto:vimal.neww...@gmail.com]
Sent: 2010-05-20 00:01
To: Ghorai, Sukumar
Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org;
t...@atomide.com; sako...@gmail.com; m...@compulab.co.il;
artem.bityuts...@nokia.com; peter.bar...@gmail.com
Subject: Re: [PATCH v3 1/3] omap3 gpmc: functionality enhancement
On Wed, May 19, 2010 at 11:34 PM, Ghorai, Sukumar s-gho...@ti.com wrote:
+
+ case GPMC_CONFIG_RDY_BSY:
+ regval = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
+ regval |= WR_RD_PIN_MONITORING;
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1, regval);
+ break;
IIRC, at least in OMAP2/3, ready/busy pin is not in use (not
connected).
On the Logic OMAP3530 LV SOM and Torpedo modules, the R/B# pin of the
NAND in the Micron mt29c2g4maklajg-6it POP part is connected to the
WAIT0 pin on the OMAP3530 and I'm looking to use it to speed up NAND
accesses
[Ghorai] So better keep this feature,
Yes, looks like there are some boards which can still take advantage of
this.
[...]
@@ -456,13 +572,20 @@ EXPORT_SYMBOL(gpmc_prefetch_enable);
/**
* gpmc_prefetch_reset - disables and stops the prefetch engine
*/
-void gpmc_prefetch_reset(void)
+int gpmc_prefetch_reset(int cs)
{
+ if (gpmc_pref_used == cs)
+ gpmc_pref_used = -EINVAL;
+ else
+ return -EINVAL;
+
This is also not required. As, this function will be called only if
prefetch was used.
[Ghorai] Agree. Can you see this input too?
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg28520.html
Exactly, this is what I am telling here. Enable prefetch engine call
is already being check for *busy* or not.
[...]
+int gpmc_ecc_init(int cs, int ecc_size)
+{
+ unsigned int val = 0x0;
+
+ /* check if ecc engine already by another cs */
+ if (gpmc_ecc_used == -EINVAL)
+ gpmc_ecc_used = cs;
+ else
+ return -EBUSY;
Here few things need be to consider:
1. 'init' is supposed to done once for every instance of driver
during
probe
2. But ECC engine, too, have only one instance at a time, So
3. As long as all NAND chip are supposed to use same ECC machenism,
we
can go for only one time 'init' for all drivers, perhaps in
gpmc_nand.c.
4. But in case, different instances of driver (or NAND chip) requires
different ECC machenism (for ex. Hamming or BCH, or even with
different capabilities of error correction),
this will no longer vailid. Then rather we should have something like
'gpmc_ecc_config' call to configer ECC engine for everytime a driver
needs it (something like as it is done for prefetch engine).
[Ghorai]
a. do you think it will reduce the throughput?
No. But in current implementation it will be called for each instance
driver. (see my 3rd point)
b. Moreover I think we will take this as 5th patch as cleanup/
improvemnt.
c. And how to know that ECC engine is in used other driver should not
use it? Any bit to know that ecc engine is busy, as we check for prefetch?
Do not really remember config registers. Perhaps there is no way.
But I guess you should check into register GPMC_ECC_CONFIG at bit 1.
This is the bit we are setting to enable ECC calculation, IIRC.
d. any further input on http://www.mail-archive.com/linux-
o...@vger.kernel.org/msg28520.html
And this what I was suggesting in my point 4. In my example
'gpmc_ecc_config' is analogy to 'gpmc_ecc_request'.
I said *config*, since in such scenario you need to configer HW
ECCconfig register everytime as well, rather just checking
availability and enabling.
[Ghorai] still I feel we should not mix this patch with cleanup. And yes if
possible this will be the 5th one as cleanup.
4th one - prefetch cleanup
5th one - ecc cleanup.
Do you think still missing anything for this patch?
As long as you take care of current comments, I do not have any
further comment for now.
--
Regards,
Vimal Singh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: Fix Memory leak
On Thu, May 20, 2010 at 7:59 PM, Manjunatha GK manj...@ti.com wrote: From: Satish x0124...@ti.com The memory allocated for sgt structure is not freed on error when sg_alloc_table is called in sg_alloc_table(). Typo mistake: correct sg_alloc_table to sgtable_alloc for second time. -- Regards, Vimal Singh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP2/3: Keypad: Fix memory leak
On Thu, May 20, 2010 at 7:59 PM, Manjunatha GK manj...@ti.com wrote:
From: Damodar x0132...@ti.com
This patch corrects Possible memory leak of 'input' allocated
through input_allocate_device and Suspicious dereference of pointer 'pdata'
before NULL check
Signed-off-by: Damodar Santhapuri x0132...@ti.com
Signed-off-by: Manjunatha GK manj...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
drivers/input/keyboard/twl4030_keypad.c | 21 +
1 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/input/keyboard/twl4030_keypad.c
b/drivers/input/keyboard/twl4030_keypad.c
index 7aa59e0..aa13aec 100644
--- a/drivers/input/keyboard/twl4030_keypad.c
+++ b/drivers/input/keyboard/twl4030_keypad.c
@@ -326,30 +326,34 @@ static int __devinit twl4030_kp_program(struct
twl4030_keypad *kp)
*/
static int __devinit twl4030_kp_probe(struct platform_device *pdev)
{
- struct twl4030_keypad_data *pdata = pdev-dev.platform_data;
- const struct matrix_keymap_data *keymap_data = pdata-keymap_data;
+ struct twl4030_keypad_data *pdata;
+ const struct matrix_keymap_data *keymap_data;
struct twl4030_keypad *kp;
struct input_dev *input;
u8 reg;
int error;
-
+ if (!pdev) {
+ printk(KERN_ERR Invalid platorm_device\n);
+ return -EINVAL;
+ }
+ pdata = pdev-dev.platform_data;
if (!pdata || !pdata-rows || !pdata-cols ||
pdata-rows TWL4030_MAX_ROWS || pdata-cols TWL4030_MAX_COLS) {
dev_err(pdev-dev, Invalid platform_data\n);
return -EINVAL;
}
-
+ keymap_data = pdata-keymap_data;
kp = kzalloc(sizeof(*kp), GFP_KERNEL);
+ if (!kp)
+ return -ENOMEM;
input = input_allocate_device();
- if (!kp || !input) {
+ if (!input) {
error = -ENOMEM;
- goto err1;
+ goto err0;
If I am not mistaking you should still goto 'err1', as
'input_register_device' is yet not called.
--
Regards,
Vimal Singh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP2/3: Keypad: Fix memory leak
On Thu, May 20, 2010 at 8:41 PM, Vimal Singh vimal.neww...@gmail.com wrote:
On Thu, May 20, 2010 at 7:59 PM, Manjunatha GK manj...@ti.com wrote:
From: Damodar x0132...@ti.com
This patch corrects Possible memory leak of 'input' allocated
through input_allocate_device and Suspicious dereference of pointer 'pdata'
before NULL check
Signed-off-by: Damodar Santhapuri x0132...@ti.com
Signed-off-by: Manjunatha GK manj...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
drivers/input/keyboard/twl4030_keypad.c | 21 +
1 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/input/keyboard/twl4030_keypad.c
b/drivers/input/keyboard/twl4030_keypad.c
index 7aa59e0..aa13aec 100644
--- a/drivers/input/keyboard/twl4030_keypad.c
+++ b/drivers/input/keyboard/twl4030_keypad.c
@@ -326,30 +326,34 @@ static int __devinit twl4030_kp_program(struct
twl4030_keypad *kp)
*/
static int __devinit twl4030_kp_probe(struct platform_device *pdev)
{
- struct twl4030_keypad_data *pdata = pdev-dev.platform_data;
- const struct matrix_keymap_data *keymap_data = pdata-keymap_data;
+ struct twl4030_keypad_data *pdata;
+ const struct matrix_keymap_data *keymap_data;
struct twl4030_keypad *kp;
struct input_dev *input;
u8 reg;
int error;
-
+ if (!pdev) {
+ printk(KERN_ERR Invalid platorm_device\n);
+ return -EINVAL;
+ }
+ pdata = pdev-dev.platform_data;
if (!pdata || !pdata-rows || !pdata-cols ||
pdata-rows TWL4030_MAX_ROWS || pdata-cols TWL4030_MAX_COLS)
{
dev_err(pdev-dev, Invalid platform_data\n);
return -EINVAL;
}
-
+ keymap_data = pdata-keymap_data;
kp = kzalloc(sizeof(*kp), GFP_KERNEL);
+ if (!kp)
+ return -ENOMEM;
input = input_allocate_device();
- if (!kp || !input) {
+ if (!input) {
error = -ENOMEM;
- goto err1;
+ goto err0;
If I am not mistaking you should still goto 'err1', as
'input_register_device' is yet not called.
Sorry, my ignorance that device is yet not allocated.
--
Regards,
Vimal Singh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] omap3 gpmc: functionality enhancement
@@ static void omap_write_buf_pref(struct mtd_info *mtd, } /* disable and stop the PFPW engine */ - gpmc_prefetch_reset(); + gpmc_prefetch_reset(info-gpmc_cs); Not required. see above comments. } } -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Regards, Vimal Singh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/3] omap3 nand: cleanup virtual address usages
-comp);
- while (0x3fff (prefetch_status = gpmc_prefetch_status()))
- ;
+ do {
+ gpmc_hwcontrol(info-gpmc_cs,
+ GPMC_PREFETCH_COUNT, 0, 0, prefetch_status);
+ } while (prefetch_status);
/* disable and stop the PFPW engine */
gpmc_prefetch_reset();
@@ -502,7 +468,7 @@ static void omap_write_buf_dma_pref(struct mtd_info *mtd,
omap_write_buf_pref(mtd, buf, len);
else
/* start transfer in DMA mode */
- omap_nand_dma_transfer(mtd, buf, len, 0x1);
+ omap_nand_dma_transfer(mtd, (u_char *) buf, len, 0x1);
This is already fixed. See commit:
http://git.infradead.org/mtd-2.6.git/commitdiff/bdaefc41627b6f2815ef7aa476dfa4ebb3ad499f
Rest, patches looks good. It is a good clean-up all together.
--
Regards,
Vimal Singh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/3] omap3 nand: cleanup virtual address usages
()))
- ;
+ do {
+ gpmc_hwcontrol(info-gpmc_cs,
+ GPMC_PREFETCH_COUNT, 0, 0,
prefetch_status);
+ } while (prefetch_status);
/* disable and stop the PFPW engine */
gpmc_prefetch_reset();
@@ -502,7 +468,7 @@ static void omap_write_buf_dma_pref(struct mtd_info
*mtd,
omap_write_buf_pref(mtd, buf, len);
else
/* start transfer in DMA mode */
- omap_nand_dma_transfer(mtd, buf, len, 0x1);
+ omap_nand_dma_transfer(mtd, (u_char *) buf, len, 0x1);
This is already fixed. See commit:
http://git.infradead.org/mtd-
2.6.git/commitdiff/bdaefc41627b6f2815ef7aa476dfa4ebb3ad499f
[Ghorai] thanks I will omit this from this patch
Rest, patches looks good. It is a good clean-up all together.
[Ghorai] Is it possible for you to check once again if you have any
additional comments! This is to identify the issue if any at early stage.
Yeah, I can understand. I tried to review it fully, but can not say if
still something left and gets attention later on. Even sometimes they
will become visible when you fix current one.
As of now this is all what I had.
--
Regards,
Vimal Singh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] omap3 nand: cleanup for not to use GPMC virtual address
On Mon, May 17, 2010 at 9:52 AM, Ghorai, Sukumar s-gho...@ti.com wrote:
[...]
@@ -108,11 +108,27 @@ static u32 gpmc_read_reg(int idx)
return __raw_readl(gpmc_base + idx);
}
+static void gpmc_cs_write_byte(int cs, int idx, u8 val)
+{
+ void __iomem *reg_addr;
+
+ reg_addr = gpmc_base + GPMC_CS0_BASE + (cs * GPMC_CS_SIZE) +
idx;
+ __raw_writeb(val, reg_addr);
+}
+
+static u8 gpmc_cs_read_byte(int cs, int idx)
+{
+ void __iomem *reg_addr;
+
+ reg_addr = gpmc_base + GPMC_CS0_BASE + (cs * GPMC_CS_SIZE) +
idx;
+ return __raw_readb(reg_addr);
+}
+
I do not think we need these functions.
[Ghorai] This is used in gpmc_hwcontrol() and to get the nand status from
omap2.c.
Yes, I can see that. But I think you should read complete register
(32-bits) and the manipulate them accordingly.
[...]
@@ -229,14 +191,15 @@ static void omap_read_buf8(struct mtd_info *mtd,
u_char *buf, int len)
*/
static void omap_write_buf8(struct mtd_info *mtd, const u_char *buf,
int len)
{
- struct omap_nand_info *info = container_of(mtd,
- struct omap_nand_info,
mtd);
+ u32 status;
+ struct nand_chip *nand = mtd-priv;
u_char *p = (u_char *)buf;
while (len--) {
- iowrite8(*p++, info-nand.IO_ADDR_W);
- while (GPMC_BUF_EMPTY == (readl(info-gpmc_baseaddr +
- GPMC_STATUS)
GPMC_BUF_FULL));
+ iowrite8(*p++, nand-IO_ADDR_W);
+ gpmc_hwcontrol(0, 0, GPMC_GET_SET_STATUS, 0, status);
If I am not mistaking, 2nd argument is 'cs', correct? And then, why
are you hard coding this?
Different boards will have NAND chip present at different 'cs'.
Please have a look at uses of 'gpmc_hwcontrol' elsewhere as well for this.
[Ghorai] I agree.
Again, say, you got '(status GPMC_BUF_FULL) != GPMC_BUF_EMPTY', then:
+ while (GPMC_BUF_EMPTY == (status GPMC_BUF_FULL))
+ ;
You got in an infinite loop here?
[Ghorai] if you see carefully this is same as existing code. Let me check if
any better solution.
No. Look carefully. In previous code 'gpmc status' was being read in
each loop, while in your code you read it once and then you never look
for updated value.
That's why your code is going into infinite loop
--
Regards,
Vimal Singh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] omap3 nand: cleanup for not to use GPMC virtual address
omap_read_buf16(struct mtd_info *mtd,
u_char *buf, int len)
*/
static void omap_write_buf16(struct mtd_info *mtd, const u_char * buf, int
len)
{
- struct omap_nand_info *info = container_of(mtd,
- struct omap_nand_info, mtd);
+ u32 status;
+ struct nand_chip *nand = mtd-priv;
u16 *p = (u16 *) buf;
/* FIXME try bursts of writesw() or DMA ... */
len = 1;
while (len--) {
- iowrite16(*p++, info-nand.IO_ADDR_W);
-
- while (GPMC_BUF_EMPTY == (readl(info-gpmc_baseaddr +
- GPMC_STATUS) GPMC_BUF_FULL))
+ iowrite16(*p++, nand-IO_ADDR_W);
+ gpmc_hwcontrol(0, 0, GPMC_GET_SET_STATUS, 0, status);
+ while (GPMC_BUF_EMPTY == (status GPMC_BUF_FULL))
same as above.
--
Regards,
Vimal Singh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Upcoming merge window and omap NAND patches
On Wed, May 5, 2010 at 10:19 AM, Artem Bityutskiy artem.bityuts...@nokia.com wrote: On Wed, 2010-05-05 at 00:08 +0200, ext Tony Lindgren wrote: Hi all, There are several omap NAND patches pending, but some basic things should be fixed first. 1. The NAND driver needs to stop tinkering with the GPMC registers The omap General Purpose Memory Controller (GPMC) registers are omap specific, and not driver specific. Tinkering with these registers can cause issues with the other devices on the GPMC. To find out what needs to disappear fomr the NAND driver, just do: $ grep baseaddr drivers/mtd/nand/omap2.c Any GPMC register tinkering needs to happen in arch/arm/mach-omap2/gpmc.c. If there are not currently GPMC functions to do something in gpmc.c, then let's add the necessary support there. 2. Passing hardcoded GPMC_CS0_BASE needs to go from the board files Passing hardcoded GPMC virtual addressess is sure way to mess up things. This should all become unnecessary once the NAND drivers stops messing with the GPMC registers directly. So, as a result, I'm not planning on pushing any omap NAND related patches until these basic issues are fixed. I'll mark these patches as Changes requested in patchwork.kernel.org even if these patches don't have anything else wrong with them. Let's fix the basic things for good, and put the other patches on hold for a while. Sorry if this causes problems! Hi, fair enough. I guess Vimal should address this, as he seems to be the TI mr. NAND, right? :-) Hi All, Sorry again. I am no more with TI and I don't have any board with me too. So, I'm unable to fix these. :( I hope someone else from TI can take care of it. -- Regards, Vimal Singh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] omap: gpmc-nand: add ability to keep timings defined by the bootloader
On Thu, Apr 29, 2010 at 12:23 PM, Mike Rapoport m...@compulab.co.il wrote:
Vimal Singh wrote:
On Wed, Apr 28, 2010 at 9:36 PM, Mike Rapoport m...@compulab.co.il
wrote:
Signed-off-by: Mike Rapoport m...@compulab.co.il
+ if (gpmc_nand_data-keep_timings) {
+ gpmc_nand_detect_timings();
+ gpmc_nand_data-gpmc_t = gpmc_default_timings;
+ }
+
I guess moving this part to omap2_nand_gpmc_retime will be a good idea.
As there, once we get old/default timings we can simply skip the
rounding part and directly jump to setting the timings.
This way it would be the same as to pass 'gpmc_nand_data-gpmc_t =
NULL'. If I correctly understood the previous comments ([1]), the
problem with skipping retime is that when L3 clock changes, the gpmc
timings became wrong. So, if we convert old/default timings to
nanoseconds early during startup every time retime is called it will use
the timing settings in nanoseconds thus yielding proper gpmc registers
configuration.
OK. Then I think we can at least put __rounding__ code inside an 'if'
case, something like:
if (!gpmc_nand_data-keep_timings) {
...
do rounding for supplied timings from board file.
...
}
And, if I'm not terribly mistaken retime should be called each time L3
frequency changes, though with current kernel it's not yet the case...
Yes. This is still left.
--
Regards,
Vimal Singh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] omap: gpmc-nand: add ability to keep timings defined by the bootloader
On Wed, Apr 28, 2010 at 9:36 PM, Mike Rapoport m...@compulab.co.il wrote:
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/gpmc-nand.c | 19 ++-
arch/arm/plat-omap/include/plat/nand.h | 1 +
2 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index e57fb29..7c6c027 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -22,6 +22,7 @@
#define WR_RD_PIN_MONITORING 0x0060
static struct omap_nand_platform_data *gpmc_nand_data;
+static struct gpmc_timings gpmc_default_timings;
static struct resource gpmc_nand_resource = {
.flags = IORESOURCE_MEM,
@@ -34,13 +35,24 @@ static struct platform_device gpmc_nand_device = {
.resource = gpmc_nand_resource,
};
+static void gpmc_nand_detect_timings(void)
+{
+ struct gpmc_timings t;
+
+ memset(t, 0, sizeof(t));
+ gpmc_cs_get_timings(gpmc_nand_data-cs, gpmc_default_timings);
+}
+
static int omap2_nand_gpmc_retime(void)
{
+ struct device *dev = gpmc_nand_device.dev;
struct gpmc_timings t;
int err;
- if (!gpmc_nand_data-gpmc_t)
+ if (!gpmc_nand_data-gpmc_t) {
+ dev_warn(dev, No timings provided, skipping retime\n);
return 0;
+ }
memset(t, 0, sizeof(t));
t.sync_clk = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-sync_clk);
@@ -112,6 +124,11 @@ int __init gpmc_nand_init(struct omap_nand_platform_data
*_nand_data)
return err;
}
+ if (gpmc_nand_data-keep_timings) {
+ gpmc_nand_detect_timings();
+ gpmc_nand_data-gpmc_t = gpmc_default_timings;
+ }
+
I guess moving this part to omap2_nand_gpmc_retime will be a good idea.
As there, once we get old/default timings we can simply skip the
rounding part and directly jump to setting the timings.
Rest looks fine to me.
--
Regards,
Vimal Singh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug in omap2_nand_gpmc_retime? (was: Re: [PATCH] OMAP: fix gpmc nand setup when no timings supplied)
On Wed, Apr 28, 2010 at 8:35 PM, Mike Rapoport m...@compulab.co.il wrote: Tony Lindgren wrote: * Mike Rapoport m...@compulab.co.il [100427 00:40]: Tony Lindgren wrote: * Mike Rapoport m...@compulab.co.il [100422 01:41]: Ghorai, Sukumar wrote: CM-T35, for instance can be assembled with different NAND flash chips. Besides, boards that use NAND as primary boot device, we anyway depend on proper GPMC configuration in the bootloader chain. Having ability to define GPMC timings in the kernel and keep the settings made by the bootloader adds flexibility level for board designers. Not implementing the retime function for GPMC will cause issues with PM as you cannot scale the L3 frequency without breaking your GPMC timings. I agree that without retime function scaling the frequency will break the GPMC timings. But my point was that there should be an _option_ to keep the timings defined by the bootloader rather than enforce board files to specify timings. Sure. Can you please check one more time your patch and what is still missing after Stanley's fix? That's now in omap-fixes and master branches as commit 11e1ef2d105900a302b7ca92bcaf96a96d0274a1. Since skipping the retime function will break gpmc timings in PM-enabled kernel, we need to implement this option in smarter way. E.g. something like: Yeah we should print some warning if the retime function is not implemented as it can cause mysterious bugs later on. I guess implementing a dummy retime function would be best as then the warning would be related to the actual L3 rate change. While working on implementation of gpmc_nand_detect_timings I've seen that omap2_nand_gpmc_retime converts the timings supplied by the platform to ticks and passes it to gpmc_cs_set_timings which in turn converts the timings to ticks. Is it a bug or am I missing something? No, 'omap2_nand_gpmc_retime' does not convert timings supplied by the platform to tick. Rather it rounds the timings passed by the platform to timings in units of 'tick' period. -- Regards, Vimal Singh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: fix gpmc nand setup when no timings supplied
On Mon, Apr 26, 2010 at 11:44 PM, Tony Lindgren t...@atomide.com wrote: * Mike Rapoport m...@compulab.co.il [100422 01:41]: Ghorai, Sukumar wrote: CM-T35, for instance can be assembled with different NAND flash chips. Besides, boards that use NAND as primary boot device, we anyway depend on proper GPMC configuration in the bootloader chain. Having ability to define GPMC timings in the kernel and keep the settings made by the bootloader adds flexibility level for board designers. Not implementing the retime function for GPMC will cause issues with PM as you cannot scale the L3 frequency without breaking your GPMC timings. BTW, there is a patch from Stanley.Miao already in LO: https://patchwork.kernel.org/patch/93613/ But it is still advisable to implement the retime function as stated by Tony. -- Regards, Vimal Singh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] OMAP NAND: configurable fifo threshold to gain the throughput
Hi Ghorai,
On Fri, Apr 16, 2010 at 5:05 PM, Sukumar Ghorai s-gho...@ti.com wrote:
[...]
- ret = gpmc_prefetch_enable(info-gpmc_cs, 0x0, len, 0x0);
+ ret = gpmc_prefetch_enable(info-gpmc_cs, 0x40, 0x0, len, 0x0);
Use macros here too then.
if (ret) {
/* PFPW engine is busy, use cpu copy method */
if (info-nand.options NAND_BUSWIDTH_16)
@@ -354,7 +354,7 @@ static void omap_write_buf_pref(struct mtd_info *mtd,
}
/* configure and start prefetch transfer */
- ret = gpmc_prefetch_enable(info-gpmc_cs, 0x0, len, 0x1);
+ ret = gpmc_prefetch_enable(info-gpmc_cs, 0x40, 0x0, len, 0x1);
here too
if (ret) {
/* PFPW engine is busy, use cpu copy method */
if (info-nand.options NAND_BUSWIDTH_16)
@@ -405,10 +405,11 @@ static inline int omap_nand_dma_transfer(struct
mtd_info *mtd, void *addr,
dma_addr_t dma_addr;
int ret;
- /* The fifo depth is 64 bytes. We have a sync at each frame and frame
-* length is 64 bytes.
+ /* The fifo depth is 64 bytes max.
+* But configure the FIFO-threahold to 32 to get a sync at each frame
+* and frame length is 32 bytes.
*/
- int buf_len = len 6;
+ int buf_len = len 5;
if (addr = high_memory) {
struct page *p1;
@@ -447,7 +448,7 @@ static inline int omap_nand_dma_transfer(struct mtd_info
*mtd, void *addr,
OMAP24XX_DMA_GPMC, OMAP_DMA_SRC_SYNC);
}
/* configure and start prefetch transfer */
- ret = gpmc_prefetch_enable(info-gpmc_cs, 0x1, len, is_write);
+ ret = gpmc_prefetch_enable(info-gpmc_cs, 0x20, 0x1, len, is_write);
if (ret)
/* PFPW engine is busy, use cpu copy methode */
goto out_copy;
@@ -524,6 +525,7 @@ static void omap_write_buf_dma_pref(struct mtd_info *mtd,
static irqreturn_t omap_nand_irq(int this_irq, void *dev)
{
struct omap_nand_info *info = (struct omap_nand_info *) dev;
+ u32 *p = (u32 *) info-buf;
u32 irq_enb = 0, pref_status = 0, bytes = 0;
u32 irq_stats = __raw_readl(info-gpmc_baseaddr + GPMC_IRQSTATUS);
u32 pref_config = __raw_readl(info-gpmc_baseaddr +
@@ -533,14 +535,11 @@ static irqreturn_t omap_nand_irq(int this_irq, void
*dev)
if (irq_stats 0x2)
goto done;
- u32 *p = (u32 *) info-buf;
- pref_status = gpmc_prefetch_status();
- bytes = ((pref_status 24) 0x7F);
+ bytes = PREFETCH_FIFOTHRESHOLD_WRITE;
By this, you are not really keeping prefetch the busyest.
you are filling only 'PREFETCH_FIFOTHRESHOLD_WRITE' bytes, while there
could be more free spaces.
Previous way of doing it was more efficent.
iowrite32_rep(info-nand_pref_fifo_add, p, bytes 2);
info-buf = info-buf + bytes;
} else {
- u32 *p = (u32 *) info-buf;
pref_status = gpmc_prefetch_status();
bytes = ((pref_status 24) 0x7F);
ioread32_rep(info-nand_pref_fifo_add, p, bytes 2);
@@ -586,7 +585,8 @@ static void omap_read_buf_irq_pref(struct mtd_info *mtd,
u_char *buf, int len)
init_completion(info-comp);
/* configure and start prefetch transfer */
- ret = gpmc_prefetch_enable(info-gpmc_cs, 0x0, len, 0x0);
+ ret = gpmc_prefetch_enable(info-gpmc_cs,
+ PREFETCH_FIFOTHRESHOLD_READ, 0x0, len, 0x0);
if (ret)
/* PFPW engine is busy, use cpu copy methode */
goto out_copy;
@@ -630,7 +630,8 @@ static void omap_write_buf_irq_pref(struct mtd_info *mtd,
init_completion(info-comp);
/* configure and start prefetch transfer */
- ret = gpmc_prefetch_enable(info-gpmc_cs, 0x0, len, 0x1);
+ ret = gpmc_prefetch_enable(info-gpmc_cs,
+ PREFETCH_FIFOTHRESHOLD_WRITE, 0x0, len, 0x1);
In case of write, in my experiments, fifo thresholed '24' was the best
compromise for throughput and cpu load.
Regards,
Vimal
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] nand support on omap3 boards
You post this mail in previous thread. Do not do that. ($SUBJECT is same as last one). Post it in different thread. And why this is not posted as a series? In fact these patches should be posted in two set of patches: 1. patches related to IRQ mode support 2. patches related ROM code ecc layout And IMHO, these patches should in revers order: omap: NAND: ecc layout select from board file omap: NAND: Making ecc layout as compatible with romcode ecc One more thing all these patches should also be posted to MTD list. In fact, most of these patches should go through mtd tree itself. -- Regards, Vimal Singh On Tue, Apr 13, 2010 at 11:07 PM, Sukumar Ghorai s-gho...@ti.com wrote: The following set of patches applies on top of the Tony's master branch. And dependency on following series of patch - Sukumar Ghorai (3): omap3: GPMC register definition at common location omap3: NAND Prefetch in IRQ mode support omap-3630 NAND: enable NAND io in prefetch-irq mode omap: NAND: ecc layout select from board file omap: NAND: Making ecc layout as compatible with romcode ecc -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] nand support on omap3 boards
On Wed, Apr 14, 2010 at 10:05 AM, Vimal Singh vimal.neww...@gmail.com wrote: You post this mail in previous thread. Do not do that. ($SUBJECT is same as last one). Post it in different thread. And why this is not posted as a series? In fact these patches should be posted in two set of patches: 1. patches related to IRQ mode support 2. patches related ROM code ecc layout And IMHO, these patches should in revers order: omap: NAND: ecc layout select from board file omap: NAND: Making ecc layout as compatible with romcode ecc I saw them again. Please discard this comment. It looks OK to me. -- Regards, Vimal Singh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 2/3] OMAP4: Keyboard Board Support
On Wed, Apr 14, 2010 at 6:40 AM, Arce, Abraham x0066...@ti.com wrote:
From: Syed Rafiuddin rafiuddin.s...@ti.com
Keyboard support for SDP OMAP4430
Signed-off-by: Abraham Arce x0066...@ti.com
---
'Form: Syed Rafiuddin', but not 'Signed-off-by:'... is it correct?
arch/arm/mach-omap2/board-4430sdp.c | 61 ++
1 files changed, 25 insertions(+), 36 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 9a35367..747a4d8 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -35,16 +35,13 @@
#include plat/timer-gp.h
#include plat/usb.h
#include plat/syntm12xx.h
-#include plat/keypad.h
#include asm/hardware/gic.h
#include asm/hardware/cache-l2x0.h
#include linux/i2c/twl.h
#include linux/regulator/machine.h
#include mmc-twl4030.h
-#define OMAP4_KBDOCP_BASE 0x4A31C000
-
-static int omap_keymap[] = {
+static int sdp4430_keymap[] = {
KEY(0, 0, KEY_E),
KEY(0, 1, KEY_D),
KEY(0, 2, KEY_X),
@@ -52,7 +49,7 @@ static int omap_keymap[] = {
KEY(0, 4, KEY_W),
KEY(0, 5, KEY_S),
KEY(0, 6, KEY_Q),
- KEY(0, 7, KEY_UNKNOWN),
+ KEY(0, 7, KEY_PROG1),
KEY(1, 0, KEY_R),
KEY(1, 1, KEY_F),
@@ -61,7 +58,7 @@ static int omap_keymap[] = {
KEY(1, 4, KEY_Y),
KEY(1, 5, KEY_H),
KEY(1, 6, KEY_A),
- KEY(1, 7, KEY_UNKNOWN),
+ KEY(1, 7, KEY_PROG2),
KEY(2, 0, KEY_T),
KEY(2, 1, KEY_G),
@@ -70,23 +67,23 @@ static int omap_keymap[] = {
KEY(2, 4, KEY_U),
KEY(2, 5, KEY_J),
KEY(2, 6, KEY_N),
- KEY(2, 7, KEY_UNKNOWN),
+ KEY(2, 7, KEY_PROG3),
KEY(3, 0, KEY_HOME),
KEY(3, 1, KEY_SEND),
KEY(3, 2, KEY_END),
KEY(3, 3, KEY_F1),
- KEY(3, 4, KEY_LEFTSHIFT),
+ KEY(3, 4, KEY_F2),
KEY(3, 5, KEY_F3),
KEY(3, 6, KEY_BACK),
- KEY(3, 7, KEY_UNKNOWN),
+ KEY(3, 7, KEY_PROG4),
- KEY(4, 0, KEY_UNKNOWN),
- KEY(4, 1, KEY_UNKNOWN),
- KEY(4, 2, KEY_UNKNOWN),
- KEY(4, 3, KEY_UNKNOWN),
+ KEY(4, 0, KEY_F5),
+ KEY(4, 1, KEY_F6),
+ KEY(4, 2, KEY_F7),
+ KEY(4, 3, KEY_F8),
KEY(4, 4, KEY_VOLUMEUP),
- KEY(4, 5, KEY_UNKNOWN),
+ KEY(4, 5, KEY_F9),
KEY(4, 6, KEY_BACKSPACE),
KEY(4, 7, KEY_F4),
@@ -108,7 +105,7 @@ static int omap_keymap[] = {
KEY(6, 6, KEY_P),
KEY(6, 7, KEY_OK),
- KEY(7, 0, KEY_UNKNOWN),
+ KEY(7, 0, KEY_LEFTSHIFT),
KEY(7, 1, KEY_ENTER),
KEY(7, 2, KEY_CAPSLOCK),
KEY(7, 3, KEY_SPACE),
@@ -119,31 +116,23 @@ static int omap_keymap[] = {
0,
};
Are you aware of that interpretation of 'row' and 'col' get reversed
in matrix keymap framework.
Also last element '0' should be removed.
--
Regards,
Vimal Singh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAP3630SDP: Add support for Flash
On Tue, Apr 6, 2010 at 5:59 PM, Sukumar Ghorai s-gho...@ti.com wrote: Add support for NAND, OneNAND, NOR on OMAP 3630-sdp board. Signed-off-by: Sukumar Ghorai s-gho...@ti.com --- Feel free to add my acked-by: Acked-by: Vimal Singh vimal.neww...@gmail.com Regards, Vimal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ASK] OMAP 3430 LDP Trouble
On Wed, Apr 7, 2010 at 1:19 AM, Gadiyar, Anand gadi...@ti.com wrote: Gadiyar, Anand wrote: Tar Gz wrote: if NAND support is currently missing for OMAP3430 LDP,,how i boot my ldp again like before?...any idea? You can still have x-loader and u-boot on NAND (flash them from u-boot prompt, once you get booted up by any other method. for example serial boot as mentioned by Anand) and use NFS filesystem to work with. NAND driver support is missing in kernel, so, you will not be able to see/mount NAND partitions from kernel. -- Regards, Vimal Singh snip If I understand you correctly, you now have a non-booting LDP, and want to get a bootloader flashed on it? You may need to do a serial boot. Maybe this (old, and no longer maintained) page will help? https://gforge.ti.com/gf/project/omapzoom/wiki/?pagename=BootingAndFlashing Or this one: http://omappedia.org/wiki/Zoom_Flashing#Serial_Boot_Procedure -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ASK] OMAP 3430 LDP Trouble
AFAIK, NAND support is currently missing for OMAP3430 LDP boards in LO.
-Vimal
On Sun, Apr 4, 2010 at 9:34 PM, Ghorai, Sukumar s-gho...@ti.com wrote:
Aldyth,
1. Do you mean that NAND boot is not working?
2. Does MMC/SD boot working? If yes, boot the platform from MMC/SD using the
latest x-loade/ u-boot and flush the same binaries to NAND using the
following commands.
mmcinit 0
nand unlock 8 8
nand erase 8 8
fatload mmc 0 8000 u-boot.bin
nand write.i 8000 8 ${filesize}
nand unlock 0 8
nand erase 0 8
fatload mmc 0 8000 MLO
nand write.i 8000 0 ${filesize}
Regards,
Ghorai
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Tar Gz
Sent: 2010-04-04 11:13
To: linux-omap
Subject: [ASK] OMAP 3430 LDP Trouble
Hi all,
i'm sorry if my english too bad
I try to porting linux to omap 3430 LDP..but my board have trouble
after i running this command:
nand ecc sw
nand unlock 8 8
nand erase 8 8
nand ecc hw
nand unlock 0 8
nand erase 0 8
and if i try to turn on my board, BT led [blue led] always on and my
minicom can't show anything...and i forget to setting the enviroment
variable mmcinit..
my question is, how to make my board can run normally like before?
best regards,
Aldyth M
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-V2] OMAP: Fix for bus width which improves SD card's peformance.
drivers/mmc/host/omap_hsmmc.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 83f0aff..8c97c22 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -2092,7 +2092,7 @@ static int __init omap_hsmmc_probe(struct MMC_CAP_WAIT_WHILE_BUSY; if (mmc_slot(host).wires = 8) - mmc-caps |= MMC_CAP_8_BIT_DATA; + mmc-caps |= (MMC_CAP_8_BIT_DATA | MMC_CAP_4_BIT_DATA); else if (mmc_slot(host).wires = 4) mmc-caps |= MMC_CAP_4_BIT_DATA; Your mailer has some issue, 'tabs' got replaced by 'spaces' in this patch. Please fix it and repost. Also take care off deleting below unrelated content. - Regards, Vimal On Thu, Feb 11, 2010 at 11:04 PM, Madhusudhan madhu...@ti.com wrote: -Original Message- From: kishore kadiyala [mailto:kishore.kadiy...@ti.com] Sent: Thursday, February 11, 2010 8:20 AM To: linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org Cc: jarkko.lavi...@nokia.com; madhu...@ti.com Subject: [PATCH] OMAP: Fix for bus width which improves SD card's peformance. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: probe of omap2-nand failed with -16
On Tue, Mar 9, 2010 at 1:34 AM, Pablo Bitton pablo.bit...@gmail.com wrote: Hi, I've started working on beagle board. Using pre-compiled kernel (angstrom) - i've got nand driver loaded and running. When I am trying to compile my own kernel from the source, I get error: probe of omap2-nand failed with -16 (EBUSY) This happens because we moved 'gpmc_cs_request' from nand driver (nand/omap2.c) probe to 'mach-omap2/gpmc-nand.c'. I've selected all configs for Nand... Am I missing something? Mux configuration? GPIO's? Anybody has any idea? Yes. You need to adopt gpmc-nand.c for beagle boards. For help you may have a look into below commits: 1. http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commitdiff;h=c2798e9342a1394de966c31703e0410ee3988378 2. http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commitdiff;h=88c8460ac32283e2a25e36e4670ff5ab02f3b521 -- Regards, Vimal Singh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] OMAP: ZOOM: Introducing 'board-zoom-flash.c'
On Fri, Feb 12, 2010 at 2:49 AM, Tony Lindgren t...@atomide.com wrote:
* Tony Lindgren t...@atomide.com [100211 12:43]:
* Vimal Singh vimal.neww...@gmail.com [100210 21:16]:
From: Vimal Singh vimalsi...@ti.com
This patch adds 'board-zoom-flash.c', which could be utilized
by boards similar to ZOOM2. (For ex: LDP, ZOOM2, ZOOM3).
This does initialization for NAND device based on the 'cs' number
and partition information passed from board file (ex: board-zoom2.c).
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/board-zoom-flash.c | 85
+
arch/arm/mach-omap2/include/mach/board-zoom.h | 11 +++
2 files changed, 96 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-zoom-flash.c
diff --git a/arch/arm/mach-omap2/board-zoom-flash.c
b/arch/arm/mach-omap2/board-zoom-flash.c
new file mode 100644
index 000..f2328a4
--- /dev/null
+++ b/arch/arm/mach-omap2/board-zoom-flash.c
@@ -0,0 +1,85 @@
+/*
+ * board-zoom-flash.c
+ *
+ * Copyright (C) 2009 Texas Instruments Inc.
+ * Vimal Singh vimalsi...@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/delay.h
+#include linux/platform_device.h
+#include linux/mtd/nand.h
+#include linux/types.h
+#include linux/io.h
+
+#include asm/mach/flash.h
+#include plat/board.h
+#include plat/gpmc.h
+#include plat/nand.h
+
+#include mach/board-zoom.h
+
+#if defined(CONFIG_MTD_NAND_OMAP2) || \
+ defined(CONFIG_MTD_NAND_OMAP2_MODULE)
+
+/* Note that all values in this struct are in nanoseconds */
+static struct gpmc_timings nand_timings = {
+
+ .sync_clk = 0,
+
+ .cs_on = 0,
+ .cs_rd_off = 36,
+ .cs_wr_off = 36,
+
+ .adv_on = 6,
+ .adv_rd_off = 24,
+ .adv_wr_off = 36,
+
+ .we_off = 30,
+ .oe_off = 48,
+
+ .access = 54,
+ .rd_cycle = 72,
+ .wr_cycle = 72,
+
+ .wr_access = 30,
+ .wr_data_mux_bus = 0,
+};
+
+/* NAND chip access: 16 bit */
+static struct omap_nand_platform_data zoom_nand_data = {
+ .nand_setup = NULL,
+ .gpmc_t = nand_timings,
+ .dma_channel = -1, /* disable DMA in OMAP NAND driver */
+ .dev_ready = NULL,
+ .devsize = 1, /* '0' for 8-bit, '1' for 16-bit device */
+};
+
+/**
+ * zoom_flash_init - Identify devices connected to GPMC and register.
+ *
+ * @return - void.
+ */
+void __init zoom_flash_init(struct flash_partitions zoom_nand_parts[],
int cs)
+{
+ u32 gpmc_base_add = OMAP34XX_GPMC_VIRT;
+
+ zoom_nand_data.cs = cs;
+ zoom_nand_data.parts = zoom_nand_parts[0].parts;
+ zoom_nand_data.nr_parts = zoom_nand_parts[0].nr_parts;
+ zoom_nand_data.gpmc_baseaddr = (void *)(gpmc_base_add);
+ zoom_nand_data.gpmc_cs_baseaddr = (void *)(gpmc_base_add +
+ GPMC_CS0_BASE +
+ cs * GPMC_CS_SIZE);
The gpmc_baseaddr and gpmc_cs_baseaddr should no longer be
needed with gpmc-nand.c, right?
As said earlier too these are needed by 'nand/omap2.c' driver not for
gpmc.-nand.c, we still need to pass these.
Yeah.. For now, I suggest you set the gpmc_baseaddr and
gpmc_cs_baseaddr in gpmc_nand_init() based on the results from
gpmc_cs_request.
That will allow us to remove the insane hardcoded gpmc virtual
addresses from all board-*.c files.
OK
And then we can finally fix gpmc-nand.c driver not to go tinker
You mean omap2.c nand driver?
with the GPMC registers directly. All of that should be in
gpmc-nand.c using gpmc.c. The driver should be just a generic
NAND driver.
Yes, but that will take complete clean-up of omap2.c nand driver by
moving all functions accessing GPMC registers from 'nand/omap2.c' to
'gpmc-nand.c'. And we can take that work later.
Once everything is working fine and is at proper place, clean-up will
have more visibility.
IMHO, you can still take patches for now. As, this is how already done
for sdp boards too.
--
Regards,
Vimal Singh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] nand support on zoom boards
Re-posting this patch series once again after re-basing on latest LO master. - vimal On Wed, Jan 13, 2010 at 12:31 PM, Vimal Singh vimal.neww...@gmail.com wrote: From 345704a79f15b0481b14d5d504b0bcdf55f2a9a6 Mon Sep 17 00:00:00 2001 From: Vimal Singh vimalsi...@ti.com Date: Tue, 12 Jan 2010 18:12:53 +0530 Subject: [PATCH] nand support on zoom boards I have verified it on zoom2/3 support on zoom boards. I still have not tried it on LDP (zoom1) board. So, I'll post patch for same later. Vimal Singh (3): OMAP: ZOOM: Introducing 'board-zoom-flash.c' OMAP3: Add support for NAND on ZOOM2 board OMAP3: Add support for NAND on ZOOM3 board arch/arm/mach-omap2/Makefile | 2 + arch/arm/mach-omap2/board-zoom-flash.c | 85 + arch/arm/mach-omap2/board-zoom2.c | 49 ++ arch/arm/mach-omap2/board-zoom3.c | 49 ++ arch/arm/mach-omap2/include/mach/board-zoom.h | 11 +++ 5 files changed, 196 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/board-zoom-flash.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/3] OMAP: ZOOM: Introducing 'board-zoom-flash.c'
From: Vimal Singh vimalsi...@ti.com
This patch adds 'board-zoom-flash.c', which could be utilized
by boards similar to ZOOM2. (For ex: LDP, ZOOM2, ZOOM3).
This does initialization for NAND device based on the 'cs' number
and partition information passed from board file (ex: board-zoom2.c).
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/board-zoom-flash.c| 85 +
arch/arm/mach-omap2/include/mach/board-zoom.h | 11 +++
2 files changed, 96 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-zoom-flash.c
diff --git a/arch/arm/mach-omap2/board-zoom-flash.c
b/arch/arm/mach-omap2/board-zoom-flash.c
new file mode 100644
index 000..f2328a4
--- /dev/null
+++ b/arch/arm/mach-omap2/board-zoom-flash.c
@@ -0,0 +1,85 @@
+/*
+ * board-zoom-flash.c
+ *
+ * Copyright (C) 2009 Texas Instruments Inc.
+ * Vimal Singh vimalsi...@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/delay.h
+#include linux/platform_device.h
+#include linux/mtd/nand.h
+#include linux/types.h
+#include linux/io.h
+
+#include asm/mach/flash.h
+#include plat/board.h
+#include plat/gpmc.h
+#include plat/nand.h
+
+#include mach/board-zoom.h
+
+#if defined(CONFIG_MTD_NAND_OMAP2) || \
+ defined(CONFIG_MTD_NAND_OMAP2_MODULE)
+
+/* Note that all values in this struct are in nanoseconds */
+static struct gpmc_timings nand_timings = {
+
+ .sync_clk = 0,
+
+ .cs_on = 0,
+ .cs_rd_off = 36,
+ .cs_wr_off = 36,
+
+ .adv_on = 6,
+ .adv_rd_off = 24,
+ .adv_wr_off = 36,
+
+ .we_off = 30,
+ .oe_off = 48,
+
+ .access = 54,
+ .rd_cycle = 72,
+ .wr_cycle = 72,
+
+ .wr_access = 30,
+ .wr_data_mux_bus = 0,
+};
+
+/* NAND chip access: 16 bit */
+static struct omap_nand_platform_data zoom_nand_data = {
+ .nand_setup = NULL,
+ .gpmc_t = nand_timings,
+ .dma_channel= -1, /* disable DMA in OMAP NAND driver */
+ .dev_ready = NULL,
+ .devsize= 1,/* '0' for 8-bit, '1' for 16-bit device */
+};
+
+/**
+ * zoom_flash_init - Identify devices connected to GPMC and register.
+ *
+ * @return - void.
+ */
+void __init zoom_flash_init(struct flash_partitions zoom_nand_parts[], int cs)
+{
+ u32 gpmc_base_add = OMAP34XX_GPMC_VIRT;
+
+ zoom_nand_data.cs = cs;
+ zoom_nand_data.parts= zoom_nand_parts[0].parts;
+ zoom_nand_data.nr_parts = zoom_nand_parts[0].nr_parts;
+ zoom_nand_data.gpmc_baseaddr= (void *)(gpmc_base_add);
+ zoom_nand_data.gpmc_cs_baseaddr = (void *)(gpmc_base_add +
+ GPMC_CS0_BASE +
+ cs * GPMC_CS_SIZE);
+ gpmc_nand_init(zoom_nand_data);
+}
+#else
+void __init zoom_flash_init(struct flash_partitions zoom_nand_parts[], int cs)
+{
+}
+#endif /* CONFIG_MTD_NAND_OMAP2 || CONFIG_MTD_NAND_OMAP2_MODULE */
+
diff --git a/arch/arm/mach-omap2/include/mach/board-zoom.h
b/arch/arm/mach-omap2/include/mach/board-zoom.h
index c93b29e..f4469d3 100644
--- a/arch/arm/mach-omap2/include/mach/board-zoom.h
+++ b/arch/arm/mach-omap2/include/mach/board-zoom.h
@@ -1,5 +1,16 @@
/*
* Defines for zoom boards
*/
+#include linux/mtd/mtd.h
+#include linux/mtd/partitions.h
+
+struct flash_partitions {
+ struct mtd_partition *parts;
+ int nr_parts;
+};
+
+#define ZOOM_NAND_CS 0
+
+extern void __init zoom_flash_init(struct flash_partitions [], int);
extern int __init zoom_debugboard_init(void);
extern void __init zoom_peripherals_init(void);
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] OMAP3: Add support for NAND on ZOOM2 board
From: Vimal Singh vimalsi...@ti.com
This patch adds NAND support to ZOOM2 board.
This uses 'board-zoom-flash.c' for NAND initialization.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-zoom2.c | 49 +
2 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index d3e54da..bd37d6e 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -110,6 +110,7 @@ obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o
\
board-rx51-peripherals.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom2.o \
+ board-zoom-flash.o \
board-zoom-peripherals.o \
hsmmc.o \
board-zoom-debugboard.o
diff --git a/arch/arm/mach-omap2/board-zoom2.c
b/arch/arm/mach-omap2/board-zoom2.c
index 9a26f84..1e39677 100644
--- a/arch/arm/mach-omap2/board-zoom2.c
+++ b/arch/arm/mach-omap2/board-zoom2.c
@@ -77,10 +77,59 @@ static struct omap_board_mux board_mux[]
#define board_mux NULL
#endif
+static struct mtd_partition zoom_nand_partitions[] = {
+ /* All the partition sizes are listed in terms of NAND block size */
+ {
+ .name = X-Loader-NAND,
+ .offset = 0,
+ .size = 4 * (64 * 2048), /* 512KB, 0x8 */
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+},
+ {
+ .name = U-Boot-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x8 */
+ .size = 10 * (64 * 2048), /* 1.25MB, 0x14 */
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = Boot Env-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x1c */
+ .size = 2 * (64 * 2048), /* 256KB, 0x4 */
+ },
+ {
+ .name = Kernel-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x020*/
+ .size = 240 * (64 * 2048),/* 30M, 0x1E0 */
+ },
+ {
+ .name = system,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x200 */
+ .size = 1280 * (64 * 2048), /* 160M, 0xA00 */
+ },
+ {
+ .name = userdata,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0xC00 */
+ .size = 256 * (64 * 2048),/* 32M, 0x200 */
+ },
+ {
+ .name = cache,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0xE00 */
+ .size = 256 * (64 * 2048),/* 32M, 0x200 */
+ },
+};
+
+static struct flash_partitions zoom_flash_partitions[] = {
+ {
+ .parts = zoom_nand_partitions,
+ .nr_parts = ARRAY_SIZE(zoom_nand_partitions),
+ },
+};
+
static void __init omap_zoom2_init(void)
{
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
zoom_peripherals_init();
+ zoom_flash_init(zoom_flash_partitions, ZOOM_NAND_CS);
zoom_debugboard_init();
}
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/3] OMAP3: Add support for NAND on ZOOM3 board
From: Vimal Singh vimalsi...@ti.com
This patch adds NAND support to ZOOM3 board.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-zoom3.c | 49 +
2 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index bd37d6e..556e62f 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -115,6 +115,7 @@ obj-$(CONFIG_MACH_OMAP_ZOOM2) +=
board-zoom2.o \
hsmmc.o \
board-zoom-debugboard.o
obj-$(CONFIG_MACH_OMAP_ZOOM3) += board-zoom3.o \
+ board-zoom-flash.o \
board-zoom-peripherals.o \
hsmmc.o \
board-zoom-debugboard.o
diff --git a/arch/arm/mach-omap2/board-zoom3.c
b/arch/arm/mach-omap2/board-zoom3.c
index d3e3cd5..fcd0c0d 100644
--- a/arch/arm/mach-omap2/board-zoom3.c
+++ b/arch/arm/mach-omap2/board-zoom3.c
@@ -34,6 +34,54 @@ static void __init omap_zoom_map_io(void)
static struct omap_board_config_kernel zoom_config[] __initdata = {
};
+static struct mtd_partition zoom_nand_partitions[] = {
+ /* All the partition sizes are listed in terms of NAND block size */
+ {
+ .name = X-Loader-NAND,
+ .offset = 0,
+ .size = 4 * (64 * 2048), /* 512KB, 0x8 */
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = U-Boot-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x8 */
+ .size = 10 * (64 * 2048), /* 1.25MB, 0x14 */
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = Boot Env-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x1c */
+ .size = 2 * (64 * 2048), /* 256KB, 0x4 */
+ },
+ {
+ .name = Kernel-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x020*/
+ .size = 240 * (64 * 2048),/* 30M, 0x1E0 */
+ },
+ {
+ .name = system,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x200 */
+ .size = 1280 * (64 * 2048), /* 160M, 0xA00 */
+ },
+ {
+ .name = userdata,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0xC00 */
+ .size = 256 * (64 * 2048),/* 32M, 0x200 */
+ },
+ {
+ .name = cache,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0xE00 */
+ .size = 256 * (64 * 2048),/* 32M, 0x200 */
+ },
+};
+
+static struct flash_partitions zoom_flash_partitions[] = {
+ {
+ .parts = zoom_nand_partitions,
+ .nr_parts = ARRAY_SIZE(zoom_nand_partitions),
+ },
+};
+
static void __init omap_zoom_init_irq(void)
{
omap_board_config = zoom_config;
@@ -66,6 +114,7 @@ static void __init omap_zoom_init(void)
{
omap3_mux_init(board_mux, OMAP_PACKAGE_CBP);
zoom_peripherals_init();
+ zoom_flash_init(zoom_flash_partitions, ZOOM_NAND_CS);
zoom_debugboard_init();
omap_mux_init_gpio(64, OMAP_PIN_OUTPUT);
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/3] OMAP: NAND: support flashes on sdp boards
On Wed, Jan 13, 2010 at 12:16 PM, Vimal Singh vimal.neww...@gmail.com wrote: From 4fbddd880c7a0da61fb66ae1d2c2553e3fbc82cb Mon Sep 17 00:00:00 2001 From: Vimal Singh vimalsi...@ti.com Date: Tue, 12 Jan 2010 18:14:14 +0530 Subject: [PATCH] OMAP: NAND: support flashes on sdp boards Reposting this patch set again after fixes in 1st patch as per comments from Tony: - Removing 'nand_base' from functions specified and correcting prototype in header file too - calling gpmc_cs_request first Rest of the patches in the series are untouched and just have been re-based on LO master branch. -- Vimal From d3e5ee6d8a6449aee01fbc93313201a4674f5577 Mon Sep 17 00:00:00 2001 From: Vimal Singh vimalsi...@ti.com Date: Mon, 8 Feb 2010 05:19:20 +0530 Subject: [PATCH] OMAP: NAND: support flashes on sdp boards 1st patch introduces 'gpmc-nand.c' for generic gpmc stuffs. Which may be used by any omap board. 2nd and 3rd patches are to show up how to use 'gpmc-nand.c' with example of 3430sdp board. Vimal Singh (3): Introducing 'gpmc-nand.c' for GPMC specific NAND init OMAP: SDP: Introducing 'board-sdp-flash.c' for flash init OMAP3: Add support for flash on 3430SDP board arch/arm/mach-omap2/Makefile |4 + arch/arm/mach-omap2/board-3430sdp.c | 111 ++ arch/arm/mach-omap2/board-sdp-flash.c| 295 ++ arch/arm/mach-omap2/gpmc-nand.c | 139 arch/arm/mach-omap2/include/mach/board-sdp.h | 22 ++ arch/arm/plat-omap/include/plat/gpmc.h |2 + arch/arm/plat-omap/include/plat/nand.h | 10 +- drivers/mtd/nand/omap2.c | 35 +--- 8 files changed, 586 insertions(+), 32 deletions(-) create mode 100644 arch/arm/mach-omap2/board-sdp-flash.c create mode 100644 arch/arm/mach-omap2/gpmc-nand.c create mode 100644 arch/arm/mach-omap2/include/mach/board-sdp.h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/3] Introducing 'gpmc-nand.c' for GPMC specific NAND init
From 35da04834f4b0363e90a628bdb369318d80b7a6c Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Fri, 5 Feb 2010 05:56:18 +0530
Subject: [PATCH 1/3] Introducing 'gpmc-nand.c' for GPMC specific NAND init
Introducing 'gpmc-nand.c' for GPMC specific NAND init.
For example: GPMC timing parameters and all.
This patch also migrates gpmc related calls from 'nand/omap2.c'
to 'gpmc-nand.c'.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/Makefile |3 +
arch/arm/mach-omap2/gpmc-nand.c| 139
arch/arm/plat-omap/include/plat/nand.h | 10 ++-
drivers/mtd/nand/omap2.c | 35 +---
4 files changed, 155 insertions(+), 32 deletions(-)
create mode 100644 arch/arm/mach-omap2/gpmc-nand.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index dba44a1..c012dd1 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -135,5 +135,8 @@ obj-y += usb-ehci.o
onenand-$(CONFIG_MTD_ONENAND_OMAP2):= gpmc-onenand.o
obj-y += $(onenand-m) $(onenand-y)
+nand-$(CONFIG_MTD_NAND_OMAP2) := gpmc-nand.o
+obj-y += $(nand-m) $(nand-y)
+
smc91x-$(CONFIG_SMC91X):= gpmc-smc91x.o
obj-y += $(smc91x-m) $(smc91x-y)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
new file mode 100644
index 000..64d74f0
--- /dev/null
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -0,0 +1,139 @@
+/*
+ * gpmc-nand.c
+ *
+ * Copyright (C) 2009 Texas Instruments
+ * Vimal Singh vimalsi...@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/nand.h
+#include plat/board.h
+#include plat/gpmc.h
+
+#define WR_RD_PIN_MONITORING 0x0060
+
+static struct omap_nand_platform_data *gpmc_nand_data;
+
+static struct resource gpmc_nand_resource = {
+ .flags = IORESOURCE_MEM,
+};
+
+static struct platform_device gpmc_nand_device = {
+ .name = omap2-nand,
+ .id = 0,
+ .num_resources = 1,
+ .resource = gpmc_nand_resource,
+};
+
+static int omap2_nand_gpmc_retime(void)
+{
+ struct gpmc_timings t;
+ int err;
+
+ memset(t, 0, sizeof(t));
+ t.sync_clk = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-sync_clk);
+ t.cs_on = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-cs_on);
+ t.adv_on = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-adv_on);
+
+ /* Read */
+ t.adv_rd_off = gpmc_round_ns_to_ticks(
+ gpmc_nand_data-gpmc_t-adv_rd_off);
+ t.oe_on = t.adv_on;
+ t.access = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-access);
+ t.oe_off = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-oe_off);
+ t.cs_rd_off = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-cs_rd_off);
+ t.rd_cycle = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-rd_cycle);
+
+ /* Write */
+ t.adv_wr_off = gpmc_round_ns_to_ticks(
+ gpmc_nand_data-gpmc_t-adv_wr_off);
+ t.we_on = t.oe_on;
+ if (cpu_is_omap34xx()) {
+ t.wr_data_mux_bus = gpmc_round_ns_to_ticks(
+ gpmc_nand_data-gpmc_t-wr_data_mux_bus);
+ t.wr_access = gpmc_round_ns_to_ticks(
+ gpmc_nand_data-gpmc_t-wr_access);
+ }
+ t.we_off = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-we_off);
+ t.cs_wr_off = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-cs_wr_off);
+ t.wr_cycle = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-wr_cycle);
+
+ /* Configure GPMC */
+ gpmc_cs_write_reg(gpmc_nand_data-cs, GPMC_CS_CONFIG1,
+ GPMC_CONFIG1_DEVICESIZE(gpmc_nand_data-devsize) |
+ GPMC_CONFIG1_DEVICETYPE_NAND);
+
+ err = gpmc_cs_set_timings(gpmc_nand_data-cs, t);
+ if (err)
+ return err;
+
+ return 0;
+}
+
+static int gpmc_nand_setup(void)
+{
+ struct device *dev = gpmc_nand_device.dev;
+
+ /* Set timings in GPMC */
+ if (omap2_nand_gpmc_retime() 0) {
+ dev_err(dev, Unable to set gpmc timings\n);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+int __init gpmc_nand_init(struct omap_nand_platform_data *_nand_data)
+{
+ unsigned int val;
+ int err = 0;
+ struct device *dev = gpmc_nand_device.dev;
+
+ gpmc_nand_data = _nand_data;
+ gpmc_nand_data-nand_setup = gpmc_nand_setup;
+ gpmc_nand_device.dev.platform_data = gpmc_nand_data;
+
+ err = gpmc_cs_request
[PATCH v2 2/3] OMAP: SDP: Introducing 'board-sdp-flash.c' for flash init
From e586d2fbbecc60bc66687c4e6d4798913bb33b7a Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Mon, 8 Feb 2010 05:02:45 +0530
Subject: [PATCH 2/3] 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 vimalsi...@ti.com
---
arch/arm/mach-omap2/board-sdp-flash.c| 295 ++
arch/arm/mach-omap2/include/mach/board-sdp.h | 22 ++
arch/arm/plat-omap/include/plat/gpmc.h |2 +
3 files changed, 319 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 000..54ef19f
--- /dev/null
+++ b/arch/arm/mach-omap2/board-sdp-flash.c
@@ -0,0 +1,295 @@
+/*
+ * board-sdp-flash.c
+ * Modified from mach-omap2/board-3430sdp-flash.c
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Copyright (C) 2009 Texas Instruments
+ *
+ * Vimal Singh vimalsi...@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/mtd/physmap.h
+#include linux/io.h
+
+#include plat/gpmc.h
+#include plat/nand.h
+#include plat/onenand.h
+#include plat/tc.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 0x0800 /* debug board */
+
+#define PDC_NOR1
+#define PDC_NAND 2
+#define PDC_ONENAND3
+#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: */
+ {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 void omap_set_vpp(struct map_info *map, int enable)
+{
+ static int count;
+ u32 l;
+
+ if (cpu_class_is_omap1()) {
+ if (enable) {
+ if (count++ == 0) {
+ l = omap_readl(EMIFS_CONFIG);
+ l |= OMAP_EMIFS_CONFIG_WP;
+ omap_writel(l, EMIFS_CONFIG);
+ }
+ } else {
+ if (count (--count == 0)) {
+ l = omap_readl(EMIFS_CONFIG);
+ l = ~OMAP_EMIFS_CONFIG_WP;
+ omap_writel(l, EMIFS_CONFIG);
+ }
+ }
+ }
+}
+
+static struct physmap_flash_data sdp_nor_data = {
+ .width = 2,
+ .set_vpp= omap_set_vpp,
+};
+
+static struct resource sdp_nor_resource = {
+ .flags = IORESOURCE_MEM,
+};
+
+static struct platform_device sdp_nor_device = {
+ .name = physmap-flash,
+ .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
[PATCH v2 3/3] OMAP3: Add support for flash on 3430SDP board
From d3e5ee6d8a6449aee01fbc93313201a4674f5577 Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Mon, 8 Feb 2010 05:06:33 +0530
Subject: [PATCH 3/3] OMAP3: Add support for flash on 3430SDP board
This patch adds support for flashes on 3430SDP boards. All three
NAND, NOR and OneNAND are supported. I have tested it on
3430SDP (ES2 and ES3.1).
This patch can be treated as an example to how to utilize:
'gpmc-nand.c' and 'board-sdp-flash.c'.
Similar patches can be created for 2430sdp and 3630sdp or any other
similar board.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/Makefile|1 +
arch/arm/mach-omap2/board-3430sdp.c | 111 +++
2 files changed, 112 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index c012dd1..9454a92 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -100,6 +100,7 @@ obj-$(CONFIG_MACH_OMAP3EVM) += board-omap3evm.o \
obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP_3430SDP)+= board-3430sdp.o \
+ board-sdp-flash.o \
hsmmc.o
obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o
obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 854b6f4..5adef51 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -41,6 +41,8 @@
#include plat/control.h
#include plat/gpmc-smc91x.h
+#include mach/board-sdp.h
+
#include mux.h
#include sdram-qimonda-hyb18m512160af-6.h
#include hsmmc.h
@@ -650,6 +652,114 @@ static struct omap_board_mux board_mux[] __initdata = {
#define board_mux NULL
#endif
+static struct mtd_partition sdp_nor_partitions[] = {
+ /* bootloader (U-Boot, etc) in first sector */
+ {
+ .name = Bootloader-NOR,
+ .offset = 0,
+ .size = SZ_256K,
+ .mask_flags = MTD_WRITEABLE, /* force read-only */
+ },
+ /* bootloader params in the next sector */
+ {
+ .name = Params-NOR,
+ .offset = MTDPART_OFS_APPEND,
+ .size = SZ_256K,
+ .mask_flags = 0,
+ },
+ /* kernel */
+ {
+ .name = Kernel-NOR,
+ .offset = MTDPART_OFS_APPEND,
+ .size = SZ_2M,
+ .mask_flags = 0
+ },
+ /* file system */
+ {
+ .name = Filesystem-NOR,
+ .offset = MTDPART_OFS_APPEND,
+ .size = MTDPART_SIZ_FULL,
+ .mask_flags = 0
+ }
+};
+
+static struct mtd_partition sdp_onenand_partitions[] = {
+ {
+ .name = X-Loader-OneNAND,
+ .offset = 0,
+ .size = 4 * (64 * 2048),
+ .mask_flags = MTD_WRITEABLE /* force read-only */
+ },
+ {
+ .name = U-Boot-OneNAND,
+ .offset = MTDPART_OFS_APPEND,
+ .size = 2 * (64 * 2048),
+ .mask_flags = MTD_WRITEABLE /* force read-only */
+ },
+ {
+ .name = U-Boot Environment-OneNAND,
+ .offset = MTDPART_OFS_APPEND,
+ .size = 1 * (64 * 2048),
+ },
+ {
+ .name = Kernel-OneNAND,
+ .offset = MTDPART_OFS_APPEND,
+ .size = 16 * (64 * 2048),
+ },
+ {
+ .name = File System-OneNAND,
+ .offset = MTDPART_OFS_APPEND,
+ .size = MTDPART_SIZ_FULL,
+ },
+};
+
+static struct mtd_partition sdp_nand_partitions[] = {
+ /* All the partition sizes are listed in terms of NAND block size */
+ {
+ .name = X-Loader-NAND,
+ .offset = 0,
+ .size = 4 * (64 * 2048),
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = U-Boot-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x8 */
+ .size = 10 * (64 * 2048),
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = Boot Env-NAND,
+
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x1c */
+ .size = 6 * (64 * 2048),
+ },
+ {
+ .name = Kernel-NAND,
+ .offset
Re: [PATCH v2 2/3] OMAP: SDP: Introducing 'board-sdp-flash.c' for flash init
On Mon, Feb 8, 2010 at 7:22 PM, Ladislav Michl ladislav.mi...@seznam.cz wrote:
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 000..54ef19f
--- /dev/null
+++ b/arch/arm/mach-omap2/board-sdp-flash.c
[snip]
+static void omap_set_vpp(struct map_info *map, int enable)
+{
+ static int count;
+ u32 l;
+
+ if (cpu_class_is_omap1()) {
+ if (enable) {
+ if (count++ == 0) {
+ l = omap_readl(EMIFS_CONFIG);
+ l |= OMAP_EMIFS_CONFIG_WP;
+ omap_writel(l, EMIFS_CONFIG);
+ }
+ } else {
+ if (count (--count == 0)) {
+ l = omap_readl(EMIFS_CONFIG);
+ l = ~OMAP_EMIFS_CONFIG_WP;
+ omap_writel(l, EMIFS_CONFIG);
+ }
+ }
+ }
+}
Hmm, as you are adding files into arch/arm/mach-omap2 directory, is there
a chance cpu_class_is_omap1() ever returns non-zero?
+static struct physmap_flash_data sdp_nor_data = {
+ .width = 2,
+ .set_vpp = omap_set_vpp,
+};
... and in case there is not, just leave set_vpp set to NULL and delete this
incarnation of omap_set_vpp.
My bad. I just did not look into that.
I'll fix it as per your suggestion.
--
Regards,
Vimal Singh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/3] OMAP: SDP: Introducing 'board-sdp-flash.c' for flash init
In this version: (as per comments recieved for 2nd version)
- remove 'omap_set_vpp' function
- set 'set_vpp' to null
These changes do not have any impact on rest of the patches in series.
-vimal
From 6199d9c4db83dfd006f7cc2e74089ca1e9fdf8dc Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Mon, 8 Feb 2010 05:02:45 +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 vimalsi...@ti.com
---
arch/arm/mach-omap2/board-sdp-flash.c| 273 ++
arch/arm/mach-omap2/include/mach/board-sdp.h | 22 ++
arch/arm/plat-omap/include/plat/gpmc.h |2 +
3 files changed, 297 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 000..a0b80e7
--- /dev/null
+++ b/arch/arm/mach-omap2/board-sdp-flash.c
@@ -0,0 +1,273 @@
+/*
+ * board-sdp-flash.c
+ * Modified from mach-omap2/board-3430sdp-flash.c
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Copyright (C) 2009 Texas Instruments
+ *
+ * Vimal Singh vimalsi...@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/mtd/physmap.h
+#include linux/io.h
+
+#include plat/gpmc.h
+#include plat/nand.h
+#include plat/onenand.h
+#include plat/tc.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 0x0800 /* debug board */
+
+#define PDC_NOR1
+#define PDC_NAND 2
+#define PDC_ONENAND3
+#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: */
+ {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 physmap_flash_data sdp_nor_data = {
+ .width = 2,
+ .set_vpp= NULL,
+};
+
+static struct resource sdp_nor_resource = {
+ .flags = IORESOURCE_MEM,
+};
+
+static struct platform_device sdp_nor_device = {
+ .name = physmap-flash,
+ .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
Re: [PATCH v3 2/3] OMAP: SDP: Introducing 'board-sdp-flash.c' for flash init
On Mon, Feb 8, 2010 at 9:02 PM, Ladislav Michl ladislav.mi...@seznam.cz wrote:
On Mon, Feb 08, 2010 at 06:38:57PM +0530, Vimal Singh wrote:
In this version: (as per comments recieved for 2nd version)
- remove 'omap_set_vpp' function
- set 'set_vpp' to null
Ah, I'm sorry for not being quite exact. leave set_vpp set to NULL means
there is no need to asign anything to that structure member, because BSS is
zeroed (set to NULL) anyway. Something like this:
static struct physmap_flash_data sdp_nor_data = {
.width = 2,
};
Yes, this is a nitpick only...
Below is updated patch. I am not increasing the version number for
this tinny change.
-vimal
From f931fb85b774f97db3b0a25cde4a8154bb8d6dba Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Mon, 8 Feb 2010 05:02:45 +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 vimalsi...@ti.com
---
arch/arm/mach-omap2/board-sdp-flash.c| 272 ++
arch/arm/mach-omap2/include/mach/board-sdp.h | 22 ++
arch/arm/plat-omap/include/plat/gpmc.h |2 +
3 files changed, 296 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 000..b1b88de
--- /dev/null
+++ b/arch/arm/mach-omap2/board-sdp-flash.c
@@ -0,0 +1,272 @@
+/*
+ * board-sdp-flash.c
+ * Modified from mach-omap2/board-3430sdp-flash.c
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Copyright (C) 2009 Texas Instruments
+ *
+ * Vimal Singh vimalsi...@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/mtd/physmap.h
+#include linux/io.h
+
+#include plat/gpmc.h
+#include plat/nand.h
+#include plat/onenand.h
+#include plat/tc.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 0x0800 /* debug board */
+
+#define PDC_NOR1
+#define PDC_NAND 2
+#define PDC_ONENAND3
+#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: */
+ {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 physmap_flash_data sdp_nor_data = {
+ .width = 2,
+};
+
+static struct resource sdp_nor_resource = {
+ .flags = IORESOURCE_MEM,
+};
+
+static struct platform_device sdp_nor_device = {
+ .name = physmap-flash,
+ .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
[PATCH v3 2/3] OMAP: SDP: Introducing 'board-sdp-flash.c' for flash init
Sorry, mailer corrupted the last patch (line wrapped).
Here is the correct patch.
-
vimal
From f931fb85b774f97db3b0a25cde4a8154bb8d6dba Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Mon, 8 Feb 2010 05:02:45 +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 vimalsi...@ti.com
---
arch/arm/mach-omap2/board-sdp-flash.c| 272 ++
arch/arm/mach-omap2/include/mach/board-sdp.h | 22 ++
arch/arm/plat-omap/include/plat/gpmc.h |2 +
3 files changed, 296 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 000..b1b88de
--- /dev/null
+++ b/arch/arm/mach-omap2/board-sdp-flash.c
@@ -0,0 +1,272 @@
+/*
+ * board-sdp-flash.c
+ * Modified from mach-omap2/board-3430sdp-flash.c
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Copyright (C) 2009 Texas Instruments
+ *
+ * Vimal Singh vimalsi...@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/mtd/physmap.h
+#include linux/io.h
+
+#include plat/gpmc.h
+#include plat/nand.h
+#include plat/onenand.h
+#include plat/tc.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 0x0800 /* debug board */
+
+#define PDC_NOR1
+#define PDC_NAND 2
+#define PDC_ONENAND3
+#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: */
+ {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 physmap_flash_data sdp_nor_data = {
+ .width = 2,
+};
+
+static struct resource sdp_nor_resource = {
+ .flags = IORESOURCE_MEM,
+};
+
+static struct platform_device sdp_nor_device = {
+ .name = physmap-flash,
+ .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
Re: [PATCH 1/3] Introducing 'gpmc-nand.c' for GPMC specific NAND init
On Fri, Feb 5, 2010 at 5:17 AM, Tony Lindgren t...@atomide.com wrote:
Hi,
Almost there.. Few more comments below.
* Vimal Singh vimal.neww...@gmail.com [100112 22:48]:
From 89eaa5d55e04f65e76ad49ed8b010cba578d91ca Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Mon, 11 Jan 2010 16:01:29 +0530
Subject: [PATCH] Introducing 'gpmc-nand.c' for GPMC specific NAND init
Introducing 'gpmc-nand.c' for GPMC specific NAND init.
For example: GPMC timing parameters and all.
This patch also migrates gpmc related calls from 'nand/omap2.c'
to 'gpmc-nand.c'.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/Makefile | 3 +
arch/arm/mach-omap2/gpmc-nand.c | 139
arch/arm/plat-omap/include/plat/nand.h | 8 ++
drivers/mtd/nand/omap2.c | 35 +---
4 files changed, 154 insertions(+), 31 deletions(-)
create mode 100644 arch/arm/mach-omap2/gpmc-nand.c
snip
+static int omap2_nand_gpmc_config(void __iomem *nand_base)
+{
+ struct gpmc_timings t;
+ int err;
+
+ memset(t, 0, sizeof(t));
+ t.sync_clk = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-sync_clk);
+ t.cs_on = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-cs_on);
+ t.adv_on = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-adv_on);
+
+ /* Read */
+ t.adv_rd_off = gpmc_round_ns_to_ticks(
+ gpmc_nand_data-gpmc_t-adv_rd_off);
+ t.oe_on = t.adv_on;
+ t.access = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-access);
+ t.oe_off = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-oe_off);
+ t.cs_rd_off =
gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-cs_rd_off);
+ t.rd_cycle = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-rd_cycle);
+
+ /* Write */
+ t.adv_wr_off = gpmc_round_ns_to_ticks(
+ gpmc_nand_data-gpmc_t-adv_wr_off);
+ t.we_on = t.oe_on;
+ if (cpu_is_omap34xx()) {
+ t.wr_data_mux_bus = gpmc_round_ns_to_ticks(
+ gpmc_nand_data-gpmc_t-wr_data_mux_bus);
+ t.wr_access = gpmc_round_ns_to_ticks(
+ gpmc_nand_data-gpmc_t-wr_access);
+ }
+ t.we_off = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-we_off);
+ t.cs_wr_off =
gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-cs_wr_off);
+ t.wr_cycle = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-wr_cycle);
+
+ /* Configure GPMC */
+ gpmc_cs_write_reg(gpmc_nand_data-cs, GPMC_CS_CONFIG1,
+ GPMC_CONFIG1_DEVICESIZE(gpmc_nand_data-devsize) |
+ GPMC_CONFIG1_DEVICETYPE_NAND);
+
+ err = gpmc_cs_set_timings(gpmc_nand_data-cs, t);
+ if (err)
+ return err;
+
+ return 0;
+}
The nand_base is unused in omap2_nand_gpmc_config. And it's not needed there,
see below.
Also, maybe rename it to omap2_nand_gpmc_retime() instead? It should get
get called dynamically based on the cpufreq notifications from the driver
whenever the L3 frequency is being scaled. Otherwise NAND will stop working :)
+
+static int gpmc_nand_setup(void __iomem *nand_base)
+{
+ struct device *dev = gpmc_nand_device.dev;
+
+ /* Set timings in GPMC */
+ if (omap2_nand_gpmc_config(nand_base) 0) {
+ dev_err(dev, Unable to set gpmc timings\n);
+ return -EINVAL;
+ }
+
+ return 0;
+}
Here too nand_base is not needed. You can now get rid of this function.
Yeah, I will remove 'nand_base' from these functions. Actually
prototype of 'nand_setup' func in 'plat/nand.h' file was already
present with this arg. I'll correct that too.
+
+int __init gpmc_nand_init(struct omap_nand_platform_data *_nand_data)
+{
+ unsigned int val;
+ int err = 0;
+ struct device *dev = gpmc_nand_device.dev;
+
+ gpmc_nand_data = _nand_data;
+ gpmc_nand_data-nand_setup = gpmc_nand_setup;
+ gpmc_nand_device.dev.platform_data = gpmc_nand_data;
+
+ err = gpmc_nand_setup(gpmc_nand_data-gpmc_cs_baseaddr);
+ if (err 0) {
+ dev_err(dev, NAND platform setup failed: %d\n, err);
+ return err;
+ }
And this ordering must be changed around. You need to first call
gpmc_cs_request to allocate the GPMC area based on the chip select
and size from the gpmc_nand_data.
Only then you can call the timing function.
+ err = gpmc_cs_request(gpmc_nand_data-cs, NAND_IO_SIZE,
+ gpmc_nand_data-phys_base);
+ if (err 0) {
+ dev_err(dev, Cannot request GPMC CS\n);
+ return err;
+ }
So please do the gpmc_cs_request first.
That's correct, I'll do this.
Should be easy to fix for the whole series. Then let's plan on
merging it, it will be a nice improvment for all omaps using
NAND.
I'll reply on comments on those patches.
--
Regards,
Vimal Singh
--
To unsubscribe from
Re: NAND misreads on omap beagle and overo
I did not went through complete mail. Still, you may want to try this patch: http://git.infradead.org/users/dedekind/l2-mtd-2.6.git/commitdiff/dcb2469bdd3d12f760bae509f86b4069081a99c5 On Fri, Jan 29, 2010 at 1:40 PM, Jeff DeFouw je...@i2k.com wrote: I'm getting occasional bad reads from NAND on a rev B7 Beagleboard and a Gumstix Overo Water. Both use OMAP3530 with 16-bit 256MB NAND, omap-patched kernels from 2.6.31 to 2.6.32.6 (Ubuntu beagleboard kernel binaries and my own compiled from source), and software ECC. Sometimes a read request will read back the last written command byte several times before the page data. The problem occurs with or without prefetch mode, and increasing chip_delay to 100 or 200 doesn't fix it. The chip is only supposed to need 25us anyway. If I prepare the flash with a pattern 00 01 02 03 ... fc fd fe ff ff fe fd fc ... 03 02 01 00 and then read every page (full or partial), sometimes I will get e0 ff e0 ff e0 ff e0 ff ... e0 ff 00 01 02 03 ... or 30 ff 30 ff 30 ff 30 ff ... 30 ff 00 01 02 03 ... 0x30 and 0xE0 are probably the read and change-column commands echoing back for some reason. This can cause uncorrectable ECC errors, so you can do a simple read of the mtd char device (no pattern necessary, erased flash will do) and run into the problem on the console if you're patient. (while dd if=/dev/mtd4 of=/dev/null bs=2048; do sleep 1; done) I can usually get at least one bad read within 4 full 250MB partition reads at 512-bytes per read call (more commands that way). For some reason some kernels, like the Ubuntu beagleboard 2.6.31.6-x6.0 binary, make this harder to reproduce. If you flip enough (unrelated) settings in the build config, it will happen more often. For example, removing the built-in (=y) RT2800USB wireless driver from that kernel can somehow make the difference between seeing an error in a couple minutes and not seeing an error for over 10 minutes of continuous reading. I've tried adding some udelays, and adjusting timings in the OMAP GPMC and checking for incorrect config. A long udelay in the read_buf function helped in one test, but also cut the transfer rate in half and may not have eliminated the problem. What event would cause the command byte to echo back anyway? Is that a typical busy NAND response, or something the OMAP memory controller has to be doing? -- Jeff DeFouw je...@i2k.com __ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ -- Regards, Vimal Singh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3]: Introducing 'gpmc-nand.c' for GPMC specific NAND init
On Tue, Jan 12, 2010 at 6:31 AM, Tony Lindgren t...@atomide.com wrote:
Hi,
Few more comments below.
* Vimal Singh vimal.neww...@gmail.com [100111 02:47]:
On Mon, Jan 11, 2010 at 4:10 PM, Vimal Singh vimal.neww...@gmail.com wrote:
Re-summiting this patch. After re-basing on LO master.
-vimal
From a7ea8851fe96690c9322393eb35a344853992166 Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Mon, 11 Jan 2010 16:01:29 +0530
Subject: [PATCH] Introducing 'gpmc-nand.c' for GPMC specific NAND init
Introducing 'gpmc-nand.c' for GPMC specific NAND init.
For example: GPMC timing parameters and all.
This patch also migrates gpmc related calls from 'nand/omap2.c'
to 'gpmc-nand.c'.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/Makefile | 3 +
arch/arm/mach-omap2/gpmc-nand.c | 136
arch/arm/plat-omap/include/plat/nand.h | 6 ++
drivers/mtd/nand/omap2.c | 26 +--
4 files changed, 148 insertions(+), 23 deletions(-)
create mode 100644 arch/arm/mach-omap2/gpmc-nand.c
Patch got line wrapped. Corrected it below.
From a7ea8851fe96690c9322393eb35a344853992166 Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Mon, 11 Jan 2010 16:01:29 +0530
Subject: [PATCH] Introducing 'gpmc-nand.c' for GPMC specific NAND init
Introducing 'gpmc-nand.c' for GPMC specific NAND init.
For example: GPMC timing parameters and all.
This patch also migrates gpmc related calls from 'nand/omap2.c'
to 'gpmc-nand.c'.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/Makefile | 3 +
arch/arm/mach-omap2/gpmc-nand.c | 136
arch/arm/plat-omap/include/plat/nand.h | 6 ++
drivers/mtd/nand/omap2.c | 26 +--
4 files changed, 148 insertions(+), 23 deletions(-)
create mode 100644 arch/arm/mach-omap2/gpmc-nand.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index b32678b..247438b 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -119,5 +119,8 @@ obj-y += usb-ehci.o
onenand-$(CONFIG_MTD_ONENAND_OMAP2) := gpmc-onenand.o
obj-y += $(onenand-m) $(onenand-y)
+nand-$(CONFIG_MTD_NAND_OMAP2) := gpmc-nand.o
+obj-y += $(nand-m) $(nand-y)
+
smc91x-$(CONFIG_SMC91X) := gpmc-smc91x.o
obj-y += $(smc91x-m) $(smc91x-y)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c
b/arch/arm/mach-omap2/gpmc-nand.c
new file mode 100644
index 000..822ba82
--- /dev/null
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -0,0 +1,136 @@
+/*
+ * gpmc-nand.c
+ *
+ * Copyright (C) 2009 Texas Instruments
+ * Vimal Singh vimalsi...@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/nand.h
+#include plat/board.h
+#include plat/gpmc.h
+
+#define WR_RD_PIN_MONITORING 0x0060
+
+static struct omap_nand_platform_data *gpmc_nand_data;
+
+static struct resource gpmc_nand_resource = {
+ .flags = IORESOURCE_MEM,
+};
+
+static struct platform_device gpmc_nand_device = {
+ .name = omap2-nand,
+ .id = 0,
+ .num_resources = 1,
+ .resource = gpmc_nand_resource,
+};
+
+static int omap2_nand_gpmc_config(int cs, void __iomem *nand_base)
+{
+ struct gpmc_timings t;
+ int err;
+
+ const int cs_rd_off = 36;
+ const int cs_wr_off = 36;
+ const int adv_on = 6;
+ const int adv_rd_off = 24;
+ const int adv_wr_off = 36;
+ const int oe_off = 48;
+ const int we_off = 30;
+ const int rd_cycle = 72;
+ const int wr_cycle = 72;
+ const int access = 54;
+ const int wr_data_mux_bus = 0;
+ const int wr_access = 30;
+
+ memset(t, 0, sizeof(t));
+ t.sync_clk = 0;
+ t.cs_on = 0;
+ t.adv_on = gpmc_round_ns_to_ticks(adv_on);
+
+ /* Read */
+ t.adv_rd_off = gpmc_round_ns_to_ticks(adv_rd_off);
+ t.oe_on = t.adv_on;
+ t.access = gpmc_round_ns_to_ticks(access);
+ t.oe_off = gpmc_round_ns_to_ticks(oe_off);
+ t.cs_rd_off = gpmc_round_ns_to_ticks(cs_rd_off);
+ t.rd_cycle = gpmc_round_ns_to_ticks(rd_cycle);
+
+ /* Write */
+ t.adv_wr_off = gpmc_round_ns_to_ticks(adv_wr_off);
+ t.we_on = t.oe_on;
+ if (cpu_is_omap34xx()) {
+ t.wr_data_mux_bus = gpmc_round_ns_to_ticks(wr_data_mux_bus);
+ t.wr_access = gpmc_round_ns_to_ticks(wr_access
[PATCH 1/3] Introducing 'gpmc-nand.c' for GPMC specific NAND init
From 89eaa5d55e04f65e76ad49ed8b010cba578d91ca Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Mon, 11 Jan 2010 16:01:29 +0530
Subject: [PATCH] Introducing 'gpmc-nand.c' for GPMC specific NAND init
Introducing 'gpmc-nand.c' for GPMC specific NAND init.
For example: GPMC timing parameters and all.
This patch also migrates gpmc related calls from 'nand/omap2.c'
to 'gpmc-nand.c'.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/Makefile |3 +
arch/arm/mach-omap2/gpmc-nand.c| 139
arch/arm/plat-omap/include/plat/nand.h |8 ++
drivers/mtd/nand/omap2.c | 35 +---
4 files changed, 154 insertions(+), 31 deletions(-)
create mode 100644 arch/arm/mach-omap2/gpmc-nand.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index b32678b..247438b 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -119,5 +119,8 @@ obj-y += usb-ehci.o
onenand-$(CONFIG_MTD_ONENAND_OMAP2):= gpmc-onenand.o
obj-y += $(onenand-m) $(onenand-y)
+nand-$(CONFIG_MTD_NAND_OMAP2) := gpmc-nand.o
+obj-y += $(nand-m) $(nand-y)
+
smc91x-$(CONFIG_SMC91X):= gpmc-smc91x.o
obj-y += $(smc91x-m) $(smc91x-y)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
new file mode 100644
index 000..e3765f2
--- /dev/null
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -0,0 +1,139 @@
+/*
+ * gpmc-nand.c
+ *
+ * Copyright (C) 2009 Texas Instruments
+ * Vimal Singh vimalsi...@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/nand.h
+#include plat/board.h
+#include plat/gpmc.h
+
+#define WR_RD_PIN_MONITORING 0x0060
+
+static struct omap_nand_platform_data *gpmc_nand_data;
+
+static struct resource gpmc_nand_resource = {
+ .flags = IORESOURCE_MEM,
+};
+
+static struct platform_device gpmc_nand_device = {
+ .name = omap2-nand,
+ .id = 0,
+ .num_resources = 1,
+ .resource = gpmc_nand_resource,
+};
+
+static int omap2_nand_gpmc_config(void __iomem *nand_base)
+{
+ struct gpmc_timings t;
+ int err;
+
+ memset(t, 0, sizeof(t));
+ t.sync_clk = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-sync_clk);
+ t.cs_on = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-cs_on);
+ t.adv_on = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-adv_on);
+
+ /* Read */
+ t.adv_rd_off = gpmc_round_ns_to_ticks(
+ gpmc_nand_data-gpmc_t-adv_rd_off);
+ t.oe_on = t.adv_on;
+ t.access = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-access);
+ t.oe_off = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-oe_off);
+ t.cs_rd_off = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-cs_rd_off);
+ t.rd_cycle = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-rd_cycle);
+
+ /* Write */
+ t.adv_wr_off = gpmc_round_ns_to_ticks(
+ gpmc_nand_data-gpmc_t-adv_wr_off);
+ t.we_on = t.oe_on;
+ if (cpu_is_omap34xx()) {
+ t.wr_data_mux_bus = gpmc_round_ns_to_ticks(
+ gpmc_nand_data-gpmc_t-wr_data_mux_bus);
+ t.wr_access = gpmc_round_ns_to_ticks(
+ gpmc_nand_data-gpmc_t-wr_access);
+ }
+ t.we_off = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-we_off);
+ t.cs_wr_off = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-cs_wr_off);
+ t.wr_cycle = gpmc_round_ns_to_ticks(gpmc_nand_data-gpmc_t-wr_cycle);
+
+ /* Configure GPMC */
+ gpmc_cs_write_reg(gpmc_nand_data-cs, GPMC_CS_CONFIG1,
+ GPMC_CONFIG1_DEVICESIZE(gpmc_nand_data-devsize) |
+ GPMC_CONFIG1_DEVICETYPE_NAND);
+
+ err = gpmc_cs_set_timings(gpmc_nand_data-cs, t);
+ if (err)
+ return err;
+
+ return 0;
+}
+
+static int gpmc_nand_setup(void __iomem *nand_base)
+{
+ struct device *dev = gpmc_nand_device.dev;
+
+ /* Set timings in GPMC */
+ if (omap2_nand_gpmc_config(nand_base) 0) {
+ dev_err(dev, Unable to set gpmc timings\n);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+int __init gpmc_nand_init(struct omap_nand_platform_data *_nand_data)
+{
+ unsigned int val;
+ int err = 0;
+ struct device *dev = gpmc_nand_device.dev;
+
+ gpmc_nand_data = _nand_data;
+ gpmc_nand_data-nand_setup = gpmc_nand_setup;
+ gpmc_nand_device.dev.platform_data
[PATCH 2/3] OMAP: SDP: Introducing 'board-sdp-flash.c' for flash init
From 994785b066a9bd4fbaf7753cb6ab7317440afd36 Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
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
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/board-sdp-flash.c| 295 ++
arch/arm/mach-omap2/include/mach/board-sdp.h | 22 ++
arch/arm/plat-omap/include/plat/gpmc.h |2 +
3 files changed, 319 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 000..54ef19f
--- /dev/null
+++ b/arch/arm/mach-omap2/board-sdp-flash.c
@@ -0,0 +1,295 @@
+/*
+ * board-sdp-flash.c
+ * Modified from mach-omap2/board-3430sdp-flash.c
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Copyright (C) 2009 Texas Instruments
+ *
+ * Vimal Singh vimalsi...@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/mtd/physmap.h
+#include linux/io.h
+
+#include plat/gpmc.h
+#include plat/nand.h
+#include plat/onenand.h
+#include plat/tc.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 0x0800 /* debug board */
+
+#define PDC_NOR1
+#define PDC_NAND 2
+#define PDC_ONENAND3
+#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: */
+ {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 void omap_set_vpp(struct map_info *map, int enable)
+{
+ static int count;
+ u32 l;
+
+ if (cpu_class_is_omap1()) {
+ if (enable) {
+ if (count++ == 0) {
+ l = omap_readl(EMIFS_CONFIG);
+ l |= OMAP_EMIFS_CONFIG_WP;
+ omap_writel(l, EMIFS_CONFIG);
+ }
+ } else {
+ if (count (--count == 0)) {
+ l = omap_readl(EMIFS_CONFIG);
+ l = ~OMAP_EMIFS_CONFIG_WP;
+ omap_writel(l, EMIFS_CONFIG);
+ }
+ }
+ }
+}
+
+static struct physmap_flash_data sdp_nor_data = {
+ .width = 2,
+ .set_vpp= omap_set_vpp,
+};
+
+static struct resource sdp_nor_resource = {
+ .flags = IORESOURCE_MEM,
+};
+
+static struct platform_device sdp_nor_device = {
+ .name = physmap-flash,
+ .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
[PATCH 3/3] OMAP3: Add support for flash on 3430SDP board
From 4fbddd880c7a0da61fb66ae1d2c2553e3fbc82cb Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Tue, 12 Jan 2010 17:23:57 +0530
Subject: [PATCH] OMAP3: Add support for flash on 3430SDP board
This patch adds support for flashes on 3430SDP boards. All three
NAND, NOR and OneNAND are supported. I have tested it on
3430SDP (ES2 and ES3.1).
This patch can be treated as an example to how to utilize:
'gpmc-nand.c' and 'board-sdp-flash.c'.
Similar patches can be created for 2430sdp and 3630sdp or any other
similar board.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/Makefile|1 +
arch/arm/mach-omap2/board-3430sdp.c | 111 +++
2 files changed, 112 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 247438b..c74437c 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -84,6 +84,7 @@ obj-$(CONFIG_MACH_OMAP3EVM) += board-omap3evm.o \
obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o \
mmc-twl4030.o
obj-$(CONFIG_MACH_OMAP_3430SDP)+= board-3430sdp.o \
+ board-sdp-flash.o \
mmc-twl4030.o
obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o
obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index c90b0d0..2e010ec 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -41,6 +41,8 @@
#include plat/control.h
#include plat/gpmc-smc91x.h
+#include mach/board-sdp.h
+
#include mux.h
#include sdram-qimonda-hyb18m512160af-6.h
#include mmc-twl4030.h
@@ -650,6 +652,114 @@ static struct omap_board_mux board_mux[]
#define board_mux NULL
#endif
+static struct mtd_partition sdp_nor_partitions[] = {
+ /* bootloader (U-Boot, etc) in first sector */
+ {
+ .name = Bootloader-NOR,
+ .offset = 0,
+ .size = SZ_256K,
+ .mask_flags = MTD_WRITEABLE, /* force read-only */
+ },
+ /* bootloader params in the next sector */
+ {
+ .name = Params-NOR,
+ .offset = MTDPART_OFS_APPEND,
+ .size = SZ_256K,
+ .mask_flags = 0,
+ },
+ /* kernel */
+ {
+ .name = Kernel-NOR,
+ .offset = MTDPART_OFS_APPEND,
+ .size = SZ_2M,
+ .mask_flags = 0
+ },
+ /* file system */
+ {
+ .name = Filesystem-NOR,
+ .offset = MTDPART_OFS_APPEND,
+ .size = MTDPART_SIZ_FULL,
+ .mask_flags = 0
+ }
+};
+
+static struct mtd_partition sdp_onenand_partitions[] = {
+ {
+ .name = X-Loader-OneNAND,
+ .offset = 0,
+ .size = 4 * (64 * 2048),
+ .mask_flags = MTD_WRITEABLE /* force read-only */
+ },
+ {
+ .name = U-Boot-OneNAND,
+ .offset = MTDPART_OFS_APPEND,
+ .size = 2 * (64 * 2048),
+ .mask_flags = MTD_WRITEABLE /* force read-only */
+ },
+ {
+ .name = U-Boot Environment-OneNAND,
+ .offset = MTDPART_OFS_APPEND,
+ .size = 1 * (64 * 2048),
+ },
+ {
+ .name = Kernel-OneNAND,
+ .offset = MTDPART_OFS_APPEND,
+ .size = 16 * (64 * 2048),
+ },
+ {
+ .name = File System-OneNAND,
+ .offset = MTDPART_OFS_APPEND,
+ .size = MTDPART_SIZ_FULL,
+ },
+};
+
+static struct mtd_partition sdp_nand_partitions[] = {
+ /* All the partition sizes are listed in terms of NAND block size */
+ {
+ .name = X-Loader-NAND,
+ .offset = 0,
+ .size = 4 * (64 * 2048),
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = U-Boot-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x8 */
+ .size = 10 * (64 * 2048),
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = Boot Env-NAND,
+
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x1c */
+ .size = 6 * (64 * 2048),
+ },
+ {
+ .name = Kernel-NAND,
+ .offset
[PATCH 0/3] nand support on zoom boards
From 345704a79f15b0481b14d5d504b0bcdf55f2a9a6 Mon Sep 17 00:00:00 2001 From: Vimal Singh vimalsi...@ti.com Date: Tue, 12 Jan 2010 18:12:53 +0530 Subject: [PATCH] nand support on zoom boards I have verified it on zoom2/3 support on zoom boards. I still have not tried it on LDP (zoom1) board. So, I'll post patch for same later. Vimal Singh (3): OMAP: ZOOM: Introducing 'board-zoom-flash.c' OMAP3: Add support for NAND on ZOOM2 board OMAP3: Add support for NAND on ZOOM3 board arch/arm/mach-omap2/Makefile |2 + arch/arm/mach-omap2/board-zoom-flash.c| 85 + arch/arm/mach-omap2/board-zoom2.c | 49 ++ arch/arm/mach-omap2/board-zoom3.c | 49 ++ arch/arm/mach-omap2/include/mach/board-zoom.h | 11 +++ 5 files changed, 196 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/board-zoom-flash.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] OMAP: ZOOM: Introducing 'board-zoom-flash.c'
From c97a9126f713fa7577ea555a555dc9f22513c154 Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Tue, 12 Jan 2010 17:26:07 +0530
Subject: [PATCH] OMAP: ZOOM: Introducing 'board-zoom-flash.c'
This patch adds 'board-zoom-flash.c', which could be utilized
by boards similar to ZOOM2. (For ex: LDP, ZOOM2, ZOOM3).
This does initialization for NAND device based on the 'cs' number
and partition information passed from board file (ex: board-zoom2.c).
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/board-zoom-flash.c| 85 +
arch/arm/mach-omap2/include/mach/board-zoom.h | 11 +++
2 files changed, 96 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-zoom-flash.c
diff --git a/arch/arm/mach-omap2/board-zoom-flash.c
b/arch/arm/mach-omap2/board-zoom-flash.c
new file mode 100644
index 000..f2328a4
--- /dev/null
+++ b/arch/arm/mach-omap2/board-zoom-flash.c
@@ -0,0 +1,85 @@
+/*
+ * board-zoom-flash.c
+ *
+ * Copyright (C) 2009 Texas Instruments Inc.
+ * Vimal Singh vimalsi...@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/delay.h
+#include linux/platform_device.h
+#include linux/mtd/nand.h
+#include linux/types.h
+#include linux/io.h
+
+#include asm/mach/flash.h
+#include plat/board.h
+#include plat/gpmc.h
+#include plat/nand.h
+
+#include mach/board-zoom.h
+
+#if defined(CONFIG_MTD_NAND_OMAP2) || \
+ defined(CONFIG_MTD_NAND_OMAP2_MODULE)
+
+/* Note that all values in this struct are in nanoseconds */
+static struct gpmc_timings nand_timings = {
+
+ .sync_clk = 0,
+
+ .cs_on = 0,
+ .cs_rd_off = 36,
+ .cs_wr_off = 36,
+
+ .adv_on = 6,
+ .adv_rd_off = 24,
+ .adv_wr_off = 36,
+
+ .we_off = 30,
+ .oe_off = 48,
+
+ .access = 54,
+ .rd_cycle = 72,
+ .wr_cycle = 72,
+
+ .wr_access = 30,
+ .wr_data_mux_bus = 0,
+};
+
+/* NAND chip access: 16 bit */
+static struct omap_nand_platform_data zoom_nand_data = {
+ .nand_setup = NULL,
+ .gpmc_t = nand_timings,
+ .dma_channel= -1, /* disable DMA in OMAP NAND driver */
+ .dev_ready = NULL,
+ .devsize= 1,/* '0' for 8-bit, '1' for 16-bit device */
+};
+
+/**
+ * zoom_flash_init - Identify devices connected to GPMC and register.
+ *
+ * @return - void.
+ */
+void __init zoom_flash_init(struct flash_partitions zoom_nand_parts[], int cs)
+{
+ u32 gpmc_base_add = OMAP34XX_GPMC_VIRT;
+
+ zoom_nand_data.cs = cs;
+ zoom_nand_data.parts= zoom_nand_parts[0].parts;
+ zoom_nand_data.nr_parts = zoom_nand_parts[0].nr_parts;
+ zoom_nand_data.gpmc_baseaddr= (void *)(gpmc_base_add);
+ zoom_nand_data.gpmc_cs_baseaddr = (void *)(gpmc_base_add +
+ GPMC_CS0_BASE +
+ cs * GPMC_CS_SIZE);
+ gpmc_nand_init(zoom_nand_data);
+}
+#else
+void __init zoom_flash_init(struct flash_partitions zoom_nand_parts[], int cs)
+{
+}
+#endif /* CONFIG_MTD_NAND_OMAP2 || CONFIG_MTD_NAND_OMAP2_MODULE */
+
diff --git a/arch/arm/mach-omap2/include/mach/board-zoom.h
b/arch/arm/mach-omap2/include/mach/board-zoom.h
index c93b29e..f4469d3 100644
--- a/arch/arm/mach-omap2/include/mach/board-zoom.h
+++ b/arch/arm/mach-omap2/include/mach/board-zoom.h
@@ -1,5 +1,16 @@
/*
* Defines for zoom boards
*/
+#include linux/mtd/mtd.h
+#include linux/mtd/partitions.h
+
+struct flash_partitions {
+ struct mtd_partition *parts;
+ int nr_parts;
+};
+
+#define ZOOM_NAND_CS 0
+
+extern void __init zoom_flash_init(struct flash_partitions [], int);
extern int __init zoom_debugboard_init(void);
extern void __init zoom_peripherals_init(void);
--
1.5.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] OMAP3: Add support for NAND on ZOOM3 board
From 345704a79f15b0481b14d5d504b0bcdf55f2a9a6 Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Tue, 12 Jan 2010 17:56:44 +0530
Subject: [PATCH] OMAP3: Add support for NAND on ZOOM3 board
This patch adds NAND support to ZOOM3 board.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-zoom3.c | 49 +
2 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 434310e..f9b8473 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -97,6 +97,7 @@ obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom2.o \
mmc-twl4030.o \
board-zoom-debugboard.o
obj-$(CONFIG_MACH_OMAP_ZOOM3) += board-zoom3.o \
+ board-zoom-flash.o \
board-zoom-peripherals.o \
mmc-twl4030.o \
board-zoom-debugboard.o
diff --git a/arch/arm/mach-omap2/board-zoom3.c
b/arch/arm/mach-omap2/board-zoom3.c
index a9fe918..3b5e45a 100644
--- a/arch/arm/mach-omap2/board-zoom3.c
+++ b/arch/arm/mach-omap2/board-zoom3.c
@@ -33,6 +33,54 @@ static void __init omap_zoom_map_io(void)
static struct omap_board_config_kernel zoom_config[] __initdata = {
};
+static struct mtd_partition zoom_nand_partitions[] = {
+ /* All the partition sizes are listed in terms of NAND block size */
+ {
+ .name = X-Loader-NAND,
+ .offset = 0,
+ .size = 4 * (64 * 2048), /* 512KB, 0x8 */
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = U-Boot-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x8 */
+ .size = 10 * (64 * 2048), /* 1.25MB, 0x14 */
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = Boot Env-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x1c */
+ .size = 2 * (64 * 2048), /* 256KB, 0x4 */
+ },
+ {
+ .name = Kernel-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x020*/
+ .size = 240 * (64 * 2048),/* 30M, 0x1E0 */
+ },
+ {
+ .name = system,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x200 */
+ .size = 1280 * (64 * 2048), /* 160M, 0xA00 */
+ },
+ {
+ .name = userdata,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0xC00 */
+ .size = 256 * (64 * 2048),/* 32M, 0x200 */
+ },
+ {
+ .name = cache,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0xE00 */
+ .size = 256 * (64 * 2048),/* 32M, 0x200 */
+ },
+};
+
+static struct flash_partitions zoom_flash_partitions[] = {
+ {
+ .parts = zoom_nand_partitions,
+ .nr_parts = ARRAY_SIZE(zoom_nand_partitions),
+ },
+};
+
static void __init omap_zoom_init_irq(void)
{
omap_board_config = zoom_config;
@@ -55,6 +103,7 @@ static void __init omap_zoom_init(void)
{
omap3_mux_init(board_mux, OMAP_PACKAGE_CBP);
zoom_peripherals_init();
+ zoom_flash_init(zoom_flash_partitions, ZOOM_NAND_CS);
zoom_debugboard_init();
}
--
1.5.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3]: Introducing 'gpmc-nand.c' for GPMC specific NAND init
Re-summiting this patch. After re-basing on LO master.
-vimal
From a7ea8851fe96690c9322393eb35a344853992166 Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Mon, 11 Jan 2010 16:01:29 +0530
Subject: [PATCH] Introducing 'gpmc-nand.c' for GPMC specific NAND init
Introducing 'gpmc-nand.c' for GPMC specific NAND init.
For example: GPMC timing parameters and all.
This patch also migrates gpmc related calls from 'nand/omap2.c'
to 'gpmc-nand.c'.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/Makefile |3 +
arch/arm/mach-omap2/gpmc-nand.c| 136
arch/arm/plat-omap/include/plat/nand.h |6 ++
drivers/mtd/nand/omap2.c | 26 +--
4 files changed, 148 insertions(+), 23 deletions(-)
create mode 100644 arch/arm/mach-omap2/gpmc-nand.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index b32678b..247438b 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -119,5 +119,8 @@ obj-y += usb-ehci.o
onenand-$(CONFIG_MTD_ONENAND_OMAP2):= gpmc-onenand.o
obj-y += $(onenand-m) $(onenand-y)
+nand-$(CONFIG_MTD_NAND_OMAP2) := gpmc-nand.o
+obj-y += $(nand-m) $(nand-y)
+
smc91x-$(CONFIG_SMC91X):= gpmc-smc91x.o
obj-y += $(smc91x-m) $(smc91x-y)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
new file mode 100644
index 000..822ba82
--- /dev/null
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -0,0 +1,136 @@
+/*
+ * gpmc-nand.c
+ *
+ * Copyright (C) 2009 Texas Instruments
+ * Vimal Singh vimalsi...@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/nand.h
+#include plat/board.h
+#include plat/gpmc.h
+
+#define WR_RD_PIN_MONITORING 0x0060
+
+static struct omap_nand_platform_data *gpmc_nand_data;
+
+static struct resource gpmc_nand_resource = {
+ .flags = IORESOURCE_MEM,
+};
+
+static struct platform_device gpmc_nand_device = {
+ .name = omap2-nand,
+ .id = 0,
+ .num_resources = 1,
+ .resource = gpmc_nand_resource,
+};
+
+static int omap2_nand_gpmc_config(int cs, void __iomem *nand_base)
+{
+ struct gpmc_timings t;
+ int err;
+
+ const int cs_rd_off = 36;
+ const int cs_wr_off = 36;
+ const int adv_on = 6;
+ const int adv_rd_off = 24;
+ const int adv_wr_off = 36;
+ const int oe_off = 48;
+ const int we_off = 30;
+ const int rd_cycle = 72;
+ const int wr_cycle = 72;
+ const int access = 54;
+ const int wr_data_mux_bus = 0;
+ const int wr_access = 30;
+
+ memset(t, 0, sizeof(t));
+ t.sync_clk = 0;
+ t.cs_on = 0;
+ t.adv_on = gpmc_round_ns_to_ticks(adv_on);
+
+ /* Read */
+ t.adv_rd_off = gpmc_round_ns_to_ticks(adv_rd_off);
+ t.oe_on = t.adv_on;
+ t.access = gpmc_round_ns_to_ticks(access);
+ t.oe_off = gpmc_round_ns_to_ticks(oe_off);
+ t.cs_rd_off = gpmc_round_ns_to_ticks(cs_rd_off);
+ t.rd_cycle = gpmc_round_ns_to_ticks(rd_cycle);
+
+ /* Write */
+ t.adv_wr_off = gpmc_round_ns_to_ticks(adv_wr_off);
+ t.we_on = t.oe_on;
+ if (cpu_is_omap34xx()) {
+ t.wr_data_mux_bus = gpmc_round_ns_to_ticks(wr_data_mux_bus);
+ t.wr_access = gpmc_round_ns_to_ticks(wr_access);
+ }
+ t.we_off = gpmc_round_ns_to_ticks(we_off);
+ t.cs_wr_off = gpmc_round_ns_to_ticks(cs_wr_off);
+ t.wr_cycle = gpmc_round_ns_to_ticks(wr_cycle);
+
+ /* Configure GPMC */
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1,
+ GPMC_CONFIG1_DEVICESIZE(gpmc_nand_data-devsize) |
+ GPMC_CONFIG1_DEVICETYPE_NAND);
+
+ err = gpmc_cs_set_timings(cs, t);
+ if (err)
+ return err;
+
+ return 0;
+}
+
+static int gpmc_nand_setup(void __iomem *nand_base)
+{
+ struct device *dev = gpmc_nand_device.dev;
+
+ /* Set timings in GPMC */
+ if (omap2_nand_gpmc_config(gpmc_nand_data-cs, nand_base) 0) {
+ dev_err(dev, Unable to set gpmc timings\n);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+int __init gpmc_nand_init(struct omap_nand_platform_data *_nand_data)
+{
+ unsigned int val;
+ int err = 0;
+ struct device *dev = gpmc_nand_device.dev;
+
+ gpmc_nand_data = _nand_data;
+ gpmc_nand_data-nand_setup = gpmc_nand_setup;
+ gpmc_nand_device.dev.platform_data = gpmc_nand_data;
+
+ err
Re: [PATCH v3]: Introducing 'gpmc-nand.c' for GPMC specific NAND init
On Mon, Jan 11, 2010 at 4:10 PM, Vimal Singh vimal.neww...@gmail.com wrote:
Re-summiting this patch. After re-basing on LO master.
-vimal
From a7ea8851fe96690c9322393eb35a344853992166 Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Mon, 11 Jan 2010 16:01:29 +0530
Subject: [PATCH] Introducing 'gpmc-nand.c' for GPMC specific NAND init
Introducing 'gpmc-nand.c' for GPMC specific NAND init.
For example: GPMC timing parameters and all.
This patch also migrates gpmc related calls from 'nand/omap2.c'
to 'gpmc-nand.c'.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/Makefile | 3 +
arch/arm/mach-omap2/gpmc-nand.c | 136
arch/arm/plat-omap/include/plat/nand.h | 6 ++
drivers/mtd/nand/omap2.c | 26 +--
4 files changed, 148 insertions(+), 23 deletions(-)
create mode 100644 arch/arm/mach-omap2/gpmc-nand.c
Patch got line wrapped. Corrected it below.
From a7ea8851fe96690c9322393eb35a344853992166 Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Mon, 11 Jan 2010 16:01:29 +0530
Subject: [PATCH] Introducing 'gpmc-nand.c' for GPMC specific NAND init
Introducing 'gpmc-nand.c' for GPMC specific NAND init.
For example: GPMC timing parameters and all.
This patch also migrates gpmc related calls from 'nand/omap2.c'
to 'gpmc-nand.c'.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/Makefile |3 +
arch/arm/mach-omap2/gpmc-nand.c| 136
arch/arm/plat-omap/include/plat/nand.h |6 ++
drivers/mtd/nand/omap2.c | 26 +--
4 files changed, 148 insertions(+), 23 deletions(-)
create mode 100644 arch/arm/mach-omap2/gpmc-nand.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index b32678b..247438b 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -119,5 +119,8 @@ obj-y += usb-ehci.o
onenand-$(CONFIG_MTD_ONENAND_OMAP2):= gpmc-onenand.o
obj-y += $(onenand-m) $(onenand-y)
+nand-$(CONFIG_MTD_NAND_OMAP2) := gpmc-nand.o
+obj-y += $(nand-m) $(nand-y)
+
smc91x-$(CONFIG_SMC91X):= gpmc-smc91x.o
obj-y += $(smc91x-m) $(smc91x-y)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
new file mode 100644
index 000..822ba82
--- /dev/null
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -0,0 +1,136 @@
+/*
+ * gpmc-nand.c
+ *
+ * Copyright (C) 2009 Texas Instruments
+ * Vimal Singh vimalsi...@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/nand.h
+#include plat/board.h
+#include plat/gpmc.h
+
+#define WR_RD_PIN_MONITORING 0x0060
+
+static struct omap_nand_platform_data *gpmc_nand_data;
+
+static struct resource gpmc_nand_resource = {
+ .flags = IORESOURCE_MEM,
+};
+
+static struct platform_device gpmc_nand_device = {
+ .name = omap2-nand,
+ .id = 0,
+ .num_resources = 1,
+ .resource = gpmc_nand_resource,
+};
+
+static int omap2_nand_gpmc_config(int cs, void __iomem *nand_base)
+{
+ struct gpmc_timings t;
+ int err;
+
+ const int cs_rd_off = 36;
+ const int cs_wr_off = 36;
+ const int adv_on = 6;
+ const int adv_rd_off = 24;
+ const int adv_wr_off = 36;
+ const int oe_off = 48;
+ const int we_off = 30;
+ const int rd_cycle = 72;
+ const int wr_cycle = 72;
+ const int access = 54;
+ const int wr_data_mux_bus = 0;
+ const int wr_access = 30;
+
+ memset(t, 0, sizeof(t));
+ t.sync_clk = 0;
+ t.cs_on = 0;
+ t.adv_on = gpmc_round_ns_to_ticks(adv_on);
+
+ /* Read */
+ t.adv_rd_off = gpmc_round_ns_to_ticks(adv_rd_off);
+ t.oe_on = t.adv_on;
+ t.access = gpmc_round_ns_to_ticks(access);
+ t.oe_off = gpmc_round_ns_to_ticks(oe_off);
+ t.cs_rd_off = gpmc_round_ns_to_ticks(cs_rd_off);
+ t.rd_cycle = gpmc_round_ns_to_ticks(rd_cycle);
+
+ /* Write */
+ t.adv_wr_off = gpmc_round_ns_to_ticks(adv_wr_off);
+ t.we_on = t.oe_on;
+ if (cpu_is_omap34xx()) {
+ t.wr_data_mux_bus = gpmc_round_ns_to_ticks(wr_data_mux_bus);
+ t.wr_access = gpmc_round_ns_to_ticks(wr_access);
+ }
+ t.we_off = gpmc_round_ns_to_ticks(we_off);
+ t.cs_wr_off = gpmc_round_ns_to_ticks(cs_wr_off);
+ t.wr_cycle = gpmc_round_ns_to_ticks(wr_cycle);
+
+ /* Configure GPMC */
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1
Re: Issue in oamp nand driver with 32-bit reads in prefetch mode
On Sun, Jan 10, 2010 at 2:16 PM, Artem Bityutskiy dedeki...@gmail.com wrote:
On Thu, 2009-12-31 at 17:50 +0530, Vimal Singh wrote:
There is a bug in nand prefetch read routine, which comes into effect
only if nand device is a 16-bit device (as we have in zoom boards).
This bug is effective only with below combination of conditions:
1. nand deivce, in use, is a 16 bit device
2. nand driver supports 'subpage' read
3. SW ECC is in use
This was not seen old kernel (ex: .23), because when, in early days,
we tested this (nand prefetch read in LDP boards) there was no
'subpage read' support.
Later when we had subpage read in (.27) kernel, we had hw ecc enabled
always in our internal tree. So, we missed this bug.
Here is a patch to fix this issue:
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 1bb799f..75004fe 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -295,11 +295,14 @@ static void omap_read_buf_pref(struct
u32 *p = (u32 *)buf;
/* take care of subpage reads */
- for (; len % 4 != 0; ) {
- *buf++ = __raw_readb(info-nand.IO_ADDR_R);
- len--;
+ if (len % 4) {
+ if (info-nand.options NAND_BUSWIDTH_16)
+ omap_read_buf16(mtd, buf, len % 4);
+ else
+ omap_read_buf8(mtd, buf, len % 4);
+ p = (u32 *) (buf + len % 4);
+ len -= len % 4;
}
- p = (u32 *) buf;
/* configure and start prefetch transfer */
ret = gpmc_prefetch_enable(info-gpmc_cs, 0x0, len, 0x0);
Pushed this patch to my l2-mtd-2.6.git/dunno.
I have posted this patch formally in patch series:
[PATCH 0/3][NAND][OMAP]: fixing omap nand driver issues
Corresponding patch is:
[PATCH 3/3][NAND][OMAP] : Fixing issue in oamp nand driver in prefetch mode read
Can you please give a look for this patch series?
--
Regards,
Vimal Singh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3][NAND][OMAP]: Fixing compilation warning for 'nand/omap2.c'
On Fri, Jan 8, 2010 at 8:31 PM, Premi, Sanjeev pr...@ti.com wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Vimal Singh Sent: Wednesday, January 06, 2010 7:30 PM To: Linux MTD Cc: linux-omap@vger.kernel.org Subject: [PATCH 1/3][NAND][OMAP]: Fixing compilation warning for 'nand/omap2.c' From 3e856346f93afaf3f519dffe7987e4bbf56a136d Mon Sep 17 00:00:00 2001 From: Vimal Singh vimalsi...@ti.com Date: Tue, 5 Jan 2010 12:49:24 +0530 Subject: [PATCH] Fixing compilation warning for 'nand/omap2.c' Fixing below warning in compilation: drivers/mtd/nand/omap2.c: In function 'omap_write_buf_dma_pref': drivers/mtd/nand/omap2.c:508: warning: passing argument 2 of 'omap_nand_dma_transfer' discards qualifiers from pointer target type Signed-off-by: Vimal Singh vimalsi...@ti.com --- drivers/mtd/nand/omap2.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c index 1bb799f..4eea97c 100644 --- a/drivers/mtd/nand/omap2.c +++ b/drivers/mtd/nand/omap2.c @@ -505,7 +505,7 @@ static void omap_write_buf_dma_pref(struct mtd_info *mtd, omap_write_buf_pref(mtd, buf, len); else /* start transfer in DMA mode */ - omap_nand_dma_transfer(mtd, buf, len, 0x1); + omap_nand_dma_transfer(mtd, (u_char *) buf, len, 0x1); } Vimal, I had posted the fix in DEC. Did you miss it? http://lists.infradead.org/pipermail/linux-mtd/2009-December/028373.html I did. But I wanted to have all of these together. In fact I had posted a patch for this sometime back, which was handling this quite differently. http://patchwork.kernel.org/patch/57235/ -- Regards, Vimal Singh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3][NAND][OMAP]: fixing omap nand driver issues
From 3700088e8da8c890d9e4c6eb626e18287d149b97 Mon Sep 17 00:00:00 2001 From: Vimal Singh vimalsi...@ti.com Date: Tue, 5 Jan 2010 16:43:08 +0530 Subject: [PATCH] fixing omap nand driver issues fixing omap nand driver issues. Vimal Singh (3): Fixing compilation warning for 'nand/omap2.c' NAND: OMAP: correct 'info' pointer in 'omap_nand_remove' NAND: OMAP: Fixing issue in oamp nand driver in prefetch mode read drivers/mtd/nand/omap2.c | 16 ++-- 1 files changed, 10 insertions(+), 6 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3][NAND][OMAP]: Fixing compilation warning for 'nand/omap2.c'
From 3e856346f93afaf3f519dffe7987e4bbf56a136d Mon Sep 17 00:00:00 2001 From: Vimal Singh vimalsi...@ti.com Date: Tue, 5 Jan 2010 12:49:24 +0530 Subject: [PATCH] Fixing compilation warning for 'nand/omap2.c' Fixing below warning in compilation: drivers/mtd/nand/omap2.c: In function 'omap_write_buf_dma_pref': drivers/mtd/nand/omap2.c:508: warning: passing argument 2 of 'omap_nand_dma_transfer' discards qualifiers from pointer target type Signed-off-by: Vimal Singh vimalsi...@ti.com --- drivers/mtd/nand/omap2.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c index 1bb799f..4eea97c 100644 --- a/drivers/mtd/nand/omap2.c +++ b/drivers/mtd/nand/omap2.c @@ -505,7 +505,7 @@ static void omap_write_buf_dma_pref(struct mtd_info *mtd, omap_write_buf_pref(mtd, buf, len); else /* start transfer in DMA mode */ - omap_nand_dma_transfer(mtd, buf, len, 0x1); + omap_nand_dma_transfer(mtd, (u_char *) buf, len, 0x1); } /** -- 1.5.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3][NAND][OMAP]: correct 'info' pointer in 'omap_nand_remove'
From bf5256c8c29100c3a55e29a8a5d6718ba5817519 Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Tue, 5 Jan 2010 16:01:08 +0530
Subject: [PATCH] NAND: OMAP: correct 'info' pointer in 'omap_nand_remove'
Removing OMAP NAND driver, when loaded as a module, gives error and
does not get success. This fixes this and makes driver loadable and
removable run time.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
drivers/mtd/nand/omap2.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 4eea97c..16120e2 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1054,7 +1054,8 @@ out_free_info:
static int omap_nand_remove(struct platform_device *pdev)
{
struct mtd_info *mtd = platform_get_drvdata(pdev);
- struct omap_nand_info *info = mtd-priv;
+ struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
+ mtd);
platform_set_drvdata(pdev, NULL);
if (use_dma)
--
1.5.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3][NAND][OMAP]: Fixing issue in oamp nand driver in prefetch mode read
From 3700088e8da8c890d9e4c6eb626e18287d149b97 Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Tue, 5 Jan 2010 16:37:03 +0530
Subject: [PATCH] NAND: OMAP: Fixing issue in oamp nand driver in
prefetch mode read
There is a bug in nand prefetch read routine, which comes into effect
only if nand device is a 16-bit device (as we have in zoom boards).
This bug is effective only with below combination of conditions:
1. nand deivce, in use, is a 16 bit device
2. nand driver supports 'subpage' read
3. SW ECC is in use
This was not seen old kernel (ex: .23), because when, in early days,
we tested this (nand prefetch read in LDP boards) there was no
'subpage read' support.
Later when we had subpage read in (.27) kernel, we had hw ecc enabled
always in our internal tree. So, we missed this bug.
This patch fixes the issue.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
drivers/mtd/nand/omap2.c | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 16120e2..7df303a 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -295,11 +295,14 @@ static void omap_read_buf_pref(struct mtd_info
*mtd, u_char *buf, int len)
u32 *p = (u32 *)buf;
/* take care of subpage reads */
- for (; len % 4 != 0; ) {
- *buf++ = __raw_readb(info-nand.IO_ADDR_R);
- len--;
+ if (len % 4) {
+ if (info-nand.options NAND_BUSWIDTH_16)
+ omap_read_buf16(mtd, buf, len % 4);
+ else
+ omap_read_buf8(mtd, buf, len % 4);
+ p = (u32 *) (buf + len % 4);
+ len -= len % 4;
}
- p = (u32 *) buf;
/* configure and start prefetch transfer */
ret = gpmc_prefetch_enable(info-gpmc_cs, 0x0, len, 0x0);
--
1.5.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2]: Introducing 'gpmc-nand.c' for GPMC specific NAND init
On Wed, Jan 6, 2010 at 8:04 PM, Artem Bityutskiy dedeki...@gmail.com wrote: On Mon, 2009-12-14 at 15:17 +0530, Vimal Singh wrote: From 6170aa1c63c49a3f09e76258f400230b742fdd6f Mon Sep 17 00:00:00 2001 From: Vimal Singh vimalsi...@ti.com Date: Wed, 25 Nov 2009 18:23:15 +0530 Subject: [PATCH] Introducing 'gpmc-nand.c' for GPMC specific NAND init Introducing 'gpmc-nand.c' for GPMC specific NAND init. For example: GPMC timing parameters and all. This patch also migrates gpmc related calls from 'nand/omap2.c' to 'gpmc-nand.c'. Signed-off-by: Vimal Singh vimalsi...@ti.com --- arch/arm/mach-omap2/Makefile | 3 + arch/arm/mach-omap2/gpmc-nand.c | 137 arch/arm/plat-omap/include/plat/nand.h | 6 ++ drivers/mtd/nand/omap2.c | 26 +-- 4 files changed, 149 insertions(+), 23 deletions(-) create mode 100644 arch/arm/mach-omap2/gpmc-nand.c I assume this is material for Tony and the omap tree. Yes, it is. -- Regards, Vimal Singh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3][NAND][OMAP]: Fixing issue in oamp nand driver in prefetch mode read
On Wed, Jan 6, 2010 at 7:36 PM, Vimal Singh vimal.neww...@gmail.com wrote:
From 3700088e8da8c890d9e4c6eb626e18287d149b97 Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Tue, 5 Jan 2010 16:37:03 +0530
Subject: [PATCH] NAND: OMAP: Fixing issue in oamp nand driver in
prefetch mode read
There is a bug in nand prefetch read routine, which comes into effect
only if nand device is a 16-bit device (as we have in zoom boards).
This bug is effective only with below combination of conditions:
1. nand deivce, in use, is a 16 bit device
2. nand driver supports 'subpage' read
3. SW ECC is in use
This was not seen old kernel (ex: .23), because when, in early days,
we tested this (nand prefetch read in LDP boards) there was no
'subpage read' support.
Later when we had subpage read in (.27) kernel, we had hw ecc enabled
always in our internal tree. So, we missed this bug.
This patch fixes the issue.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
drivers/mtd/nand/omap2.c | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 16120e2..7df303a 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -295,11 +295,14 @@ static void omap_read_buf_pref(struct mtd_info
*mtd, u_char *buf, int len)
u32 *p = (u32 *)buf;
/* take care of subpage reads */
- for (; len % 4 != 0; ) {
- *buf++ = __raw_readb(info-nand.IO_ADDR_R);
- len--;
+ if (len % 4) {
+ if (info-nand.options NAND_BUSWIDTH_16)
+ omap_read_buf16(mtd, buf, len % 4);
+ else
+ omap_read_buf8(mtd, buf, len % 4);
+ p = (u32 *) (buf + len % 4);
+ len -= len % 4;
}
- p = (u32 *) buf;
/* configure and start prefetch transfer */
ret = gpmc_prefetch_enable(info-gpmc_cs, 0x0, len, 0x0);
--
1.5.5
Above patch was line wrapped. Here is the correct one:
From 3700088e8da8c890d9e4c6eb626e18287d149b97 Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Tue, 5 Jan 2010 16:37:03 +0530
Subject: [PATCH] NAND: OMAP: Fixing issue in oamp nand driver in
prefetch mode read
There is a bug in nand prefetch read routine, which comes into effect
only if nand device is a 16-bit device (as we have in zoom boards).
This bug is effective only with below combination of conditions:
1. nand deivce, in use, is a 16 bit device
2. nand driver supports 'subpage' read
3. SW ECC is in use
This was not seen old kernel (ex: .23), because when, in early days,
we tested this (nand prefetch read in LDP boards) there was no
'subpage read' support.
Later when we had subpage read in (.27) kernel, we had hw ecc enabled
always in our internal tree. So, we missed this bug.
This patch fixes the issue.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
drivers/mtd/nand/omap2.c | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 16120e2..7df303a 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -295,11 +295,14 @@ static void omap_read_buf_pref(struct
u32 *p = (u32 *)buf;
/* take care of subpage reads */
- for (; len % 4 != 0; ) {
- *buf++ = __raw_readb(info-nand.IO_ADDR_R);
- len--;
+ if (len % 4) {
+ if (info-nand.options NAND_BUSWIDTH_16)
+ omap_read_buf16(mtd, buf, len % 4);
+ else
+ omap_read_buf8(mtd, buf, len % 4);
+ p = (u32 *) (buf + len % 4);
+ len -= len % 4;
}
- p = (u32 *) buf;
/* configure and start prefetch transfer */
ret = gpmc_prefetch_enable(info-gpmc_cs, 0x0, len, 0x0);
--
1.5.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2]: OMAP: SDP: Introducing 'board-sdp-flash.c' for flash init
Tony,
On Tue, Dec 22, 2009 at 2:21 PM, Vimal Singh vimal.neww...@gmail.com wrote:
On Tue, Dec 15, 2009 at 1:01 AM, Tony Lindgren t...@atomide.com wrote:
* Vimal Singh vimal.neww...@gmail.com [091214 01:58]:
On Tue, Dec 8, 2009 at 12:06 AM, Tony Lindgren t...@atomide.com wrote:
* Vimal Singh vimal.neww...@gmail.com [091206 22:39]:
On Sat, Dec 5, 2009 at 3:47 AM, Tony Lindgren t...@atomide.com wrote:
Hi,
* Vimal Singh vimal.neww...@gmail.com [091203 06:09]:
From 13d52884956a26f93826c443e2b8bd78615f74d6 Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@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 vimalsi...@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 000..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
Re: Issue in oamp nand driver with 32-bit reads in prefetch mode
On Wed, Dec 30, 2009 at 3:17 AM, Steve Sakoman sako...@gmail.com wrote:
On Tue, Dec 29, 2009 at 12:38 PM, Steve Sakoman sako...@gmail.com wrote:
I can confirm that this issue exists on Overo too. Sadly, switching
to 16 bit reads does not fix the issue for me. I'll start digging to
see if I can find what's broken.
I can also confirm that there are days when I am not even capable of
applying a patch properly :-(
Switching to 16 bit read accesses does indeed fix the ECC issue on Overo too.
Which still leaves us needing to find the root cause of the breakage . . .
There is a bug in nand prefetch read routine, which comes into effect
only if nand device is a 16-bit device (as we have in zoom boards).
This bug is effective only with below combination of conditions:
1. nand deivce, in use, is a 16 bit device
2. nand driver supports 'subpage' read
3. SW ECC is in use
This was not seen old kernel (ex: .23), because when, in early days,
we tested this (nand prefetch read in LDP boards) there was no
'subpage read' support.
Later when we had subpage read in (.27) kernel, we had hw ecc enabled
always in our internal tree. So, we missed this bug.
Here is a patch to fix this issue:
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 1bb799f..75004fe 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -295,11 +295,14 @@ static void omap_read_buf_pref(struct
u32 *p = (u32 *)buf;
/* take care of subpage reads */
- for (; len % 4 != 0; ) {
- *buf++ = __raw_readb(info-nand.IO_ADDR_R);
- len--;
+ if (len % 4) {
+ if (info-nand.options NAND_BUSWIDTH_16)
+ omap_read_buf16(mtd, buf, len % 4);
+ else
+ omap_read_buf8(mtd, buf, len % 4);
+ p = (u32 *) (buf + len % 4);
+ len -= len % 4;
}
- p = (u32 *) buf;
/* configure and start prefetch transfer */
ret = gpmc_prefetch_enable(info-gpmc_cs, 0x0, len, 0x0);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Issue in oamp nand driver with 32-bit reads in prefetch mode
In omap nand driver we used to do 32-bit reads (in function
omap_read_buf_pref, using 'ioread32_rep' i.e.: __raw_readsl), and it
was working fine till some time back. But now, somehow, this has got
some problem. Reads are not being done successfully, and driver gives
lots for error reprot like below:
td-read(0x604 bytes from 0x1fc) returned ECC error
uncorrectable error :
uncorrectable error :
uncorrectable error :
uncorrectable error :
uncorrectable error :
uncorrectable error :
mtd-read(0x520 bytes from 0x2e0) returned ECC error
While if we change 32-bit reads to 16-bit reads (using 'ioread16_rep'
i.e.: __raw_readwl) makes it working fine. (A patch to do this is
listed below at the bottom of this mail.)
I have not seen any change in routine '__raw_readsl'.
So, could someone help me find out the root cause the issue?
Thanks for any input.
--
Regards,
Vimal Singh
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index aaef170..dc493f5 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -288,14 +288,14 @@ static void omap_read_buf_pref(struct mtd_info
struct omap_nand_info, mtd);
uint32_t pfpw_status = 0, r_count = 0;
int ret = 0;
- u32 *p = (u32 *)buf;
+ u16 *p = (u16 *)buf;
/* take care of subpage reads */
- for (; len % 4 != 0; ) {
+ for (; len % 2 != 0; ) {
*buf++ = __raw_readb(info-nand.IO_ADDR_R);
len--;
}
- p = (u32 *) buf;
+ p = (u16 *) buf;
/* configure and start prefetch transfer */
ret = gpmc_prefetch_enable(info-gpmc_cs, 0x0, len, 0x0);
@@ -308,10 +308,10 @@ static void omap_read_buf_pref(struct mtd_info
*mtd, u_char *buf, int len)
} else {
do {
pfpw_status = gpmc_prefetch_status();
- r_count = ((pfpw_status 24) 0x7F) 2;
- ioread32_rep(info-nand_pref_fifo_add, p, r_count);
+ r_count = ((pfpw_status 24) 0x7F) 1;
+ ioread16_rep(info-nand_pref_fifo_add, p, r_count);
p += r_count;
- len -= r_count 2;
+ len -= r_count 1;
} while (len);
/* disable and stop the PFPW engine */
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2]: OMAP: SDP: Introducing 'board-sdp-flash.c' for flash init
On Tue, Dec 15, 2009 at 1:01 AM, Tony Lindgren t...@atomide.com wrote:
* Vimal Singh vimal.neww...@gmail.com [091214 01:58]:
On Tue, Dec 8, 2009 at 12:06 AM, Tony Lindgren t...@atomide.com wrote:
* Vimal Singh vimal.neww...@gmail.com [091206 22:39]:
On Sat, Dec 5, 2009 at 3:47 AM, Tony Lindgren t...@atomide.com wrote:
Hi,
* Vimal Singh vimal.neww...@gmail.com [091203 06:09]:
From 13d52884956a26f93826c443e2b8bd78615f74d6 Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@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 vimalsi...@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 000..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
[PATCH] OMAP: ZOOM2: Correcting key mapping for few keys
From ab3239189c25a19d7764042cc3f05cce8a91f291 Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Fri, 18 Dec 2009 12:09:10 +0530
Subject: [PATCH] OMAP: ZOOM2: Correcting key mapping for few keys
Keys: 'right arrow', 'up arrow' and 'select' were mapped
wrongly. This patch corrects them.
This patch also adds one missing key present in the board,
currently I added it as 'unknown' key, as I am not able to
find proper description for this key.
One key entry (r: 7, c: 5) is present in the keymap, which
is really not present in the board, removing it.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/board-zoom-peripherals.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index 8dd277c..1e3dfb6 100755
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -63,21 +63,21 @@ static int board_keymap[] = {
KEY(5, 1, KEY_H),
KEY(5, 2, KEY_J),
KEY(5, 3, KEY_F3),
+ KEY(5, 4, KEY_UNKNOWN),
KEY(5, 5, KEY_VOLUMEDOWN),
KEY(5, 6, KEY_M),
- KEY(5, 7, KEY_ENTER),
+ KEY(5, 7, KEY_RIGHT),
KEY(6, 0, KEY_Q),
KEY(6, 1, KEY_A),
KEY(6, 2, KEY_N),
KEY(6, 3, KEY_BACKSPACE),
KEY(6, 6, KEY_P),
- KEY(6, 7, KEY_SELECT),
+ KEY(6, 7, KEY_UP),
KEY(7, 0, KEY_PROG1), /*MACRO 1 User defined */
KEY(7, 1, KEY_PROG2), /*MACRO 2 User defined */
KEY(7, 2, KEY_PROG3), /*MACRO 3 User defined */
KEY(7, 3, KEY_PROG4), /*MACRO 4 User defined */
- KEY(7, 5, KEY_RIGHT),
- KEY(7, 6, KEY_UP),
+ KEY(7, 6, KEY_SELECT),
KEY(7, 7, KEY_DOWN)
};
--
1.5.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP: NAND: Adding config option to enable/disable HW ECC mode
OMAP NAND driver got HW ECC implemented. From d5e28c9fdbc6b0a95c1259fac7add207f9c294d7 Mon Sep 17 00:00:00 2001 From: Vimal Singh vimalsi...@ti.com Date: Tue, 15 Dec 2009 21:10:54 +0530 Subject: [PATCH] OMAP: NAND: Adding config option to enable/disable HW ECC mode This patch adds config option to select/deselect HW ECC feature on OMAP NAND driver. This is a feature provided by OMAP GPMC for NAND devices. Signed-off-by: Vimal Singh vimalsi...@ti.com --- drivers/mtd/nand/Kconfig | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index 34598e9..6c4b27c 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -97,6 +97,16 @@ config MTD_NAND_OMAP_PREFETCH_DMA or in DMA interrupt mode. Say y for DMA mode or MPU mode will be used +config MTD_NAND_OMAP_HWECC + bool The Hardware ECC support + depends on MTD_NAND MTD_NAND_OMAP2 + default n + help +The ECC compuatation for the data to be written/read can be either by +software or omap has Hw ecc engine which calculates it. +MTD_NAND_OMAP_HWECC = y which enables the hw ecc +MTD_NAND_OMAP_HWECC = n enables software ecc + config MTD_NAND_TS7250 tristate NAND Flash device on TS-7250 board depends on MACH_TS72XX -- 1.5.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: NAND: Adding config option to enable/disable HW ECC mode
On Tue, Dec 15, 2009 at 11:05 PM, Tony Lindgren t...@atomide.com wrote: * Vimal Singh vimal.neww...@gmail.com [091215 07:45]: OMAP NAND driver got HW ECC implemented. From d5e28c9fdbc6b0a95c1259fac7add207f9c294d7 Mon Sep 17 00:00:00 2001 From: Vimal Singh vimalsi...@ti.com Date: Tue, 15 Dec 2009 21:10:54 +0530 Subject: [PATCH] OMAP: NAND: Adding config option to enable/disable HW ECC mode This patch adds config option to select/deselect HW ECC feature on OMAP NAND driver. This is a feature provided by OMAP GPMC for NAND devices. Signed-off-by: Vimal Singh vimalsi...@ti.com --- drivers/mtd/nand/Kconfig | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index 34598e9..6c4b27c 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -97,6 +97,16 @@ config MTD_NAND_OMAP_PREFETCH_DMA or in DMA interrupt mode. Say y for DMA mode or MPU mode will be used +config MTD_NAND_OMAP_HWECC + bool The Hardware ECC support + depends on MTD_NAND MTD_NAND_OMAP2 + default n + help + The ECC compuatation for the data to be written/read can be either by + software or omap has Hw ecc engine which calculates it. + MTD_NAND_OMAP_HWECC = y which enables the hw ecc + MTD_NAND_OMAP_HWECC = n enables software ecc + config MTD_NAND_TS7250 tristate NAND Flash device on TS-7250 board depends on MACH_TS72XX This sounds like it should be an option passed from the board-*.c files as platform_data rather than a Kconfig option. ACK. I'll do it once flash support patches get merged. -- Regards, Vimal Singh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2]: Introducing 'gpmc-nand.c' for GPMC specific NAND init
From 6170aa1c63c49a3f09e76258f400230b742fdd6f Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Wed, 25 Nov 2009 18:23:15 +0530
Subject: [PATCH] Introducing 'gpmc-nand.c' for GPMC specific NAND init
Introducing 'gpmc-nand.c' for GPMC specific NAND init.
For example: GPMC timing parameters and all.
This patch also migrates gpmc related calls from 'nand/omap2.c'
to 'gpmc-nand.c'.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/Makefile |3 +
arch/arm/mach-omap2/gpmc-nand.c| 137
arch/arm/plat-omap/include/plat/nand.h |6 ++
drivers/mtd/nand/omap2.c | 26 +--
4 files changed, 149 insertions(+), 23 deletions(-)
create mode 100644 arch/arm/mach-omap2/gpmc-nand.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 59b0ccc..0dfe27a 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -103,5 +103,8 @@ obj-y += usb-ehci.o
onenand-$(CONFIG_MTD_ONENAND_OMAP2):= gpmc-onenand.o
obj-y += $(onenand-m) $(onenand-y)
+nand-$(CONFIG_MTD_NAND_OMAP2) := gpmc-nand.o
+obj-y += $(nand-m) $(nand-y)
+
smc91x-$(CONFIG_SMC91X):= gpmc-smc91x.o
obj-y += $(smc91x-m) $(smc91x-y)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
new file mode 100644
index 000..c0e8ba7
--- /dev/null
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -0,0 +1,137 @@
+/*
+ * gpmc-nand.c
+ *
+ * Copyright (C) 2009 Texas Instruments
+ * Vimal Singh vimalsi...@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/nand.h
+#include plat/board.h
+#include plat/gpmc.h
+
+#define WR_RD_PIN_MONITORING 0x0060
+#define MASKADDR 8
+
+static struct omap_nand_platform_data *gpmc_nand_data;
+
+static struct resource gpmc_nand_resource = {
+ .flags = IORESOURCE_MEM,
+};
+
+static struct platform_device gpmc_nand_device = {
+ .name = omap2-nand,
+ .id = 0,
+ .num_resources = 1,
+ .resource = gpmc_nand_resource,
+};
+
+static int omap2_nand_gpmc_config(int cs, void __iomem *nand_base)
+{
+ struct gpmc_timings t;
+ int err;
+
+ const int cs_rd_off = 36;
+ const int cs_wr_off = 36;
+ const int adv_on = 6;
+ const int adv_rd_off = 24;
+ const int adv_wr_off = 36;
+ const int oe_off = 48;
+ const int we_off = 30;
+ const int rd_cycle = 72;
+ const int wr_cycle = 72;
+ const int access = 54;
+ const int wr_data_mux_bus = 0;
+ const int wr_access = 30;
+
+ memset(t, 0, sizeof(t));
+ t.sync_clk = 0;
+ t.cs_on = 0;
+ t.adv_on = gpmc_round_ns_to_ticks(adv_on);
+
+ /* Read */
+ t.adv_rd_off = gpmc_round_ns_to_ticks(adv_rd_off);
+ t.oe_on = t.adv_on;
+ t.access = gpmc_round_ns_to_ticks(access);
+ t.oe_off = gpmc_round_ns_to_ticks(oe_off);
+ t.cs_rd_off = gpmc_round_ns_to_ticks(cs_rd_off);
+ t.rd_cycle = gpmc_round_ns_to_ticks(rd_cycle);
+
+ /* Write */
+ t.adv_wr_off = gpmc_round_ns_to_ticks(adv_wr_off);
+ t.we_on = t.oe_on;
+ if (cpu_is_omap34xx()) {
+ t.wr_data_mux_bus = gpmc_round_ns_to_ticks(wr_data_mux_bus);
+ t.wr_access = gpmc_round_ns_to_ticks(wr_access);
+ }
+ t.we_off = gpmc_round_ns_to_ticks(we_off);
+ t.cs_wr_off = gpmc_round_ns_to_ticks(cs_wr_off);
+ t.wr_cycle = gpmc_round_ns_to_ticks(wr_cycle);
+
+ /* Configure GPMC */
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1,
+ GPMC_CONFIG1_DEVICESIZE(gpmc_nand_data-devsize) |
+ GPMC_CONFIG1_DEVICETYPE_NAND);
+
+ err = gpmc_cs_set_timings(cs, t);
+ if (err)
+ return err;
+
+ return 0;
+}
+
+static int gpmc_nand_setup(void __iomem *nand_base)
+{
+ struct device *dev = gpmc_nand_device.dev;
+
+ /* Set timings in GPMC */
+ if (omap2_nand_gpmc_config(gpmc_nand_data-cs, nand_base) 0) {
+ dev_err(dev, Unable to set gpmc timings\n);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+int __init gpmc_nand_init(struct omap_nand_platform_data *_nand_data)
+{
+ unsigned int val;
+ int err = 0;
+ struct device *dev = gpmc_nand_device.dev;
+
+ gpmc_nand_data = _nand_data;
+ gpmc_nand_data-nand_setup = gpmc_nand_setup;
+ gpmc_nand_device.dev.platform_data = gpmc_nand_data;
+
+ err = gpmc_nand_setup(gpmc_nand_data
Re: [PATCH 1/2]: OMAP: SDP: Introducing 'board-sdp-flash.c' for flash init
On Tue, Dec 8, 2009 at 12:06 AM, Tony Lindgren t...@atomide.com wrote:
* Vimal Singh vimal.neww...@gmail.com [091206 22:39]:
On Sat, Dec 5, 2009 at 3:47 AM, Tony Lindgren t...@atomide.com wrote:
Hi,
* Vimal Singh vimal.neww...@gmail.com [091203 06:09]:
From 13d52884956a26f93826c443e2b8bd78615f74d6 Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@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 vimalsi...@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 000..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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2]: Introducing 'gpmc-nand.c' for GPMC specific NAND init
Last time I forgot to cc linux-arm-ker...@lists.infradead.org. Looping now.
-vimal
On Mon, Dec 14, 2009 at 3:17 PM, Vimal Singh vimal.neww...@gmail.com wrote:
From 6170aa1c63c49a3f09e76258f400230b742fdd6f Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Wed, 25 Nov 2009 18:23:15 +0530
Subject: [PATCH] Introducing 'gpmc-nand.c' for GPMC specific NAND init
Introducing 'gpmc-nand.c' for GPMC specific NAND init.
For example: GPMC timing parameters and all.
This patch also migrates gpmc related calls from 'nand/omap2.c'
to 'gpmc-nand.c'.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/Makefile |3 +
arch/arm/mach-omap2/gpmc-nand.c| 137
arch/arm/plat-omap/include/plat/nand.h |6 ++
drivers/mtd/nand/omap2.c | 26 +--
4 files changed, 149 insertions(+), 23 deletions(-)
create mode 100644 arch/arm/mach-omap2/gpmc-nand.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 59b0ccc..0dfe27a 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -103,5 +103,8 @@ obj-y += usb-ehci.o
onenand-$(CONFIG_MTD_ONENAND_OMAP2) := gpmc-onenand.o
obj-y+= $(onenand-m) $(onenand-y)
+nand-$(CONFIG_MTD_NAND_OMAP2):= gpmc-nand.o
+obj-y+= $(nand-m) $(nand-y)
+
smc91x-$(CONFIG_SMC91X) := gpmc-smc91x.o
obj-y+= $(smc91x-m) $(smc91x-y)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
new file mode 100644
index 000..c0e8ba7
--- /dev/null
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -0,0 +1,137 @@
+/*
+ * gpmc-nand.c
+ *
+ * Copyright (C) 2009 Texas Instruments
+ * Vimal Singh vimalsi...@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/nand.h
+#include plat/board.h
+#include plat/gpmc.h
+
+#define WR_RD_PIN_MONITORING 0x0060
+#define MASKADDR 8
+
+static struct omap_nand_platform_data *gpmc_nand_data;
+
+static struct resource gpmc_nand_resource = {
+ .flags = IORESOURCE_MEM,
+};
+
+static struct platform_device gpmc_nand_device = {
+ .name = omap2-nand,
+ .id = 0,
+ .num_resources = 1,
+ .resource = gpmc_nand_resource,
+};
+
+static int omap2_nand_gpmc_config(int cs, void __iomem *nand_base)
+{
+ struct gpmc_timings t;
+ int err;
+
+ const int cs_rd_off = 36;
+ const int cs_wr_off = 36;
+ const int adv_on = 6;
+ const int adv_rd_off = 24;
+ const int adv_wr_off = 36;
+ const int oe_off = 48;
+ const int we_off = 30;
+ const int rd_cycle = 72;
+ const int wr_cycle = 72;
+ const int access = 54;
+ const int wr_data_mux_bus = 0;
+ const int wr_access = 30;
+
+ memset(t, 0, sizeof(t));
+ t.sync_clk = 0;
+ t.cs_on = 0;
+ t.adv_on = gpmc_round_ns_to_ticks(adv_on);
+
+ /* Read */
+ t.adv_rd_off = gpmc_round_ns_to_ticks(adv_rd_off);
+ t.oe_on = t.adv_on;
+ t.access = gpmc_round_ns_to_ticks(access);
+ t.oe_off = gpmc_round_ns_to_ticks(oe_off);
+ t.cs_rd_off = gpmc_round_ns_to_ticks(cs_rd_off);
+ t.rd_cycle = gpmc_round_ns_to_ticks(rd_cycle);
+
+ /* Write */
+ t.adv_wr_off = gpmc_round_ns_to_ticks(adv_wr_off);
+ t.we_on = t.oe_on;
+ if (cpu_is_omap34xx()) {
+ t.wr_data_mux_bus = gpmc_round_ns_to_ticks(wr_data_mux_bus);
+ t.wr_access = gpmc_round_ns_to_ticks(wr_access);
+ }
+ t.we_off = gpmc_round_ns_to_ticks(we_off);
+ t.cs_wr_off = gpmc_round_ns_to_ticks(cs_wr_off);
+ t.wr_cycle = gpmc_round_ns_to_ticks(wr_cycle);
+
+ /* Configure GPMC */
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1,
+ GPMC_CONFIG1_DEVICESIZE(gpmc_nand_data-devsize) |
+ GPMC_CONFIG1_DEVICETYPE_NAND);
+
+ err = gpmc_cs_set_timings(cs, t);
+ if (err)
+ return err;
+
+ return 0;
+}
+
+static int gpmc_nand_setup(void __iomem *nand_base)
+{
+ struct device *dev = gpmc_nand_device.dev;
+
+ /* Set timings in GPMC */
+ if (omap2_nand_gpmc_config(gpmc_nand_data-cs, nand_base) 0) {
+ dev_err(dev, Unable to set gpmc timings\n);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+int __init gpmc_nand_init(struct omap_nand_platform_data *_nand_data)
+{
+ unsigned int val;
+ int err = 0;
+ struct device *dev = gpmc_nand_device.dev
Re: [PATCH 2/2]: Introducing 'gpmc-nand.c' for GPMC specific NAND init
Any news on posting the updated version of this? Would be nice to get it in this merge window, so time's running out :) When re-posting, please also cc linux-arm-ker...@lists.infradead.org in addition to linux-omap list. That way we can have it quickly reviewed there too. Sorry for replying late. Last week I was on vacation. I will drop new version of this patch today. -- Regards, Vimal Singh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2]: Introducing 'gpmc-nand.c' for GPMC specific NAND init
On Mon, Dec 7, 2009 at 11:59 AM, Vimal Singh vimal.neww...@gmail.com wrote:
On Sat, Dec 5, 2009 at 3:31 AM, Tony Lindgren t...@atomide.com wrote:
Hi,
Looks good, just one comment below.
* Govindraj.R govindraj.r...@ti.com [091204 05:37]:
From: Vimal Singh vimalsi...@ti.com
Date: Wed, 25 Nov 2009 18:23:15 +0530
Subject: [PATCH] Introducing 'gpmc-nand.c' for GPMC specific NAND init
Introducing 'gpmc-nand.c' for GPMC specific NAND init.
For example: GPMC timing parameters and all.
This patch also migrates gpmc related calls from 'nand/omap2.c'
to 'gpmc-nand.c'.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/Makefile | 3 +
arch/arm/mach-omap2/gpmc-nand.c | 141
arch/arm/plat-omap/include/plat/nand.h | 6 ++
drivers/mtd/nand/omap2.c | 26 +-
4 files changed, 153 insertions(+), 23 deletions(-)
create mode 100644 arch/arm/mach-omap2/gpmc-nand.c
snip
--- /dev/null
+++ b/arch/arm/mach-omap2/gpmc-nand.c
snip
+int __init gpmc_nand_init(struct omap_nand_platform_data *_nand_data)
+{
+ unsigned int val;
+ int err = 0;
+ struct device *dev = gpmc_nand_device.dev;
+
+ gpmc_nand_data = _nand_data;
+ gpmc_nand_data-nand_setup = gpmc_nand_setup;
+ gpmc_nand_device.dev.platform_data = gpmc_nand_data;
+
+ err = gpmc_nand_setup(gpmc_nand_data-gpmc_cs_baseaddr);
+ if (err 0) {
+ dev_err(dev, NAND platform setup failed: %d\n, err);
+ return err;
+ }
+
+ /* Enable RD PIN Monitoring Reg */
+ if (gpmc_nand_data-dev_ready) {
+ val = gpmc_cs_read_reg(gpmc_nand_data-cs,
+ GPMC_CS_CONFIG1);
+ val |= WR_RD_PIN_MONITORING;
+ gpmc_cs_write_reg(gpmc_nand_data-cs,
+ GPMC_CS_CONFIG1, val);
+ }
Above looks OK..
+ val = gpmc_cs_read_reg(gpmc_nand_data-cs, GPMC_CS_CONFIG7);
+ val = ~(0xf 8);
+ val |= (0xc 0xf) 8;
+ gpmc_cs_write_reg(gpmc_nand_data-cs, GPMC_CS_CONFIG7, val);
..but this looks messy. Maybe use some GPMC defines for the
0xf 8 mask?
Then the 0xc 0xf part looks a bit redundant, what's the 0xf
there for?
I know it's all from the old code, but might as well clean it up
while at it :)
Ok, I'll drop next version of this patch for this.
In fact this peace of code is not required too. This will be taken
care in 'gpmc_cs_request'.
I will remove it.
--
Regards,
Vimal Singh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2]: Introducing 'gpmc-nand.c' for GPMC specific NAND init
On Sat, Dec 5, 2009 at 3:31 AM, Tony Lindgren t...@atomide.com wrote:
Hi,
Looks good, just one comment below.
* Govindraj.R govindraj.r...@ti.com [091204 05:37]:
From: Vimal Singh vimalsi...@ti.com
Date: Wed, 25 Nov 2009 18:23:15 +0530
Subject: [PATCH] Introducing 'gpmc-nand.c' for GPMC specific NAND init
Introducing 'gpmc-nand.c' for GPMC specific NAND init.
For example: GPMC timing parameters and all.
This patch also migrates gpmc related calls from 'nand/omap2.c'
to 'gpmc-nand.c'.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/Makefile | 3 +
arch/arm/mach-omap2/gpmc-nand.c | 141
arch/arm/plat-omap/include/plat/nand.h | 6 ++
drivers/mtd/nand/omap2.c | 26 +-
4 files changed, 153 insertions(+), 23 deletions(-)
create mode 100644 arch/arm/mach-omap2/gpmc-nand.c
snip
--- /dev/null
+++ b/arch/arm/mach-omap2/gpmc-nand.c
snip
+int __init gpmc_nand_init(struct omap_nand_platform_data *_nand_data)
+{
+ unsigned int val;
+ int err = 0;
+ struct device *dev = gpmc_nand_device.dev;
+
+ gpmc_nand_data = _nand_data;
+ gpmc_nand_data-nand_setup = gpmc_nand_setup;
+ gpmc_nand_device.dev.platform_data = gpmc_nand_data;
+
+ err = gpmc_nand_setup(gpmc_nand_data-gpmc_cs_baseaddr);
+ if (err 0) {
+ dev_err(dev, NAND platform setup failed: %d\n, err);
+ return err;
+ }
+
+ /* Enable RD PIN Monitoring Reg */
+ if (gpmc_nand_data-dev_ready) {
+ val = gpmc_cs_read_reg(gpmc_nand_data-cs,
+ GPMC_CS_CONFIG1);
+ val |= WR_RD_PIN_MONITORING;
+ gpmc_cs_write_reg(gpmc_nand_data-cs,
+ GPMC_CS_CONFIG1, val);
+ }
Above looks OK..
+ val = gpmc_cs_read_reg(gpmc_nand_data-cs, GPMC_CS_CONFIG7);
+ val = ~(0xf 8);
+ val |= (0xc 0xf) 8;
+ gpmc_cs_write_reg(gpmc_nand_data-cs, GPMC_CS_CONFIG7, val);
..but this looks messy. Maybe use some GPMC defines for the
0xf 8 mask?
Then the 0xc 0xf part looks a bit redundant, what's the 0xf
there for?
I know it's all from the old code, but might as well clean it up
while at it :)
Ok, I'll drop next version of this patch for this.
--
Regards,
Vimal Singh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2]: OMAP: SDP: Introducing 'board-sdp-flash.c' for flash init
On Sat, Dec 5, 2009 at 3:47 AM, Tony Lindgren t...@atomide.com wrote:
Hi,
* Vimal Singh vimal.neww...@gmail.com [091203 06:09]:
From 13d52884956a26f93826c443e2b8bd78615f74d6 Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@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 vimalsi...@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 000..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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2]: Introducing 'gpmc-nand.c' for GPMC specific NAND init
Hi all,
Please ignore previous patch, it has a compilation error.
Correct patch is present below.
-vimal
From e024a2e6aa2051259ad904daff13bdac73b3b1b8 Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Wed, 25 Nov 2009 18:23:15 +0530
Subject: [PATCH] Introducing 'gpmc-nand.c' for GPMC specific NAND init
Introducing 'gpmc-nand.c' for GPMC specific NAND init.
For example: GPMC timing parameters and all.
This patch also migrates gpmc related calls from 'nand/omap2.c'
to 'gpmc-nand.c'.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/Makefile |3 +
arch/arm/mach-omap2/gpmc-nand.c| 142
arch/arm/plat-omap/include/plat/nand.h |6 ++
drivers/mtd/nand/omap2.c | 26 +-
4 files changed, 154 insertions(+), 23 deletions(-)
create mode 100644 arch/arm/mach-omap2/gpmc-nand.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 59b0ccc..0dfe27a 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -103,5 +103,8 @@ obj-y += usb-ehci.o
onenand-$(CONFIG_MTD_ONENAND_OMAP2):= gpmc-onenand.o
obj-y += $(onenand-m) $(onenand-y)
+nand-$(CONFIG_MTD_NAND_OMAP2) := gpmc-nand.o
+obj-y += $(nand-m) $(nand-y)
+
smc91x-$(CONFIG_SMC91X):= gpmc-smc91x.o
obj-y += $(smc91x-m) $(smc91x-y)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
new file mode 100644
index 000..0621e39
--- /dev/null
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -0,0 +1,142 @@
+/*
+ * gpmc-nand.c
+ *
+ * Copyright (C) 2009 Texas Instruments
+ * Vimal Singh vimalsi...@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/nand.h
+#include plat/board.h
+#include plat/gpmc.h
+
+#define WR_RD_PIN_MONITORING 0x0060
+
+static struct omap_nand_platform_data *gpmc_nand_data;
+
+static struct resource gpmc_nand_resource = {
+ .flags = IORESOURCE_MEM,
+};
+
+static struct platform_device gpmc_nand_device = {
+ .name = omap2-nand,
+ .id = 0,
+ .num_resources = 1,
+ .resource = gpmc_nand_resource,
+};
+
+static int omap2_nand_gpmc_config(int cs, void __iomem *nand_base)
+{
+ struct gpmc_timings t;
+ int err;
+
+ const int cs_rd_off = 36;
+ const int cs_wr_off = 36;
+ const int adv_on = 6;
+ const int adv_rd_off = 24;
+ const int adv_wr_off = 36;
+ const int oe_off = 48;
+ const int we_off = 30;
+ const int rd_cycle = 72;
+ const int wr_cycle = 72;
+ const int access = 54;
+ const int wr_data_mux_bus = 8;
+ const int wr_access = 30;
+
+ memset(t, 0, sizeof(t));
+ t.sync_clk = 0;
+ t.cs_on = 0;
+ t.adv_on = gpmc_round_ns_to_ticks(adv_on);
+
+ /* Read */
+ t.adv_rd_off = gpmc_round_ns_to_ticks(adv_rd_off);
+ t.oe_on = t.adv_on;
+ t.access = gpmc_round_ns_to_ticks(access);
+ t.oe_off = gpmc_round_ns_to_ticks(oe_off);
+ t.cs_rd_off = gpmc_round_ns_to_ticks(cs_rd_off);
+ t.rd_cycle = gpmc_round_ns_to_ticks(rd_cycle);
+
+ /* Write */
+ t.adv_wr_off = gpmc_round_ns_to_ticks(adv_wr_off);
+ t.we_on = t.oe_on;
+ if (cpu_is_omap34xx()) {
+ t.wr_data_mux_bus = gpmc_round_ns_to_ticks(wr_data_mux_bus);
+ t.wr_access = gpmc_round_ns_to_ticks(wr_access);
+ }
+ t.we_off = gpmc_round_ns_to_ticks(we_off);
+ t.cs_wr_off = gpmc_round_ns_to_ticks(cs_wr_off);
+ t.wr_cycle = gpmc_round_ns_to_ticks(wr_cycle);
+
+ /* Configure GPMC */
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1,
+ GPMC_CONFIG1_DEVICESIZE(gpmc_nand_data-devsize) |
+ GPMC_CONFIG1_DEVICETYPE_NAND);
+
+ err = gpmc_cs_set_timings(cs, t);
+ if (err)
+ return err;
+
+ return 0;
+}
+
+static int gpmc_nand_setup(void __iomem *nand_base)
+{
+ struct device *dev = gpmc_nand_device.dev;
+
+ /* Set timings in GPMC */
+ if (omap2_nand_gpmc_config(gpmc_nand_data-cs, nand_base) 0) {
+ dev_err(dev, Unable to set gpmc timings\n);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+int __init gpmc_nand_init(struct omap_nand_platform_data *_nand_data)
+{
+ unsigned int val;
+ int err = 0;
+ struct device *dev = gpmc_nand_device.dev;
+
+ gpmc_nand_data = _nand_data;
+ gpmc_nand_data-nand_setup = gpmc_nand_setup
Re: [PATCH 2/2]: Introducing 'gpmc-nand.c' for GPMC specific NAND init
Ahh.. this is my bad.
[...]
+ err = gpmc_nand_setup((void __iomem *)
+ gpmc_nand_data-gpmc_cs_baseaddr);
we just do not need casting here.
Apologies for making noise and confusion.
Please take this one.
-vimal
From e024a2e6aa2051259ad904daff13bdac73b3b1b8 Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Wed, 25 Nov 2009 18:23:15 +0530
Subject: [PATCH] Introducing 'gpmc-nand.c' for GPMC specific NAND init
Introducing 'gpmc-nand.c' for GPMC specific NAND init.
For example: GPMC timing parameters and all.
This patch also migrates gpmc related calls from 'nand/omap2.c'
to 'gpmc-nand.c'.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/Makefile |3 +
arch/arm/mach-omap2/gpmc-nand.c| 141
arch/arm/plat-omap/include/plat/nand.h |6 ++
drivers/mtd/nand/omap2.c | 26 +-
4 files changed, 153 insertions(+), 23 deletions(-)
create mode 100644 arch/arm/mach-omap2/gpmc-nand.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 59b0ccc..0dfe27a 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -103,5 +103,8 @@ obj-y += usb-ehci.o
onenand-$(CONFIG_MTD_ONENAND_OMAP2):= gpmc-onenand.o
obj-y += $(onenand-m) $(onenand-y)
+nand-$(CONFIG_MTD_NAND_OMAP2) := gpmc-nand.o
+obj-y += $(nand-m) $(nand-y)
+
smc91x-$(CONFIG_SMC91X):= gpmc-smc91x.o
obj-y += $(smc91x-m) $(smc91x-y)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
new file mode 100644
index 000..0621e39
--- /dev/null
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -0,0 +1,141 @@
+/*
+ * gpmc-nand.c
+ *
+ * Copyright (C) 2009 Texas Instruments
+ * Vimal Singh vimalsi...@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/nand.h
+#include plat/board.h
+#include plat/gpmc.h
+
+#define WR_RD_PIN_MONITORING 0x0060
+
+static struct omap_nand_platform_data *gpmc_nand_data;
+
+static struct resource gpmc_nand_resource = {
+ .flags = IORESOURCE_MEM,
+};
+
+static struct platform_device gpmc_nand_device = {
+ .name = omap2-nand,
+ .id = 0,
+ .num_resources = 1,
+ .resource = gpmc_nand_resource,
+};
+
+static int omap2_nand_gpmc_config(int cs, void __iomem *nand_base)
+{
+ struct gpmc_timings t;
+ int err;
+
+ const int cs_rd_off = 36;
+ const int cs_wr_off = 36;
+ const int adv_on = 6;
+ const int adv_rd_off = 24;
+ const int adv_wr_off = 36;
+ const int oe_off = 48;
+ const int we_off = 30;
+ const int rd_cycle = 72;
+ const int wr_cycle = 72;
+ const int access = 54;
+ const int wr_data_mux_bus = 8;
+ const int wr_access = 30;
+
+ memset(t, 0, sizeof(t));
+ t.sync_clk = 0;
+ t.cs_on = 0;
+ t.adv_on = gpmc_round_ns_to_ticks(adv_on);
+
+ /* Read */
+ t.adv_rd_off = gpmc_round_ns_to_ticks(adv_rd_off);
+ t.oe_on = t.adv_on;
+ t.access = gpmc_round_ns_to_ticks(access);
+ t.oe_off = gpmc_round_ns_to_ticks(oe_off);
+ t.cs_rd_off = gpmc_round_ns_to_ticks(cs_rd_off);
+ t.rd_cycle = gpmc_round_ns_to_ticks(rd_cycle);
+
+ /* Write */
+ t.adv_wr_off = gpmc_round_ns_to_ticks(adv_wr_off);
+ t.we_on = t.oe_on;
+ if (cpu_is_omap34xx()) {
+ t.wr_data_mux_bus = gpmc_round_ns_to_ticks(wr_data_mux_bus);
+ t.wr_access = gpmc_round_ns_to_ticks(wr_access);
+ }
+ t.we_off = gpmc_round_ns_to_ticks(we_off);
+ t.cs_wr_off = gpmc_round_ns_to_ticks(cs_wr_off);
+ t.wr_cycle = gpmc_round_ns_to_ticks(wr_cycle);
+
+ /* Configure GPMC */
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1,
+ GPMC_CONFIG1_DEVICESIZE(gpmc_nand_data-devsize) |
+ GPMC_CONFIG1_DEVICETYPE_NAND);
+
+ err = gpmc_cs_set_timings(cs, t);
+ if (err)
+ return err;
+
+ return 0;
+}
+
+static int gpmc_nand_setup(void __iomem *nand_base)
+{
+ struct device *dev = gpmc_nand_device.dev;
+
+ /* Set timings in GPMC */
+ if (omap2_nand_gpmc_config(gpmc_nand_data-cs, nand_base) 0) {
+ dev_err(dev, Unable to set gpmc timings\n);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+int __init gpmc_nand_init(struct omap_nand_platform_data *_nand_data)
+{
+ unsigned int val;
+ int err = 0;
+ struct device *dev
[PATCH 0/2]OMAP: Introducing gpmc-nand.c
From fadc45cca4026d26d00a759efdc681303b0d3097 Mon Sep 17 00:00:00 2001 From: Vimal Singh vimalsi...@ti.com Date: Thu, 3 Dec 2009 18:35:23 +0530 Subject: [PATCH] OMAP: Introducing gpmc-nand.c This patch series introduces generic gpmc-nand.c for nand device related gpmc init. Vimal Singh (2): Correcting GPMC_CONFIG1_DEVICETYPE_NAND Introducing 'gpmc-nand.c' for GPMC specific NAND init arch/arm/mach-omap2/Makefile |3 + arch/arm/mach-omap2/gpmc-nand.c| 141 arch/arm/plat-omap/include/plat/gpmc.h |2 +- arch/arm/plat-omap/include/plat/nand.h |6 ++ drivers/mtd/nand/omap2.c | 26 +- 5 files changed, 154 insertions(+), 24 deletions(-) create mode 100644 arch/arm/mach-omap2/gpmc-nand.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2]: Correcting GPMC_CONFIG1_DEVICETYPE_NAND
From efeeb1cfc592c827424b4c76b18150e801bdfbab Mon Sep 17 00:00:00 2001 From: Vimal Singh vimalsi...@ti.com Date: Wed, 25 Nov 2009 17:47:46 +0530 Subject: [PATCH] Correcting GPMC_CONFIG1_DEVICETYPE_NAND For NAND devices '2' should be used with GPMC_CONFIG1_DEVICETYPE instead of '1'. Signed-off-by: Vimal Singh vimalsi...@ti.com --- arch/arm/plat-omap/include/plat/gpmc.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/gpmc.h b/arch/arm/plat-omap/include/plat/gpmc.h index 696e0ca..e081338 100644 --- a/arch/arm/plat-omap/include/plat/gpmc.h +++ b/arch/arm/plat-omap/include/plat/gpmc.h @@ -45,7 +45,7 @@ #define GPMC_CONFIG1_DEVICESIZE_16 GPMC_CONFIG1_DEVICESIZE(1) #define GPMC_CONFIG1_DEVICETYPE(val)((val 3) 10) #define GPMC_CONFIG1_DEVICETYPE_NOR GPMC_CONFIG1_DEVICETYPE(0) -#define GPMC_CONFIG1_DEVICETYPE_NANDGPMC_CONFIG1_DEVICETYPE(1) +#define GPMC_CONFIG1_DEVICETYPE_NANDGPMC_CONFIG1_DEVICETYPE(2) #define GPMC_CONFIG1_MUXADDDATA (1 9) #define GPMC_CONFIG1_TIME_PARA_GRAN (1 4) #define GPMC_CONFIG1_FCLK_DIV(val) (val 3) -- 1.5.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2]: Introducing 'gpmc-nand.c' for GPMC specific NAND init
From fadc45cca4026d26d00a759efdc681303b0d3097 Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Wed, 25 Nov 2009 18:23:15 +0530
Subject: [PATCH] Introducing 'gpmc-nand.c' for GPMC specific NAND init
Introducing 'gpmc-nand.c' for GPMC specific NAND init.
For example: GPMC timing parameters and all.
This patch also migrates gpmc related calls from 'nand/omap2.c'
to 'gpmc-nand.c'.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/Makefile |3 +
arch/arm/mach-omap2/gpmc-nand.c| 141
arch/arm/plat-omap/include/plat/nand.h |6 ++
drivers/mtd/nand/omap2.c | 26 +-
4 files changed, 153 insertions(+), 23 deletions(-)
create mode 100644 arch/arm/mach-omap2/gpmc-nand.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 59b0ccc..0dfe27a 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -103,5 +103,8 @@ obj-y += usb-ehci.o
onenand-$(CONFIG_MTD_ONENAND_OMAP2):= gpmc-onenand.o
obj-y += $(onenand-m) $(onenand-y)
+nand-$(CONFIG_MTD_NAND_OMAP2) := gpmc-nand.o
+obj-y += $(nand-m) $(nand-y)
+
smc91x-$(CONFIG_SMC91X):= gpmc-smc91x.o
obj-y += $(smc91x-m) $(smc91x-y)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
new file mode 100644
index 000..d92abdf
--- /dev/null
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -0,0 +1,141 @@
+/*
+ * gpmc-nand.c
+ *
+ * Copyright (C) 2009 Texas Instruments
+ * Vimal Singh vimalsi...@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/nand.h
+#include plat/board.h
+#include plat/gpmc.h
+
+#define WR_RD_PIN_MONITORING 0x0060
+
+static struct omap_nand_platform_data *gpmc_nand_data;
+
+static struct resource gpmc_nand_resource = {
+ .flags = IORESOURCE_MEM,
+};
+
+static struct platform_device gpmc_nand_device = {
+ .name = omap2-nand,
+ .id = 0,
+ .num_resources = 1,
+ .resource = gpmc_nand_resource,
+};
+
+static int omap2_nand_gpmc_config(int cs, void __iomem *nand_base)
+{
+ struct gpmc_timings t;
+ int err;
+
+ const int cs_rd_off = 36;
+ const int cs_wr_off = 36;
+ const int adv_on = 6;
+ const int adv_rd_off = 24;
+ const int adv_wr_off = 36;
+ const int oe_off = 48;
+ const int we_off = 30;
+ const int rd_cycle = 72;
+ const int wr_cycle = 72;
+ const int access = 54;
+ const int wr_data_mux_bus = 8;
+ const int wr_access = 30;
+
+ memset(t, 0, sizeof(t));
+ t.sync_clk = 0;
+ t.cs_on = 0;
+ t.adv_on = gpmc_round_ns_to_ticks(adv_on);
+
+ /* Read */
+ t.adv_rd_off = gpmc_round_ns_to_ticks(adv_rd_off);
+ t.oe_on = t.adv_on;
+ t.access = gpmc_round_ns_to_ticks(access);
+ t.oe_off = gpmc_round_ns_to_ticks(oe_off);
+ t.cs_rd_off = gpmc_round_ns_to_ticks(cs_rd_off);
+ t.rd_cycle = gpmc_round_ns_to_ticks(rd_cycle);
+
+ /* Write */
+ t.adv_wr_off = gpmc_round_ns_to_ticks(adv_wr_off);
+ t.we_on = t.oe_on;
+ if (cpu_is_omap34xx()) {
+ t.wr_data_mux_bus = gpmc_round_ns_to_ticks(wr_data_mux_bus);
+ t.wr_access = gpmc_round_ns_to_ticks(wr_access);
+ }
+ t.we_off = gpmc_round_ns_to_ticks(we_off);
+ t.cs_wr_off = gpmc_round_ns_to_ticks(cs_wr_off);
+ t.wr_cycle = gpmc_round_ns_to_ticks(wr_cycle);
+
+ /* Configure GPMC */
+ gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1,
+ GPMC_CONFIG1_DEVICESIZE(gpmc_nand_data-devsize) |
+ GPMC_CONFIG1_DEVICETYPE_NAND);
+
+ err = gpmc_cs_set_timings(cs, t);
+ if (err)
+ return err;
+
+ return 0;
+}
+
+static int gpmc_nand_setup(void __iomem *nand_base)
+{
+ struct device *dev = gpmc_nand_device.dev;
+
+ /* Set timings in GPMC */
+ if (omap2_nand_gpmc_config(gpmc_nand_data-cs, nand_base) 0) {
+ dev_err(dev, Unable to set gpmc timings\n);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+int __init gpmc_nand_init(struct omap_nand_platform_data *_nand_data)
+{
+ unsigned int val;
+ int err = 0;
+ struct device *dev = gpmc_nand_device.dev;
+
+ gpmc_nand_data = _nand_data;
+ gpmc_nand_data-nand_setup = gpmc_nand_setup;
+ gpmc_nand_device.dev.platform_data = gpmc_nand_data;
+
+ err = gpmc_nand_setup((void __iomem *)gpmc_nand_data-start);
+ if (err
[PATCH 1/2]: OMAP: SDP: Introducing 'board-sdp-flash.c' for flash init
From 13d52884956a26f93826c443e2b8bd78615f74d6 Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@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 vimalsi...@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 000..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 vimalsi...@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 0x0800 /* debug board */
+
+#define PDC_NOR1
+#define PDC_NAND 2
+#define PDC_ONENAND3
+#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: */
+ {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
[PATCH 2/2]: OMAP3: Add support for flash on 3430SDP board
From f48199dc44e1bf5f56aa981d20f35dc8ce1113bf Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Tue, 1 Dec 2009 11:24:46 +0530
Subject: [PATCH] OMAP3: Add support for flash on 3430SDP board
This patch adds support for flashes on 3430SDP boards. All three
NAND, NOR and OneNAND are supported. I have tested it on
3430SDP (ES2 and ES3.1).
This patch can be treated as an example to how to utilize:
'gpmc-nand.c' and 'board-sdp-flash.c'.
Similar patches can be created for 2430sdp and 3630sdp or any other
similar board.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/Makefile|1 +
arch/arm/mach-omap2/board-3430sdp.c | 111 +++
2 files changed, 112 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 0dfe27a..f1d8544 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -69,6 +69,7 @@ obj-$(CONFIG_MACH_OMAP3EVM) += board-omap3evm.o \
obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o \
mmc-twl4030.o
obj-$(CONFIG_MACH_OMAP_3430SDP)+= board-3430sdp.o \
+ board-sdp-flash.o \
mmc-twl4030.o
obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o
obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 5bda9fd..b921f44 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -42,6 +42,8 @@
#include plat/control.h
#include plat/gpmc-smc91x.h
+#include mach/board-sdp.h
+
#include sdram-qimonda-hyb18m512160af-6.h
#include mmc-twl4030.h
@@ -640,6 +642,114 @@ static struct ehci_hcd_omap_platform_data
ehci_pdata __initconst = {
.reset_gpio_port[2] = -EINVAL
};
+static struct mtd_partition sdp_nor_partitions[] = {
+ /* bootloader (U-Boot, etc) in first sector */
+ {
+ .name = Bootloader-NOR,
+ .offset = 0,
+ .size = SZ_256K,
+ .mask_flags = MTD_WRITEABLE, /* force read-only */
+ },
+ /* bootloader params in the next sector */
+ {
+ .name = Params-NOR,
+ .offset = MTDPART_OFS_APPEND,
+ .size = SZ_256K,
+ .mask_flags = 0,
+ },
+ /* kernel */
+ {
+ .name = Kernel-NOR,
+ .offset = MTDPART_OFS_APPEND,
+ .size = SZ_2M,
+ .mask_flags = 0
+ },
+ /* file system */
+ {
+ .name = Filesystem-NOR,
+ .offset = MTDPART_OFS_APPEND,
+ .size = MTDPART_SIZ_FULL,
+ .mask_flags = 0
+ }
+};
+
+static struct mtd_partition sdp_onenand_partitions[] = {
+ {
+ .name = X-Loader-OneNAND,
+ .offset = 0,
+ .size = 4 * (64 * 2048),
+ .mask_flags = MTD_WRITEABLE /* force read-only */
+ },
+ {
+ .name = U-Boot-OneNAND,
+ .offset = MTDPART_OFS_APPEND,
+ .size = 2 * (64 * 2048),
+ .mask_flags = MTD_WRITEABLE /* force read-only */
+ },
+ {
+ .name = U-Boot Environment-OneNAND,
+ .offset = MTDPART_OFS_APPEND,
+ .size = 1 * (64 * 2048),
+ },
+ {
+ .name = Kernel-OneNAND,
+ .offset = MTDPART_OFS_APPEND,
+ .size = 16 * (64 * 2048),
+ },
+ {
+ .name = File System-OneNAND,
+ .offset = MTDPART_OFS_APPEND,
+ .size = MTDPART_SIZ_FULL,
+ },
+};
+
+static struct mtd_partition sdp_nand_partitions[] = {
+ /* All the partition sizes are listed in terms of NAND block size */
+ {
+ .name = X-Loader-NAND,
+ .offset = 0,
+ .size = 4 * (64 * 2048),
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = U-Boot-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x8 */
+ .size = 10 * (64 * 2048),
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = Boot Env-NAND,
+
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x1c */
+ .size = 6 * (64 * 2048),
+ },
+ {
+ .name = Kernel-NAND
[PATCH 0/4]: Adding NAND support for LDP/ZOOM boards
From 1786a05d3331850ff5c49e4edafe68a411597173 Mon Sep 17 00:00:00 2001 From: Vimal Singh vimalsi...@ti.com Date: Thu, 3 Dec 2009 18:36:11 +0530 Subject: [PATCH] Adding NAND support for LDP/ZOOM boards '1st' patch in this series introduces 'board-zoom-flash.c' for NAND init in ZOOM boards. Other three patch will add NAND support for ZOOM2, ZOOM3 and LDP. I have tested it for ZOOM2 and ZOOM3 boards. Could someone please test this for LDP boards? Vimal Singh (4): OMAP: ZOOM: Introducing 'board-zoom-flash.c' OMAP3: Add support for NAND on ZOOM2 board OMAP3: Add support for NAND on ZOOM3 board OMAP3: Add support for NAND on LDP board arch/arm/mach-omap2/Makefile |3 + arch/arm/mach-omap2/board-ldp.c | 41 + arch/arm/mach-omap2/board-zoom-flash.c| 59 + arch/arm/mach-omap2/board-zoom2.c | 49 arch/arm/mach-omap2/board-zoom3.c | 49 arch/arm/mach-omap2/include/mach/board-zoom.h | 11 + 6 files changed, 212 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/board-zoom-flash.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4]: OMAP: ZOOM: Introducing 'board-zoom-flash.c' for NAND init in ZOOM boards
From 948584f4157a9eb99ba085968d23add28cbfd160 Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Tue, 1 Dec 2009 11:36:56 +0530
Subject: [PATCH] OMAP: ZOOM: Introducing 'board-zoom-flash.c'
This patch adds 'board-zoom-flash.c', which could be utilized
by boards similar to ZOOM2. (For ex: LDP, ZOOM2, ZOOM3).
This does initialization for NAND device based on the 'cs' number
and partition information passed from board file (ex: board-zoom2.c).
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/board-zoom-flash.c| 59 +
arch/arm/mach-omap2/include/mach/board-zoom.h | 11 +
2 files changed, 70 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-zoom-flash.c
diff --git a/arch/arm/mach-omap2/board-zoom-flash.c
b/arch/arm/mach-omap2/board-zoom-flash.c
new file mode 100644
index 000..b3e66ca
--- /dev/null
+++ b/arch/arm/mach-omap2/board-zoom-flash.c
@@ -0,0 +1,59 @@
+/*
+ * board-zoom-flash.c
+ *
+ * Copyright (C) 2009 Texas Instruments Inc.
+ * Vimal Singh vimalsi...@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/delay.h
+#include linux/platform_device.h
+#include linux/mtd/nand.h
+#include linux/types.h
+#include linux/io.h
+
+#include asm/mach/flash.h
+#include plat/board.h
+#include plat/gpmc.h
+#include plat/nand.h
+
+#include mach/board-zoom.h
+
+#if defined(CONFIG_MTD_NAND_OMAP2) || \
+ defined(CONFIG_MTD_NAND_OMAP2_MODULE)
+/* NAND chip access: 16 bit */
+static struct omap_nand_platform_data zoom_nand_data = {
+ .nand_setup = NULL,
+ .dma_channel= -1, /* disable DMA in OMAP NAND driver */
+ .dev_ready = NULL,
+ .devsize= 1,/* '0' for 8-bit, '1' for 16-bit device */
+};
+
+/**
+ * zoom_flash_init - Identify devices connected to GPMC and register.
+ *
+ * @return - void.
+ */
+void __init zoom_flash_init(struct flash_partitions zoom_nand_parts[], int cs)
+{
+ u32 gpmc_base_add = OMAP34XX_GPMC_VIRT;
+
+ zoom_nand_data.cs = cs;
+ zoom_nand_data.parts= zoom_nand_parts[0].parts;
+ zoom_nand_data.nr_parts = zoom_nand_parts[0].nr_parts;
+ zoom_nand_data.gpmc_baseaddr= (void *)(gpmc_base_add);
+ zoom_nand_data.gpmc_cs_baseaddr = (void *)(gpmc_base_add +
+ GPMC_CS0_BASE +
+ cs * GPMC_CS_SIZE);
+ gpmc_nand_init(zoom_nand_data);
+}
+#else
+void __init zoom_flash_init(struct flash_partitions zoom_nand_parts[], int cs)
+{
+}
+#endif /* CONFIG_MTD_NAND_OMAP2 || CONFIG_MTD_NAND_OMAP2_MODULE */
+
diff --git a/arch/arm/mach-omap2/include/mach/board-zoom.h
b/arch/arm/mach-omap2/include/mach/board-zoom.h
index c93b29e..f4469d3 100644
--- a/arch/arm/mach-omap2/include/mach/board-zoom.h
+++ b/arch/arm/mach-omap2/include/mach/board-zoom.h
@@ -1,5 +1,16 @@
/*
* Defines for zoom boards
*/
+#include linux/mtd/mtd.h
+#include linux/mtd/partitions.h
+
+struct flash_partitions {
+ struct mtd_partition *parts;
+ int nr_parts;
+};
+
+#define ZOOM_NAND_CS 0
+
+extern void __init zoom_flash_init(struct flash_partitions [], int);
extern int __init zoom_debugboard_init(void);
extern void __init zoom_peripherals_init(void);
--
1.5.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4]: OMAP3: Add support for NAND on ZOOM2 board
From 06890a29ed85068787d2bc3af3c38d29b4e0e421 Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Thu, 3 Dec 2009 18:21:44 +0530
Subject: [PATCH] OMAP3: Add support for NAND on ZOOM2 board
This patch adds NAND support to ZOOM2 board.
This uses 'board-zoom-flash.c' for NAND initialization.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-zoom2.c | 49 +
2 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index f1d8544..a277d38 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -77,6 +77,7 @@ obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \
board-rx51-peripherals.o \
mmc-twl4030.o
obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom2.o \
+ board-zoom-flash.o \
board-zoom-peripherals.o \
mmc-twl4030.o \
board-zoom-debugboard.o
diff --git a/arch/arm/mach-omap2/board-zoom2.c
b/arch/arm/mach-omap2/board-zoom2.c
index 2f980e3..2c7f833 100644
--- a/arch/arm/mach-omap2/board-zoom2.c
+++ b/arch/arm/mach-omap2/board-zoom2.c
@@ -58,9 +58,58 @@ static struct twl4030_platform_data zoom2_twldata = {
#endif
+static struct mtd_partition zoom_nand_partitions[] = {
+ /* All the partition sizes are listed in terms of NAND block size */
+ {
+ .name = X-Loader-NAND,
+ .offset = 0,
+ .size = 4 * (64 * 2048), /* 512KB, 0x8 */
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+},
+ {
+ .name = U-Boot-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x8 */
+ .size = 10 * (64 * 2048), /* 1.25MB, 0x14 */
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = Boot Env-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x1c */
+ .size = 2 * (64 * 2048), /* 256KB, 0x4 */
+ },
+ {
+ .name = Kernel-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x020*/
+ .size = 240 * (64 * 2048),/* 30M, 0x1E0 */
+ },
+ {
+ .name = system,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x200 */
+ .size = 1280 * (64 * 2048), /* 160M, 0xA00 */
+ },
+ {
+ .name = userdata,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0xC00 */
+ .size = 256 * (64 * 2048),/* 32M, 0x200 */
+ },
+ {
+ .name = cache,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0xE00 */
+ .size = 256 * (64 * 2048),/* 32M, 0x200 */
+ },
+};
+
+static struct flash_partitions zoom_flash_partitions[] = {
+ {
+ .parts = zoom_nand_partitions,
+ .nr_parts = ARRAY_SIZE(zoom_nand_partitions),
+ },
+};
+
static void __init omap_zoom2_init(void)
{
zoom_peripherals_init();
+ zoom_flash_init(zoom_flash_partitions, ZOOM_NAND_CS);
zoom_debugboard_init();
}
--
1.5.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4]: OMAP3: Add support for NAND on ZOOM3 board
From 4259c6ae2e6d9b5e316fa8289a9fca729fc6bc83 Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Thu, 3 Dec 2009 18:23:37 +0530
Subject: [PATCH] OMAP3: Add support for NAND on ZOOM3 board
This patch adds NAND support to ZOOM3 board.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-zoom3.c | 49 +
2 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index a277d38..4848ab0 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -82,6 +82,7 @@ obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom2.o \
mmc-twl4030.o \
board-zoom-debugboard.o
obj-$(CONFIG_MACH_OMAP_ZOOM3) += board-zoom3.o \
+ board-zoom-flash.o \
board-zoom-peripherals.o \
mmc-twl4030.o \
board-zoom-debugboard.o
diff --git a/arch/arm/mach-omap2/board-zoom3.c
b/arch/arm/mach-omap2/board-zoom3.c
index 8d965a6..49090da 100644
--- a/arch/arm/mach-omap2/board-zoom3.c
+++ b/arch/arm/mach-omap2/board-zoom3.c
@@ -42,9 +42,58 @@ static void __init omap_zoom_init_irq(void)
omap_gpio_init();
}
+static struct mtd_partition zoom_nand_partitions[] = {
+ /* All the partition sizes are listed in terms of NAND block size */
+ {
+ .name = X-Loader-NAND,
+ .offset = 0,
+ .size = 4 * (64 * 2048), /* 512KB, 0x8 */
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+},
+ {
+ .name = U-Boot-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x8 */
+ .size = 10 * (64 * 2048), /* 1.25MB, 0x14 */
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = Boot Env-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x1c */
+ .size = 2 * (64 * 2048), /* 256KB, 0x4 */
+ },
+ {
+ .name = Kernel-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x020*/
+ .size = 240 * (64 * 2048),/* 30M, 0x1E0 */
+ },
+ {
+ .name = system,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x200 */
+ .size = 1280 * (64 * 2048), /* 160M, 0xA00 */
+ },
+ {
+ .name = userdata,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0xC00 */
+ .size = 256 * (64 * 2048),/* 32M, 0x200 */
+ },
+ {
+ .name = cache,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0xE00 */
+ .size = 256 * (64 * 2048),/* 32M, 0x200 */
+ },
+};
+
+static struct flash_partitions zoom_flash_partitions[] = {
+ {
+ .parts = zoom_nand_partitions,
+ .nr_parts = ARRAY_SIZE(zoom_nand_partitions),
+ },
+};
+
static void __init omap_zoom_init(void)
{
zoom_peripherals_init();
+ zoom_flash_init(zoom_flash_partitions, ZOOM_NAND_CS);
zoom_debugboard_init();
}
--
1.5.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4]: OMAP3: Add support for NAND on LDP board
From 1786a05d3331850ff5c49e4edafe68a411597173 Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Thu, 3 Dec 2009 18:26:45 +0530
Subject: [PATCH] OMAP3: Add support for NAND on LDP board
This patch adds NAND support to LDP board.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/Makefile|1 +
arch/arm/mach-omap2/board-ldp.c | 41 +++
2 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 4848ab0..f730ddc 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_MACH_OMAP_APOLLON) +=
board-apollon.o
obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o \
mmc-twl4030.o
obj-$(CONFIG_MACH_OMAP_LDP)+= board-ldp.o \
+ board-zoom-flash.o \
mmc-twl4030.o
obj-$(CONFIG_MACH_OVERO) += board-overo.o \
mmc-twl4030.o
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index c062238..25bbb4f 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -38,6 +38,7 @@
#include plat/board.h
#include plat/common.h
#include plat/gpmc.h
+#include mach/board-zoom.h
#include asm/delay.h
#include plat/control.h
@@ -374,6 +375,45 @@ static struct platform_device *ldp_devices[] __initdata = {
ldp_gpio_keys_device,
};
+static struct mtd_partition zoom_nand_partitions[] = {
+ /* All the partition sizes are listed in terms of NAND block size */
+ {
+ .name = X-Loader-NAND,
+ .offset = 0,
+ .size = 4 * (64 * 2048), /* 512KB, 0x8 */
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = U-Boot-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x8 */
+ .size = 10 * (64 * 2048), /* 1.25MB, 0x14 */
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = Boot Env-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x1c */
+ .size = 2 * (64 * 2048), /* 256KB, 0x4 */
+ },
+ {
+ .name = Kernel-NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x020*/
+ .size = 240 * (64 * 2048),/* 30M, 0x1E0 */
+ },
+ {
+ .name = File System - NAND,
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x200 */
+ .size = MTDPART_SIZ_FULL, /* 96MB, 0x600 */
+ },
+
+};
+
+static struct flash_partitions zoom_flash_partitions[] = {
+ {
+ .parts = zoom_nand_partitions,
+ .nr_parts = ARRAY_SIZE(zoom_nand_partitions),
+ },
+};
+
static void __init omap_ldp_init(void)
{
omap_i2c_init();
@@ -385,6 +425,7 @@ static void __init omap_ldp_init(void)
ads7846_dev_init();
omap_serial_init();
usb_musb_init();
+ zoom_flash_init(zoom_flash_partitions, ZOOM_NAND_CS);
twl4030_mmc_init(mmc);
/* link regulators to MMC adapters */
--
1.5.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
