From: Tony Lindgren <tony@atomide.com>
To: Juha Kuikka <juha.kuikka@gmail.com>
Cc: "linux-omap@vger.kernel.org Mailing List" <linux-omap@vger.kernel.org>
Subject: Re: OMAP NAND driver issue with subpage reads
Date: Wed, 24 Oct 2012 09:20:03 -0700 [thread overview]
Message-ID: <20121024162003.GE5605@atomide.com> (raw)
In-Reply-To: <CAKvrXUpJDuCgeZwuhtcxn0POSntWCm_Lc3YgqF9uVAU6=SjwKg@mail.gmail.com>
* Juha Kuikka <juha.kuikka@gmail.com> [121023 13:40]:
> Hi,
>
> There seems to be an issue in the omap nand driver
> (drivers/mtd/nand/omap2.c) concerning sub-page reads (visible when
> using 16bit LP NAND, SOFT_ECC and UBI).
>
> Problem is caused by the omap_read_buf_pref() function using 32bit
> reads from the pre-fetch engine. It takes care of the mis-aligned
> length but not a mis-aligned buffer pointer. Combined with how the
> nand_read_subpage() function aligns the pointer and length to NAND
> width (8 or 16 bits) this can lead to situation where the handling of
> the mis-aligned length in omap_read_buf_pref() causes the pointer to
> not be aligned to 32bits and the data gets corrupted in the read. This
> of course leds to ECC issues.
>
> The way I see is there are several ways to fix this:
>
> 1. Change nand_read_subpage() to be more strict about alignment
> 2. Change omap_read_buf_pref() to handle any reads (len % 4) || (buf %
> 4) with omap_read_bufX() completely
> 3. Change omap_read_buf_pref() to use ioread16_rep() since buffer and
> length are already aligned for us.
>
> I'm leaning towards #2 because, assuming that the nand driver cannot
> make assumptions of alignment, we need to be able to handle them all
> anyway. The common case of reading big chunks of page data would still
> be fast (since reads are always sub-page aligned) but the special case
> of reading small OOB chunks would be handled gracefully.
>
> Something like this:
>
> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> index 5c8978e..8a929cf 100644
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
> @@ -334,13 +334,12 @@ static void omap_read_buf_pref(struct mtd_info
> *mtd, u_char *buf, int len)
> u32 *p = (u32 *)buf;
>
> /* take care of subpage reads */
> - if (len % 4) {
> + if (len % 4 || (unsigned long) buf % 4) {
> if (info->nand.options & NAND_BUSWIDTH_16)
> omap_read_buf16(mtd, buf, len % 4);
> else
> omap_read_buf8(mtd, buf, len % 4);
> - p = (u32 *) (buf + len % 4);
> - len -= len % 4;
> + return;
> }
>
> /* configure and start prefetch transfer */
>
> Comments?
Seems OK to me, but please cc the MTD list as this is more in the
MTD driver area.
Regards,
Tony
prev parent reply other threads:[~2012-10-24 16:20 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-23 20:36 OMAP NAND driver issue with subpage reads Juha Kuikka
2012-10-24 16:20 ` Tony Lindgren [this message]
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=20121024162003.GE5605@atomide.com \
--to=tony@atomide.com \
--cc=juha.kuikka@gmail.com \
--cc=linux-omap@vger.kernel.org \
/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.