From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16318 invoked by alias); 20 May 2009 13:37:06 -0000 Received: (qmail 16308 invoked by uid 22791); 20 May 2009 13:37:05 -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-vbr13.xs4all.nl (HELO smtp-vbr13.xs4all.nl) (194.109.24.33) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 20 May 2009 13:37:01 +0000 Received: from [192.168.1.66] (cust.7.108.adsl.cistron.nl [82.95.157.21]) by smtp-vbr13.xs4all.nl (8.13.8/8.13.8) with ESMTP id n4KDatUP005843; Wed, 20 May 2009 15:36:55 +0200 (CEST) (envelope-from rutger@cs.vu.nl) Message-ID: <4A1408BB.1090808@cs.vu.nl> Date: Wed, 20 May 2009 13:37:00 -0000 From: Rutger Hofman User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Simon Kallweit CC: "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> <4A13E976.4050907@intefo.ch> In-Reply-To: <4A13E976.4050907@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/msg00045.txt.bz2 Simon Kallweit wrote: > 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. Uhmmm... I am not sure I understand? In my current NAND implementation, the platform is free to hide the fact that there are multiple devices by having one ANC that handles the multiplicity issues transparently, or the platform can configure things so that the multiplicity is made public by using multiple ANC structs, or everything in between. #undef-ing the multiplicity support /within/ the ANC code would be a hack to get leaner compiled code when ANCs have only one (type of) controller/chip. This leaves in multiplicity by using multiple ANCs anyway. Rutger