RE: [PATCH v9 0/7] nand prefetch-irq support and ecc layout chanage
-Original Message- From: Ghorai, Sukumar Sent: Friday, January 28, 2011 3:42 PM To: linux-omap@vger.kernel.org Cc: linux-...@lists.infradead.org; linux-arm-ker...@lists.infradead.org; Ghorai, Sukumar Subject: [PATCH v9 0/7] nand prefetch-irq support and ecc layout chanage The following set of patches applies on linux-2.6. The main motivations behind this patch series are - 1. support NAND I/O in irq mode. 2. support of different ECC schema. 3. also add support ecc layout as like in romcode ecc layout, but not enabled v9: gpmc_init() changed to postcore_initcall(gpmc_init); v8: free_irq() added; used timeout for while(tight loop) And resend of http://www.mail-archive.com/linux- o...@vger.kernel.org/msg41614.html v7: NAND type (x16 or x8) is board specific and not omap specific; this passed form board file. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg41469.html v6: configurable transfer type from board file; #define irq number used for nand-irq http://www.mail-archive.com/linux-omap@vger.kernel.org/msg39397.html v5: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg35860.html This address the input as to support the irq_chained in GPMC. And resend of http://www.mail-archive.com/linux-omap@vger.kernel.org/msg35848.html v4: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg34882.html and resend of http://www.mail-archive.com/linux-omap@vger.kernel.org/msg32689.html v3: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg32071.html Rebase on latest codebase and previous patch(posted). http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31963.html v2: Rebase on latest codebase and previous patch(posted). http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31471.html v1: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg2.html Sukumar Ghorai (7): omap3630: nand: fix device size to work in polled mode omap3: nand: configurable transfer type per board omap: gpmc: enable irq mode in gpmc omap3: nand: prefetch in irq mode support omap3: nand: configurable fifo threshold to gain the throughput omap3: nand: ecc layout select from board file omap3: nand: making ecc layout as compatible with romcode ecc arch/arm/mach-omap2/board-3430sdp.c|2 +- arch/arm/mach-omap2/board-3630sdp.c|3 +- arch/arm/mach-omap2/board-flash.c | 13 +- arch/arm/mach-omap2/board-flash.h |4 +- arch/arm/mach-omap2/board-ldp.c|2 +- arch/arm/mach-omap2/board-zoom.c |5 +- arch/arm/mach-omap2/gpmc-nand.c|7 +- arch/arm/mach-omap2/gpmc.c | 56 +- arch/arm/mach-omap2/io.c |2 - arch/arm/plat-omap/include/plat/gpmc.h | 18 ++- arch/arm/plat-omap/include/plat/irqs.h |9 +- arch/arm/plat-omap/include/plat/nand.h | 11 + drivers/mtd/nand/Kconfig | 17 -- drivers/mtd/nand/omap2.c | 367 --- - 14 files changed, 386 insertions(+), 130 deletions(-) Tony, In this version I have addressed all inputs on previous versions. Please check if it's possible to push all theses in any of your testing branch! -- 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 RESEND v8 3/7] omap: gpmc: enable irq mode in gpmc
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Tuesday, January 25, 2011 10:28 PM To: Ghorai, Sukumar Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org; linux-arm- ker...@lists.infradead.org Subject: Re: [PATCH RESEND v8 3/7] omap: gpmc: enable irq mode in gpmc * Ghorai, Sukumar s-gho...@ti.com [110122 09:53]: I think I've commented on this before, but why don't you make gpmc_init a subsys_initcall? There should be no reason to call this earlier. If something does not work because of that, then that issue must be fixed. [Ghorai] You suggested the same in previous v5 and v6; and I mentioned the issues [1] that - nand_init()called before subsys_initcall(gpmc_init); Let me know if I am missing anything again. There should not be any need to call nand_init early either. We want to initialize as much as possible late so we have proper console error messages. [Ghorai] thanks... changed to postcore_initcall() and it solved the problem I mentioned earlier. And it simplifies the overall modification in different board files. postcore_initcall(gpmc_init); Tony -- 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 RESEND v8 3/7] omap: gpmc: enable irq mode in gpmc
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Saturday, January 22, 2011 12:10 AM
To: Ghorai, Sukumar
Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org; linux-arm-
ker...@lists.infradead.org
Subject: Re: [PATCH RESEND v8 3/7] omap: gpmc: enable irq mode in gpmc
* Sukumar Ghorai s-gho...@ti.com [110119 05:24]:
add support the irq mode in GPMC.
gpmc_init() function move after omap_init_irq() as it has dependecy on
irq.
[..snip..]
static struct twl4030_gpio_platform_data sdp2430_gpio_data = {
diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-
omap2/board-3430sdp.c
index 8fb5f43..8304d16 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -335,6 +335,7 @@ static void __init omap_3430sdp_init_irq(void)
omap2_init_common_infrastructure();
omap2_init_common_devices(hyb18m512160af6_sdrc_params, NULL);
omap_init_irq();
+ gpmc_init();
}
...
I think I've commented on this before, but why don't you make gpmc_init
a subsys_initcall? There should be no reason to call this earlier.
If something does not work because of that, then that issue must be
fixed.
[Ghorai] You suggested the same in previous v5 and v6; and I mentioned
the issues [1] that - nand_init()called before subsys_initcall(gpmc_init);
Let me know if I am missing anything again.
[1] https://patchwork.kernel.org/patch/212452/
[2] https://patchwork.kernel.org/patch/359152/
Tony
--
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
-Original Message- From: Vimal Singh [mailto:vimal.neww...@gmail.com] Sent: Friday, January 21, 2011 1:08 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 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) [Ghorai] can you send me the version? 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. [Ghorai] there is no special idea needed to correct the ecc. Only correct algorithm is nedded. [Ghorai]And not all code is changed. Does it? [Ghorai] can you send me your latest version? 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
-Original Message- From: Kishore Kadiyala [mailto:kishorek.kadiy...@gmail.com] Sent: Friday, January 21, 2011 1:42 PM To: Ghorai, Sukumar Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org; linux-arm- ker...@lists.infradead.org Subject: Re: [PATCH] omap3: nand: bch ecc support added Ghorai, snip #ifdef CONFIG_MTD_PARTITIONS diff --git a/drivers/mtd/nand/omap_bch_decoder.c b/drivers/mtd/nand/omap_bch_decoder.c new file mode 100644 index 000..da42bda --- /dev/null +++ b/drivers/mtd/nand/omap_bch_decoder.c @@ -0,0 +1,393 @@ +/* + * drivers/mtd/nand/omap_omap_bch_decoder.c + * + * Whole BCH ECC Decoder (Post hardware generated syndrome decoding) + * + * Copyright (c) 2007 Texas Instruments + * + * Author: Sukumar Ghorai s-gho...@ti.com + * Michael Fillinger m-fillin...@ti.com Vimal was the original author who has created this file [No change in file name/directory hierarchy]. It's not fair to remove Vimal's author and add your's. Instead you should have kept his name and added your's. [Ghorai] Ok. I will do .. But can you send me working version of these? At least comipled version for any kernel? snip Regards, Kishore -- 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
-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
2. non functional,
So can you check this version matching with your original code?
In that case I can add your Signed-off.
Thanks and Regards,
Vimal
On Thu, Jan 20, 2011 at 3:48 PM, Sukumar Ghorai s-gho...@ti.com wrote:
bch error correction (t=4 and t=8) for 512 bytes support added.
Tested in omap-3630 es-1.1 silicon.
Need to select the bch-ecc from board file. E.g.
arch/arm/mach-omap2/board-flash.c: board_nand_init()
board_nand_data.ecc_opt = OMAP_ECC_BCH4_CODE_HW
This patch has dependency on -
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg42658.html
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 126 ---
arch/arm/plat-omap/include/plat/gpmc.h |6 +-
drivers/mtd/nand/Makefile |1 +
drivers/mtd/nand/omap2.c | 119 --
drivers/mtd/nand/omap_bch_decoder.c| 393
5 files changed, 583 insertions(+), 62 deletions(-)
create mode 100644 drivers/mtd/nand/omap_bch_decoder.c
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 29c9732..91cfdca 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -48,6 +48,7 @@
#define GPMC_ECC_CONTROL 0x1f8
#define GPMC_ECC_SIZE_CONFIG 0x1fc
#define GPMC_ECC1_RESULT0x200
+#define GPMC_ECC_BCH_RESULT_0 0x240
#define GPMC_CS0_OFFSET0x60
#define GPMC_CS_SIZE 0x30
@@ -94,7 +95,6 @@ static struct resourcegpmc_mem_root;
static struct resource gpmc_cs_mem[GPMC_CS_NUM];
static DEFINE_SPINLOCK(gpmc_mem_lock);
static unsigned int gpmc_cs_map; /* flag for cs which are
initialized */
-static int gpmc_ecc_used = -EINVAL;/* cs using ecc engine */
static void __iomem *gpmc_base;
@@ -832,52 +832,77 @@ void omap3_gpmc_restore_context(void)
/**
* gpmc_enable_hwecc - enable hardware ecc functionality
+ * @ecc_type: ecc type e.g. Hamming, BCH
* @cs: chip select number
* @mode: read/write mode
* @dev_width: device bus width(1 for x16, 0 for x8)
* @ecc_size: bytes for which ECC will be generated
*/
-int gpmc_enable_hwecc(int cs, int mode, int dev_width, int ecc_size)
+int gpmc_enable_hwecc(int ecc_type, int cs, int mode,
+ int dev_width, int ecc_size)
{
- unsigned int val;
-
- /* check if ecc module is in used */
- if (gpmc_ecc_used != -EINVAL)
- return -EINVAL;
-
- gpmc_ecc_used = cs;
-
- /* clear ecc and enable bits */
- val = ((0x00018) | 0x0001);
- gpmc_write_reg(GPMC_ECC_CONTROL, val);
-
- /* program ecc and result sizes */
- val = ecc_size 1) - 1) 22) | (0x000F));
- gpmc_write_reg(GPMC_ECC_SIZE_CONFIG, val);
+ unsigned int bch_mod = 0, bch_wrapmode = 0, eccsize1 = 0,
eccsize0 = 0;
+ unsigned int ecc_conf_val = 0, ecc_size_conf_val = 0;
switch (mode) {
case GPMC_ECC_READ:
- gpmc_write_reg(GPMC_ECC_CONTROL, 0x101);
+ if (ecc_type == OMAP_ECC_BCH4_CODE_HW) {
+ eccsize1 = 0xD; eccsize0 = 0x48;
+ bch_mod = 0;
+ bch_wrapmode = 0x09;
+ } else if (ecc_type == OMAP_ECC_BCH8_CODE_HW) {
+ eccsize1 = 0x1A; eccsize0 = 0x18;
+ bch_mod = 1;
+ bch_wrapmode = 0x04;
+ } else
+ eccsize1 = ((ecc_size 1) - 1) 22;
break;
+
case GPMC_ECC_READSYN:
-gpmc_write_reg(GPMC_ECC_CONTROL, 0x100);
break;
+
case GPMC_ECC_WRITE:
- gpmc_write_reg(GPMC_ECC_CONTROL, 0x101);
+ if (ecc_type == OMAP_ECC_BCH4_CODE_HW) {
+ eccsize1 = 0x20; eccsize0 = 0x00;
+ bch_mod = 0;
+ bch_wrapmode = 0x06;
+ } else if (ecc_type == OMAP_ECC_BCH8_CODE_HW) {
+ eccsize1 = 0x20; eccsize0 = 0x00;
+ bch_mod = 1;
+ bch_wrapmode = 0x06;
+ } else
+ eccsize1 = ((ecc_size 1) - 1) 22;
break;
+
default
RE: Merging xloader, bootloader and boot environment variables partitions into a single partition on NAND
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Elvis Dowson Sent: Thursday, January 20, 2011 10:51 PM To: linux-omap Mailing List Subject: Merging xloader, bootloader and boot environment variables partitions into a single partition on NAND Hi, I was wondering what the merits and demerits are of having a single integrated xloader+bootloader+boot environment variables in a single partition in NAND, as opposed to having multiple partitions that hold xloader, bootloader and the uboot environment in separate partitions? [Ghorai] This the way we represent or arrange the nand/flash. Current design helps to update x-loader, u-boot, saveen or kernel in different partition(s) from user-space without remember the offset. Elvis Dowson -- 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: Issues with ADATA SD cards on OMAP?
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Steve Sakoman
Sent: Sunday, January 09, 2011 10:45 PM
To: Elvis Dowson
Cc: linux-omap Mailing List
Subject: Re: Issues with ADATA SD cards on OMAP?
On Sun, Jan 9, 2011 at 9:07 AM, Elvis Dowson elvis.dow...@mac.com wrote:
Hi Steve,
On Jan 9, 2011, at 9:00 PM, Steve Sakoman wrote:
mmcblk0: error -110 sending read/write command, response 0x900, card
status 0xe00
Error -110 is ETIMEOUT.
The card might be getting detected but not powering up, perhaps?
something to do with
voltage regulator setup or probably a bad mmc hardware port?
Not likely to be bad hardware since it fails the same way on multiple
Overo and Beagle boards.
And not likely to be a bad SD card, since the cards work perfectly on
my desktop and laptop.
I suspect something marginal in the mmc interface hw/config. If you
look at the schematics for most boards the mmc card is directly
connected to the OMAP for signal lines, and the twl4030 for power.
As such, I'm not surprised that these cards fail with every OMAP3
board I've tried.
I'm using a 2GB class 4 SanDisk microSD card with a custom beagle board,
and tried it with
android-2.6.32 kernel as well as mainline 2.6.37-rc7 kernel, it worked
fine.
Sure, I have tons of SanDisk cards that work perfectly (and always
have). It is the brand new, just out of the box Sandisk that fails.
[Ghorai]
We also experienced the same issue using 32GB SD card for omap3 and omap4.
And the problem is seen is that DTO value (in SYSCTL) is not current
in following function.
So add the following modification and please update the status.
And we will submit proper patch towards the same.
static void set_data_timeout(..){
...
cycle_ns = 10 / (clk_get_rate(host-fclk) / clkd);
timeout = timeout_ns / cycle_ns;
timeout += timeout_clks;
+ timeout *=2;
if (timeout) {
...
}
--
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 v7 4/7] omap3: nand: prefetch in irq mode support
[..snip...]
+ if (info-buf_len (info-buf_len bytes))
Meant to use logical AND here?
[Ghorai] thanks, you are right.
[..snip..]
+ init_completion(info-comp);
You can use INIT_COMPLETION to reset the completion variable.
Same change can be done in write below.
[..snip..]
s/methode/method
[Ghorai] yes. I will do this
[..snip..]
+ /* waiting for write to complete */
+ wait_for_completion(info-comp);
+ /* wait for data to flushed-out before reset the prefetch */
+ do {
+ ret = gpmc_read_status(GPMC_PREFETCH_COUNT);
+ } while (ret);
Please have a timeout for this while loop in case hardware does
not become ready. Also, consider using cpu_relax() inside the
tight loop.
[Ghorai] Thanks. I will send again.
--
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: OMAP NAND redux
-Original Message-
From: Charles Manning [mailto:mannin...@actrix.gen.nz]
Sent: Friday, December 17, 2010 3:31 AM
To: linux-omap@vger.kernel.org
Cc: Ghorai, Sukumar; Grazvydas Ignotas
Subject: OMAP NAND redux
Hello All
Over the last while I have been working on getting ubifs working on
omap3530
using 16-bit NAND with the latest 2.6.37 prefetch code. This is basically
a
tweaked Overo kernel.
Here is what I found:
After initial exploration I found that there were three problem:
* ECC bytes not being read correctly during sub-page reads.
* Disabling prefetch meant that the flash was not being read at all.
* NAND access seems to have slowed down significantly.
Both these boiled down to one root cause. After the prefetch changes,
nand-IO_ADDR_R is set to an address that only works within the context of
the prefetch code. It no longer works if prefetch is disabled. Execution
of:
static void omap_read_buf16(struct mtd_info *mtd, u_char *buf, int len)
{
struct nand_chip *nand = mtd-priv;
ioread16_rep(nand-IO_ADDR_R, buf, len / 2);
}
Even if prefetch is enabled, subpage reads that are not 32-bit aligned
call
the above function which means the ECC does not read correctly - resulting
in
ECC errors.
[Ghorai] please give a try with CONFIG_MTD_NAND_OMAP_HWECC enable;
i.e. NAND_ECC_HW; by this I did not see this issue
I managed to work around this by applying the following patch to force all
buffer reads to u32 alignment:
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -245,6 +245,18 @@ static void omap_read_buf_pref(struct mtd_info *mtd,
u_char *buf, int len)
int ret = 0;
u32 *p = (u32 *)buf;
+ /* u32 align the buffer and read */
+ /* NB: This assumes the buf ptr can be aligned *down* which is a
valid.
+* Assumption when dealing with ecc buffers etc.
+*/
+ u32 addr = (u32)p;
+
+ int diff = addr 3;
+ addr -= diff;
+ len += diff;
+ len = (len + 3) ~3;
+ p = (u32 *)addr;
+
/* take care of subpage reads */
if (len % 4) {
if (info-nand.options NAND_BUSWIDTH_16)
Yeah I know that is ugly, but it works!
Prefetch is enabled, dma is disabled. ECC is done in software.
[Ghorai] please give a try with CONFIG_MTD_NAND_OMAP_HWECC enable
OK, that gives me a working UBIFS, but I found something else...
NAND access has got way, way slower since 2.6.34.
I created a 2MB file foo then do the following:
sync; date; cp foo bar; sync; date
In 2.6.34 the time between the two dates was 3 seconds.
In 2.6.37 this now takes 14 seconds!
Now question time:
1) How well has the prefetch code been tested?
[Ghorai] yes, its enable by default even in 2.6.34 onwards
And many omap products using this.
2) Does it work with prefetch disabled?
[Ghorai] yes.
3) Has it been performance tested?
[Ghorai] yes. I did not remember the numbers.
4) What should the value in nand-IO_ADDR_R be?
[Ghorai] this could be the same as IO_ADDR_W
And you can refer Section in TRM: Global Memory Space Mapping
Thanks
Charles
--
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 v6 3/7] omap: gpmc: enable irq mode in gpmc
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Saturday, December 18, 2010 5:40 AM To: Ghorai, Sukumar Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org; linux-arm- ker...@lists.infradead.org Subject: Re: [PATCH v6 3/7] omap: gpmc: enable irq mode in gpmc * Sukumar Ghorai s-gho...@ti.com [101126 07:25]: add support the irq mode in GPMC. gpmc_init() function move after omap_init_irq() as it has dependecy on irq. Signed-off-by: Sukumar Ghorai s-gho...@ti.com --- arch/arm/mach-omap2/board-2430sdp.c|1 + arch/arm/mach-omap2/board-3430sdp.c|1 + arch/arm/mach-omap2/board-3630sdp.c|1 + arch/arm/mach-omap2/board-4430sdp.c|2 + arch/arm/mach-omap2/board-am3517evm.c |2 + arch/arm/mach-omap2/board-apollon.c|1 + arch/arm/mach-omap2/board-cm-t35.c |1 + arch/arm/mach-omap2/board-devkit8000.c |1 + arch/arm/mach-omap2/board-generic.c|2 + arch/arm/mach-omap2/board-h4.c |1 + arch/arm/mach-omap2/board-igep0020.c |1 + arch/arm/mach-omap2/board-ldp.c|1 + arch/arm/mach-omap2/board-n8x0.c |2 + arch/arm/mach-omap2/board-omap3beagle.c|1 + arch/arm/mach-omap2/board-omap3evm.c |2 + arch/arm/mach-omap2/board-omap3pandora.c |2 + arch/arm/mach-omap2/board-omap3stalker.c |1 + arch/arm/mach-omap2/board-omap3touchbook.c |1 + arch/arm/mach-omap2/board-omap4panda.c |2 + arch/arm/mach-omap2/board-overo.c |1 + arch/arm/mach-omap2/board-rx51.c |1 + arch/arm/mach-omap2/board-zoom2.c |2 + arch/arm/mach-omap2/board-zoom3.c |2 + arch/arm/mach-omap2/gpmc.c | 39 ++- arch/arm/mach-omap2/io.c |2 - arch/arm/plat-omap/include/plat/gpmc.h |4 +++ arch/arm/plat-omap/include/plat/irqs.h |9 +- 27 files changed, 81 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach- omap2/board-2430sdp.c index b527f8d..11c89dc 100644 --- a/arch/arm/mach-omap2/board-2430sdp.c +++ b/arch/arm/mach-omap2/board-2430sdp.c @@ -145,6 +145,7 @@ static void __init omap_2430sdp_init_irq(void) omap_board_config_size = ARRAY_SIZE(sdp2430_config); omap2_init_common_hw(NULL, NULL); omap_init_irq(); + gpmc_init(); omap_gpio_init(); } diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach- omap2/board-3430sdp.c index 4e3742c..a040165 100644 --- a/arch/arm/mach-omap2/board-3430sdp.c +++ b/arch/arm/mach-omap2/board-3430sdp.c @@ -328,6 +328,7 @@ static void __init omap_3430sdp_init_irq(void) omap3_pm_init_cpuidle(omap3_cpuidle_params_table); omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL); omap_init_irq(); + gpmc_init(); omap_gpio_init(); } ... The gpmc init should be done with subsys_initcall instead. [Ghorai] You suggested the same in previous v5; and I mentioned the issues [1] that - nand_init()called before subsys_initcall(gpmc_init); Let me know if I am missing anything again. [1] https://patchwork.kernel.org/patch/212452/ -- 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/7] omap3630: nand: fix device size to work in polled mode
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Saturday, December 18, 2010 5:34 AM To: Ghorai, Sukumar Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org; linux-arm- ker...@lists.infradead.org Subject: Re: [PATCH 1/7] omap3630: nand: fix device size to work in polled mode * Sukumar Ghorai s-gho...@ti.com [101126 07:25]: zoom3 and 3630-sdp having the x16 nand device. This patch configure gpmc as x16 and select the currect function in driver for polled mode (without prefetch enable) transfer. Signed-off-by: Sukumar Ghorai s-gho...@ti.com --- arch/arm/mach-omap2/board-flash.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/board-flash.c b/arch/arm/mach- omap2/board-flash.c index fd38c05..001c605 100644 --- a/arch/arm/mach-omap2/board-flash.c +++ b/arch/arm/mach-omap2/board-flash.c @@ -145,6 +145,9 @@ __init board_nand_init(struct mtd_partition *nand_parts, u8 nr_parts, u8 cs) board_nand_data.parts = nand_parts; board_nand_data.nr_parts= nr_parts; + if (cpu_is_omap3630()) + board_nand_data.devsize = 1; + gpmc_nand_init(board_nand_data); } #else I guess this is board specific for the size, not omap specific? [Ghorai] Agree, the NAND type (i.e. x8 NAND or x16 NAND) is a board specific, So I will change the definition of board_nand_init() to pass the devsize form board file. And I will submit the patch-series again. -- 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 v6 0/7] nand prefetch-irq support and ecc layout chanage
-Original Message- From: Charles Manning [mailto:mannin...@actrix.gen.nz] Sent: Monday, December 20, 2010 3:16 AM To: linux-...@lists.infradead.org Cc: Ghorai, Sukumar; linux-omap@vger.kernel.org; linux-arm- ker...@lists.infradead.org Subject: Re: [PATCH v6 0/7] nand prefetch-irq support and ecc layout chanage On Saturday 27 November 2010 04:34:30 Sukumar Ghorai wrote: The following set of patches applies on linux-2.6. The main motivations behind this patch series are - 1. support NAND I/O in irq mode. 2. support of different ECC schema. 3. also to make ecc layout as like in romcode ecc layout Why change the ECC layout? Be very careful when you change ECC layouts. This can break production systems. For example if people are running something earlier and then want to deliver a new kernel with 2.6.37 then their existing NAND file systems will no longer be readable. Changes to ECC should only be done for very good reasons and should be controlled with a Kconfig with the default being the existing ECC layout. [Ghorai] we are just adding few ecc-layout(s) and based on the request from different customer. The default ecc-layout is the old one for backward compatibility and selection of ecc-layput is exposed form board file. -- 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/7] omap3: nand: configurable transfer type per board
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Saturday, December 18, 2010 5:39 AM
To: Ghorai, Sukumar
Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org; linux-arm-
ker...@lists.infradead.org
Subject: Re: [PATCH 2/7] omap3: nand: configurable transfer type per board
* Sukumar Ghorai s-gho...@ti.com [101126 07:25]:
nand transfer type (sDMA, Polled, prefetch) can be select from board
file,
enabling all transfer type in driver, by default.
this helps in multi-omap build and to select different transfer type for
different board.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/plat-omap/include/plat/nand.h |7 +++
drivers/mtd/nand/Kconfig | 17 --
drivers/mtd/nand/omap2.c | 92 +++--
--
3 files changed, 40 insertions(+), 76 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/nand.h b/arch/arm/plat-
omap/include/plat/nand.h
index 6562cd0..78c0bdb 100644
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -10,6 +10,12 @@
#include linux/mtd/partitions.h
+enum nand_io {
+ NAND_OMAP_PREFETCH_POLLED = 0, /* prefetch polled mode, default
*/
+ NAND_OMAP_POLLED, /* polled mode, without prefetch */
+ NAND_OMAP_PREFETCH_DMA /* prefetch enabled sDMA mode */
+};
+
struct omap_nand_platform_data {
unsigned intoptions;
int cs;
@@ -20,6 +26,7 @@ struct omap_nand_platform_data {
int (*nand_setup)(void);
int (*dev_ready)(struct omap_nand_platform_data *);
int dma_channel;
+ enum nand_ioxfer_type;
unsigned long phys_base;
int devsize;
};
So maybe the devsize in patch 1/7 should be handled with this too?
[Ghorai] patch 1/7 [1] is to select the NAND type i.e. x8 or x16 NAND;
So I am keeping as separate patch. And let me know if I am missing anything.
[1] https://patchwork.kernel.org/patch/359092/
--
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 v6 0/7] nand prefetch-irq support and ecc layout chanage
Hello Grazvydas Charles, Would you please check this series in you setup and please update the status or any issue you observe? Regards, Ghorai -Original Message- From: Ghorai, Sukumar Sent: Friday, November 26, 2010 9:05 PM To: linux-omap@vger.kernel.org Cc: linux-...@lists.infradead.org; linux-arm-ker...@lists.infradead.org; Ghorai, Sukumar Subject: [PATCH v6 0/7] nand prefetch-irq support and ecc layout chanage The following set of patches applies on linux-2.6. The main motivations behind this patch series are - 1. support NAND I/O in irq mode. 2. support of different ECC schema. 3. also to make ecc layout as like in romcode ecc layout v6: configurable transfer type from board file; #define irq number used for nand-irq v5: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg35860.html This address the input as to support the irq_chained in GPMC. And resend of http://www.mail-archive.com/linux-omap@vger.kernel.org/msg35848.html v4: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg34882.html and resend of http://www.mail-archive.com/linux-omap@vger.kernel.org/msg32689.html v3: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg32071.html Rebase on latest codebase and previous patch(posted). http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31963.html v2: Rebase on latest codebase and previous patch(posted). http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31471.html v1: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg2.html Sukumar Ghorai (7): omap3630: nand: fix device size to work in polled mode omap3: nand: configurable transfer type per board omap: gpmc: enable irq mode in gpmc omap3: nand: prefetch in irq mode support omap3: nand: configurable fifo threshold to gain the throughput omap: nand: ecc layout select from board file omap: nand: making ecc layout as compatible with romcode ecc arch/arm/mach-omap2/board-2430sdp.c|1 + arch/arm/mach-omap2/board-3430sdp.c|1 + arch/arm/mach-omap2/board-3630sdp.c|1 + arch/arm/mach-omap2/board-4430sdp.c|2 + arch/arm/mach-omap2/board-am3517evm.c |2 + arch/arm/mach-omap2/board-apollon.c|1 + arch/arm/mach-omap2/board-cm-t35.c |1 + arch/arm/mach-omap2/board-devkit8000.c |1 + arch/arm/mach-omap2/board-flash.c |7 + arch/arm/mach-omap2/board-generic.c|2 + arch/arm/mach-omap2/board-h4.c |1 + arch/arm/mach-omap2/board-igep0020.c |1 + arch/arm/mach-omap2/board-ldp.c|1 + arch/arm/mach-omap2/board-n8x0.c |2 + arch/arm/mach-omap2/board-omap3beagle.c|1 + arch/arm/mach-omap2/board-omap3evm.c |2 + arch/arm/mach-omap2/board-omap3pandora.c |2 + arch/arm/mach-omap2/board-omap3stalker.c |1 + arch/arm/mach-omap2/board-omap3touchbook.c |1 + arch/arm/mach-omap2/board-omap4panda.c |2 + arch/arm/mach-omap2/board-overo.c |1 + arch/arm/mach-omap2/board-rx51.c |1 + arch/arm/mach-omap2/board-zoom2.c |2 + arch/arm/mach-omap2/board-zoom3.c |2 + arch/arm/mach-omap2/gpmc.c | 50 - arch/arm/mach-omap2/io.c |2 - arch/arm/plat-omap/include/plat/gpmc.h | 16 ++- arch/arm/plat-omap/include/plat/irqs.h |9 +- arch/arm/plat-omap/include/plat/nand.h | 11 + drivers/mtd/nand/Kconfig | 17 -- drivers/mtd/nand/omap2.c | 314 ++- - 31 files changed, 364 insertions(+), 94 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
RE: No more software ECC in omap2.c NAND driver. Why?
[..snip..]
% mkfs.jffs2 --little-endian --no-cleanmarkers --pad 2048 --pagesize 2048
--eraseblock 131072 -d /tmp/tmp.h9dKGpcNFw -D root.devices -o root.jffs2
nand write.i ${loadaddr} 0x00c0 0x200
nand write.i ${loadaddr} 0x0420 0x200
[Ghorai] why you writing in two places?
Redundant images.
Following that, the board is updated, from Linux, using 'flash_eraseall
-
q'
and 'nandwrite -p -q' on all partitions, except that containing MLO.
[Ghorai]
1. can you send the exact comment you used to write in nand? Which
partition?
flash_eraseall -q /dev/mtd7
nandwrite -p -q /dev/mtd7 root.jffs2
flash_eraseal -q /dev/mtd9
nandwrite -p -q /dev/mtd9 root.jffs2
2. What is the last kernel you used and was working perfectly?
v2.6.32_OMAPPSP_03.00.01.06.patch1
[Ghorai] I followed the steps you mentioned. Also I used the following command
to mount the jffs2 FS and working fine.
mount -t jffs2 /dev/mtdblock3 /mnt/nand
I have tested in zoom3 -
NAND device: Manufacturer ID: 0x2c, Chip ID: 0xbc (Micron NAND 512MiB 1,8V
16-bit).
And using the latest kernel -
Uncompressing Linux... done, booting the kernel.
[0.00] Linux version 2.6.37-rc3-00102-gea49b16 (a0393...@omapldc12)
(gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202) ) #20 SMP Wed Nov 24 17:27:21
IST 2010
Would you please share your latest log?
--
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: No more software ECC in omap2.c NAND driver. Why?
-Original Message- From: Grant Erickson [mailto:maratho...@gmail.com] Sent: Monday, November 22, 2010 11:39 AM To: Charles Manning Cc: linux-omap@vger.kernel.org; Grazvydas Ignotas; Ghorai, Sukumar Subject: Re: No more software ECC in omap2.c NAND driver. Why? On 11/21/10 1:01 PM, Charles Manning wrote: Just recompiling with the CONFIG_MTD_NAND_OMAP_HWECC define commented out did not result in a working system. I suspect there is more tto the problem than this. FWIW, I had the exact same issues with my Mistral AM37x EVM board. I not only had to remove/deassert CONFIG_MTD_NAND_OMAP_HWECC, but also had to roll back nand_base.c and nand_bbt.c back to their 2.6.32 versions (later ones between .32 and .35 might have worked but I didn't bother trying) to be able to read, error-free and correctly, NAND that was erased and written with a .32-era kernel. [Ghorai] are you trying again? How do you flush the FS (form u-boot or from kernel, nandwrite)? And let me know the test you are doing, to know the steps to reproduce in my platform - zoom/sdp. Best, Grant Erickson -- 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: No more software ECC in omap2.c NAND driver. Why?
[..snip..]
The board (Mistral AM37x) NAND (Micron 256 MiB) was originally
bootstrapped
over SD/MMC from u-boot using the following script:
[Ghorai] let me know the nand details - x8/x16, small/big page?
[..snip..]
nandecc sw
[..snip..]
fatload mmc 0 ${loadaddr} root.jff
[Ghorai] How you create the root.jff
mkfs.jffs2 --output=root.jffs2 --root=.. --pagesize=?? --eraseblock=?? -n
nand write.i ${loadaddr} 0x00c0 0x200
nand write.i ${loadaddr} 0x0420 0x200
[Ghorai] why you writing in two places?
Following that, the board is updated, from Linux, using 'flash_eraseall -
q'
and 'nandwrite -p -q' on all partitions, except that containing MLO.
[Ghorai]
1. can you send the exact comment you used to write in nand? Which partition?
2. What is the last kernel you used and was working perfectly?
3. If possible revert the following patches and let me know the status?
f450d86790ebf72ac93c7ea5addd6fa278aae64c..2430f9df61e2ea47ea468dfe22b7e2db97111fb4
2c01946c6b9ebaa5a89710bc42ca224a7f52f227
948d38e799f0ab87cf8ed9113fcdaaee61acf321
--
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: No more software ECC in omap2.c NAND driver. Why?
-Original Message- From: Grazvydas Ignotas [mailto:nota...@gmail.com] Sent: Friday, November 19, 2010 4:06 PM To: Ghorai, Sukumar Cc: Charles Manning; linux-omap@vger.kernel.org Subject: Re: No more software ECC in omap2.c NAND driver. Why? On Thu, Nov 18, 2010 at 4:33 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 Charles Manning Sent: Thursday, November 18, 2010 6:36 AM To: linux-omap@vger.kernel.org Subject: No more software ECC in omap2.c NAND driver. Why? Between 2.6.35 and 2.6.36 there have need quite a few changes in the NAND driver, including a change from software to hardware ECC. The new code has hardware ECC forced on by: #define CONFIG_MTD_NAND_OMAP_HWECC I am surprised that this was done. Surely this should have been a Kconfig option to select either sw ECC or hw ECC? Does moving to hardware ECC to the exclusion of software ECC reduce functionality? [Ghorai] This is wrongly added by me, during last few patches. So I have send the fix as you mentioned too as. [PATCH] omap: nand: remove hardware ECC as default And please let me know still if it has any issue. For me it makes normal sw ECC page IO work, but for subpages to work I have to disable the prefetch option. [Ghorai] I was thinking that I have modularize some GPMC call and did not do anything prefetch related modificaiton. I will check this too. And I am re-working on the patches for the different ecc schema including s/w, h/w or different, to pass it form board file. Does the new hwecc scheme still support sub-page writes or does it only provide full page writes? If sub-page writes are lost then this has a ripple effect in breaking the way some UBI stuff works. [Ghorai] 1. do you think this sub-page read/write support was there before, say in 2.6.35? And breaks in 2.6.36? It certainly was there for sw ECC as we've been using UBI from 2.6.27 to 2.6.35 just fine. [Ghorai] uoderstand. 2. In that case would you please let know what are the size(s) used for sub-page/read write? 512 bytes. [Ghorai] I feel still its support in 2.6.36 too. Let me check too. -- 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: No more software ECC in omap2.c NAND driver. Why?
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Charles Manning Sent: Thursday, November 18, 2010 6:36 AM To: linux-omap@vger.kernel.org Subject: No more software ECC in omap2.c NAND driver. Why? Between 2.6.35 and 2.6.36 there have need quite a few changes in the NAND driver, including a change from software to hardware ECC. The new code has hardware ECC forced on by: #define CONFIG_MTD_NAND_OMAP_HWECC I am surprised that this was done. Surely this should have been a Kconfig option to select either sw ECC or hw ECC? Does moving to hardware ECC to the exclusion of software ECC reduce functionality? [Ghorai] This is wrongly added by me, during last few patches. So I have send the fix as you mentioned too as. [PATCH] omap: nand: remove hardware ECC as default And please let me know still if it has any issue. And I am re-working on the patches for the different ecc schema including s/w, h/w or different, to pass it form board file. Does the new hwecc scheme still support sub-page writes or does it only provide full page writes? If sub-page writes are lost then this has a ripple effect in breaking the way some UBI stuff works. [Ghorai] 1. do you think this sub-page read/write support was there before, say in 2.6.35? And breaks in 2.6.36? 2. In that case would you please let know what are the size(s) used for sub-page/read write? -- Charles -- 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 v5 1/5] omap gpmc: enable irq mode in gpmc
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Saturday, November 06, 2010 2:43 AM To: Ghorai, Sukumar Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org; linux-arm- ker...@lists.infradead.org Subject: Re: [PATCH v5 1/5] omap gpmc: enable irq mode in gpmc * Ghorai, Sukumar s-gho...@ti.com [101028 07:02]: Tony, -Original Message- From: Ghorai, Sukumar Sent: Wednesday, September 29, 2010 12:08 PM To: 'Tony Lindgren' Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org; linux- arm- ker...@lists.infradead.org Subject: RE: [PATCH v5 1/5] omap gpmc: enable irq mode in gpmc [..snip..] diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach- omap2/board-3430sdp.c index 67b95b5..549cd62 100644 --- a/arch/arm/mach-omap2/board-3430sdp.c +++ b/arch/arm/mach-omap2/board-3430sdp.c @@ -328,6 +328,7 @@ static void __init omap_3430sdp_init_irq(void) omap3_pm_init_cpuidle(omap3_cpuidle_params_table); omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL); omap_init_irq(); + gpmc_init(); omap_gpio_init(); } ... You can avoid adding gpmc_init() by making it a subsys_initcall(). Just make sure you return early from it with if (!cpu_class_is_omap2()). [Ghorai] will do [Ghorai] I was trying this and no success, as nand_init() get called before subsys_initcall(gpmc_init); 126 MACHINE_START(OMAP_ZOOM3, OMAP Zoom3 board) .. 130 .init_irq = omap_zoom_init_irq, 131 .init_machine = omap_zoom_init, .. Step-(n): kernel_init() - customize_machine() - omap_zoom_init() - gpmc_nand_init() - which call gpmc functions, that's crashing, as gpmc is not initialized. Step-(n+1): Followed by subsys_initcall(gpmc_init) So I will incorporate the other input and will re-submit. [..snip..] I don't see why you could not make gpmc_nand_init happen later? Also, some of these calls can be moved to omap2_init_common_hw()? [Ghorai] is it that gpmc_nand_init() better to call inside omap2_init_common_hw()? 27 files used the omap2_init_common_hw(); including omap4, and 15 files used the gpmc_nand_init directly or via board_nand_init() Just thinking how to put gpmc_nand_init() inside omap2_init_common_hw(), when board may not have the nand. -- 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 RESEND v5 4/5] omap: nand: ecc layout select from board file
-Original Message- From: Grazvydas Ignotas [mailto:nota...@gmail.com] Sent: Thursday, November 04, 2010 3:22 PM To: Ghorai, Sukumar Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org; linux-arm- ker...@lists.infradead.org; artem.bityuts...@nokia.com; Vimal Singh; Tony Lindgren Subject: Re: [PATCH RESEND v5 4/5] omap: nand: ecc layout select from board file On Thu, Nov 4, 2010 at 3:02 AM, Ghorai, Sukumar s-gho...@ti.com wrote: -Original Message- From: Grazvydas Ignotas [mailto:nota...@gmail.com] Sent: Wednesday, November 03, 2010 6:33 PM To: Ghorai, Sukumar Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org; linux- arm- ker...@lists.infradead.org; Vimal Singh; artem.bityuts...@nokia.com Subject: Re: [PATCH RESEND v5 4/5] omap: nand: ecc layout select from board file On Mon, Sep 27, 2010 at 5:11 PM, Sukumar Ghorai s-gho...@ti.com wrote: This patch makes it possible to select sw or hw (different layout options) ecc scheme supported by omap nand driver. And hw ecc layout selected for sdp and zoom boards, by default. Signed-off-by: Vimal Singh vimalsi...@ti.com Signed-off-by: Sukumar Ghorai s-gho...@ti.com Any news on this? Commit 2c01946c accidentally (?) enabled hardware ECC and now my board is broken, as the driver always used sw ecc and my NAND partitions are formatted accordingly. We should at least switch the default back to sw ecc, don't you think? [Ghorai] 1. which board you are working. 2. and the default layout is the same as previous + board_nand_data.ecc_opt = OMAP_ECC_HAMMING_CODE_DIFF_LAYOUT; OMAP3 pandora. What I wanted to say is that current mainline code has hw ECC forced which is wrong for some boards, and this patch did not make into last merge window, so NAND is broken. It would be good to take this patch out of larger series you sent earlier and resend as a fix for -rc1, so that NAND works on 2.6.37. It's not too large and should probably be ok for -rc2. [Ghorai] There is an additional patch I will send (with this series by next week) to select the ECC from board file, such that different board file can select the different ECC method. 1. This is mainly for OMAP3630 onwards and has been aligned with many customers to use the hw ecc. 2. I did not understand how it's not working, would you please explain again? If you apply the series then it's storing the same ecc value in different location and generated from h/w module. File: arch/arm/mach-omap2/board-flash.c board_nand_data.ecc_opt = OMAP_ECC_HAMMING_CODE_DIFF_LAYOUT; change to - board_nand_data.ecc_opt = OMAP_ECC_HAMMING_CODE_HW; - to switch back to s/w generated ECC stores at end of the spare area. 3. This patches are not upstream yet; send me the git-link you referring that these patches are available in 2.6.37? -- 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 RESEND v5 4/5] omap: nand: ecc layout select from board file
-Original Message- From: Grazvydas Ignotas [mailto:nota...@gmail.com] Sent: Thursday, November 04, 2010 4:27 PM To: Ghorai, Sukumar Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org; linux-arm- ker...@lists.infradead.org; artem.bityuts...@nokia.com; Vimal Singh; Tony Lindgren Subject: Re: [PATCH RESEND v5 4/5] omap: nand: ecc layout select from board file On Thu, Nov 4, 2010 at 12:15 PM, Ghorai, Sukumar s-gho...@ti.com wrote: -Original Message- From: Grazvydas Ignotas [mailto:nota...@gmail.com] OMAP3 pandora. What I wanted to say is that current mainline code has hw ECC forced which is wrong for some boards, and this patch did not make into last merge window, so NAND is broken. It would be good to take this patch out of larger series you sent earlier and resend as a fix for -rc1, so that NAND works on 2.6.37. It's not too large and should probably be ok for -rc2. [Ghorai] There is an additional patch I will send (with this series by next week) to select the ECC from board file, such that different board file can select the different ECC method. 1. This is mainly for OMAP3630 onwards and has been aligned with many customers to use the hw ecc. 2. I did not understand how it's not working, would you please explain again? If you apply the series then it's storing the same ecc value in different location and generated from h/w module. It most likely works (need to test more), I was just complaining it's not upstream and sw ecc is broken on both 2.6.36 and 2.6.37. [Ghorai] In 2.6.36, it's a s/w ecc by default and working in all platforms like - omap3430 SDP, zoom2, 3630SDP, ZOOM3. So please explain more when you found that - sw ecc is broken on both 2.6.36 3. This patches are not upstream yet; send me the git-link you referring that these patches are available in 2.6.37? Correct, they are not upstream, so that's why suggest sending smaller fix patch for 2.6.37-rc2, so that sw ecc works on 2.6.37. -- 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 RESEND v5 4/5] omap: nand: ecc layout select from board file
-Original Message- From: Grazvydas Ignotas [mailto:nota...@gmail.com] Sent: Thursday, November 04, 2010 4:42 PM To: Ghorai, Sukumar Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org; linux-arm- ker...@lists.infradead.org; artem.bityuts...@nokia.com; Vimal Singh; Tony Lindgren Subject: Re: [PATCH RESEND v5 4/5] omap: nand: ecc layout select from board file [Ghorai] In 2.6.36, it's a s/w ecc by default and working in all platforms like - omap3430 SDP, zoom2, 3630SDP, ZOOM3. So please explain more when you found that - sw ecc is broken on both 2.6.36 It doesn't for me, see http://git.kernel.org/?p=linux/kernel/git/torvalds/linux- 2.6.git;a=blob;f=drivers/mtd/nand/omap2.c;h=513e0a76a4a73866d52bba8151e435 56a3b30a54;hb=f6f94e2ab1b33f0082ac22d71f66385a60d8157f This is omap NAND driver at v2.6.36 tag, and it has CONFIG_MTD_NAND_OMAP_HWECC forced. [Ghorai] This is the same old code since log. And this portion of code not touched for 2.6.36. And please let me know what kind of problem you are facing when you using 2.6.36; also let me know how to reproduce, I can check in my platform too. -- 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 RESEND v5 4/5] omap: nand: ecc layout select from board file
-Original Message- From: Grazvydas Ignotas [mailto:nota...@gmail.com] Sent: Thursday, November 04, 2010 5:03 PM To: Ghorai, Sukumar Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org; linux-arm- ker...@lists.infradead.org; artem.bityuts...@nokia.com; Vimal Singh; Tony Lindgren Subject: Re: [PATCH RESEND v5 4/5] omap: nand: ecc layout select from board file On Thu, Nov 4, 2010 at 1:15 PM, Ghorai, Sukumar s-gho...@ti.com wrote: -Original Message- From: Grazvydas Ignotas [mailto:nota...@gmail.com] Sent: Thursday, November 04, 2010 4:42 PM To: Ghorai, Sukumar Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org; linux- arm- ker...@lists.infradead.org; artem.bityuts...@nokia.com; Vimal Singh; Tony Lindgren Subject: Re: [PATCH RESEND v5 4/5] omap: nand: ecc layout select from board file [Ghorai] In 2.6.36, it's a s/w ecc by default and working in all platforms like - omap3430 SDP, zoom2, 3630SDP, ZOOM3. So please explain more when you found that - sw ecc is broken on both 2.6.36 It doesn't for me, see http://git.kernel.org/?p=linux/kernel/git/torvalds/linux- 2.6.git;a=blob;f=drivers/mtd/nand/omap2.c;h=513e0a76a4a73866d52bba8151e435 56a3b30a54;hb=f6f94e2ab1b33f0082ac22d71f66385a60d8157f This is omap NAND driver at v2.6.36 tag, and it has CONFIG_MTD_NAND_OMAP_HWECC forced. [Ghorai] This is the same old code since log. And this portion of code not touched for 2.6.36. And please let me know what kind of problem you are facing when you using 2.6.36; also let me know how to reproduce, I can check in my platform too. It has changed in 2.5.36, take a look how it was in 2.6.35, when it worked for me: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux- 2.6.git;a=blob;f=drivers/mtd/nand/omap2.c;h=ee87325c7712a84bbc683f9301 4c9901f337;hb=9fe6206f400646a2322096b56c59891d530e8d51 notice how 2.5.36 has CONFIG_MTD_NAND_OMAP_HWECC defined and 2.6.35 doesn't. The test case is simple: format and use NAND on 2.6.35 or earlier, works fine. upgrade to 2.6.36 or 2.6.37-rc1 and try to mount the same NAND partition - lots of ECC errors. [Ghorai] I tested this and working fine in zoom3. And as you mentioned there may be an issue we need to identify, So remove this #define form 2.6.36 and let me know the test result. -- 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 RESEND v5 4/5] omap: nand: ecc layout select from board file
-Original Message- From: Grazvydas Ignotas [mailto:nota...@gmail.com] Sent: Wednesday, November 03, 2010 6:33 PM To: Ghorai, Sukumar Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org; linux-arm- ker...@lists.infradead.org; Vimal Singh; artem.bityuts...@nokia.com Subject: Re: [PATCH RESEND v5 4/5] omap: nand: ecc layout select from board file On Mon, Sep 27, 2010 at 5:11 PM, Sukumar Ghorai s-gho...@ti.com wrote: This patch makes it possible to select sw or hw (different layout options) ecc scheme supported by omap nand driver. And hw ecc layout selected for sdp and zoom boards, by default. Signed-off-by: Vimal Singh vimalsi...@ti.com Signed-off-by: Sukumar Ghorai s-gho...@ti.com Any news on this? Commit 2c01946c accidentally (?) enabled hardware ECC and now my board is broken, as the driver always used sw ecc and my NAND partitions are formatted accordingly. We should at least switch the default back to sw ecc, don't you think? [Ghorai] 1. which board you are working. 2. and the default layout is the same as previous + board_nand_data.ecc_opt = OMAP_ECC_HAMMING_CODE_DIFF_LAYOUT; -- 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 1/5] omap gpmc: enable irq mode in gpmc
Tony, -Original Message- From: Ghorai, Sukumar Sent: Wednesday, September 29, 2010 12:08 PM To: 'Tony Lindgren' Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org; linux-arm- ker...@lists.infradead.org Subject: RE: [PATCH v5 1/5] omap gpmc: enable irq mode in gpmc [..snip..] diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach- omap2/board-3430sdp.c index 67b95b5..549cd62 100644 --- a/arch/arm/mach-omap2/board-3430sdp.c +++ b/arch/arm/mach-omap2/board-3430sdp.c @@ -328,6 +328,7 @@ static void __init omap_3430sdp_init_irq(void) omap3_pm_init_cpuidle(omap3_cpuidle_params_table); omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL); omap_init_irq(); + gpmc_init(); omap_gpio_init(); } ... You can avoid adding gpmc_init() by making it a subsys_initcall(). Just make sure you return early from it with if (!cpu_class_is_omap2()). [Ghorai] will do [Ghorai] I was trying this and no success, as nand_init() get called before subsys_initcall(gpmc_init); 126 MACHINE_START(OMAP_ZOOM3, OMAP Zoom3 board) .. 130 .init_irq = omap_zoom_init_irq, 131 .init_machine = omap_zoom_init, .. Step-(n): kernel_init() - customize_machine() - omap_zoom_init() - gpmc_nand_init() - which call gpmc functions, that's crashing, as gpmc is not initialized. Step-(n+1): Followed by subsys_initcall(gpmc_init) So I will incorporate the other input and will re-submit. [..snip..] -- 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
-Original Message- From: Vimal Singh [mailto:vimal.neww...@gmail.com] Sent: Thursday, October 07, 2010 11:02 PM To: Ghorai, Sukumar Cc: linux-...@lists.infradead.org; linux-omap@vger.kernel.org Subject: 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'. [Ghorai] in that case how other layout is working? Say storing the ecc at end of the spare area is working. 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. [Ghorai] you can see following two line in _probe() function info-nand.IO_ADDR_R = ioremap(info-phys_base, NAND_IO_SIZE); info-nand.IO_ADDR_W = info-nand.IO_ADDR_R; 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. [Ghorai] I mentioned read request does not come to driver. [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: Issue : jffs2 and ecc layout
-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
Code:
178 static struct nand_ecclayout hw_x16_romcode_oob_64 = {
179 .eccbytes = 12,
180 .eccpos = {
181 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13
182 },
183 .oobfree = {
184 {.offset = 14,
185 .length = 50}
186 }
187 };
1188 info-nand.ecc.layout = hw_x16_romcode_oob_64;
[Ghorai]
Does anyone using similar layout for Jffs2? i.e. ECC store at beginning of the
spare area?
Regards,
Ghorai
--
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] omap: Keep nwires for omap1 and 2420 MMC controller (Re: [PATCH] omap mmc: extended to pass host capabilities from board file)
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Friday, October 01, 2010 12:08 AM
To: Ghorai, Sukumar
Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org
Subject: [PATCH] omap: Keep nwires for omap1 and 2420 MMC controller (Re:
[PATCH] omap mmc: extended to pass host capabilities from board file)
* Tony Lindgren t...@atomide.com [100923 16:00]:
* Sukumar Ghorai s-gho...@ti.com [100915 07:41]:
wires variable is renamed, extended and this single variable to be
used to
pass the platform capabilities, e.g DDR mode. Also removed the
hardcoded
value was using as bus-width.
This looks like a nice clean-up, I'll queue this via the omap
patches.
And of course this patch breaks all of mach-omap1 and omap2420.
Sukumar, your patch modified also drivers/mmc/host/omap.c and board-n8x0.c
to use caps instead of nwires. When you do things like that you absolutely
_must_test_your_changes_ before sending out any patches.
Planning on merging the following fix.
Tony
From: Tony Lindgren t...@atomide.com
Date: Thu, 30 Sep 2010 10:25:46 -0700
Subject: [PATCH] Subject: [PATCH] omap: Keep nwires for omap1 and 2420 MMC
controller
A patch from Sukumar Ghorai s-gho...@ti.com changed the
nwires to use caps instead. However, nwires is still
needed for the earlier controller.
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-
n8x0.c
index abd7e77..6bd9d9a 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -488,7 +488,7 @@ static struct omap_mmc_platform_data mmc1_data = {
.max_freq = 2400,
.dma_mask = 0x,
.slots[0] = {
- .caps = MMC_CAP_4_BIT_DATA,
+ .wires = 4,
.set_power = n8x0_mmc_set_power,
.set_bus_mode = n8x0_mmc_set_bus_mode,
.get_cover_state= n8x0_mmc_get_cover_state,
diff --git a/arch/arm/plat-omap/include/plat/mmc.h b/arch/arm/plat-
omap/include/plat/mmc.h
index 4f819fc..bc85010 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -73,9 +73,16 @@ struct omap_mmc_platform_data {
struct omap_mmc_slot_data {
- /* 4/8 wires and any additional host capabilities
- * need to OR'd all capabilities (ref. linux/mmc/host.h) */
- u32 caps;
+ /*
+ * 4/8 wires and any additional host capabilities
+ * need to OR'd all capabilities (ref. linux/mmc/host.h)
+ */
+#if defined(CONFIG_ARCH_OMAP1) || defined(CONFIG_ARCH_OMAP2420)
+ u8 wires; /* Used for the MMC driver on omap1 and 2420 */
+#endif
+#ifdef CONFIG_ARCH_OMAP2PLUS
+ u32 caps; /* Used for the MMC driver on 2430 and later */
+#endif
/*
* nomux means standard muxing is wrong on this board, and
diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index a9d62cf..d98ddcf 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -1317,7 +1317,7 @@ static int __init mmc_omap_new_slot(struct
mmc_omap_host *host, int id)
host-slots[id] = slot;
mmc-caps = 0;
- if (host-pdata-slots[id].caps MMC_CAP_8_BIT_DATA)
+ if (host-pdata-slots[id].wires = 4)
mmc-caps |= MMC_CAP_4_BIT_DATA;
mmc-ops = mmc_omap_ops;
[Ghorai] thanks.. I am agreeing with you;
Acked-by: Sukumar Ghorai s-gho...@ti.com
--
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 2/5] omap3: nand: prefetch in irq mode support
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Wednesday, September 29, 2010 4:00 AM To: Ghorai, Sukumar Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org; linux-arm- ker...@lists.infradead.org; Vimal Singh Subject: Re: [PATCH v5 2/5] omap3: nand: prefetch in irq mode support * Sukumar Ghorai s-gho...@ti.com [100927 06:30]: This patch enable prefetch-irq mode for NAND. --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -112,6 +112,9 @@ config MTD_NAND_OMAP_PREFETCH help The NAND device can be accessed for Read/Write using GPMC PREFETCH engine to improve the performance. +GPMC PREFETCH can be configured eigther in MPU interrupt mode or in DMA +interrupt mode. If not selected any of them prefetch will be used in +polling mode. config MTD_NAND_OMAP_PREFETCH_DMA depends on MTD_NAND_OMAP_PREFETCH @@ -120,7 +123,16 @@ config MTD_NAND_OMAP_PREFETCH_DMA help The GPMC PREFETCH engine can be configured eigther in MPU interrupt mode or in DMA interrupt mode. -Say y for DMA mode or MPU mode will be used +Say y for DMA mode + +config MTD_NAND_OMAP_PREFETCH_IRQ + depends on MTD_NAND_OMAP_PREFETCH !MTD_NAND_OMAP_PREFETCH_DMA + bool IRQ mode + default n + help +The GPMC PREFETCH engine can be configured eigther in MPU interrupt mode +or in DMA interrupt mode. +Say y for IRQ mode config MTD_NAND_IDS tristate The configuration to use the prefetch IRQ should be passed in the platform_data from the board-*.c files. What if you want to to boot a distro kernel on omap2, 3 and 4 and only some of the boards can use the prefetch interrupt? [Ghorai] thanks.. we will provide the interface to select the io mode and ecc mode from board file. Tony -- 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 1/5] omap gpmc: enable irq mode in gpmc
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Wednesday, September 29, 2010 3:57 AM
To: Ghorai, Sukumar
Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org; linux-arm-
ker...@lists.infradead.org
Subject: Re: [PATCH v5 1/5] omap gpmc: enable irq mode in gpmc
* Sukumar Ghorai s-gho...@ti.com [100927 06:30]:
add support the irq mode in GPMC.
gpmc_init() function move after omap_init_irq() as it has dependecy on
irq.
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -144,6 +144,7 @@ static void __init omap_2430sdp_init_irq(void)
omap_board_config_size = ARRAY_SIZE(sdp2430_config);
omap2_init_common_hw(NULL, NULL);
omap_init_irq();
+ gpmc_init();
omap_gpio_init();
}
diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-
omap2/board-3430sdp.c
index 67b95b5..549cd62 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -328,6 +328,7 @@ static void __init omap_3430sdp_init_irq(void)
omap3_pm_init_cpuidle(omap3_cpuidle_params_table);
omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL);
omap_init_irq();
+ gpmc_init();
omap_gpio_init();
}
...
You can avoid adding gpmc_init() by making it a subsys_initcall().
Just make sure you return early from it with if (!cpu_class_is_omap2()).
[Ghorai] will do
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -713,6 +721,31 @@ void __init gpmc_init(void)
l |= (0x02 3) | (1 0);
gpmc_write_reg(GPMC_SYSCONFIG, l);
gpmc_mem_init();
+
+ /* initalize the irq_chained */
+ irq = OMAP_GPMC_IRQ_BASE;
+ for (cs = 0; cs GPMC_CS_NUM; cs++) {
+ set_irq_handler(irq, handle_simple_irq);
+ set_irq_flags(irq, IRQF_VALID);
+ irq++;
+ }
+
+ if (request_irq(20, gpmc_handle_irq, IRQF_SHARED, gpmc,
gpmc_base))
+ printk(KERN_ERR gpmc: irq-%d could not claim: err %d\n,
+ INT_34XX_GPMC_IRQ, irq);
+}
Hmm, this does not look right.. Shouldn't you call
set_irq_chained_handler()
somewhere too?
[Ghorai] its not use, as multi-lebel irq is not there.
Also, are you sure the interrupt is 20 for all of mach-
omap2?
It should be added to the irqs.h files.
[Ghorai] it's added in irqs.h, and will remove the hard coded value. Last
minute mistake.
+static irqreturn_t gpmc_handle_irq(int irq, void *dev)
+{
+ u8 cs;
+
+ if (irq != INT_34XX_GPMC_IRQ)
+ return IRQ_HANDLED;
+ /* check cs to invoke the irq */
+ cs = ((gpmc_read_reg(GPMC_PREFETCH_CONFIG1)) CS_NUM_SHIFT) 0x7;
+ generic_handle_irq(OMAP_GPMC_IRQ_BASE+cs);
+
+ return IRQ_HANDLED;
}
Doesn't doing OMAP_GPMC_IRQ_BASE + cs overlap with some other irq?
[Ghorai] will check the boundary condition too -
if(OMAP_GPMC_IRQ_BASE + cs = OMAP_GPMC_IRQ_END)
And will re-submit.
Regards,
Tony
--
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 : 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
Code:
178 static struct nand_ecclayout hw_x16_romcode_oob_64 = {
179 .eccbytes = 12,
180 .eccpos = {
181 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13
182 },
183 .oobfree = {
184 {.offset = 14,
185 .length = 50}
186 }
187 };
1188 info-nand.ecc.layout = hw_x16_romcode_oob_64;
Regards,
Ghorai
--
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 : jffs2 and ecc layout
Hi,
I was using the following ecc layout which is not working to mount the jffs2
File-system. I was using this in 2.6.32 kernel and was 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
Code:
178 static struct nand_ecclayout hw_x16_romcode_oob_64 = {
179 .eccbytes = 12,
180 .eccpos = {
181 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13
182 },
183 .oobfree = {
184 {.offset = 14,
185 .length = 50}
186}
187 };
1188 info-nand.ecc.layout = hw_x16_romcode_oob_64;
Regards,
Ghorai
--
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 5/5] omap: nand: making ecc layout as compatible with romcode ecc
-Original Message- From: Premi, Sanjeev Sent: Monday, September 27, 2010 7:29 PM To: Ghorai, Sukumar; linux-omap@vger.kernel.org Cc: linux-...@lists.infradead.org; linux-arm-ker...@lists.infradead.org; Ghorai, Sukumar; Vimal Singh Subject: RE: [PATCH v5 5/5] omap: nand: making ecc layout as compatible with romcode ecc -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Sukumar Ghorai Sent: Monday, September 27, 2010 7:07 PM To: linux-omap@vger.kernel.org Cc: linux-...@lists.infradead.org; linux-arm-ker...@lists.infradead.org; Ghorai, Sukumar; Vimal Singh Subject: [PATCH v5 5/5] omap: nand: making ecc layout as compatible with romcode ecc This patch overrides nand ecc layout and bad block descriptor (for 8-bit device) to support hw ecc in romcode layout. So as to have in sync with ecc layout throughout; i.e. x-loader, u-boot and kernel. This patch also enables to use romcode ecc for spd and zoom, by default. This enables to flash x-loader, u-boot, kernel, FS images from kernel itself and compatiable with other tools. The description seems to start with different whitespace indents in this patch series. [Ghorai] Thanks. I will RESEND. ~sanjeev [snip]...[snip] -- 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: omap2: Missing arg to gpmc_prefetch_reset()
-Original Message- From: Loïc Minier [mailto:loic.min...@linaro.org] Sent: Saturday, September 25, 2010 3:15 AM To: linux-...@lists.infradead.org; linux-omap@vger.kernel.org Cc: Tony Lindgren; Ghorai, Sukumar; Loïc Minier Subject: [PATCH] nand: omap2: Missing arg to gpmc_prefetch_reset() Fix missing cs arg to gpmc_prefetch_reset() when CONFIG_MTD_NAND_OMAP_PREFETCH_DMA=y which caused a build failure since 948d38e799f0ab87cf8ed9113fcdaaee61acf321: drivers/mtd/nand/omap2.c: In function 'omap_nand_dma_transfer': drivers/mtd/nand/omap2.c:416: error: too few arguments to function 'gpmc_prefetch_reset' Signed-off-by: Loïc Minier loic.min...@linaro.org --- 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 133d515..513e0a7 100644 --- a/drivers/mtd/nand/omap2.c +++ b/drivers/mtd/nand/omap2.c @@ -413,7 +413,7 @@ static inline int omap_nand_dma_transfer(struct mtd_info *mtd, void *addr, prefetch_status = gpmc_read_status(GPMC_PREFETCH_COUNT); } while (prefetch_status); /* disable and stop the PFPW engine */ - gpmc_prefetch_reset(); + gpmc_prefetch_reset(info-gpmc_cs); dma_unmap_single(info-pdev-dev, dma_addr, len, dir); return 0; -- 1.7.1 [Ghorai] Acked-by: Sukumar Ghorai s-gho...@ti.com -- 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 RESEND v4 1/4] omap3: nand: prefetch in irq mode support
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Tuesday, September 21, 2010 8:28 PM To: Ghorai, Sukumar Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org; linux-arm- ker...@lists.infradead.org Subject: Re: [PATCH RESEND v4 1/4] omap3: nand: prefetch in irq mode support * Ghorai, Sukumar s-gho...@ti.com [100918 11:16]: This handler should be in gpmc.c as it may be needed for other GPMC connected devices on the same system. You can use chained irq handlers to allow all the drivers to use the interrupt then. [Ghorai] You mean as this function used the gpmc-irq number in nand file, so handler should move to gpmc.c file? Yes, other GPMC connected drivers may want to use it too for their chip selects. 1. For that we need to add one io-struct (to keep io buffer status) in gpmc.c; 2. Also need help how to sync between gpmc.c/omap_nand_irq() and omap2.c/omap_write_buf_irq_pref(), men how read/write function know that work done in interrupt-context? Or you prefer to move the complete IO function (omap_read/write_buf_irq_pref) to gpmc.c? 3. gpmc does not now about the read and write address that's applicable for NAND. So how to pass the IO address from omap2.c to gpmc.c, interrupt handler? Hmm, I don't follow you. You can have the interrupt handler both in gpmc.c and in the nand driver with set_irq_chained_handler() and set_irq_data(). We are doing that already in lots of places, like gpio.c and twl4030-irq.c. [Ghorai] Thanks. I am working on it; and will re-submit. So, please let me know your suggestion again such that I can post this time itself. Otherwise again it will miss from coming release, this was posted/reviewed for last release too. And suggest to void repeating of missing release window again. Yes would be nice to get this patch in, to me it seems that this issue is the only blocker. It should be pretty easy change to make. Regards, Tony -- 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 RESEND v4 1/4] omap3: nand: prefetch in irq mode support
Tony,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Ghorai, Sukumar
Sent: Monday, September 20, 2010 7:01 PM
To: Tony Lindgren
Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org; linux-arm-
ker...@lists.infradead.org
Subject: RE: [PATCH RESEND v4 1/4] omap3: nand: prefetch in irq mode
support
Tony,
-Original Message-
From: Ghorai, Sukumar
Sent: Saturday, September 18, 2010 11:55 PM
To: 'Tony Lindgren'
Cc: 'linux-omap@vger.kernel.org'; 'linux-...@lists.infradead.org';
'linux-
arm-ker...@lists.infradead.org'
Subject: RE: [PATCH RESEND v4 1/4] omap3: nand: prefetch in irq mode
support
Tony,
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Friday, September 17, 2010 11:25 PM
To: Ghorai, Sukumar
Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org; linux-
arm-
ker...@lists.infradead.org; Vimal Singh
Subject: Re: [PATCH RESEND v4 1/4] omap3: nand: prefetch in irq mode
support
* Sukumar Ghorai s-gho...@ti.com [100916 00:53]:
This patch enable prefetch-irq mode for NAND.
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -467,6 +485,152 @@ static void omap_write_buf_dma_pref(struct
mtd_info *mtd,
omap_nand_dma_transfer(mtd, (u_char *) buf, len, 0x1);
}
+/*
+ * omap_nand_irq - GMPC irq handler
+ * @this_irq: gpmc irq number
+ * @dev: omap_nand_info structure pointer is passed here
+ */
+static irqreturn_t omap_nand_irq(int this_irq, void *dev)
+{
+ struct omap_nand_info *info = (struct omap_nand_info *) dev;
+ u32 bytes;
+ u32 irq_stat;
+
+ irq_stat = gpmc_read_status(GPMC_GET_IRQ_STATUS);
+ bytes = gpmc_read_status(GPMC_PREFETCH_FIFO_CNT);
+ bytes = bytes 0xFFFC; /* io in multiple of 4 bytes */
+ if (info-iomode == OMAP_NAND_IO_WRITE) { /* checks for write
io */
+ if (irq_stat 0x2)
+ goto done;
+
+ if (info-buf_len (info-buf_len bytes))
+ bytes = info-buf_len;
+ else if (!info-buf_len)
+ bytes = 0;
+ iowrite32_rep(info-nand.IO_ADDR_W,
+ (u32 *)info-buf, bytes
2);
+ info-buf = info-buf + bytes;
+ info-buf_len -= bytes;
+
+ } else {
+ ioread32_rep(info-nand.IO_ADDR_R,
+ (u32 *)info-buf, bytes
2);
+ info-buf = info-buf + bytes;
+
+ if (irq_stat 0x2)
+ goto done;
+ }
+ gpmc_cs_configure(info-gpmc_cs, GPMC_SET_IRQ_STATUS,
irq_stat);
+ irq_stat = gpmc_read_status(GPMC_GET_IRQ_STATUS);
+
+ return IRQ_HANDLED;
+
+done:
+ complete(info-comp);
+ /* disable irq */
+ gpmc_cs_configure(info-gpmc_cs, GPMC_ENABLE_IRQ, 0);
+
+ /* clear status */
+ gpmc_cs_configure(info-gpmc_cs, GPMC_SET_IRQ_STATUS,
irq_stat);
+ irq_stat = gpmc_read_status(GPMC_GET_IRQ_STATUS);
+
+ return IRQ_HANDLED;
+}
This handler should be in gpmc.c as it may be needed for other GPMC
connected devices on the same system. You can use chained irq handlers
to allow all the drivers to use the interrupt then.
[Ghorai]
You mean as this function used the gpmc-irq number in nand file, so
handler should move to gpmc.c file?
1. For that we need to add one io-struct (to keep io buffer status)
in gpmc.c;
2. Also need help how to sync between gpmc.c/omap_nand_irq() and
omap2.c/omap_write_buf_irq_pref(), men how read/write function know that
work done in interrupt-context? Or you prefer to move the complete IO
function (omap_read/write_buf_irq_pref) to gpmc.c?
3. gpmc does not now about the read and write address that's
applicable for NAND. So how to pass the IO address from omap2.c to
gpmc.c,
interrupt handler?
So, please let me know your suggestion again such that I can post this
time itself. Otherwise again it will miss from coming release, this was
posted/reviewed for last release too. And suggest to void repeating of
missing release window again.
[Ghorai] Please reply with your 2nd suggestion.
[Ghorai] Please reply with your 2nd suggestion.
Regards,
Tony
--
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
RE: [PATCH RESEND v4 1/4] omap3: nand: prefetch in irq mode support
Tony,
-Original Message-
From: Ghorai, Sukumar
Sent: Saturday, September 18, 2010 11:55 PM
To: 'Tony Lindgren'
Cc: 'linux-omap@vger.kernel.org'; 'linux-...@lists.infradead.org'; 'linux-
arm-ker...@lists.infradead.org'
Subject: RE: [PATCH RESEND v4 1/4] omap3: nand: prefetch in irq mode
support
Tony,
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Friday, September 17, 2010 11:25 PM
To: Ghorai, Sukumar
Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org; linux-
arm-
ker...@lists.infradead.org; Vimal Singh
Subject: Re: [PATCH RESEND v4 1/4] omap3: nand: prefetch in irq mode
support
* Sukumar Ghorai s-gho...@ti.com [100916 00:53]:
This patch enable prefetch-irq mode for NAND.
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -467,6 +485,152 @@ static void omap_write_buf_dma_pref(struct
mtd_info *mtd,
omap_nand_dma_transfer(mtd, (u_char *) buf, len, 0x1);
}
+/*
+ * omap_nand_irq - GMPC irq handler
+ * @this_irq: gpmc irq number
+ * @dev: omap_nand_info structure pointer is passed here
+ */
+static irqreturn_t omap_nand_irq(int this_irq, void *dev)
+{
+ struct omap_nand_info *info = (struct omap_nand_info *) dev;
+ u32 bytes;
+ u32 irq_stat;
+
+ irq_stat = gpmc_read_status(GPMC_GET_IRQ_STATUS);
+ bytes = gpmc_read_status(GPMC_PREFETCH_FIFO_CNT);
+ bytes = bytes 0xFFFC; /* io in multiple of 4 bytes */
+ if (info-iomode == OMAP_NAND_IO_WRITE) { /* checks for write io */
+ if (irq_stat 0x2)
+ goto done;
+
+ if (info-buf_len (info-buf_len bytes))
+ bytes = info-buf_len;
+ else if (!info-buf_len)
+ bytes = 0;
+ iowrite32_rep(info-nand.IO_ADDR_W,
+ (u32 *)info-buf, bytes 2);
+ info-buf = info-buf + bytes;
+ info-buf_len -= bytes;
+
+ } else {
+ ioread32_rep(info-nand.IO_ADDR_R,
+ (u32 *)info-buf, bytes 2);
+ info-buf = info-buf + bytes;
+
+ if (irq_stat 0x2)
+ goto done;
+ }
+ gpmc_cs_configure(info-gpmc_cs, GPMC_SET_IRQ_STATUS, irq_stat);
+ irq_stat = gpmc_read_status(GPMC_GET_IRQ_STATUS);
+
+ return IRQ_HANDLED;
+
+done:
+ complete(info-comp);
+ /* disable irq */
+ gpmc_cs_configure(info-gpmc_cs, GPMC_ENABLE_IRQ, 0);
+
+ /* clear status */
+ gpmc_cs_configure(info-gpmc_cs, GPMC_SET_IRQ_STATUS, irq_stat);
+ irq_stat = gpmc_read_status(GPMC_GET_IRQ_STATUS);
+
+ return IRQ_HANDLED;
+}
This handler should be in gpmc.c as it may be needed for other GPMC
connected devices on the same system. You can use chained irq handlers
to allow all the drivers to use the interrupt then.
[Ghorai]
You mean as this function used the gpmc-irq number in nand file, so
handler should move to gpmc.c file?
1. For that we need to add one io-struct (to keep io buffer status)
in gpmc.c;
2. Also need help how to sync between gpmc.c/omap_nand_irq() and
omap2.c/omap_write_buf_irq_pref(), men how read/write function know that
work done in interrupt-context? Or you prefer to move the complete IO
function (omap_read/write_buf_irq_pref) to gpmc.c?
3. gpmc does not now about the read and write address that's
applicable for NAND. So how to pass the IO address from omap2.c to gpmc.c,
interrupt handler?
So, please let me know your suggestion again such that I can post this
time itself. Otherwise again it will miss from coming release, this was
posted/reviewed for last release too. And suggest to void repeating of
missing release window again.
[Ghorai] Please reply with your 2nd suggestion.
Regards,
Tony
--
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 RESEND v4 1/4] omap3: nand: prefetch in irq mode support
Tony,
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Friday, September 17, 2010 11:25 PM
To: Ghorai, Sukumar
Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org; linux-arm-
ker...@lists.infradead.org; Vimal Singh
Subject: Re: [PATCH RESEND v4 1/4] omap3: nand: prefetch in irq mode
support
* Sukumar Ghorai s-gho...@ti.com [100916 00:53]:
This patch enable prefetch-irq mode for NAND.
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -467,6 +485,152 @@ static void omap_write_buf_dma_pref(struct
mtd_info *mtd,
omap_nand_dma_transfer(mtd, (u_char *) buf, len, 0x1);
}
+/*
+ * omap_nand_irq - GMPC irq handler
+ * @this_irq: gpmc irq number
+ * @dev: omap_nand_info structure pointer is passed here
+ */
+static irqreturn_t omap_nand_irq(int this_irq, void *dev)
+{
+ struct omap_nand_info *info = (struct omap_nand_info *) dev;
+ u32 bytes;
+ u32 irq_stat;
+
+ irq_stat = gpmc_read_status(GPMC_GET_IRQ_STATUS);
+ bytes = gpmc_read_status(GPMC_PREFETCH_FIFO_CNT);
+ bytes = bytes 0xFFFC; /* io in multiple of 4 bytes */
+ if (info-iomode == OMAP_NAND_IO_WRITE) { /* checks for write io */
+ if (irq_stat 0x2)
+ goto done;
+
+ if (info-buf_len (info-buf_len bytes))
+ bytes = info-buf_len;
+ else if (!info-buf_len)
+ bytes = 0;
+ iowrite32_rep(info-nand.IO_ADDR_W,
+ (u32 *)info-buf, bytes 2);
+ info-buf = info-buf + bytes;
+ info-buf_len -= bytes;
+
+ } else {
+ ioread32_rep(info-nand.IO_ADDR_R,
+ (u32 *)info-buf, bytes 2);
+ info-buf = info-buf + bytes;
+
+ if (irq_stat 0x2)
+ goto done;
+ }
+ gpmc_cs_configure(info-gpmc_cs, GPMC_SET_IRQ_STATUS, irq_stat);
+ irq_stat = gpmc_read_status(GPMC_GET_IRQ_STATUS);
+
+ return IRQ_HANDLED;
+
+done:
+ complete(info-comp);
+ /* disable irq */
+ gpmc_cs_configure(info-gpmc_cs, GPMC_ENABLE_IRQ, 0);
+
+ /* clear status */
+ gpmc_cs_configure(info-gpmc_cs, GPMC_SET_IRQ_STATUS, irq_stat);
+ irq_stat = gpmc_read_status(GPMC_GET_IRQ_STATUS);
+
+ return IRQ_HANDLED;
+}
This handler should be in gpmc.c as it may be needed for other GPMC
connected devices on the same system. You can use chained irq handlers
to allow all the drivers to use the interrupt then.
[Ghorai]
You mean as this function used the gpmc-irq number in nand file, so handler
should move to gpmc.c file?
1. For that we need to add one io-struct (to keep io buffer status) in
gpmc.c;
2. Also need help how to sync between gpmc.c/omap_nand_irq() and
omap2.c/omap_write_buf_irq_pref(), men how read/write function know that work
done in interrupt-context? Or you prefer to move the complete IO function
(omap_read/write_buf_irq_pref) to gpmc.c?
3. gpmc does not now about the read and write address that's applicable
for NAND. So how to pass the IO address from omap2.c to gpmc.c, interrupt
handler?
So, please let me know your suggestion again such that I can post this time
itself. Otherwise again it will miss from coming release, this was
posted/reviewed for last release too. And suggest to void repeating of missing
release window again.
Regards,
Tony
--
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/7] omap4: Fixes, hacks for es2.0
[snip] [Ghorai] I have tested MMC/SD boot using omap3_defconfig on ZOOM3, 4430 ES2.0 SDP, Blaze and Panda and all booting fine. And omap_4430sdp_defconfig also ok omap4. Which Panda version are you using during your tests? I tried omap_4430sdp_defconfig using omap4-for-tony branch at my ES2.0 and I'm unable to detect the MMC. Do I need any other patch to make the MMC work with Panda? [Ghorai] I have tested based on following tree/branch and using ES2.0 PANDA only. Can you share bootlog enabling mmc/sd debug message? http://dev.omapzoom.org/?p=santosh/kernel-omap4- base.git;a=shortlog;h=refs/heads/omap4-for-tony My boot log: http://paste.ubuntu.com/491645/ [Ghorai] can you use this bootargs? setenv bootargs root=/dev/mmcblk0p2 rw rootwait mem=463M console=ttyS2,115200n8 And here is the log from my setup. [2.493194] Waiting for root device /dev/mmcblk0p2... [2.502960] mmc0: host does not support reading read-only switch. assuming write-enable. [2.523895] mmc0: new high speed SDHC card at address e1ed [2.531616] mmcblk0: mmc0:e1ed SD04G 3.75 GiB [2.539550] mmcblk0: p1 p2 [2.607360] EXT3-fs: barriers not enabled Using x-loader from http://gitorious.org/pandaboard/x-loader/commits/omap4_panda_L24.9 and upstream u-boot. [Ghorai] can you try with this x-loader https://docs.google.com/leaf?id=0B8fdjBBEQ4lDZGE3ZTBjNzEtOTQ0Ni00ZmFlLTlhODgtN2QzNjUwMzBkNDI2hl=en In the mean time I will try with yours! Cheers, -- Ricardo Salveti de Araujo -- 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/7] omap4: Fixes, hacks for es2.0
-Original Message- From: Ricardo Salveti [mailto:rsalv...@rsalveti.net] Sent: Tuesday, September 14, 2010 12:22 AM To: Ghorai, Sukumar Cc: Shilimkar, Santosh; Kevin Hilman; linux-omap@vger.kernel.org; t...@atomide.com; Bryan Wu Subject: Re: [PATCH 0/7] omap4: Fixes, hacks for es2.0 On Mon, Sep 13, 2010 at 12:06 PM, Ghorai, Sukumar s-gho...@ti.com wrote: [Ghorai] I have tested MMC/SD boot using omap3_defconfig on ZOOM3, 4430 ES2.0 SDP, Blaze and Panda and all booting fine. And omap_4430sdp_defconfig also ok omap4. Which Panda version are you using during your tests? I tried omap_4430sdp_defconfig using omap4-for-tony branch at my ES2.0 and I'm unable to detect the MMC. Do I need any other patch to make the MMC work with Panda? [Ghorai] I have tested based on following tree/branch and using ES2.0 PANDA only. Can you share bootlog enabling mmc/sd debug message? http://dev.omapzoom.org/?p=santosh/kernel-omap4- base.git;a=shortlog;h=refs/heads/omap4-for-tony My boot log: http://paste.ubuntu.com/491645/ [Ghorai] can you use this bootargs? setenv bootargs root=/dev/mmcblk0p2 rw rootwait mem=463M console=ttyS2,115200n8 And here is the log from my setup. [ 2.493194] Waiting for root device /dev/mmcblk0p2... [ 2.502960] mmc0: host does not support reading read-only switch. assuming write-enable. [ 2.523895] mmc0: new high speed SDHC card at address e1ed [ 2.531616] mmcblk0: mmc0:e1ed SD04G 3.75 GiB [ 2.539550] mmcblk0: p1 p2 [ 2.607360] EXT3-fs: barriers not enabled Using x-loader from http://gitorious.org/pandaboard/x-loader/commits/omap4_panda_L24.9 and upstream u-boot. [Ghorai] can you try with this x-loader https://docs.google.com/leaf?id=0B8fdjBBEQ4lDZGE3ZTBjNzEtOTQ0Ni00ZmFlLTlhO DgtN2QzNjUwMzBkNDI2hl=en In the mean time I will try with yours! I'm unable to boot with your x-loader at my ES2.0 (6 and 8 layers), however I'm able to boot it with ES1. Are you sure you're testing it at an ES2 board? This is what I get, it just hangs: Texas Instruments X-Loader 1.41 (Aug 11 2010 - 10:51:13) Could not read bootloader! X-Loader hangs [Ghorai] format the card and copy MLo and followed by u-boot, uImage And yes I am using EX 2.0 6-layer board. Cheers, -- Ricardo Salveti de Araujo -- 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 erase failures on overo
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Cliff Brake Sent: Saturday, September 11, 2010 3:22 AM To: Linux OMAP Users Subject: NAND erase failures on overo With the current, linux-omap:master branch (8475b9e5077d9e9b4ba7a92afd4c5c7d65564c09), I get the following errors on a overo system when erasing flash: r...@ts3:~# flash_eraseall -j /dev/mtd4 Erasing 128 Kibyte @ 8c4 -- 56 % complete. Cleanmarker written at 8c2. flash_eraseall: /dev/mtd4: MTD Erase failure: Input/output error Erasing 128 Kibyte @ 944 -- 59 % complete. Cleanmarker written at 942. flash_eraseall: /dev/mtd4: MTD Erase failure: Input/output error Erasing 128 Kibyte @ f98 -- 100 % complete.Cleanmarker written at f96. [Ghorai] There are few bad blocks reported by NAND erase. On the omap3530 TI EVM, with the same kernel, I don't see any of these errors. I'm not sure if its related to something like this: http://lists.infradead.org/pipermail/linux-mtd/2010-August/031563.html Thanks, Cliff -- = http://bec-systems.com -- 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 0/7] omap4: Fixes, hacks for es2.0
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh Sent: Thursday, September 09, 2010 4:53 PM To: linux-omap@vger.kernel.org Cc: t...@atomide.com; khil...@deeprootsystems.com; Shilimkar, Santosh Subject: [PATCH 0/7] omap4: Fixes, hacks for es2.0 This series has few fixes, hacks to get omap4 es2.0 working on mainline. The patches are generated against the mainline 2.6.36-rc3. The series is boot tested tested on 4430 SDP, Blaze with omap_4430sdp_defconfig with file over NFS and MMC. Also boot tested omap3_defconfig with ramdisk on OMAP4 and OMAP3 SDPs. Same observation with Panda With omap3_defconfig, MMC while mounting the rootfs over MMC, the boot hangs. Same observation with Panda [Ghorai] Santosh, It's booing in another Panda. I think that's a board issue. [5.794616] regulator_init_complete: incomplete constraints, leaving VUSIM on [5.802764] regulator_init_complete: incomplete constraints, leaving VPP on [5.816131] twl_rtc twl_rtc: setting system clock to 2000-01-01 00:53:12 UTC (9 ) [5.849304] mmc0: new high speed MMC card at address 0001 [5.856323] mmcblk0: mmc0:0001 SEM08G 7.39 GiB [5.862091] mmcblk0: unknown partition table [6.325500] omap_device: mmci-omap-hs.1: new worst case deactivate latency 0: 6 [ 18.424407] VFS: Cannot open root device mmcblk0p2 or unknown- block(179,2) [ 18.431823] Please append a correct root= boot option; here are the available ons: [ 18.440643] b300 7757824 mmcblk0 driver: mmcblk [ 18.446166] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown All these patches are also available at: http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=summary head: omap4-for-tony David Anders (1): omap4: Panda: Add DEBUG_LL support Eric Dumazet (1): KS8851: Correct RX packet allocation Madhusudhan Chikkature (1): omap4: Workaround for CMD line reset. Santosh Shilimkar (4): omap4: Update id.c and cpu.h for es2.0 omap4: Temporary fix silicon version detection omap4: l2x0: Fix init parameter for ES2.0 omap4: Fix bootup crash observed with higher CPU clocks arch/arm/mach-omap2/id.c | 39 + arch/arm/mach-omap2/omap4-common.c |5 ++- arch/arm/plat-omap/dmtimer.c |2 +- arch/arm/plat-omap/include/plat/cpu.h|5 ++- arch/arm/plat-omap/include/plat/uncompress.h |1 + drivers/mmc/host/omap_hsmmc.c|8 + drivers/net/ks8851.c | 39 ++--- - 7 files changed, 71 insertions(+), 28 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 -- 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/7] omap4: Fixes, hacks for es2.0
-Original Message- [..snip..] The series is boot tested tested on 4430 SDP, Blaze with omap_4430sdp_defconfig with file over NFS and MMC. Also boot tested omap3_defconfig with ramdisk on OMAP4 and OMAP3 SDPs. Same observation with Panda With omap3_defconfig, MMC while mounting the rootfs over MMC, the boot hangs. Same observation with Panda On my ES2.0 Panda, rootfs on MMC is now working with this series. I observed the same with MMC. Ramdisk boot worked for me on PANDA. Note that I said now working. I think you read my message as not working. Yes I read it otherway ... Second time today :) IOW, rootfs on MMC *is* working for me on my es2.0 Panda. I applied your series to current l-o master, and it works. Cool!! [Ghorai] I have tested MMC/SD boot using omap3_defconfig on ZOOM3, 4430 ES2.0 SDP, Blaze and Panda and all booting fine. And omap_4430sdp_defconfig also ok omap4. However, rootfs over NFS is not yet working, presumably because the OMAP4 EHCI support is needed for the USB-attached smsc95xx to work properly. This is correct. We need to get the MMC fixed o.w panda is unusable in it's current form. [5.794616] regulator_init_complete: incomplete constraints, leaving VUSIM on [5.802764] regulator_init_complete: incomplete constraints, leaving VPP on [5.816131] twl_rtc twl_rtc: setting system clock to 2000-01-01 00:53:12 UTC (9 ) [5.849304] mmc0: new high speed MMC card at address 0001 [5.856323] mmcblk0: mmc0:0001 SEM08G 7.39 GiB [5.862091] mmcblk0: unknown partition table [6.325500] omap_device: mmci-omap-hs.1: new worst case deactivate latency 0: 6 Based on this message, this is not a mainline kernel, but one where the omap_device conversion for MMC has been applied. This is mainline 2.6.36-rc3 http://dev.omapzoom.org/?p=santosh/kernel-omap4- base.git;a=shortlog;h=refs/heads/omap4-for-tony [..snip ..] -- 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/7] omap4: Fixes, hacks for es2.0
-Original Message- From: Ricardo Salveti [mailto:rsalv...@rsalveti.net] Sent: Friday, September 10, 2010 8:34 PM To: Ghorai, Sukumar Cc: Shilimkar, Santosh; Kevin Hilman; linux-omap@vger.kernel.org; t...@atomide.com Subject: Re: [PATCH 0/7] omap4: Fixes, hacks for es2.0 On Fri, Sep 10, 2010 at 7:30 AM, Ghorai, Sukumar s-gho...@ti.com wrote: -Original Message- [..snip..] The series is boot tested tested on 4430 SDP, Blaze with omap_4430sdp_defconfig with file over NFS and MMC. Also boot tested omap3_defconfig with ramdisk on OMAP4 and OMAP3 SDPs. Same observation with Panda With omap3_defconfig, MMC while mounting the rootfs over MMC, the boot hangs. Same observation with Panda On my ES2.0 Panda, rootfs on MMC is now working with this series. I observed the same with MMC. Ramdisk boot worked for me on PANDA. Note that I said now working. I think you read my message as not working. Yes I read it otherway ... Second time today :) IOW, rootfs on MMC *is* working for me on my es2.0 Panda. I applied your series to current l-o master, and it works. Cool!! [Ghorai] I have tested MMC/SD boot using omap3_defconfig on ZOOM3, 4430 ES2.0 SDP, Blaze and Panda and all booting fine. And omap_4430sdp_defconfig also ok omap4. Which Panda version are you using during your tests? I tried omap_4430sdp_defconfig using omap4-for-tony branch at my ES2.0 and I'm unable to detect the MMC. Do I need any other patch to make the MMC work with Panda? [Ghorai] I have tested based on following tree/branch and using ES2.0 PANDA only. Can you share bootlog enabling mmc/sd debug message? http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=shortlog;h=refs/heads/omap4-for-tony Thanks, -- Ricardo Salveti de Araujo -- 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
Vimal,
-Original Message-
From: Vimal Singh [mailto:vimal.neww...@gmail.com]
Sent: Saturday, August 28, 2010 2:07 AM
To: Cliff Brake
Cc: Ghorai, Sukumar; Kamat, Nishant; linux-omap@vger.kernel.org; Linux MTD
Subject: 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).
[Ghorai]
1. You mean revert the old code will solve the issue mentioned by Cliff?
2. Can you check if the problem already exists before applying these patch
itself?
--
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
-Original Message- From: Cliff Brake [mailto:cliff.br...@gmail.com] Sent: Wednesday, August 18, 2010 9:16 PM To: Ghorai, Sukumar Cc: Linux OMAP Users; Kamat, Nishant Subject: Re: NAND ECC in linux-omap On Wed, Aug 18, 2010 at 12:14 AM, Ghorai, Sukumar s-gho...@ti.com wrote: [Ghorai] 1. Can you send the git tree link and branch you are referring? git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git branch: pm 95e42b92313f229cbc9fc81bf68fe60aaee515aa I'm pretty sure this branch tracks linux-omap. I have not tested linux-omap yet (git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap- 2.6.git:master) 2. I am working to support the NAND BCH and not upstream yet, how you apply this patch in PM branch. What do you mean by upstream? I'm not sure what NAND changes are in the above pm branch -- that is what I'm trying to figure out :-) Perhaps you can suggest if I'm using BCH, etc. 3. which x-loader and u-boot you are referring? And no x-loader/ u-boot supports the BCH I'm using the x-loader/u-boot from for the Gumstix Overo. My understanding is that it uses software -- likely not BCH, but I'm not sure. [Ghorai] understand the problem, it's a nand ECC layout (location where ECC stors) problem, I think you flush the JFFS2 flash filesystem from u-boot and kernel not able to mount it. So let boot the image form say from MMC/SD or NFS (1st time); and use the utility after boot (flash_eraseall, nandwrite, ..) to write the JFFS2 image in NAND. And you can check JFFS2 mount or any further test. If this does not help, send me the nanddump of the any page you write the data from u-boot. Thanks, Cliff -- = http://bec-systems.com -- 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
-Original Message- From: Cliff Brake [mailto:cliff.br...@gmail.com] Sent: Wednesday, August 18, 2010 3:27 AM To: Linux OMAP Users; Ghorai, Sukumar Subject: NAND ECC in linux-omap Hi, I'm using the latest pm branch (based on linux-omap I think), and running into the following problems. The first is my x-loader uses software ECC. Looking in the omap nand driver, I made the following change which gets x-loader/u-boot working again: diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c index 133d515..1593c60 100644 --- a/drivers/mtd/nand/omap2.c +++ b/drivers/mtd/nand/omap2.c @@ -7,7 +7,7 @@ * it under the terms of the GNU General Public License version 2 as * published by the Free Software Foundation. */ -#define CONFIG_MTD_NAND_OMAP_HWECC +//#define CONFIG_MTD_NAND_OMAP_HWECC #include linux/platform_device.h #include linux/dma-mapping.h But, I'm still getting a ton of ECC errors in JFFS2 flash filesystem. Does anyone have any suggestions as to where to go from here? I see some patches on the mail lists from Sukumar Ghorai that make HW/SW ECC selectable from the board file. Thanks, Cliff [Ghorai] 1. Can you send the git tree link and branch you are referring? 2. I am working to support the NAND BCH and not upstream yet, how you apply this patch in PM branch. 3. which x-loader and u-boot you are referring? And no x-loader/ u-boot supports the BCH -- = http://bec-systems.com -- 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] ARM: OMAP: Beagle: support MMC gpio_wp differences on xM
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Robert Nelson
Sent: Tuesday, August 10, 2010 8:10 PM
To: t...@atomide.com
Cc: linux-omap@vger.kernel.org; Robert Nelson
Subject: [PATCH] ARM: OMAP: Beagle: support MMC gpio_wp differences on xM
The omap3630 based BeagleBoard xM uses a MicroSD card slot with
no write protection.
Signed-off-by: Robert Nelson robertcnel...@gmail.com
---
arch/arm/mach-omap2/board-omap3beagle.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-
omap2/board-omap3beagle.c
index 87969c7..15929be 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -185,7 +185,9 @@ static struct gpio_led gpio_leds[];
static int beagle_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
- if (system_rev = 0x20 system_rev = 0x34301000) {
+ if (cpu_is_omap3630()) {
+ mmc[0].gpio_wp = -EINVAL;
+ } else if (system_rev = 0x20 system_rev = 0x34301000) {
[Ghorai] it's an old code. But I think we can replace the hardcode value to use
omap_rev() as you are changing the same! Or default for all omap34xx?
omap_mux_init_gpio(23, OMAP_PIN_INPUT);
mmc[0].gpio_wp = 23;
} else {
--
1.7.0.4
--
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] Initializing gpmc before accessing flash
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Mathieu Poirier Sent: Wednesday, August 11, 2010 8:12 PM To: t...@atomide.com Cc: linux-omap@vger.kernel.org; Mathieu Poirier Subject: [PATCH] Initializing gpmc before accessing flash From b12de3010763a8c047eefd2eb9296eb68157b07e Mon Sep 17 00:00:00 2001 From: Mathieu J. Poirier mathieu.poir...@canonical.com Date: Tue, 10 Aug 2010 17:14:25 -0400 Subject: [PATCH] Initializing gpmc before accessing flash Adding initialization of the General Purpose Memory Controller (gpmc) in 'omap3beagle_flash_init'. The gpmc init was decoupled from nand flash init and got its own init function. This change was not reflected in 'omap3beagle_flash_init' resulting in a lookup failure when probing for flash. BugLink: https://bugs/launchpad.net/bugs/608266 Signed-off-by: Mathieu Poirier mathieu.poir...@canonical.com --- arch/arm/mach-omap2/board-omap3beagle.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach- omap2/board-omap3beagle.c index 7a1b351..e1203a4 100644 --- a/arch/arm/mach-omap2/board-omap3beagle.c +++ b/arch/arm/mach-omap2/board-omap3beagle.c @@ -466,6 +466,7 @@ static void __init omap3beagle_flash_init(void) omap3beagle_nand_data.gpmc_cs_baseaddr = (void *) (gpmc_base_add + GPMC_CS0_BASE + nandcs * GPMC_CS_SIZE); omap3beagle_nand_data.gpmc_baseaddr = (void *) (gpmc_base_add); + gpmc_nand_init(omap3beagle_nand_data); [Ghorai] things are queued for 2.6.36; can refer http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=f450d86790ebf72ac93c7ea5addd6fa278aae64c printk(KERN_INFO Registering NAND on CS%d\n, nandcs); if (platform_device_register(omap3beagle_nand_device) 0) -- 1.7.0.4 -- 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 v4 0/4] nand prefetch-irq support and ecc layout chanage
Tony, -Original Message- From: Ghorai, Sukumar Sent: Wednesday, August 04, 2010 9:29 AM To: linux-omap@vger.kernel.org; 'Tony Lindgren' Cc: linux-arm-ker...@lists.infradead.org; linux-...@lists.infradead.org Subject: RE: [PATCH v4 0/4] nand prefetch-irq support and ecc layout chanage -Original Message- From: Ghorai, Sukumar Sent: Monday, August 02, 2010 9:20 PM To: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org; linux-...@lists.infradead.org; Ghorai, Sukumar Subject: [PATCH v4 0/4] nand prefetch-irq support and ecc layout chanage The following set of patches applies on top of omap-for-linus. v4: Comments incorporated v3: http://www.mail-archive.com/linux- o...@vger.kernel.org/msg32071.html Rebase on latest codebase and previous patch(posted). http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31963.html v2: Rebase on latest codebase and previous patch(posted). http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31471.html v1: http://www.mail-archive.com/linux- o...@vger.kernel.org/msg2.html Sukumar Ghorai (4): omap3: nand: prefetch in irq mode support omap: nand: configurable fifo threshold to gain the throughput omap: nand: ecc layout select from board file omap: nand: making ecc layout as compatible with romcode ecc arch/arm/mach-omap2/board-flash.c |5 +- arch/arm/mach-omap2/gpmc.c | 15 ++- arch/arm/plat-omap/include/plat/gpmc.h |9 +- arch/arm/plat-omap/include/plat/irqs.h |1 + arch/arm/plat-omap/include/plat/nand.h |7 + drivers/mtd/nand/Kconfig | 14 ++- drivers/mtd/nand/omap2.c | 277 --- 7 files changed, 294 insertions(+), 34 deletions(-) [Ghorai] Tony, Would you please check if you have any input further? [Ghorai] Tony, Would you please check the status of these patch(s). Regards, Ghorai -- 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 0/4] nand prefetch-irq support and ecc layout chanage
-Original Message- From: Ghorai, Sukumar Sent: Monday, August 02, 2010 9:20 PM To: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org; linux-...@lists.infradead.org; Ghorai, Sukumar Subject: [PATCH v4 0/4] nand prefetch-irq support and ecc layout chanage The following set of patches applies on top of omap-for-linus. v4: Comments incorporated v3: http://www.mail-archive.com/linux- o...@vger.kernel.org/msg32071.html Rebase on latest codebase and previous patch(posted). http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31963.html v2: Rebase on latest codebase and previous patch(posted). http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31471.html v1: http://www.mail-archive.com/linux- o...@vger.kernel.org/msg2.html Sukumar Ghorai (4): omap3: nand: prefetch in irq mode support omap: nand: configurable fifo threshold to gain the throughput omap: nand: ecc layout select from board file omap: nand: making ecc layout as compatible with romcode ecc arch/arm/mach-omap2/board-flash.c |5 +- arch/arm/mach-omap2/gpmc.c | 15 ++- arch/arm/plat-omap/include/plat/gpmc.h |9 +- arch/arm/plat-omap/include/plat/irqs.h |1 + arch/arm/plat-omap/include/plat/nand.h |7 + drivers/mtd/nand/Kconfig | 14 ++- drivers/mtd/nand/omap2.c | 277 --- 7 files changed, 294 insertions(+), 34 deletions(-) [Ghorai] Tony, Would you please check if you have any input further? Regards, Ghorai -- 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: Unable to load ext3 partition from mmc card
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Elvis Dowson Sent: Wednesday, August 04, 2010 6:25 AM To: linux-omap@vger.kernel.org Subject: Re: Unable to load ext3 partition from mmc card On Aug 4, 2010, at 3:53 AM, Elvis Dowson wrote: Hi, I'm trying out u-boot-2010.06 and linux-omap-2.6.34, and I'm using the omap3_defconfig. I get the following error upon boot: [2.097320] Waiting for root device /dev/mmcblk0p2... [2.235595] mmc0: new SD card at address b874 [2.243530] mmcblk0: mmc0:b874 SU02G 1.87 GiB (ro) [2.250213] mmcblk0: p1 p2 [2.323638] VFS: Cannot open root device mmcblk0p2 or unknown- block(179,2) [2.330871] Please append a correct root= boot option; here are the available partitions: [2.339477] b300 1971712 mmcblk0 driver: mmcblk [2.344848] b301 40131 mmcblk0p1 [2.349182] b302 514080 mmcblk0p2 [2.353973] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(179,2) I found that switching to v2.6.35 and using the omap3_beagleboard_defconfig, works. It doesn't work for some reason for v2.6.34. [Ghorai] I used omap3_defconfig on v2.6.34 for beagleboard; here is the bootargs that works for me - setenv bootargs 'console=ttyS2,115200n8 console=tty0 noinitrd root=/dev/mmcblk0p2 rootdelay=3' Best regards, Elvis Dowson -- 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 v3 1/4] omap3: nand: prefetch in irq mode support
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Monday, August 02, 2010 6:33 PM
To: Ghorai, Sukumar
Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org; linux-arm-
ker...@lists.infradead.org; Vimal Singh
Subject: Re: [PATCH v3 1/4] omap3: nand: prefetch in irq mode support
* Sukumar Ghorai s-gho...@ti.com [100713 07:39]:
This patch enable prefetch-irq mode for NAND.
snip
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -133,6 +133,7 @@ static struct omap_nand_platform_data
board_nand_data = {
.nand_setup = NULL,
.gpmc_t = nand_timings,
.dma_channel= -1, /* disable DMA in OMAP NAND driver */
+ .gpmc_irq = GPMC_IRQ_NUMBER,
.dev_ready = NULL,
.devsize= 0,/* '0' for 8-bit, '1' for 16-bit device */
};
--- a/arch/arm/mach-omap2/include/mach/board-flash.h
+++ b/arch/arm/mach-omap2/include/mach/board-flash.h
@@ -19,6 +19,9 @@
#define PDC_ONENAND3
#define DBG_MPDB 4
+/* Interrupt number to the MPU Subsystem for GPMC */
+#define GPMC_IRQ_NUMBER20
+
This does not look right for the IRQ. Please add it to the irqs.h and 34xx,
then set it dynamically during the init just like we handle the other
interrupt numbers.
This is because the irq numbers can change between omaps, like irqs-44xx.h
already has
#define OMAP44XX_IRQ_GPMC (20 +
OMAP44XX_IRQ_GIC_START)
@@ -130,6 +141,13 @@ struct omap_nand_info {
unsigned long phys_base;
struct completion comp;
int dma_ch;
+ int gpmc_irq;
+ enum {
+ NAND_IO_READ = 0, /* read */
+ NAND_IO_WRITE, /* write */
+ } iomode;
+ u_char *buf;
+ int buf_len;
};
These should probably be OMAP_NAND_IO_READ and OMAP_NAND_IO_WRITE?
[Ghorai] Thanks. I understand all your comments. I will rework and submit
again.
Regards,
Ghorai
Regards,
Tony
--
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: hsmmc funtionality breaks when CONFIG_PM not define
Adrian,
-Original Message-
From: Adrian Hunter [mailto:adrian.hun...@nokia.com]
Sent: Wednesday, July 21, 2010 11:46 AM
To: Ghorai, Sukumar
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Shilimkar,
Santosh; Chikkature Rajashekar, Madhusudhan; Andrew Morton
Subject: Re: [PATCH] omap: hsmmc funtionality breaks when CONFIG_PM not
define
[Ghorai] thanks and need input again,
we have two tables -
1. static const struct mmc_host_ops omap_hsmmc_ops = {
}
-- This is without CONFIG_PM, assumed.
No it is independent of CONFIG_PM
With CONFIG_PM
- the driver will restore registers if the host controller
has been powered off / on by PRCM
- suspend / resume can be used
2. static const struct mmc_host_ops omap_hsmmc_ps_ops = {
}
- this with CONFIG_PM, assumed.
No it is independent of CONFIG_PM
Without CONFIG_PM
- card will be put to sleep after 1 second
- card will be powered off after another 8 seconds
a. And you feel we should remove #1
Nothing should need to be removed.
b. use omap_hsmmc_ps_ops default.
With power_saving it is yes.
[Ghorai] Is it that power_saving (true or false) is independent of
CONFIG_PM?
Yes, power_saving (true or false) *is* independent of CONFIG_PM.
[Ghorai] Thanks and would you please reply for query from Kishore and now query
from my side too?
Is there any use case or a valid scenario when to use omap_hsmmc_ps_ops or
omap_hsmmc_ops ? I meant using power_saving option and without power_saving
option.
Ideally I feel having omap_hsmmc_ps_ops as default with or without CONFIG_PM
would be better as it internally has a state handling.
Regards,
Ghorai
--
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: hsmmc funtionality breaks when CONFIG_PM not define
-Original Message- From: Adrian Hunter [mailto:adrian.hun...@nokia.com] Sent: Tuesday, July 20, 2010 12:39 PM To: Ghorai, Sukumar Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Shilimkar, Santosh; Chikkature Rajashekar, Madhusudhan; Andrew Morton Subject: Re: [PATCH] omap: hsmmc funtionality breaks when CONFIG_PM not define Sukumar Ghorai wrote: Issue if power_saving option passed from board file and CONFIG_PM not define. This is because hosts refer to wrong operation table and that try to power save. power_saving is not related to power management. It should work with or without CONFIG_PM. What problem are you seeing? [Ghorai] when CONFIG_PM is not defined but power_saving flag is TRUE, then host operation table point to table which handles in state machine as: ENABLE - CARDSLEEP - REGSLEEP - DISABLED for power/clock cut. And do the reverse for the enable clock/power. And power saving is not required and wont work when CONFIG_PM is not enabled. So if CONFIG_PM is not enable, then it should do simple clock disable/enable, and not via the power state machine. Signed-off-by: Sukumar Ghorai s-gho...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com CC: Madhusudhan Chikkature madhu...@ti.com CC: Andrew Morton a...@linux-foundation.org --- Tested on omap3, omap4430 ES2.0 drivers/mmc/host/omap_hsmmc.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index b032828..f84eed0 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -2015,9 +2015,11 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev) platform_set_drvdata(pdev, host); INIT_WORK(host-mmc_carddetect_work, omap_hsmmc_detect); +#ifdef CONFIG_PM if (mmc_slot(host).power_saving) mmc-ops= omap_hsmmc_ps_ops; else +#endif mmc-ops= omap_hsmmc_ops; /* -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Regards, Ghorai -- 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: hsmmc funtionality breaks when CONFIG_PM not define
Adrian, -Original Message- From: Adrian Hunter [mailto:adrian.hun...@nokia.com] Sent: Tuesday, July 20, 2010 1:40 PM To: Ghorai, Sukumar Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Shilimkar, Santosh; Chikkature Rajashekar, Madhusudhan; Andrew Morton Subject: Re: [PATCH] omap: hsmmc funtionality breaks when CONFIG_PM not define Ghorai, Sukumar wrote: -Original Message- From: Adrian Hunter [mailto:adrian.hun...@nokia.com] Sent: Tuesday, July 20, 2010 12:39 PM To: Ghorai, Sukumar Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Shilimkar, Santosh; Chikkature Rajashekar, Madhusudhan; Andrew Morton Subject: Re: [PATCH] omap: hsmmc funtionality breaks when CONFIG_PM not define Sukumar Ghorai wrote: Issue if power_saving option passed from board file and CONFIG_PM not define. This is because hosts refer to wrong operation table and that try to power save. power_saving is not related to power management. It should work with or without CONFIG_PM. What problem are you seeing? [Ghorai] when CONFIG_PM is not defined but power_saving flag is TRUE, then host operation table point to table which handles in state machine as: ENABLE - CARDSLEEP - REGSLEEP - DISABLED for power/clock cut. And do the reverse for the enable clock/power. And power saving is not required and wont work when CONFIG_PM is not enabled. How is that a problem? It would be useful to know what you need? [Ghorai] do men when CONFIG_PM is not enabled still we should do power saving in mmc? Because issue is iclk/fclk is quite depended on PRCM framework when we are using omap_hsmmc_ps_ops operation table. So if CONFIG_PM is not enable, then it should do simple clock disable/enable, and not via the power state machine. If that is what you want, simply change your board file: #if CONFIG_PM .power_saving = true, #else .power_saving = false, #end [Ghorai] the fix I send is to guard in MMC/SD host driver to avoid mistake in board file(s). And this file is used for multiple omap3, omap4 boards. Signed-off-by: Sukumar Ghorai s-gho...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com CC: Madhusudhan Chikkature madhu...@ti.com CC: Andrew Morton a...@linux-foundation.org --- Tested on omap3, omap4430 ES2.0 drivers/mmc/host/omap_hsmmc.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index b032828..f84eed0 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -2015,9 +2015,11 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev) platform_set_drvdata(pdev, host); INIT_WORK(host-mmc_carddetect_work, omap_hsmmc_detect); +#ifdef CONFIG_PM if (mmc_slot(host).power_saving) mmc-ops= omap_hsmmc_ps_ops; else +#endif mmc-ops= omap_hsmmc_ops; /* -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Regards, Ghorai -- To unsubscribe from this list: send the line unsubscribe linux-mmc 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] omap: hsmmc funtionality breaks when CONFIG_PM not define
-Original Message-
From: Adrian Hunter [mailto:adrian.hun...@nokia.com]
Sent: Tuesday, July 20, 2010 2:10 PM
To: Ghorai, Sukumar
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Shilimkar,
Santosh; Chikkature Rajashekar, Madhusudhan; Andrew Morton
Subject: Re: [PATCH] omap: hsmmc funtionality breaks when CONFIG_PM not
define
Ghorai, Sukumar wrote:
Adrian,
-Original Message-
From: Adrian Hunter [mailto:adrian.hun...@nokia.com]
Sent: Tuesday, July 20, 2010 1:40 PM
To: Ghorai, Sukumar
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Shilimkar,
Santosh; Chikkature Rajashekar, Madhusudhan; Andrew Morton
Subject: Re: [PATCH] omap: hsmmc funtionality breaks when CONFIG_PM not
define
Ghorai, Sukumar wrote:
-Original Message-
From: Adrian Hunter [mailto:adrian.hun...@nokia.com]
Sent: Tuesday, July 20, 2010 12:39 PM
To: Ghorai, Sukumar
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Shilimkar,
Santosh; Chikkature Rajashekar, Madhusudhan; Andrew Morton
Subject: Re: [PATCH] omap: hsmmc funtionality breaks when CONFIG_PM
not
define
Sukumar Ghorai wrote:
Issue if power_saving option passed from board file and
CONFIG_PM
not define.
This is because hosts refer to wrong operation table and that
try
to
power save.
power_saving is not related to power management. It should work with
or
without
CONFIG_PM. What problem are you seeing?
[Ghorai] when CONFIG_PM is not defined but power_saving flag is TRUE,
then host operation table point to table which handles in state machine
as: ENABLE - CARDSLEEP - REGSLEEP - DISABLED for power/clock cut.
And
do the reverse for the enable clock/power.
And power saving is not required and wont work when CONFIG_PM is not
enabled.
How is that a problem? It would be useful to know what you need?
[Ghorai] do men when CONFIG_PM is not enabled still we should do power
saving in mmc?
Why not?
Because issue is iclk/fclk is quite depended on PRCM framework when we are
using omap_hsmmc_ps_ops operation table.
iclk is left alone.
fclk is manipulated with or without power_saving.
I still do not understand your problem sorry :-(
[Ghorai] thanks and need input again,
we have two tables -
1. static const struct mmc_host_ops omap_hsmmc_ops = {
}
-- This is without CONFIG_PM, assumed.
2. static const struct mmc_host_ops omap_hsmmc_ps_ops = {
}
- this with CONFIG_PM, assumed.
a. And you feel we should remove #1
b. use omap_hsmmc_ps_ops default.
c. And it should work in all case?
So if CONFIG_PM is not enable, then it should do simple clock
disable/enable, and not via the power state machine.
If that is what you want, simply change your board file:
#if CONFIG_PM
.power_saving = true,
#else
.power_saving = false,
#end
[Ghorai] the fix I send is to guard in MMC/SD host driver to avoid
mistake in board file(s). And this file is used for multiple omap3, omap4
boards.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
CC: Madhusudhan Chikkature madhu...@ti.com
CC: Andrew Morton a...@linux-foundation.org
---
Tested on omap3, omap4430 ES2.0
drivers/mmc/host/omap_hsmmc.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c
b/drivers/mmc/host/omap_hsmmc.c
index b032828..f84eed0 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2015,9 +2015,11 @@ static int __init omap_hsmmc_probe(struct
platform_device *pdev)
platform_set_drvdata(pdev, host);
INIT_WORK(host-mmc_carddetect_work, omap_hsmmc_detect);
+#ifdef CONFIG_PM
if (mmc_slot(host).power_saving)
mmc-ops= omap_hsmmc_ps_ops;
else
+#endif
mmc-ops= omap_hsmmc_ops;
/*
--
To unsubscribe from this list: send the line unsubscribe linux-mmc
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Regards,
Ghorai
--
To unsubscribe from this list: send the line unsubscribe linux-mmc
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] omap: hsmmc funtionality breaks when CONFIG_PM not define
Adrian,
-Original Message-
From: Adrian Hunter [mailto:adrian.hun...@nokia.com]
Sent: Tuesday, July 20, 2010 2:44 PM
To: Ghorai, Sukumar
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Shilimkar,
Santosh; Chikkature Rajashekar, Madhusudhan; Andrew Morton
Subject: Re: [PATCH] omap: hsmmc funtionality breaks when CONFIG_PM not
define
Ghorai, Sukumar wrote:
-Original Message-
From: Adrian Hunter [mailto:adrian.hun...@nokia.com]
Sent: Tuesday, July 20, 2010 2:10 PM
To: Ghorai, Sukumar
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Shilimkar,
Santosh; Chikkature Rajashekar, Madhusudhan; Andrew Morton
Subject: Re: [PATCH] omap: hsmmc funtionality breaks when CONFIG_PM not
define
Ghorai, Sukumar wrote:
Adrian,
-Original Message-
From: Adrian Hunter [mailto:adrian.hun...@nokia.com]
Sent: Tuesday, July 20, 2010 1:40 PM
To: Ghorai, Sukumar
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Shilimkar,
Santosh; Chikkature Rajashekar, Madhusudhan; Andrew Morton
Subject: Re: [PATCH] omap: hsmmc funtionality breaks when CONFIG_PM
not
define
Ghorai, Sukumar wrote:
-Original Message-
From: Adrian Hunter [mailto:adrian.hun...@nokia.com]
Sent: Tuesday, July 20, 2010 12:39 PM
To: Ghorai, Sukumar
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org;
Shilimkar,
Santosh; Chikkature Rajashekar, Madhusudhan; Andrew Morton
Subject: Re: [PATCH] omap: hsmmc funtionality breaks when CONFIG_PM
not
define
Sukumar Ghorai wrote:
Issue if power_saving option passed from board file and
CONFIG_PM
not define.
This is because hosts refer to wrong operation table and that
try
to
power save.
power_saving is not related to power management. It should work
with
or
without
CONFIG_PM. What problem are you seeing?
[Ghorai] when CONFIG_PM is not defined but power_saving flag is TRUE,
then host operation table point to table which handles in state
machine
as: ENABLE - CARDSLEEP - REGSLEEP - DISABLED for power/clock cut.
And
do the reverse for the enable clock/power.
And power saving is not required and wont work when CONFIG_PM is not
enabled.
How is that a problem? It would be useful to know what you need?
[Ghorai] do men when CONFIG_PM is not enabled still we should do power
saving in mmc?
Why not?
Because issue is iclk/fclk is quite depended on PRCM framework when we
are
using omap_hsmmc_ps_ops operation table.
iclk is left alone.
fclk is manipulated with or without power_saving.
I still do not understand your problem sorry :-(
[Ghorai] thanks and need input again,
we have two tables -
1. static const struct mmc_host_ops omap_hsmmc_ops = {
}
-- This is without CONFIG_PM, assumed.
No it is independent of CONFIG_PM
With CONFIG_PM
- the driver will restore registers if the host controller
has been powered off / on by PRCM
- suspend / resume can be used
2. static const struct mmc_host_ops omap_hsmmc_ps_ops = {
}
- this with CONFIG_PM, assumed.
No it is independent of CONFIG_PM
Without CONFIG_PM
- card will be put to sleep after 1 second
- card will be powered off after another 8 seconds
a. And you feel we should remove #1
Nothing should need to be removed.
b. use omap_hsmmc_ps_ops default.
With power_saving it is yes.
[Ghorai] Is it that power_saving (true or false) is independent of CONFIG_PM?
c. And it should work in all case?
It should work in all cases.
So if CONFIG_PM is not enable, then it should do simple clock
disable/enable, and not via the power state machine.
If that is what you want, simply change your board file:
#if CONFIG_PM
.power_saving = true,
#else
.power_saving = false,
#end
[Ghorai] the fix I send is to guard in MMC/SD host driver to avoid
mistake in board file(s). And this file is used for multiple omap3,
omap4
boards.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
CC: Madhusudhan Chikkature madhu...@ti.com
CC: Andrew Morton a...@linux-foundation.org
---
Tested on omap3, omap4430 ES2.0
drivers/mmc/host/omap_hsmmc.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c
b/drivers/mmc/host/omap_hsmmc.c
index b032828..f84eed0 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2015,9 +2015,11 @@ static int __init omap_hsmmc_probe(struct
platform_device *pdev)
platform_set_drvdata(pdev, host);
INIT_WORK(host-mmc_carddetect_work, omap_hsmmc_detect);
+#ifdef CONFIG_PM
if (mmc_slot(host).power_saving)
mmc-ops= omap_hsmmc_ps_ops;
else
+#endif
mmc-ops= omap_hsmmc_ops;
/*
--
To unsubscribe from this list: send the line
RE: [PATCH] mmc: csd version check updated to support MMC v4.41
-Original Message-
From: Sripathy, Vishwanath
Sent: Wednesday, July 14, 2010 5:23 PM
To: Ghorai, Sukumar; linux-...@vger.kernel.org; linux-omap@vger.kernel.org
Subject: RE: [PATCH] mmc: csd version check updated to support MMC v4.41
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Ghorai, Sukumar
Sent: Wednesday, July 14, 2010 1:51 PM
To: linux-...@vger.kernel.org; linux-omap@vger.kernel.org
Cc: Ghorai, Sukumar
Subject: [PATCH] mmc: csd version check updated to support MMC v4.41
CSD_STRUCTURE [127:126] describes the version of the CSD structure.
According to the MMC specificaiton (v4.4.1), 3 is also a valid number.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
Tested on omap4430 ES2.0
drivers/mmc/core/mmc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 89f7a25..525af33 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -122,7 +122,7 @@ static int mmc_decode_csd(struct mmc_card *card)
* v1.2 has extra information in bits 15, 11 and 10.
*/
csd_struct = UNSTUFF_BITS(resp, 126, 2);
- if (csd_struct != 1 csd_struct != 2) {
+ if (csd_struct 3) {
Can't csd_struct be 0? If so then your new check will break right?
[Ghorai] 0 to 3 are the valid numbers.
printk(KERN_ERR %s: unrecognised CSD structure version %d\n,
mmc_hostname(card-host), csd_struct);
return -EINVAL;
--
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] mmc: csd version check updated to support MMC v4.41
-Original Message-
From: kyungmi...@gmail.com [mailto:kyungmi...@gmail.com] On Behalf Of
Kyungmin Park
Sent: Wednesday, July 14, 2010 6:09 PM
To: Ghorai, Sukumar
Cc: Sripathy, Vishwanath; linux-...@vger.kernel.org; linux-
o...@vger.kernel.org
Subject: Re: [PATCH] mmc: csd version check updated to support MMC v4.41
Hi,
you can find it's already merged at mmc tree.
Try to find this one. [PATCH v2] Recognize CSD structure version 3
[Ghorai] Thanks I got it.
Thank you,
Kyungmin Park
On Wed, Jul 14, 2010 at 9:19 PM, Ghorai, Sukumar s-gho...@ti.com wrote:
-Original Message-
From: Sripathy, Vishwanath
Sent: Wednesday, July 14, 2010 5:23 PM
To: Ghorai, Sukumar; linux-...@vger.kernel.org; linux-
o...@vger.kernel.org
Subject: RE: [PATCH] mmc: csd version check updated to support MMC
v4.41
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Ghorai, Sukumar
Sent: Wednesday, July 14, 2010 1:51 PM
To: linux-...@vger.kernel.org; linux-omap@vger.kernel.org
Cc: Ghorai, Sukumar
Subject: [PATCH] mmc: csd version check updated to support MMC v4.41
CSD_STRUCTURE [127:126] describes the version of the CSD structure.
According to the MMC specificaiton (v4.4.1), 3 is also a valid
number.
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
Tested on omap4430 ES2.0
drivers/mmc/core/mmc.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 89f7a25..525af33 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -122,7 +122,7 @@ static int mmc_decode_csd(struct mmc_card *card)
* v1.2 has extra information in bits 15, 11 and 10.
*/
csd_struct = UNSTUFF_BITS(resp, 126, 2);
- if (csd_struct != 1 csd_struct != 2) {
+ if (csd_struct 3) {
Can't csd_struct be 0? If so then your new check will break right?
[Ghorai] 0 to 3 are the valid numbers.
printk(KERN_ERR %s: unrecognised CSD structure
version %d\n,
mmc_hostname(card-host), csd_struct);
return -EINVAL;
--
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-mmc 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 v6 0/3] omap3 nand: cleanup exiting platform related code
Tony, -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Friday, July 09, 2010 2:03 PM To: Ghorai, Sukumar Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org Subject: Re: [PATCH v6 0/3] omap3 nand: cleanup exiting platform related code * Sukumar Ghorai s-gho...@ti.com [100709 10:19]: 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. Looks good to me, thanks for doing this. One more request: Please repost this series one more time with linux-arm- kernel mailing list Cc'd. Then if no comments, I'll merge this series during the next merge window. [Ghorai] Thanks. And would you please check if you have any input on following patch series? Otherwise I will rework on this and send again. We need those patches in this time. 1. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg30735.html 2. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg31471.html Regards, Ghorai -- 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 2/3] omap3 nand: cleanup virtual address usages
Tony,
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Wednesday, July 07, 2010 3:52 PM
To: Ghorai, Sukumar
Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org;
m...@compulab.co.il
Subject: Re: [PATCH v5 2/3] omap3 nand: cleanup virtual address usages
* Sukumar Ghorai s-gho...@ti.com [100604 10:34]:
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -63,7 +60,6 @@
#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(2)
#define GPMC_CONFIG1_MUXADDDATA (1 9)
#define GPMC_CONFIG1_TIME_PARA_GRAN (1 4)
#define GPMC_CONFIG1_FCLK_DIV(val) (val 3)
Is this no longer needed?
[Ghorai] we pass GPMC_CONFIG_DEV_TYPE and GPMC_DEVICETYPE_NAND to
gpmc_hwcontrol(); And GPMC_DEVICETYPE_NAND define in previous patch of the same
series.
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -21,13 +21,11 @@ struct omap_nand_platform_data {
int (*dev_ready)(struct omap_nand_platform_data *);
int dma_channel;
unsigned long phys_base;
- void __iomem*gpmc_cs_baseaddr;
- void __iomem*gpmc_baseaddr;
int devsize;
};
Glad to see these finally going away!
Regards,
Tony
--
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 06/15] omap zoom2: wlan board muxing
-Original Message-
From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
ow...@vger.kernel.org] On Behalf Of Ohad Ben-Cohen
Sent: Tuesday, July 06, 2010 6:08 AM
To: linux-wirel...@vger.kernel.org; linux-...@vger.kernel.org; linux-
o...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org; li...@arm.linux.org.uk;
Chikkature Rajashekar, Madhusudhan; Luciano Coelho; a...@linux-
foundation.org; San Mehat; Ben-cohen, Ohad
Subject: [PATCH 06/15] omap zoom2: wlan board muxing
From: Ohad Ben-Cohen oh...@ti.com
Add board muxing to support the wlan wl1271 chip that is
hardwired to mmc2 (third mmc controller) on the ZOOM2.
Signed-off-by: Ohad Ben-Cohen oh...@ti.com
---
arch/arm/mach-omap2/board-zoom2.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom2.c b/arch/arm/mach-
omap2/board-zoom2.c
index 803ef14..00871be 100644
--- a/arch/arm/mach-omap2/board-zoom2.c
+++ b/arch/arm/mach-omap2/board-zoom2.c
@@ -71,6 +71,21 @@ static struct twl4030_platform_data zoom2_twldata = {
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
+#ifdef CONFIG_OMAP_ZOOM_WLAN
[Ghorai] This is zoom board specific file, So why need this additional flag?
+ /* WLAN IRQ - GPIO 162 */
+ OMAP3_MUX(MCBSP1_CLKX, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP),
+ /* WLAN POWER ENABLE - GPIO 101 */
+ OMAP3_MUX(CAM_D2, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
+ /* WLAN SDIO: MMC3 CMD */
+ OMAP3_MUX(MCSPI1_CS1, OMAP_MUX_MODE3 | OMAP_PIN_INPUT_PULLUP),
+ /* WLAN SDIO: MMC3 CLK */
+ OMAP3_MUX(ETK_CLK, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+ /* WLAN SDIO: MMC3 DAT[0-3] */
+ OMAP3_MUX(ETK_D3, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(ETK_D4, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(ETK_D5, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+ OMAP3_MUX(ETK_D6, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
+#endif
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#else
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-mmc 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 04/15] mmc: support embedded data field in mmc_host
-Original Message-
From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
ow...@vger.kernel.org] On Behalf Of Ohad Ben-Cohen
Sent: Tuesday, July 06, 2010 6:08 AM
To: linux-wirel...@vger.kernel.org; linux-...@vger.kernel.org; linux-
o...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org; li...@arm.linux.org.uk;
Chikkature Rajashekar, Madhusudhan; Luciano Coelho; a...@linux-
foundation.org; San Mehat; Ben-cohen, Ohad
Subject: [PATCH 04/15] mmc: support embedded data field in mmc_host
From: Ohad Ben-Cohen oh...@ti.com
Add support to set/get mmc_host private embedded
data.
This is needed to allow software to dynamically
create (and remove) SDIO functions which represents
embedded SDIO devices.
Typically, it will be used to set the context of
a driver that is creating a new SDIO function
(and would then expect to be able to get that context
back upon creation of the new sdio func).
Signed-off-by: Ohad Ben-Cohen oh...@ti.com
---
drivers/mmc/core/Kconfig |8
include/linux/mmc/host.h | 16
2 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
index bb22ffd..ab27eb3 100644
--- a/drivers/mmc/core/Kconfig
+++ b/drivers/mmc/core/Kconfig
@@ -16,3 +16,11 @@ config MMC_UNSAFE_RESUME
This option sets a default which can be overridden by the
module parameter removable=0 or removable=1.
+
+config MMC_EMBEDDED_SDIO
+ boolean MMC embedded SDIO device support
+ help
+ If you say Y here, support will be added for embedded SDIO
+ devices (e.g. hardwired embedded WLAN SDIO devices).
+ Such devices require software support for emulating
+ card detect events.
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index f65913c..9a48486 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -209,6 +209,10 @@ struct mmc_host {
struct led_trigger *led; /* activity led */
#endif
+#ifdef CONFIG_MMC_EMBEDDED_SDIO
+ void*embedded_data;
+#endif
+
struct dentry *debugfs_root;
unsigned long private[0] cacheline_aligned;
@@ -264,5 +268,17 @@ static inline void mmc_set_disable_delay(struct
mmc_host *host,
host-disable_delay = disable_delay;
}
+#ifdef CONFIG_MMC_EMBEDDED_SDIO
+static inline void *mmc_get_embedded_data(struct mmc_host *host)
+{
+ return host-embedded_data;
+}
+
+static inline void mmc_set_embedded_data(struct mmc_host *host, void
*data)
+{
+ host-embedded_data = data;
+}
+#endif
+
[Ghorai] we can avoid CONFIG_MMC_EMBEDDED_SDIO flag itself. Why we are passing
fixed data? We can enquire form card for the functions, features,.. and at
runtime itself. And we are adding many compile-time/kconfig options in this
patch series.
#endif
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-mmc 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 00/15] wlan+omap+mmc: out-of-the-box WLAN support for ZOOM2/3
-Original Message- From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc- ow...@vger.kernel.org] On Behalf Of Ohad Ben-Cohen Sent: Tuesday, July 06, 2010 6:08 AM To: linux-wirel...@vger.kernel.org; linux-...@vger.kernel.org; linux- o...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org; li...@arm.linux.org.uk; Chikkature Rajashekar, Madhusudhan; Luciano Coelho; a...@linux- foundation.org; San Mehat; Ben-cohen, Ohad Subject: [PATCH 00/15] wlan+omap+mmc: out-of-the-box WLAN support for ZOOM2/3 From: Ohad Ben-Cohen oh...@ti.com The ZOOM2/3 boards include TI's wl1271 wlan sdio device, hardwired to the 3rd mmc controller. These patches add support for WLAN on the ZOOM2/3 boards using only mainline components (most notably mac80211 and wl1271). Patches were tested on both ZOOM2 and ZOOM3. In short, these patches add software control for emulating card detect events, add board configurations to support the wl1271 device, and update the wl1271 driver to make use of these new mechanisms. Software card detect emulation is based on Android's EMBEDDED_SDIO patch by San Mehat s...@google.com (thanks, San!). These patches span over several differnt subsystems, but since they are highly dependent on each other, it is preferrable to pull them all together into a single tree (once approved). Patches are available at: git://wizery.com/pub/linux-2.6.git wl1271 And will also be sent as a follow-on to this message to the omap, mmc, arm and wireless mailing lists. Patches are based on mainline 2.6.35-rc4, but can easily be applied on wireless-testing (with two minor conflicts). If desired, I can rebase to wireless-testing and resend. Note: last missing part for full mainline community support of the wl1271 on ZOOM is the firmware, and for that there is already on-going TI work to provide it in linux-firmware. Hopefully that would be resolved soon. Thanks, Ohad Ben-Cohen (15): sdio: add TI + wl1271 ids wireless: wl1271: remove SDIO IDs from driver omap: mmc: prepare for software card detect support mmc: support embedded data field in mmc_host omap: hsmmc: add virtual card detect support omap zoom2: wlan board muxing omap zoom3: wlan board muxing wireless: wl1271: make wl12xx.h common to both spi and sdio wireless: wl12xx: support pdata SDIO handlers wireless: wl1271: support return value for the set power func wireless: wl1271: introduce platform device support wireless: wl1271: take irq info from platform data wireless: wl1271: make ref_clock configurable by board omap: zoom: add WLAN device omap: zoom: enable WLAN device arch/arm/mach-omap2/Kconfig |5 + arch/arm/mach-omap2/Makefile |1 + arch/arm/mach-omap2/board-zoom-peripherals.c | 15 ++ arch/arm/mach-omap2/board-zoom-wlan.c | 129 arch/arm/mach-omap2/board-zoom2.c | 15 ++ arch/arm/mach-omap2/board-zoom3.c | 15 ++ arch/arm/mach-omap2/hsmmc.c |4 + arch/arm/mach-omap2/hsmmc.h |5 + arch/arm/mach-omap2/include/mach/board-zoom.h |5 + arch/arm/plat-omap/include/plat/mmc.h |5 + drivers/mmc/core/Kconfig |8 + drivers/mmc/host/omap_hsmmc.c | 37 +- drivers/net/wireless/wl12xx/Kconfig |1 + drivers/net/wireless/wl12xx/wl1251_sdio.c |2 +- drivers/net/wireless/wl12xx/wl1251_spi.c |2 +- drivers/net/wireless/wl12xx/wl1271.h |8 +- drivers/net/wireless/wl12xx/wl1271_boot.c | 13 +- drivers/net/wireless/wl12xx/wl1271_boot.h |1 - drivers/net/wireless/wl12xx/wl1271_io.h |8 +- drivers/net/wireless/wl12xx/wl1271_main.c |4 +- drivers/net/wireless/wl12xx/wl1271_sdio.c | 204 +++- - drivers/net/wireless/wl12xx/wl1271_spi.c |8 +- include/linux/mmc/host.h | 16 ++ include/linux/mmc/sdio_ids.h |3 + include/linux/spi/wl12xx.h| 34 include/linux/wl12xx.h| 37 + 26 files changed, 486 insertions(+), 99 deletions(-) create mode 100644 arch/arm/mach-omap2/board-zoom-wlan.c delete mode 100644 include/linux/spi/wl12xx.h create mode 100644 include/linux/wl12xx.h [Ghorai] This patch series having the CONFIG_MMC_EMBEDDED_SDIO as kconfig option and I feel we should void this. This could be a generic and can be get from sdio card at runtime. Quite long codes are adding in this patch series under this flag. -- To unsubscribe from this list: send the line unsubscribe linux-mmc 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
RE: [PATCH 15/15] omap: zoom: enable WLAN device
-Original Message-
From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
ow...@vger.kernel.org] On Behalf Of Ohad Ben-Cohen
Sent: Tuesday, July 06, 2010 6:08 AM
To: linux-wirel...@vger.kernel.org; linux-...@vger.kernel.org; linux-
o...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org; li...@arm.linux.org.uk;
Chikkature Rajashekar, Madhusudhan; Luciano Coelho; a...@linux-
foundation.org; San Mehat; Ben-cohen, Ohad
Subject: [PATCH 15/15] omap: zoom: enable WLAN device
From: Ohad Ben-Cohen oh...@ti.com
Make it possible to build and use TI's wl1271
device on the ZOOM boards.
The device is an embedded SDIO WLAN chip
that is hardwired to the 3rd mmc controller
of the ZOOM2/3 boards.
Signed-off-by: Ohad Ben-Cohen oh...@ti.com
---
arch/arm/mach-omap2/Kconfig |5 +
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-zoom-peripherals.c | 15 +++
3 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index b31b6f1..7fee11b 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -131,6 +131,11 @@ config MACH_OMAP_ZOOM3
depends on ARCH_OMAP3
select OMAP_PACKAGE_CBP
+config OMAP_ZOOM_WLAN
+ bool OMAP Zoom board WLAN support
+ depends on MACH_OMAP_ZOOM2 || MACH_OMAP_ZOOM3
+ select MMC_EMBEDDED_SDIO
+
config MACH_CM_T35
bool CompuLab CM-T35 module
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index ea52b03..ac1bad9 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -129,6 +129,7 @@ obj-$(CONFIG_MACH_OMAP_ZOOM3) += board-
zoom3.o \
board-zoom-peripherals.o \
hsmmc.o \
board-zoom-debugboard.o
+obj-y+= board-zoom-wlan.o
obj-$(CONFIG_MACH_OMAP_3630SDP) += board-3630sdp.o \
board-zoom-peripherals.o \
hsmmc.o
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c b/arch/arm/mach-
omap2/board-zoom-peripherals.c
index 6b39849..3128cd4 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -16,11 +16,13 @@
#include linux/gpio.h
#include linux/i2c/twl.h
#include linux/regulator/machine.h
+#include linux/mmc/host.h
#include asm/mach-types.h
#include asm/mach/arch.h
#include asm/mach/map.h
+#include mach/board-zoom.h
#include plat/common.h
#include plat/usb.h
@@ -168,6 +170,18 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
.nonremovable = true,
.power_saving = true,
},
+#ifdef CONFIG_OMAP_ZOOM_WLAN
+ {
+ .mmc= 3,
+ .wires = 4,
+ .gpio_cd= -EINVAL,
+ .gpio_wp= -EINVAL,
+ .register_embedded_control =
+ omap_zoom_wlan_register_embedded_control,
+ .virtual_get_cd = omap_zoom_wlan_get_virtual_cd,
+ .ocr_mask = MMC_VDD_165_195,
+ },
+#endif
{} /* Terminator */
};
@@ -282,4 +296,5 @@ void __init zoom_peripherals_init(void)
omap_i2c_init();
usb_musb_init(musb_board_data);
enable_board_wakeup_source();
+ omap_zoom_wlan_init();
}
[Ghorai] In general we can avoid OMAP_ZOOM_WLAN and MMC_EMBEDDED_SDIO as
kconfig option. 1st one is board specific and 2nd one could be generic sdio
code. As I mentioned in other patch too.
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-mmc 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 14/15] omap: zoom: add WLAN device
-Original Message-
From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
ow...@vger.kernel.org] On Behalf Of Ohad Ben-Cohen
Sent: Tuesday, July 06, 2010 6:08 AM
To: linux-wirel...@vger.kernel.org; linux-...@vger.kernel.org; linux-
o...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org; li...@arm.linux.org.uk;
Chikkature Rajashekar, Madhusudhan; Luciano Coelho; a...@linux-
foundation.org; San Mehat; Ben-cohen, Ohad
Subject: [PATCH 14/15] omap: zoom: add WLAN device
From: Ohad Ben-Cohen oh...@ti.com
Add WLAN platform device and control
functions (power and virtual card detect)
in order to allow software to control the
embedded SDIO WLAN device which resides on
the ZOOM board (TI's wl1271 device).
Based on Android's WLAN control functions by
San Mehat s...@android.com.
Signed-off-by: Ohad Ben-Cohen oh...@ti.com
---
arch/arm/mach-omap2/board-zoom-wlan.c | 129
+
arch/arm/mach-omap2/include/mach/board-zoom.h |5 +
2 files changed, 134 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-zoom-wlan.c
diff --git a/arch/arm/mach-omap2/board-zoom-wlan.c b/arch/arm/mach-
omap2/board-zoom-wlan.c
new file mode 100644
index 000..7ed5139
--- /dev/null
+++ b/arch/arm/mach-omap2/board-zoom-wlan.c
@@ -0,0 +1,129 @@
+/* mach-omap2/board-zoom-wlan.c
+ *
+ * Board support for wl1271 embedded SDIO device.
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public
License
+ * version 2. This program is licensed as is without any warranty of
any
+ * kind, whether express or implied.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/mmc/host.h
+#include linux/mmc/sdio_ids.h
+#include linux/err.h
+#include linux/gpio.h
+#include linux/wl12xx.h
+
+#include mux.h
+
+#ifdef CONFIG_OMAP_ZOOM_WLAN
[Ghorai] Again the file itself is zoom specific, why we need the additional
flag?
+
+/* these are zoom-specific board numbers */
+#define OMAP_ZOOM_WLAN_PMENA_GPIO(101)
+#define OMAP_ZOOM_WLAN_IRQ_GPIO (162)
+
+/* wl1271 virtual 'card detect' status */
+static int omap_zoom_wlan_cd;
+static void (*wlan_set_virtual_cd)(void *dev_id, int card_present);
+static void (*wlan_set_data)(void *dev_id, void *priv);
+static void *wlan_host_devid;
+
+int omap_zoom_wlan_register_embedded_control(void *dev_id,
+ void (*set_virtual_cd)(void *dev_id, int card_present),
+ void (*set_data)(void *dev_id, void *priv))
+{
+ if (wlan_host_devid || wlan_set_virtual_cd || wlan_set_data)
+ return -EBUSY;
+
+ wlan_set_virtual_cd = set_virtual_cd;
+ wlan_set_data = set_data;
+ wlan_host_devid = dev_id;
+
+ return 0;
+}
+
+int omap_zoom_wlan_get_virtual_cd(void)
+{
+ return omap_zoom_wlan_cd;
+}
+
+static void omap_zoom_wlan_set_embedded_data(void *priv)
+{
+ if (wlan_set_data)
+ wlan_set_data(wlan_host_devid, priv);
+ else
+ pr_err(%s: host controller not registered yet\n, __func__);
+}
+
+static void omap_zoom_wlan_set_carddetect(bool card_present)
+{
+ omap_zoom_wlan_cd = card_present ? 1 : 0;
+
+ pr_info(%s: %d\n, __func__, omap_zoom_wlan_cd);
+
+ if (wlan_set_virtual_cd)
+ wlan_set_virtual_cd(wlan_host_devid, omap_zoom_wlan_cd);
+ else
+ pr_err(%s: host controller not registered yet\n, __func__);
+}
+
+static void omap_zoom_wlan_power(bool enable)
+{
+ int val = enable ? 1 : 0;
+
+ pr_info(%s: set power %d\n, __func__, val);
+
+ gpio_set_value(OMAP_ZOOM_WLAN_PMENA_GPIO, val);
+}
+
+struct wl12xx_platform_data omap_zoom_wlan_control = {
+ .set_power = omap_zoom_wlan_power,
+ .set_carddetect = omap_zoom_wlan_set_carddetect,
+ .set_embedded_data = omap_zoom_wlan_set_embedded_data,
+ /* ZOOM ref clock is 26 MHz */
+ .board_ref_clock = 1,
+ .irq = OMAP_GPIO_IRQ(OMAP_ZOOM_WLAN_IRQ_GPIO),
+};
+
+static struct platform_device omap_zoom_wlan_device = {
+ .name = wl1271_sdio,
+ .id = 1,
+ .dev = {
+ .platform_data = omap_zoom_wlan_control,
+ },
+};
+
+int __init omap_zoom_wlan_init(void)
+{
+ int ret;
+
+ ret = gpio_request(OMAP_ZOOM_WLAN_PMENA_GPIO, wlan_power);
+ if (ret 0) {
+ pr_err(%s: power gpio request failed: %d\n, __func__, ret);
+ return ret;
+ }
+
+ gpio_direction_output(OMAP_ZOOM_WLAN_PMENA_GPIO, 0);
+
+ ret = gpio_request(OMAP_ZOOM_WLAN_IRQ_GPIO, wlan_irq);
+ if (ret 0) {
+ pr_err(%s: gpio request failed: %d\n, __func__, ret);
+ return ret;
+ }
+ gpio_direction_input(OMAP_ZOOM_WLAN_IRQ_GPIO);
+
+ ret = platform_device_register(omap_zoom_wlan_device);
+
+ return ret;
+}
+
+#else
RE: [PATCH v5 1/3] omap3 gpmc: functionality enhancement
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Wednesday, July 07, 2010 6:32 PM To: Ghorai, Sukumar Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org; m...@compulab.co.il Subject: Re: [PATCH v5 1/3] omap3 gpmc: functionality enhancement * Ghorai, Sukumar s-gho...@ti.com [100707 15:26]: From: Tony Lindgren [mailto:t...@atomide.com] You should just replace this function with simple functions like we already have in gpmc.c rather than trying to pack everything into one function. Just add various gpmc_xxx_get/set functions rather than pass int *rval. [Ghorai] So I was having the same query very 1st time. So we need to implement 15 separate functions to do the same as you suggested. And in my approach it's very easy to enhance the functionally in future, say to add new set/get. E.g. we need the similar cleanup for OneNAND code too. So, would you please confirm once again with one is the best and should follow? In general, we should have separate read and write functions. Maybe you can group them a little bit? Some of them need the chip select, and some of them are generic. Then some of them are NAND specific. [Ghorai] ok. And let me re-work this for next version. Regards, Tony -- 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/8] omap3 flash: rename board-sdp-flash.c to be use by other boards
Tony, -Original Message- From: Shilimkar, Santosh Sent: Tuesday, July 06, 2010 11:35 AM To: Tony Lindgren; Ghorai, Sukumar Cc: linux-omap@vger.kernel.org Subject: RE: [PATCH v3 1/8] omap3 flash: rename board-sdp-flash.c to be use by other boards Sukumar, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Monday, July 05, 2010 5:53 PM To: Ghorai, Sukumar Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH v3 1/8] omap3 flash: rename board-sdp-flash.c to be use by other boards * Sukumar Ghorai s-gho...@ti.com [100616 14:34]: rename board-sdp-flash.c(board-flash.c) and board-sdp.h(board-flash.h) to used by other board e.g. zoom Signed-off-by: Sukumar Ghorai s-gho...@ti.com --- arch/arm/mach-omap2/Makefile |2 +- arch/arm/mach-omap2/board-3430sdp.c| 16 ++- arch/arm/mach-omap2/board-flash.c | 253 ++ arch/arm/mach-omap2/board-sdp-flash.c | 267 --- -- --- arch/arm/mach-omap2/include/mach/board-flash.h | 28 +++ arch/arm/mach-omap2/include/mach/board-sdp.h | 21 -- 6 files changed, 296 insertions(+), 291 deletions(-) create mode 100755 arch/arm/mach-omap2/board-flash.c delete mode 100755 arch/arm/mach-omap2/board-sdp-flash.c create mode 100644 arch/arm/mach-omap2/include/mach/board-flash.h delete mode 100644 arch/arm/mach-omap2/include/mach/board-sdp.h Looks like this one won't apply: patching file arch/arm/mach-omap2/board-sdp-flash.c Hunk #1 FAILED at 1. File arch/arm/mach-omap2/board-sdp-flash.c is not empty after patch, as expected Try git format-patch -M when creating renaming patch. [Ghorai] Thanks Tony Santosh.. And I think I understood the problem of my format-patch option. Please check with the attached patch(updated). Regards, Ghorai 0001-omap3-flash-rename-board-sdp-flash.c-to-be-use-by-o.patch Description: 0001-omap3-flash-rename-board-sdp-flash.c-to-be-use-by-o.patch
RE: [PATCH v3 6/8] omap-3630-sdp: enable Flash device support
Tony, -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Monday, July 05, 2010 5:57 PM To: Ghorai, Sukumar Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH v3 6/8] omap-3630-sdp: enable Flash device support * Sukumar Ghorai s-gho...@ti.com [100616 14:34]: update config file to support for NAND, OneNAND, NOR on omap 3630-sdp board. Let's drop all the defconfig changes from this series, we won't be patching the defconfigs any longer as requested by Linus. [Ghorai] That's fine. Regards, Ghorai Regards, Tony -- 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
Tony, Please let me know if any have input on following two series. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg30305.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg30735.html Regards, Ghorai -Original Message- From: Ghorai, Sukumar Sent: Tuesday, June 15, 2010 6:57 PM To: 'Tony Lindgren' Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org; t...@atomide.com; m...@compulab.co.il; 'Vimal Singh' Subject: RE: [PATCH v5 0/3] omap3 nand: cleanup exiting platform related code Tony, -Original Message- From: Vimal Singh [mailto:vimal.neww...@gmail.com] Sent: Tuesday, June 08, 2010 10:43 PM To: Ghorai, Sukumar Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org; t...@atomide.com; m...@compulab.co.il Subject: 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- o...@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- o...@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- o...@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- o...@vger.kernel.org/msg28467.html v1: http://www.mail-archive.com/linux- o...@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(-) [Ghorai] Any comments or input on these patch? -- 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] Disable the non working eMMC on Zoom2/3
-Original Message- From: zhangfei gao [mailto:zhangfei@gmail.com] Sent: Thursday, June 24, 2010 4:26 PM To: Ghorai, Sukumar Cc: Chikkature Rajashekar, Madhusudhan; Tony Lindgren; Menon, Nishanth; linux-omap@vger.kernel.org; linux-...@vger.kernel.org Subject: Re: [PATCH] Disable the non working eMMC on Zoom2/3 On Tue, Jun 22, 2010 at 7:43 PM, Ghorai, Sukumar s-gho...@ti.com wrote: -Original Message- From: zhangfei gao [mailto:zhangfei@gmail.com] Sent: Tuesday, June 22, 2010 4:51 PM To: Chikkature Rajashekar, Madhusudhan Cc: Tony Lindgren; Menon, Nishanth; Ghorai, Sukumar; linux- o...@vger.kernel.org; linux-...@vger.kernel.org Subject: Re: [PATCH] Disable the non working eMMC on Zoom2/3 On Sat, May 8, 2010 at 5:25 AM, Madhusudhan madhu...@ti.com wrote: -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Thursday, May 06, 2010 10:31 AM To: Madhusudhan Cc: 'Nishanth Menon'; 'Ghorai, Sukumar'; linux-omap@vger.kernel.org; linux-...@vger.kernel.org Subject: Re: [PATCH] Disable the non working eMMC on Zoom2/3 * Madhusudhan madhu...@ti.com [100505 18:31]: -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] And what about this Simulate multi mmc card as one big patch? Did not get you, what patch are you referring to? Oops sorry forgot the link: https://patchwork.kernel.org/patch/87944/ This will not help. I don't know the history of the patch but what this is intended for is to support multiple MMC cards connected to a single controller. But on the Zoom the eMMC we are talking about is connected to MMC2. Regards, Madhu Tony -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Hi, Guys Just wander whether 16G Micron eMMC works on your platform. I also have such issue, 16G Micron emmc can not work with read and write, with data timeout. While 8G Micron eMMC workable. Do you have the same issue? [Ghorai] we have 16G eMMC in ZOOM3 and 3630-SDP and its working fine. Let me know what board you are using. mmc1: new high speed MMC card at address 0001 PM: Adding info for mmc:mmc1:0001 mmcblk0: mmc1:0001 STM16G 14.8 GiB PM: Adding info for No Bus:mmcblk0 mmcblk0: p1 p2 Thanks Hi, Ghorai Thanks for your valueable info. We also enabled Micron 16G eMMC, two issues stuck us before. 1. The bus_width should be inited otherwise read ext_csd would be fail. 2. The emmc may stay in boot partition and kernel should switch to user partition, where filesystem is located. [Ghorai] 1. If my understanding is not wrong, then the same problem exists in external MMC card too. 2. So, can you share your eMMC log, just to check if I have any clue! Or let me know how I can reproduce the issue. Thanks -- 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: ZOOM2 doesn't boot on upstream kernel
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Neshama Parhoti Sent: Wednesday, June 23, 2010 12:12 AM To: linux-omap@vger.kernel.org Subject: ZOOM2 doesn't boot on upstream kernel Hi all, I can't get to boot the latest mainline kernel on ZOOM2 (using omap_zoom2_defconfig). [Ghorai] It's working for me. 1. console=ttyS0 2. And can you try omap3_defconfig It just hangs after u-boot is saying loading kernel I know that my setup is ok, because if I use TI kernel sources from my BSP it boots fine.. Any idea what is the problem ? Maybe I need to use also recent upstream u-boot ? thank you ~pnesh -- 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] Disable the non working eMMC on Zoom2/3
-Original Message- From: zhangfei gao [mailto:zhangfei@gmail.com] Sent: Tuesday, June 22, 2010 4:51 PM To: Chikkature Rajashekar, Madhusudhan Cc: Tony Lindgren; Menon, Nishanth; Ghorai, Sukumar; linux- o...@vger.kernel.org; linux-...@vger.kernel.org Subject: Re: [PATCH] Disable the non working eMMC on Zoom2/3 On Sat, May 8, 2010 at 5:25 AM, Madhusudhan madhu...@ti.com wrote: -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Thursday, May 06, 2010 10:31 AM To: Madhusudhan Cc: 'Nishanth Menon'; 'Ghorai, Sukumar'; linux-omap@vger.kernel.org; linux-...@vger.kernel.org Subject: Re: [PATCH] Disable the non working eMMC on Zoom2/3 * Madhusudhan madhu...@ti.com [100505 18:31]: -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] And what about this Simulate multi mmc card as one big patch? Did not get you, what patch are you referring to? Oops sorry forgot the link: https://patchwork.kernel.org/patch/87944/ This will not help. I don't know the history of the patch but what this is intended for is to support multiple MMC cards connected to a single controller. But on the Zoom the eMMC we are talking about is connected to MMC2. Regards, Madhu Tony -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Hi, Guys Just wander whether 16G Micron eMMC works on your platform. I also have such issue, 16G Micron emmc can not work with read and write, with data timeout. While 8G Micron eMMC workable. Do you have the same issue? [Ghorai] we have 16G eMMC in ZOOM3 and 3630-SDP and its working fine. Let me know what board you are using. mmc1: new high speed MMC card at address 0001 PM: Adding info for mmc:mmc1:0001 mmcblk0: mmc1:0001 STM16G 14.8 GiB PM: Adding info for No Bus:mmcblk0 mmcblk0: p1 p2 Thanks -- 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
Tony, -Original Message- From: Vimal Singh [mailto:vimal.neww...@gmail.com] Sent: Tuesday, June 08, 2010 10:43 PM To: Ghorai, Sukumar Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org; t...@atomide.com; m...@compulab.co.il Subject: 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- o...@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- o...@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- o...@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- o...@vger.kernel.org/msg28467.html v1: http://www.mail-archive.com/linux- o...@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(-) [Ghorai] Any comments or input on these patch? -- 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
-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?
--
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
--
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
Hello Tony, I need your comment/input - whether we need an additional file for NAND support in ZOOM2/3? In current codebase has a board-sdp-flash.c file. I think we can remove -sdp- from board-sdp-flash.c and reuse the file for ZOOM boards or any other upcoming board(s). Advantage: a. No need to add any additional file like board-zoom-flash.c b. And the existing board-sdp-flash.c is very small and easily re-use for zoom boards easily. Disadvantage: a. Few additional functions in the same file for NOR and OneNAND is not applicable for zoom. b. rename the file board-sdp-flash.c to board-flash.c c. Remove the static of board_nand_init() and additional one line for zoom board checking. Please let me know your opinion. Regards, Ghorai -Original Message- From: Ghorai, Sukumar Sent: Tuesday, April 13, 2010 11:07 PM To: linux-omap@vger.kernel.org Cc: Ghorai, Sukumar Subject: [PATCH] nand support on omap3 boards The following set of patches applies on top of the Tony's master branch. And these are the patches required to enable nand (nor and onenand for sdp only) for different platform. Sukumar Ghorai (3): OMAP: ZOOM: Introducing 'board-zoom-flash.c' omap3: add support for NAND on zoom2 board omap3: add support for NAND on zoom3 board omap-3630-sdp : Add support for Flash omap-3630-sdp: enable Flash device support omap3: add support for NAND on LDP board zoom2: enable NAND support zoom3: enable NAND support arch/arm/configs/omap_3630sdp_defconfig | 77 +- arch/arm/configs/omap_zoom2_defconfig | 90 - arch/arm/configs/omap_zoom3_defconfig | 90 - arch/arm/mach-omap2/Makefile |4 + arch/arm/mach-omap2/board-3630sdp.c | 110 + arch/arm/mach-omap2/board-ldp.c | 41 + arch/arm/mach-omap2/board-sdp-flash.c |2 + arch/arm/mach-omap2/board-zoom-flash.c| 82 ++ arch/arm/mach-omap2/board-zoom2.c | 49 +++ arch/arm/mach-omap2/board-zoom3.c | 48 +++ arch/arm/mach-omap2/include/mach/board-zoom.h | 11 +++ 11 files changed, 601 insertions(+), 3 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
RE: [PATCH v4 1/3] omap3 gpmc: functionality enhancement
-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?
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.
3. Still you think problem? Let me know..
--
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
-Original Message-
From: Vimal Singh [mailto:vimal.neww...@gmail.com]
Sent: Saturday, May 29, 2010 12:20 AM
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 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.
[Ghorai] I says.. 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.
What's wrong?
--
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
Vimal,
-Original Message-
From: Vimal Singh [mailto:vimal.neww...@gmail.com]
Sent: Thursday, May 20, 2010 12:01 AM
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.
[Ghorai] Agree.
[...]
+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.
[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.
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] As above.
[...]
+int gpmc_ecc_reset(int cs)
+{
+ if (gpmc_ecc_used == cs)
+ gpmc_ecc_used = -EINVAL;
+ else
+ return -EINVAL;
+
+ return 0;
+}
I guess in this function you should also clear gpmc ecc config
register explicitly.
--
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
RE: [PATCH v3 1/3] omap3 gpmc: functionality enhancement
Vimal,
-Original Message-
From: Peter Barada [mailto:peter.bar...@gmail.com]
Sent: 2010-05-19 21:18
To: Vimal Singh
Cc: Ghorai, Sukumar; linux-omap@vger.kernel.org; linux-
m...@lists.infradead.org; t...@atomide.com; sako...@gmail.com;
m...@compulab.co.il; artem.bityuts...@nokia.com
Subject: Re: [PATCH v3 1/3] omap3 gpmc: functionality enhancement
On Wed, 2010-05-19 at 20:16 +0530, Vimal Singh wrote:
On Tue, May 18, 2010 at 4:46 PM, Sukumar Ghorai s-gho...@ti.com wrote:
few functions added in gpmc module and to be used by other drivers
like NAND.
E.g.: - ioctl function
- ecc functions
Signed-off-by: Sukumar Ghorai s-gho...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 246
+++-
arch/arm/plat-omap/include/plat/gpmc.h | 35 -
drivers/mtd/nand/omap2.c |4 +-
3 files changed, 274 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 5bc3ca0..7e6d821
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -46,8 +46,9 @@
#define GPMC_ECC_CONFIG0x1f4
#define GPMC_ECC_CONTROL 0x1f8
#define GPMC_ECC_SIZE_CONFIG 0x1fc
+#define GPMC_ECC1_RESULT0x200
-#define GPMC_CS0 0x60
+#define GPMC_CS0_BASE 0x60
#define GPMC_CS_SIZE 0x30
#define GPMC_MEM_START 0x
@@ -92,7 +93,9 @@ struct omap3_gpmc_regs {
static struct resource gpmc_mem_root;
static struct resource gpmc_cs_mem[GPMC_CS_NUM];
static DEFINE_SPINLOCK(gpmc_mem_lock);
-static unsignedgpmc_cs_map;
+static unsignedint gpmc_cs_map;/* flag for cs which
are initialized */
+static int gpmc_pref_used = -EINVAL; /* cs using prefetch engine */
+static int gpmc_ecc_used = -EINVAL;/* cs using ecc engine */
static void __iomem *gpmc_base;
@@ -108,11 +111,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);
+}
+
void gpmc_cs_write_reg(int cs, int idx, u32 val)
{
void __iomem *reg_addr;
- reg_addr = gpmc_base + GPMC_CS0 + (cs * GPMC_CS_SIZE) + idx;
+ reg_addr = gpmc_base + GPMC_CS0_BASE + (cs * GPMC_CS_SIZE) +
idx;
__raw_writel(val, reg_addr);
}
@@ -120,7 +139,7 @@ u32 gpmc_cs_read_reg(int cs, int idx)
{
void __iomem *reg_addr;
- reg_addr = gpmc_base + GPMC_CS0 + (cs * GPMC_CS_SIZE) + idx;
+ reg_addr = gpmc_base + GPMC_CS0_BASE + (cs * GPMC_CS_SIZE) +
idx;
return __raw_readl(reg_addr);
}
@@ -419,8 +438,100 @@ void gpmc_cs_free(int cs)
EXPORT_SYMBOL(gpmc_cs_free);
/**
+ * gpmc_hwcontrol - hardware specific access (read/ write) control
+ * @cs: chip select number
+ * @cmd: command type
+ * @write: 1 for write; 0 for read
+ * @wval: value to write
+ * @rval: read pointer
+ */
+int gpmc_hwcontrol(int cs, int cmd, int write, int wval, int *rval)
+{
+ u32 regval = 0;
+
+ if (!write !rval)
+ return -EINVAL;
+
+ switch (cmd) {
+ case GPMC_STATUS_BUFFER:
+ regval = gpmc_read_reg(GPMC_STATUS);
+ /* 1 : buffer is available to write */
+ *rval = regval GPMC_STATUS_BUFF_EMPTY;
+ break;
+
+ case GPMC_GET_SET_IRQ_STATUS:
+ if (write)
+ gpmc_write_reg(GPMC_IRQSTATUS, wval);
+ else
+ *rval = gpmc_read_reg(GPMC_IRQSTATUS);
+ break;
+
+ case GPMC_PREFETCH_FIFO_CNT:
+ regval = gpmc_read_reg(GPMC_PREFETCH_STATUS);
+ *rval = GPMC_PREFETCH_STATUS_FIFO_CNT(regval);
+ break;
+
+ case GPMC_PREFETCH_COUNT:
+ regval = gpmc_read_reg(GPMC_PREFETCH_STATUS);
+ *rval = GPMC_PREFETCH_STATUS_COUNT(regval);
+ break;
+
+ case GPMC_CONFIG_WP:
+ regval = gpmc_read_reg(GPMC_CONFIG);
+ if (wval)
+ regval = ~GPMC_CONFIG_WRITEPROTECT; /* WP is
ON */
+ else
+ regval |= GPMC_CONFIG_WRITEPROTECT; /* WP is
OFF */
+ gpmc_write_reg(GPMC_CONFIG, regval);
+ break;
+
+ case
RE: [PATCH v3 1/3] omap3 gpmc: functionality enhancement
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?
[...]
+int gpmc_ecc_reset(int cs)
+{
+ if (gpmc_ecc_used == cs)
+ gpmc_ecc_used = -EINVAL;
+ else
+ return -EINVAL;
+
+ return 0;
+}
I guess in this function you should also clear gpmc ecc config
register explicitly.
--
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
-Original Message-
From: Vimal Singh [mailto:vimal.neww...@gmail.com]
Sent: 2010-05-17 19:57
To: Ghorai, Sukumar
Cc: linux-omap@vger.kernel.org; artem.bityuts...@nokia.com;
t...@atomide.com; sako...@gmail.com; linux-...@lists.infradead.org
Subject: 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
[Ghorai] ok. thanks
--
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
Vimal,
-Original Message-
From: Vimal Singh [mailto:vimal.neww...@gmail.com]
Sent: 2010-05-14 23:33
To: Ghorai, Sukumar
Cc: linux-omap@vger.kernel.org; artem.bityuts...@nokia.com;
t...@atomide.com; sako...@gmail.com; linux-...@lists.infradead.org
Subject: Re: [PATCH v2 1/2] omap3 nand: cleanup for not to use GPMC
virtual address
On Fri, May 14, 2010 at 8:53 PM, Sukumar Ghorai s-gho...@ti.com wrote:
[...]
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c b/arch/arm/mach-
omap2/gpmc-onenand.c
index 7bb6922..5d66817
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -301,7 +301,7 @@ static int omap2_onenand_set_sync_mode(struct
omap_onenand_platform_data *cfg,
(GPMC_CONFIG1_WAIT_READ_MON |
GPMC_CONFIG1_WAIT_PIN_SEL(0))) |
GPMC_CONFIG1_DEVICESIZE_16 |
- GPMC_CONFIG1_DEVICETYPE_NOR |
+ GPMC_CONFIG1_DEVICETYPE(GPMC_DEVICETYPE_NOR) |
GPMC_CONFIG1_MUXADDDATA);
Please do not dp OneNAND changes in NAND patch.
[Ghorai] I agree.
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 5bc3ca0..a3fd1ed
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -29,27 +29,27 @@
#include plat/sdrc.h
/* GPMC register offsets */
-#define GPMC_REVISION 0x00
-#define GPMC_SYSCONFIG 0x10
-#define GPMC_SYSSTATUS 0x14
-#define GPMC_IRQSTATUS 0x18
-#define GPMC_IRQENABLE 0x1c
-#define GPMC_TIMEOUT_CONTROL 0x40
-#define GPMC_ERR_ADDRESS 0x44
-#define GPMC_ERR_TYPE 0x48
-#define GPMC_CONFIG0x50
-#define GPMC_STATUS0x54
-#define GPMC_PREFETCH_CONFIG1 0x1e0
-#define GPMC_PREFETCH_CONFIG2 0x1e4
-#define GPMC_PREFETCH_CONTROL 0x1ec
-#define GPMC_PREFETCH_STATUS 0x1f0
-#define GPMC_ECC_CONFIG0x1f4
-#define GPMC_ECC_CONTROL 0x1f8
-#define GPMC_ECC_SIZE_CONFIG 0x1fc
-
-#define GPMC_CS0 0x60
-#define GPMC_CS_SIZE 0x30
-
+#define GPMC_REVISION 0x00
+#define GPMC_SYSCONFIG 0x10
+#define GPMC_SYSSTATUS 0x14
+#define GPMC_IRQSTATUS 0x18
+#define GPMC_IRQENABLE 0x1c
+#define GPMC_TIMEOUT_CONTROL0x40
+#define GPMC_ERR_ADDRESS0x44
+#define GPMC_ERR_TYPE 0x48
+#define GPMC_CONFIG 0x50
+#define GPMC_STATUS 0x54
+#define GPMC_PREFETCH_CONFIG1 0x1e0
+#define GPMC_PREFETCH_CONFIG2 0x1e4
+#define GPMC_PREFETCH_CONTROL 0x1ec
+#define GPMC_PREFETCH_STATUS0x1f0
+#define GPMC_ECC_CONFIG 0x1f4
+#define GPMC_ECC_CONTROL0x1f8
+#define GPMC_ECC_SIZE_CONFIG0x1fc
+#define GPMC_ECC1_RESULT0x200
+
+#define GPMC_CS0_BASE 0x60
+#define GPMC_CS_SIZE0x30
#define GPMC_MEM_START 0x
#define GPMC_MEM_END 0x3FFF
#define BOOT_ROM_SPACE 0x10/* 1MB */
@@ -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.
void gpmc_cs_write_reg(int cs, int idx, u32 val)
{
void __iomem *reg_addr;
- reg_addr = gpmc_base + GPMC_CS0 + (cs * GPMC_CS_SIZE) + idx;
+ reg_addr = gpmc_base + GPMC_CS0_BASE + (cs * GPMC_CS_SIZE) +
idx;
__raw_writel(val, reg_addr);
}
@@ -120,7 +136,7 @@ u32 gpmc_cs_read_reg(int cs, int idx)
{
void __iomem *reg_addr;
- reg_addr = gpmc_base + GPMC_CS0 + (cs * GPMC_CS_SIZE) + idx;
+ reg_addr = gpmc_base + GPMC_CS0_BASE + (cs * GPMC_CS_SIZE) +
idx;
return __raw_readl(reg_addr);
}
@@ -419,6 +435,96 @@ void gpmc_cs_free(int cs)
EXPORT_SYMBOL(gpmc_cs_free);
/**
+ * gpmc_hwcontrol - hardware specific access (read/ write) to control
+ * @write: need 1 for configure; 0 for reading the complete register
+ * @cs: chip select number
+ * @cmd: Command type
+ * @wval: value/information to write
+ * @rval: pointer to get the value back
+ */
+int gpmc_hwcontrol(int write, int cs, int cmd, int wval, int *rval)
+{
+ u32 reg = 0;
+ u32 regval = 0;
+
+ switch (cmd) {
+
+ case GPMC_GET_SET_STATUS
RE: [PATCH v2 1/2] omap3 nand: cleanup for not to use GPMC virtual address
Tony,
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: 2010-05-15 05:29
To: Ghorai, Sukumar
Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org;
sako...@gmail.com; m...@compulab.co.il; artem.bityuts...@nokia.com
Subject: Re: [PATCH v2 1/2] omap3 nand: cleanup for not to use GPMC
virtual address
Few more comments below.
* Sukumar Ghorai s-gho...@ti.com [100514 08:18]:
+
+/**
+ * gmpc_ecc_init - Initialize the HW ECC for NAND flash in GPMC
controller
+ * @cs: Chip select number
+ * @ecc_size: bytes for which ECC will be generated
+ */
+void gpmc_ecc_init(int cs, int ecc_size)
+{
+ unsigned int val = 0x0;
+
+ /* Read from ECC Control Register */
+ val = gpmc_read_reg(GPMC_ECC_CONTROL);
+
+ /* Clear all ECC | Enable Reg1 */
+ val = ((0x00018) | 0x0001);
+ gpmc_write_reg(GPMC_ECC_CONTROL, val);
+
+ /* Read from ECC Size Config Register */
+ val = gpmc_read_reg(GPMC_ECC_SIZE_CONFIG);
+ /* ECCSIZE1=512 | Select eccResultsize[0-3] */
+ val = ecc_size 1) - 1) 22) | (0x000F));
+ gpmc_write_reg(GPMC_ECC_SIZE_CONFIG, val);
+}
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..
Maybe something like:
int gpmc_ecc_request(int cs);
void gpmc_ecc_free(int cs);
int gpmc_prefetch_request(int cs);
void gpmc_prefetch_free(int cs);
Other than that, looks like a good clean-up so we can easily
add the platform init code for all the board files.
[Ghorai] agreed.. and -
1). Adding one flag/variable for prefetch enable/reset request
2). Adding another flag/variable for ecc int/reset request
Regards,
Ghorai
Regards,
Tony
--
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] omap3 nand: cleanup for not to use GPMC virtual address
Tony,
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: 2010-05-13 21:11
To: Ghorai, Sukumar
Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org;
sako...@gmail.com; m...@compulab.co.il; artem.bityuts...@nokia.com
Subject: Re: [PATCH 2/3] omap3 nand: cleanup for not to use GPMC virtual
address
* Sukumar Ghorai s-gho...@ti.com [100512 02:43]:
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -64,16 +64,32 @@ static void __iomem *gpmc_base;
static struct clk *gpmc_l3_clk;
-static void gpmc_write_reg(int idx, u32 val)
+void gpmc_write_reg(int idx, u32 val)
{
__raw_writel(val, gpmc_base + idx);
}
-static u32 gpmc_read_reg(int idx)
+u32 gpmc_read_reg(int idx)
{
return __raw_readl(gpmc_base + idx);
}
+void gpmc_cs_write_byte(int cs, int idx, u32 val)
+{
+ void __iomem *reg_addr;
+
+ reg_addr = gpmc_base + GPMC_CS0_BASE + (cs * GPMC_CS_SIZE) + idx;
+ __raw_writeb(val, reg_addr);
+}
+
+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);
+}
+
This will not improve the situation unfortunately.
We for sure don't want to export functions to mess
with the GPMC registers all over the place.
@@ -432,15 +448,6 @@ void gpmc_prefetch_reset(void)
}
EXPORT_SYMBOL(gpmc_prefetch_reset);
-/**
- * gpmc_prefetch_status - reads prefetch status of engine
- */
-int gpmc_prefetch_status(void)
-{
- return gpmc_read_reg(GPMC_PREFETCH_STATUS);
-}
-EXPORT_SYMBOL(gpmc_prefetch_status);
-
And we don't want to remove GPMC functions like this,
instead we need to implement more functions like this
for the platform init code to use.
[Ghorai]
1. NAND IO address needed by core NAND driver. So we can't move that access to
GMPC.
2. And is it ok if we add functions as below and all need to be as
EXPORT_SYMBOL too?
get_gpmc_status()
get_gpmc_irq_status()
set_gpmc_irq_status()
set_gpmc_irq_enable()
get_gpmc_config
set_gpmc_config
get_gpmc_status()
get_gpmc_prefetch_config()
gpmc_prefetch_status
set_gpmc_ecc_config
set_gpmc_ecc_contol
set_gpmc_ecc_size
get_gpmc_ecc_result
Regards,
Sukumar
Regards,
Tony
--
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
Tony, I understand your comment/input. And I will work on it. All existing omap3 boards are using same old fashion. So let me see how many board I can test before post the patch. I will update this next week. Regards, Ghorai -Original Message- From: Vimal Singh [mailto:vimal.neww...@gmail.com] Sent: 2010-05-05 11:42 To: artem.bityuts...@nokia.com Cc: Tony Lindgren; linux-omap@vger.kernel.org; linux- m...@lists.infradead.org; Ghorai, Sukumar; Steve Sakoman; Mike Rapoport Subject: 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] nand support on omap3 boards
Tony, Would you please check if there are no further comments and could you pull them in? 1/8: https://patchwork.kernel.org/patch/92220/ 2/8: https://patchwork.kernel.org/patch/92232/ 3/8: https://patchwork.kernel.org/patch/92221/ 4/8: https://patchwork.kernel.org/patch/92230/ 5/8: https://patchwork.kernel.org/patch/92224/ 6/8: https://patchwork.kernel.org/patch/9/ 7/8: https://patchwork.kernel.org/patch/92223/ 8/8: https://patchwork.kernel.org/patch/92229/ Regards, Nishanth Menon -Original Message- From: Ghorai, Sukumar Sent: 2010-04-13 23:07 To: linux-omap@vger.kernel.org Cc: Ghorai, Sukumar Subject: [PATCH] nand support on omap3 boards The following set of patches applies on top of the Tony's master branch. And these are the patches required to enable nand (nor and onenand for sdp only) for different platform. Sukumar Ghorai (3): OMAP: ZOOM: Introducing 'board-zoom-flash.c' omap3: add support for NAND on zoom2 board omap3: add support for NAND on zoom3 board omap-3630-sdp : Add support for Flash omap-3630-sdp: enable Flash device support omap3: add support for NAND on LDP board zoom2: enable NAND support zoom3: enable NAND support arch/arm/configs/omap_3630sdp_defconfig | 77 +- arch/arm/configs/omap_zoom2_defconfig | 90 - arch/arm/configs/omap_zoom3_defconfig | 90 - arch/arm/mach-omap2/Makefile |4 + arch/arm/mach-omap2/board-3630sdp.c | 110 + arch/arm/mach-omap2/board-ldp.c | 41 + arch/arm/mach-omap2/board-sdp-flash.c |2 + arch/arm/mach-omap2/board-zoom-flash.c| 82 ++ arch/arm/mach-omap2/board-zoom2.c | 49 +++ arch/arm/mach-omap2/board-zoom3.c | 48 +++ arch/arm/mach-omap2/include/mach/board-zoom.h | 11 +++ 11 files changed, 601 insertions(+), 3 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
Recall: [PATCH] nand support on omap3 boards
Ghorai, Sukumar would like to recall the message, [PATCH] nand support on omap3 boards.-- 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
Tony, Would you please check if there are no further comments and could you pull them in? 1/8: https://patchwork.kernel.org/patch/92220/ 2/8: https://patchwork.kernel.org/patch/92232/ 3/8: https://patchwork.kernel.org/patch/92221/ 4/8: https://patchwork.kernel.org/patch/92230/ 5/8: https://patchwork.kernel.org/patch/92224/ 6/8: https://patchwork.kernel.org/patch/9/ 7/8: https://patchwork.kernel.org/patch/92223/ 8/8: https://patchwork.kernel.org/patch/92229/ Regards, Sukumar Ghorai -Original Message- From: Ghorai, Sukumar Sent: 2010-04-13 23:07 To: linux-omap@vger.kernel.org Cc: Ghorai, Sukumar Subject: [PATCH] nand support on omap3 boards The following set of patches applies on top of the Tony's master branch. And these are the patches required to enable nand (nor and onenand for sdp only) for different platform. Sukumar Ghorai (3): OMAP: ZOOM: Introducing 'board-zoom-flash.c' omap3: add support for NAND on zoom2 board omap3: add support for NAND on zoom3 board omap-3630-sdp : Add support for Flash omap-3630-sdp: enable Flash device support omap3: add support for NAND on LDP board zoom2: enable NAND support zoom3: enable NAND support arch/arm/configs/omap_3630sdp_defconfig | 77 +- arch/arm/configs/omap_zoom2_defconfig | 90 - arch/arm/configs/omap_zoom3_defconfig | 90 - arch/arm/mach-omap2/Makefile |4 + arch/arm/mach-omap2/board-3630sdp.c | 110 + arch/arm/mach-omap2/board-ldp.c | 41 + arch/arm/mach-omap2/board-sdp-flash.c |2 + arch/arm/mach-omap2/board-zoom-flash.c| 82 ++ arch/arm/mach-omap2/board-zoom2.c | 49 +++ arch/arm/mach-omap2/board-zoom3.c | 48 +++ arch/arm/mach-omap2/include/mach/board-zoom.h | 11 +++ 11 files changed, 601 insertions(+), 3 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
JFFS2 summary support : problem
Hi, I am working on TI OMAP3 platform and was looking to reduce the JFFS2 mount time (NAND). I have selected CONFIG_JFFS2_SUMMARY, but not working fully, its giving ECC error (at end of this email) after add a new file in JFFS2. Without this option its working fine; but taking long time to mount. Please let me know if I am missing anything -http://dev.omapzoom.org/pub/scm/integration/kernel-omap3.git [*] JFFS2 summary support (EXPERIMENTAL) i.e. CONFIG_JFFS2_SUMMARY=y = I have created and flushed jffs2 image with summary nodes, as- sumtool -n -e 0x2 -p -i rootdir.jffs2 -o rootdir-sum.jffs2 # mount -t jffs2 /dev/mtdblock4 /mnt JFFS2 notice: (640) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found. # umount /mnt == I checked this multiple time and no issue. # # mount -t jffs2 /dev/mtdblock4 /mnt JFFS2 notice: (644) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found. # vi /mnt/test.c (created a new file) # umount /mnt # mount -t jffs2 /dev/mtdblock4 /mnt mtd-read(0x1fb04 bytes from 0x8de04fc) returned ECC error mtd-read(0x9a74 bytes from 0x8df658c) returned ECC error Empty flash at 0x08df6588 ends at 0x08df6800 JFFS2 notice: (656) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found. mtd-read(0x7bc bytes from 0x8df6844) returned ECC error Is there another way to fix the problem? Am I missing any patch or missing any configuration? Thanks regards, Ghorai -- 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
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Mike Rapoport
Sent: 2010-04-22 10:50
To: linux-omap@vger.kernel.org
Cc: Tony Lindgren; Mike Rapoport
Subject: Re: [PATCH] OMAP: fix gpmc nand setup when no timings supplied
Any comments on this?
Mike Rapoport wrote:
The gpmc nand infrastructure crashes when there no timing structure
supplied in the omap_nand_platform_data. Adding check for
gpmc_nand_data-gpmc_t pointer validity resolves the crash and allows to
continue nand initialization without modifying gpmc timings.
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/gpmc-nand.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-
nand.c
index 64d74f0..3629da3 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -83,6 +83,11 @@ static int gpmc_nand_setup(void)
{
struct device *dev = gpmc_nand_device.dev;
+ if (!gpmc_nand_data-gpmc_t) {
+ dev_info(dev, Keeping gpmc timings\n);
+ return 0;
+ }
[Ghorai] This is the only time its setup the gpmc timings for NAND. And it
should return as error.
+
/* Set timings in GPMC */
if (omap2_nand_gpmc_retime() 0) {
dev_err(dev, Unable to set gpmc timings\n);
--
Sincerely yours,
Mike.
--
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] OMAP: fix gpmc nand setup when no timings supplied
-Original Message-
From: Mike Rapoport [mailto:m...@compulab.co.il]
Sent: 2010-04-22 12:29
To: Ghorai, Sukumar
Cc: linux-omap@vger.kernel.org; Tony Lindgren
Subject: Re: [PATCH] OMAP: fix gpmc nand setup when no timings supplied
Ghorai, Sukumar wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Mike Rapoport
Sent: 2010-04-22 10:50
To: linux-omap@vger.kernel.org
Cc: Tony Lindgren; Mike Rapoport
Subject: Re: [PATCH] OMAP: fix gpmc nand setup when no timings supplied
Any comments on this?
Mike Rapoport wrote:
The gpmc nand infrastructure crashes when there no timing structure
supplied in the omap_nand_platform_data. Adding check for
gpmc_nand_data-gpmc_t pointer validity resolves the crash and allows
to
continue nand initialization without modifying gpmc timings.
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/gpmc-nand.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-
omap2/gpmc-
nand.c
index 64d74f0..3629da3 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -83,6 +83,11 @@ static int gpmc_nand_setup(void)
{
struct device *dev = gpmc_nand_device.dev;
+ if (!gpmc_nand_data-gpmc_t) {
+ dev_info(dev, Keeping gpmc timings\n);
+ return 0;
+ }
[Ghorai] This is the only time its setup the gpmc timings for NAND. And
it should return as error.
Somehow I was under the impression that X-Loader sets up the NAND
timings even if booted from OneNAND or MMC. Apparently I'm wrong :).
What do you think about adding a flag to omap_nand_platform_data that
will allow to keep timings if they were already configured by the
bootloader? This is really useful when the board can be assembled with
different kinds of NAND flashes.
[Ghorai] firstly we should not depend on u-boot/ x-loader for this GPMC
configuration. I think each board will have only one device finally.
+
/* Set timings in GPMC */
if (omap2_nand_gpmc_retime() 0) {
dev_err(dev, Unable to set gpmc timings\n);
--
Sincerely yours,
Mike.
--
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
--
Sincerely yours,
Mike.
--
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 GPTimer for OProfile(Errata#628216)
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Siarhei Siamashka Sent: 2010-04-01 21:02 To: G, Manjunath Kondaiah; Koskinen Aaro (Nokia-D/Helsinki) Cc: linux-omap@vger.kernel.org; DebBarma, Tarun Kanti Subject: Re: [PATCH] OMAP GPTimer for OProfile(Errata#628216) On Thursday 01 April 2010 18:24:08 ext Manjunatha GK wrote: From: DebBarma, Tarun Kanti tarun.ka...@ti.com [ARM Cortex-A8 Errata 628216] If a Perf Counter OVFL occurs simultaneously with an update to a CP14 or CP15 register, the OVFL status can be lost. In order to workaround problem in Cortex-A8 Performance Counter, OMAP GPTIMER is used by OProfile. Thanks for digging this up. But even though GPTIMER has a lower overhead, there is actually a better (more portable) fix which is on the way into mainline kernel: http://marc.info/?l=oprofile-listm=126754919315010w=2 Samples collection frequency can be adjusted by another patch (the default 128Hz used on most ARM boards/devices is way too low). oprofile kernel module can be loaded with 'timer=1' parameter to override the use of buggy Cortex-A8 PMU. [Ghorai] ok. Your patch did not work if I build inside kernel image. Here is the error - $opcontrol --setup --vmlinux=/vmlinux cpu_type 'unset' is not valid you should upgrade oprofile or force the use of timer mode /usr/bin/objdump -- Best regards, Siarhei Siamashka -- 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
Recall: [PATCH] omap: NAND: ecc layout select from board file
Ghorai, Sukumar would like to recall the message, [PATCH] omap: NAND: ecc layout select from board file.-- 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
Recall: [PATCH] omap-3630 NAND: enable NAND io in prefetch-irq mode
Ghorai, Sukumar would like to recall the message, [PATCH] omap-3630 NAND: enable NAND io in prefetch-irq mode.-- 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
Recall: [PATCH 8/8] omap3: GPMC register definition at common location
Ghorai, Sukumar would like to recall the message, [PATCH 8/8] omap3: GPMC register definition at common location.-- 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
Recall: [PATCH] omap3: NAND Prefetch in IRQ mode support
Ghorai, Sukumar would like to recall the message, [PATCH] omap3: NAND Prefetch in IRQ mode support.-- 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
