All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthieu CASTET <matthieu.castet@parrot.com>
To: Scott Wood <scottwood@freescale.com>
Cc: Artem Bityutskiy <dedekind1@gmail.com>,
	LiuShuo <b35362@freescale.com>,
	"linuxppc-dev@ozlabs.org" <linuxppc-dev@ozlabs.org>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	Ivan Djelic <ivan.djelic@parrot.com>,
	"dwmw2@infradead.org" <dwmw2@infradead.org>
Subject: Re: [PATCH v3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
Date: Mon, 22 Aug 2011 18:13:42 +0200	[thread overview]
Message-ID: <4E528036.5070801@parrot.com> (raw)
In-Reply-To: <4E527E0F.1010500@freescale.com>

Scott Wood a écrit :
> On 08/22/2011 10:25 AM, Ivan Djelic wrote:
>> Did you take into account the fact that because MTD thinks this a 2K chip,
>> you will have to wait twice for the nand busy read time (typically 25 us) per
>> each 4K read. In other words, to read 4 kBytes you will do:
>>
>> 1. send read0 (00), send address, send read1 (30)
>> 2. wait tRB
>> 3. transfer 2 kBytes
>> 4. send read0 (00), send address, send read1 (30)
>> 5. wait tRB
>> 6. transfer 2 kBytes
>>
>> Same problem for writes (but rather 100 us instead of 25 us).
>>
>> How does that compare with hw ecc gain in terms of performance ?
> 
> We'd have the double-delay with the sw ecc plus buffering approach as well.
> 
> To eliminate it we'd need to do an extra data transfer without reissuing
> the command, which Shuo was unable to get to work.
> 
That's weird because our controller seems quite flexible [1].

Something like that should work ?

            out_be32(&lbc->fir,
                     (FIR_OP_CM2 << FIR_OP0_SHIFT) |
                     (FIR_OP_CA  << FIR_OP1_SHIFT) |
                     (FIR_OP_PA  << FIR_OP2_SHIFT) |
                     (FIR_OP_WB  << FIR_OP3_SHIFT));
refill FCM buffer with next 2k data

            out_be32(&lbc->fir,
                     (FIR_OP_WB  << FIR_OP3_SHIFT) |
                     (FIR_OP_CM3 << FIR_OP4_SHIFT) |
                     (FIR_OP_CW1 << FIR_OP5_SHIFT) |
                     (FIR_OP_RS  << FIR_OP6_SHIFT));



[1]
    __be32 fir;             /**< Flash Instruction Register */
#define FIR_OP0      0xF0000000
#define FIR_OP0_SHIFT        28
#define FIR_OP1      0x0F000000
#define FIR_OP1_SHIFT        24
#define FIR_OP2      0x00F00000
#define FIR_OP2_SHIFT        20
#define FIR_OP3      0x000F0000
#define FIR_OP3_SHIFT        16
#define FIR_OP4      0x0000F000
#define FIR_OP4_SHIFT        12
#define FIR_OP5      0x00000F00
#define FIR_OP5_SHIFT         8
#define FIR_OP6      0x000000F0
#define FIR_OP6_SHIFT         4
#define FIR_OP7      0x0000000F
#define FIR_OP7_SHIFT         0
#define FIR_OP_NOP   0x0    /* No operation and end of sequence */
#define FIR_OP_CA    0x1        /* Issue current column address */
#define FIR_OP_PA    0x2        /* Issue current block+page address */
#define FIR_OP_UA    0x3        /* Issue user defined address */
#define FIR_OP_CM0   0x4        /* Issue command from FCR[CMD0] */
#define FIR_OP_CM1   0x5        /* Issue command from FCR[CMD1] */
#define FIR_OP_CM2   0x6        /* Issue command from FCR[CMD2] */
#define FIR_OP_CM3   0x7        /* Issue command from FCR[CMD3] */
#define FIR_OP_WB    0x8        /* Write FBCR bytes from FCM buffer */
#define FIR_OP_WS    0x9        /* Write 1 or 2 bytes from MDR[AS] */
#define FIR_OP_RB    0xA        /* Read FBCR bytes to FCM buffer */
#define FIR_OP_RS    0xB        /* Read 1 or 2 bytes to MDR[AS] */
#define FIR_OP_CW0   0xC        /* Wait then issue FCR[CMD0] */
#define FIR_OP_CW1   0xD        /* Wait then issue FCR[CMD1] */
#define FIR_OP_RBW   0xE        /* Wait then read FBCR bytes */
#define FIR_OP_RSW   0xE        /* Wait then read 1 or 2 bytes */

  reply	other threads:[~2011-08-22 16:13 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-18  2:33 [PATCH v3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip b35362
2011-08-18  2:33 ` b35362
2011-08-18 16:25 ` Scott Wood
2011-08-18 18:27   ` Scott Wood
2011-08-23  8:37   ` LiuShuo
2011-08-23  8:37     ` LiuShuo
2011-08-23 10:02     ` Matthieu CASTET
2011-08-23 16:12       ` Scott Wood
2011-08-23 16:12         ` Scott Wood
2011-08-25 11:18         ` Artem Bityutskiy
2011-08-24  2:48       ` LiuShuo
2011-08-24  2:48         ` LiuShuo
2011-08-25 11:25         ` Matthieu CASTET
2011-09-01  9:41           ` LiuShuo
2011-09-01  9:41             ` LiuShuo
2011-09-01 22:30             ` Scott Wood
2011-08-18 17:00 ` Matthieu CASTET
2011-08-18 17:00   ` Matthieu CASTET
2011-08-18 18:24   ` Scott Wood
2011-08-18 18:24     ` Scott Wood
2011-08-19  3:20   ` LiuShuo
2011-08-19  3:20     ` LiuShuo
2011-08-19  8:57     ` Matthieu CASTET
2011-08-19  8:57       ` Matthieu CASTET
2011-08-19 18:10       ` Scott Wood
2011-08-19 18:10         ` Scott Wood
2011-08-22 10:58         ` Artem Bityutskiy
2011-08-22 15:25           ` Ivan Djelic
2011-08-22 16:04             ` Scott Wood
2011-08-22 16:13               ` Matthieu CASTET [this message]
2011-08-22 16:19                 ` Scott Wood
2011-08-22 16:19                   ` Scott Wood
2011-08-22 17:05                   ` Matthieu CASTET
2011-08-23  3:09                   ` LiuShuo
2011-08-23  3:09                     ` LiuShuo
2011-08-23  8:14                     ` Matthieu CASTET
2011-08-23  9:57                       ` LiuShuo
2011-08-23  9:57                         ` LiuShuo
2011-08-23 10:13                         ` Matthieu CASTET
2011-08-22 15:58           ` Scott Wood
2011-08-25 11:06             ` Artem Bityutskiy
2011-08-22 10:53 ` Artem Bityutskiy
2011-08-22 10:53   ` 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=4E528036.5070801@parrot.com \
    --to=matthieu.castet@parrot.com \
    --cc=b35362@freescale.com \
    --cc=dedekind1@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=ivan.djelic@parrot.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=scottwood@freescale.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.