From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gate.epygi.de ([212.126.211.241]) by pentafluge.infradead.org with esmtp (Exim 4.14 #3 (Red Hat Linux)) id 19asOy-0003Tn-Vq for ; Fri, 11 Jul 2003 08:33:09 +0100 From: "Stephan Linke" To: , "David Woodhouse" , Date: Fri, 11 Jul 2003 09:33:05 +0200 Message-ID: MIME-Version: 1.0 In-Reply-To: <200307110218.28358.tglx@linutronix.de> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable cc: Charles Manning cc: linux-mtd@lists.infradead.org Subject: RE: nand flash driver List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Hi, >=20 > It will work with addresslines, if >=20 > 1. All datasheets are reliable > 2. Your hardwaredesigner can precalculate all the timings in details = even=20 > under high interrupt load !!!! > 3. the softwareguy is aware of the above problems >=20 > My experience is (I have a bunch of different solutions here on top of = my=20 > desk): >=20 > Either you have a genius in hardware and software design available or = you have=20 > a rock solid solution with GPIO/FPGA/CPLD. The second one will either=20 > increase your production costs by <1$ per piece or decrease your = performance=20 > by about 8%. > Both negatives will be less than the debugging and redesign costs. >=20 I don't know exactly what our hardware guys did but from softer = perspective I can say the most "difficult" part is to copy = nand_command() and modify it so it uses your addresses to switch between = data, address and command mode. You can remove a few calls of = hwcontrol(). Write your own hwcontrol() and dev_ready() function, that's = it. Few magic in there. The important question is: did the hardware designer a good job? And I = hope ours did. ;-) Stephan