From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10498 invoked by alias); 20 May 2009 11:29:00 -0000 Received: (qmail 10486 invoked by uid 22791); 20 May 2009 11:28:58 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mail04.solnet.ch (HELO mail04.solnet.ch) (212.101.4.138) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 20 May 2009 11:28:50 +0000 Received: from mail04.solnet.ch ([127.0.0.1]) by localhost (mail04.solnet.ch [127.0.0.1]) (SolNet-Check, port 10024) with LMTP id i9MzjotCPDGR; Wed, 20 May 2009 11:28:47 +0000 (UTC) Received: from beta.intefo.ch (static-212-101-18-64.adsl.solnet.ch [212.101.18.64]) by mail04.solnet.ch (Postfix) with ESMTP id 8EB7486DB4; Wed, 20 May 2009 11:28:47 +0000 (UTC) Received: from beta.intefo.ch ([127.0.0.1]) by localhost (beta.intefo.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id y4CFe0QVqsMN; Wed, 20 May 2009 13:28:47 +0200 (CEST) Received: from [192.168.1.20] (simon.intefo.ch [192.168.1.20]) by beta.intefo.ch (Postfix) with ESMTP id 064847700E9; Wed, 20 May 2009 13:28:47 +0200 (CEST) Message-ID: <4A13E976.4050907@intefo.ch> Date: Wed, 20 May 2009 11:29:00 -0000 From: Simon Kallweit User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Rutger Hofman 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> <4A13E69C.3070109@cs.vu.nl> In-Reply-To: <4A13E69C.3070109@cs.vu.nl> 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/msg00041.txt.bz2 Rutger Hofman 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. I don't really like that idea, as it cuts flexibility a lot. I think we will see the need to control 2 or more NAND controllers and/or chips at the same time. With Ross's solution this is currently possible and this rare case is where his implementation shines IMHO, because you just simply implement it in the platform instead of trying to implement it generically. > 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. I'm with you on the code duplication matter and I think there should be a clear API between chips and the NAND controllers. I can't really judge if this is even possible. I have not yet used NAND flash and I don't know how diverse the controllers/chips out there are. Is there anyone with more insight? Simon