All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind@infradead.org>
To: bryan.wu@analog.com
Cc: Mike Frysinger <vapier.adi@gmail.com>,
	linux-kernel@vger.kernel.org,
	Robin Getz <rgetz@blackfin.uclinux.org>,
	linux-mtd@lists.infradead.org,
	Thomas Gleixner <tglx@linutronix.de>,
	David Woodhouse <dwmw2@infradead.org>,
	akpm@linux-foundation.org
Subject: Re: [PATCH try #2] Blackfin on-chip NAND Flash Controller driver
Date: Fri, 07 Sep 2007 08:52:21 +0300	[thread overview]
Message-ID: <1189144341.14370.77.camel@sauron> (raw)
In-Reply-To: <1188885450.7074.7.camel@roc-laptop>

On Tue, 2007-09-04 at 13:57 +0800, Bryan Wu wrote:
> This is the driver for latest Blackfin on-chip nand flash controller
> 
>  - use nand_chip and mtd_info common nand driver interface
>  - provide both PIO and dma operation
>  - compiled with ezkit bf548 configuration
>  - use hardware 1-bit ECC
>  - tested with YAFFS2 and can mount YAFFS2 filesystem as rootfs
> 
> ChangeLog from try#1
>  - use hweight32() instead of count_bits()
>  - replace bf54x with bf5xx and BF54X with BF5XX
>  - compare against plat->page_size in 2 cases when enable hardware ECC
> 
> Signed-off-by: Bryan Wu <bryan.wu@analog.com>

Bryan,

I'd suggest you to test your NAND driver with the following NAND tests:

git://git.infradead.org/~ahunter/nand-tests.git

(http://git.infradead.org/?p=users/ahunter/nand-tests.git;a=summary)


You may want to avoid the torture test, but it is useful to run it with
limited amount of erase cycles to make sure your flash/driver survives
really high I/O load.For example, we caught occasional DMA transfer
problems while running the torture test for few days.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

WARNING: multiple messages have this Message-ID (diff)
From: Artem Bityutskiy <dedekind@infradead.org>
To: bryan.wu@analog.com
Cc: David Woodhouse <dwmw2@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Mike Frysinger <vapier.adi@gmail.com>,
	Robin Getz <rgetz@blackfin.uclinux.org>,
	linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
	akpm@linux-foundation.org
Subject: Re: [PATCH try #2] Blackfin on-chip NAND Flash Controller driver
Date: Fri, 07 Sep 2007 08:52:21 +0300	[thread overview]
Message-ID: <1189144341.14370.77.camel@sauron> (raw)
In-Reply-To: <1188885450.7074.7.camel@roc-laptop>

On Tue, 2007-09-04 at 13:57 +0800, Bryan Wu wrote:
> This is the driver for latest Blackfin on-chip nand flash controller
> 
>  - use nand_chip and mtd_info common nand driver interface
>  - provide both PIO and dma operation
>  - compiled with ezkit bf548 configuration
>  - use hardware 1-bit ECC
>  - tested with YAFFS2 and can mount YAFFS2 filesystem as rootfs
> 
> ChangeLog from try#1
>  - use hweight32() instead of count_bits()
>  - replace bf54x with bf5xx and BF54X with BF5XX
>  - compare against plat->page_size in 2 cases when enable hardware ECC
> 
> Signed-off-by: Bryan Wu <bryan.wu@analog.com>

Bryan,

I'd suggest you to test your NAND driver with the following NAND tests:

git://git.infradead.org/~ahunter/nand-tests.git

(http://git.infradead.org/?p=users/ahunter/nand-tests.git;a=summary)


You may want to avoid the torture test, but it is useful to run it with
limited amount of erase cycles to make sure your flash/driver survives
really high I/O load.For example, we caught occasional DMA transfer
problems while running the torture test for few days.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)


  reply	other threads:[~2007-09-07  5:53 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-04  5:57 [PATCH try #2] Blackfin on-chip NAND Flash Controller driver Bryan Wu
2007-09-07  5:52 ` Artem Bityutskiy [this message]
2007-09-07  5:52   ` Artem Bityutskiy
2007-09-10  9:50   ` Bryan Wu
2007-09-10  9:50     ` Bryan Wu
2007-09-11  8:35     ` Artem Bityutskiy
2007-09-11  8:35       ` Artem Bityutskiy
2007-09-11  9:04       ` Bryan Wu
2007-09-11  9:04         ` Bryan Wu
2007-09-14  7:15 ` [PATCH try #3] " Bryan Wu

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=1189144341.14370.77.camel@sauron \
    --to=dedekind@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=bryan.wu@analog.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=rgetz@blackfin.uclinux.org \
    --cc=tglx@linutronix.de \
    --cc=vapier.adi@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.