public inbox for ecos-devel@sourceware.org
 help / color / mirror / Atom feed
From: Rutger Hofman <rutger@cs.vu.nl>
To: Simon Kallweit <simon.kallweit@intefo.ch>
Cc: "ecos-devel@ecos.sourceware.org" <ecos-devel@ecos.sourceware.org>
Subject: Re: NAND review
Date: Wed, 20 May 2009 13:37:00 -0000	[thread overview]
Message-ID: <4A1408BB.1090808@cs.vu.nl> (raw)
In-Reply-To: <4A13E976.4050907@intefo.ch>

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

      reply	other threads:[~2009-05-20 13:37 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
2009-05-20 11:29       ` Simon Kallweit
2009-05-20 13:37         ` Rutger Hofman [this message]

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=4A1408BB.1090808@cs.vu.nl \
    --to=rutger@cs.vu.nl \
    --cc=ecos-devel@ecos.sourceware.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).