From: Tony Lindgren <tony@atomide.com>
To: Vimal Singh <vimal.newwork@gmail.com>
Cc: linux-omap@vger.kernel.org,
Linux MTD <linux-mtd@lists.infradead.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: Issue in oamp nand driver with 32-bit reads in prefetch mode
Date: Wed, 23 Dec 2009 09:44:29 -0800 [thread overview]
Message-ID: <20091223174429.GD3512@atomide.com> (raw)
In-Reply-To: <ce9ab5790912230133wae2c4dcw73051221b66cb40f@mail.gmail.com>
* Vimal Singh <vimal.newwork@gmail.com> [091223 01:32]:
> In omap nand driver we used to do 32-bit reads (in function
> omap_read_buf_pref, using 'ioread32_rep' i.e.: __raw_readsl), and it
> was working fine till some time back. But now, somehow, this has got
> some problem. Reads are not being done successfully, and driver gives
> lots for error reprot like below:
>
> td->read(0x604 bytes from 0x1fc) returned ECC error
> uncorrectable error :
> uncorrectable error :
> uncorrectable error :
> uncorrectable error :
> uncorrectable error :
> uncorrectable error :
> mtd->read(0x520 bytes from 0x2e0) returned ECC error
>
> While if we change 32-bit reads to 16-bit reads (using 'ioread16_rep'
> i.e.: __raw_readwl) makes it working fine. (A patch to do this is
> listed below at the bottom of this mail.)
>
> I have not seen any change in routine '__raw_readsl'.
> So, could someone help me find out the root cause the issue?
>
> Thanks for any input.
Maybe an issue with the GPMC timings?
Regards,
Tony
>
> --
> Regards,
> Vimal Singh
>
> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> index aaef170..dc493f5 100644
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
> @@ -288,14 +288,14 @@ static void omap_read_buf_pref(struct mtd_info
> struct omap_nand_info, mtd);
> uint32_t pfpw_status = 0, r_count = 0;
> int ret = 0;
> - u32 *p = (u32 *)buf;
> + u16 *p = (u16 *)buf;
>
> /* take care of subpage reads */
> - for (; len % 4 != 0; ) {
> + for (; len % 2 != 0; ) {
> *buf++ = __raw_readb(info->nand.IO_ADDR_R);
> len--;
> }
> - p = (u32 *) buf;
> + p = (u16 *) buf;
>
> /* configure and start prefetch transfer */
> ret = gpmc_prefetch_enable(info->gpmc_cs, 0x0, len, 0x0);
> @@ -308,10 +308,10 @@ static void omap_read_buf_pref(struct mtd_info
> *mtd, u_char *buf, int len)
> } else {
> do {
> pfpw_status = gpmc_prefetch_status();
> - r_count = ((pfpw_status >> 24) & 0x7F) >> 2;
> - ioread32_rep(info->nand_pref_fifo_add, p, r_count);
> + r_count = ((pfpw_status >> 24) & 0x7F) >> 1;
> + ioread16_rep(info->nand_pref_fifo_add, p, r_count);
> p += r_count;
> - len -= r_count << 2;
> + len -= r_count << 1;
> } while (len);
>
> /* disable and stop the PFPW engine */
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: Issue in oamp nand driver with 32-bit reads in prefetch mode
Date: Wed, 23 Dec 2009 09:44:29 -0800 [thread overview]
Message-ID: <20091223174429.GD3512@atomide.com> (raw)
In-Reply-To: <ce9ab5790912230133wae2c4dcw73051221b66cb40f@mail.gmail.com>
* Vimal Singh <vimal.newwork@gmail.com> [091223 01:32]:
> In omap nand driver we used to do 32-bit reads (in function
> omap_read_buf_pref, using 'ioread32_rep' i.e.: __raw_readsl), and it
> was working fine till some time back. But now, somehow, this has got
> some problem. Reads are not being done successfully, and driver gives
> lots for error reprot like below:
>
> td->read(0x604 bytes from 0x1fc) returned ECC error
> uncorrectable error :
> uncorrectable error :
> uncorrectable error :
> uncorrectable error :
> uncorrectable error :
> uncorrectable error :
> mtd->read(0x520 bytes from 0x2e0) returned ECC error
>
> While if we change 32-bit reads to 16-bit reads (using 'ioread16_rep'
> i.e.: __raw_readwl) makes it working fine. (A patch to do this is
> listed below at the bottom of this mail.)
>
> I have not seen any change in routine '__raw_readsl'.
> So, could someone help me find out the root cause the issue?
>
> Thanks for any input.
Maybe an issue with the GPMC timings?
Regards,
Tony
>
> --
> Regards,
> Vimal Singh
>
> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> index aaef170..dc493f5 100644
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
> @@ -288,14 +288,14 @@ static void omap_read_buf_pref(struct mtd_info
> struct omap_nand_info, mtd);
> uint32_t pfpw_status = 0, r_count = 0;
> int ret = 0;
> - u32 *p = (u32 *)buf;
> + u16 *p = (u16 *)buf;
>
> /* take care of subpage reads */
> - for (; len % 4 != 0; ) {
> + for (; len % 2 != 0; ) {
> *buf++ = __raw_readb(info->nand.IO_ADDR_R);
> len--;
> }
> - p = (u32 *) buf;
> + p = (u16 *) buf;
>
> /* configure and start prefetch transfer */
> ret = gpmc_prefetch_enable(info->gpmc_cs, 0x0, len, 0x0);
> @@ -308,10 +308,10 @@ static void omap_read_buf_pref(struct mtd_info
> *mtd, u_char *buf, int len)
> } else {
> do {
> pfpw_status = gpmc_prefetch_status();
> - r_count = ((pfpw_status >> 24) & 0x7F) >> 2;
> - ioread32_rep(info->nand_pref_fifo_add, p, r_count);
> + r_count = ((pfpw_status >> 24) & 0x7F) >> 1;
> + ioread16_rep(info->nand_pref_fifo_add, p, r_count);
> p += r_count;
> - len -= r_count << 2;
> + len -= r_count << 1;
> } while (len);
>
> /* disable and stop the PFPW engine */
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2009-12-23 17:44 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-23 9:33 Issue in oamp nand driver with 32-bit reads in prefetch mode Vimal Singh
2009-12-23 9:33 ` Vimal Singh
2009-12-23 17:44 ` Tony Lindgren [this message]
2009-12-23 17:44 ` Tony Lindgren
2009-12-29 20:38 ` Steve Sakoman
2009-12-29 20:38 ` Steve Sakoman
2009-12-29 20:38 ` Steve Sakoman
2009-12-29 21:47 ` Steve Sakoman
2009-12-29 21:47 ` Steve Sakoman
2009-12-29 21:47 ` Steve Sakoman
2009-12-31 12:20 ` Vimal Singh
2009-12-31 12:20 ` Vimal Singh
2009-12-31 12:20 ` Vimal Singh
2010-01-02 15:02 ` Steve Sakoman
2010-01-02 15:02 ` Steve Sakoman
2010-01-02 15:02 ` Steve Sakoman
2010-01-10 8:46 ` Artem Bityutskiy
2010-01-10 8:46 ` Artem Bityutskiy
2010-01-10 8:46 ` Artem Bityutskiy
2010-01-11 6:30 ` Vimal Singh
2010-01-11 6:30 ` Vimal Singh
2010-01-11 6:30 ` Vimal Singh
2010-01-16 21:35 ` Artem Bityutskiy
2010-01-16 21:35 ` Artem Bityutskiy
2010-01-16 21:35 ` Artem Bityutskiy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091223174429.GD3512@atomide.com \
--to=tony@atomide.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=vimal.newwork@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.