From: Rutger Hofman <rutger@cs.vu.nl>
To: Simon Kallweit <simon.kallweit@intefo.ch>
Cc: Jonathan Larmour <jifl@jifvik.org>,
"ecos-devel@ecos.sourceware.org"
<ecos-devel@ecos.sourceware.org>
Subject: Re: NAND review
Date: Wed, 20 May 2009 11:12:00 -0000 [thread overview]
Message-ID: <4A13E69C.3070109@cs.vu.nl> (raw)
In-Reply-To: <4A13AD30.40405@intefo.ch>
Simon Kallweit wrote:
> Jonathan Larmour wrote:
>> that). But I'm also concerned about possibly having too much layering
>> in Rutger's version for small simple implementations.
Well, there is one obvious candidate for being thinned out in my NAND
implementation: the ANC layer that hides the presence of multiple
controllers and/or chips. Making this optional for the (common) case of
one controller and one (or multiple identical) chips will be easy.
This leaves 3 layers:
- common controller code, which takes care of unavoidable nuisances like
spare layout, ECC handling, etc;
- controller-specific driver code;
- chip code that does interrogation and bad-block management; this, as
often as not, is just the common large-page regular chip implementation,
so no chip-specifics. Later in life we will see ONFI chips rule (maybe!)
-- no chip-specifics here either.
I dislike the idea of code duplication, and so much is common across
controller functionality. Hence the split into common and
device-specific code, which enforces an API in-between. I did my best to
design this API in a way that is flexible and powerful, but of course I
cannot rule out that controllers exist that fit this interface only with
a lot of workarounds. Needless to say, I am very much open to
suggestions for improvement.
AFAIK, Linux's MTD also has an API between common and specific
controller code, but it allows even more pluggability for controllers
than my design. I wouldn't be surprised if all common code can be
run-time replaced in MTD.
Rutger
next prev parent reply other threads:[~2009-05-20 11:12 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-19 8:27 Simon Kallweit
2009-05-19 13:47 ` Ross Younger
2009-05-19 14:17 ` Andrew Lunn
2009-05-20 13:24 ` Bart Veer
2009-05-20 13:34 ` Rutger Hofman
2009-05-20 13:53 ` Andrew Lunn
2009-05-20 13:56 ` Gary Thomas
2009-05-20 14:22 ` Andrew Lunn
2009-05-20 15:22 ` Andrew Lunn
2009-05-20 15:34 ` Bart Veer
2009-05-20 13:58 ` Rutger Hofman
2009-05-20 14:16 ` Ross Younger
2009-05-20 14:21 ` Gary Thomas
2009-05-20 15:25 ` Ross Younger
2009-05-20 15:37 ` Gary Thomas
2009-05-19 16:29 ` Andrew Lunn
2009-06-03 8:51 ` Andrew Lunn
2009-06-03 10:21 ` Ross Younger
2009-06-03 10:48 ` Andrew Lunn
2009-06-03 11:52 ` Simon Kallweit
2009-06-03 12:26 ` Rutger Hofman
2009-06-03 13:33 ` Jürgen Lambrecht
2009-06-10 17:39 ` Nick Garnett
2009-06-11 11:25 ` Rutger Hofman
2009-06-13 16:31 ` Andrew Lunn
2009-06-18 14:10 ` Nick Garnett
2009-06-19 7:47 ` Andrew Lunn
2009-06-19 14:14 ` Ross Younger
2009-06-19 15:02 ` Andrew Lunn
2009-06-19 16:54 ` Jürgen Lambrecht
2009-06-29 11:09 ` Nick Garnett
2009-06-19 8:07 ` Andrew Lunn
2009-06-19 11:37 ` Daniel Morris
2009-06-19 12:06 ` Andrew Lunn
2009-05-20 1:02 ` Jonathan Larmour
2009-05-20 7:11 ` Simon Kallweit
2009-05-20 11:12 ` Rutger Hofman [this message]
2009-05-20 11:29 ` Simon Kallweit
2009-05-20 13:37 ` Rutger Hofman
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=4A13E69C.3070109@cs.vu.nl \
--to=rutger@cs.vu.nl \
--cc=ecos-devel@ecos.sourceware.org \
--cc=jifl@jifvik.org \
--cc=simon.kallweit@intefo.ch \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).