From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1630 invoked by alias); 20 May 2009 11:12:01 -0000 Received: (qmail 1613 invoked by uid 22791); 20 May 2009 11:12:00 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from smtp-vbr4.xs4all.nl (HELO smtp-vbr4.xs4all.nl) (194.109.24.24) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 20 May 2009 11:11:52 +0000 Received: from [192.168.1.66] (cust.7.108.adsl.cistron.nl [82.95.157.21]) by smtp-vbr4.xs4all.nl (8.13.8/8.13.8) with ESMTP id n4KBBMJK005118; Wed, 20 May 2009 13:11:26 +0200 (CEST) (envelope-from rutger@cs.vu.nl) Message-ID: <4A13E69C.3070109@cs.vu.nl> Date: Wed, 20 May 2009 11:12:00 -0000 From: Rutger Hofman User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Simon Kallweit CC: Jonathan Larmour , "ecos-devel@ecos.sourceware.org" Subject: Re: NAND review References: <4A126D59.7070404@intefo.ch> <4A134A31.4080806@jifvik.org> <4A13AD30.40405@intefo.ch> In-Reply-To: <4A13AD30.40405@intefo.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2009-05/txt/msg00040.txt.bz2 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