From: Thomas Gleixner <tglx@linutronix.de>
To: Aras Vaichas <arasv@magellan-technology.com>
Cc: MTD-LIST <linux-mtd@lists.infradead.org>
Subject: Re: Read/nBusy via interrupt
Date: Fri, 29 Oct 2004 12:16:18 +0200 [thread overview]
Message-ID: <1099044978.22387.557.camel@thomas> (raw)
In-Reply-To: <418213C3.3050706@magellan-technology.com>
On Fri, 2004-10-29 at 19:56 +1000, Aras Vaichas wrote:
> > No. Usually R/B is connected anyway.
>
> usually? If the software doesn't need it, then why would you connect it?
There's a different between needs it and takes advantage of it. If I can
take advantage, then I will connect it. Using the R/B signal instead of
polling is an advantage.
> >>* more code to write and debug!
> >
> > About 20 lines. I'm scared.
>
> No need to be scared. Software engineers don't come for free. development time
> == money.
Developing efficient polling might need software engineers too.
> I never said it would affect it significantly (or did I?). I was simply stating
> the fact that the time does increase. Every pin on a chip costs extra and when
> you are planning on making 10,000+ per year of a product, that price difference
> makes a affects your company's bottom line. If you don't believe me, then take
> a look at the Digikey page for the AT45DB081 and take a long hard look at unit
> price versus pin count.
I'm aware of high volume designs, where the pin count, pcb size ... has
to be taken into account.
> Doesn't it count as an MTD device? Where did this kernel option come from ->
> "CONFIG_MTD_AT91_DATAFLASH" ??
Did I say that ?
>
> > We are talking about NAND >= 32MB, which is often used for filesystems.
>
> Ben didn't mention "NAND >= 32MB, which is often used for filesystems", or
> perhaps I read the initial email incorrectly ... hmmm, my bad.
Ben was explicitly talking about NAND FLASH, where today the non
obsolete devices start at 32MB
> Thomas, your reply to my email was so ridiculously over the top and harsh.
Sorry, It was not my intention to offend you.
> I was simply offering an opinion and some information on a useful MTD device from
> the position of someone with hardware experience. Perhaps next time you should
> re-think the tone of your replies and consider the signal-to-noise ratio of
> what you write. I'm sure this forum will be a better place for it.
Just FYI, I have >20 years hardware/software experience.
Talking about signal/noise ratio. Is an extensive explanation of
DataFlash in answer to a question on NAND FLASH signal or noise ?
tglx
next prev parent reply other threads:[~2004-10-29 10:24 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-28 23:06 Read/nBusy via interrupt Ben Dooks
2004-10-28 23:13 ` Thomas Gleixner
2004-10-28 23:43 ` Aras Vaichas
2004-10-29 7:33 ` Thomas Gleixner
2004-10-29 9:56 ` Aras Vaichas
2004-10-29 9:57 ` jasmine
2004-10-29 10:16 ` Thomas Gleixner [this message]
2004-11-01 0:01 ` Aras Vaichas
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=1099044978.22387.557.camel@thomas \
--to=tglx@linutronix.de \
--cc=arasv@magellan-technology.com \
--cc=linux-mtd@lists.infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.