From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Petazzoni Date: Wed, 9 Jun 2010 09:06:26 +0200 Subject: [U-Boot] [PATCH 1/4] Atmel Dataflash: convert to C struct accessors In-Reply-To: <201006081520.58084.vapier@gentoo.org> References: <4C0CE8A6.8080608@bumblecow.com> <201006071852.04592.vapier@gentoo.org> <20100608142433.268060ee@surf> <201006081520.58084.vapier@gentoo.org> Message-ID: <20100609090626.7a1c67ca@surf> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Tue, 8 Jun 2010 15:20:57 -0400 Mike Frysinger wrote: > speaking historically, the dataflash code absolutely has its place. > it existed long before the SPI flash framework. but i'm looking > forward only now. Yes, of course, understood. However, the Dataflash aren't normal SPI flash, they don't have the same opcodes. For example, drivers/mtd/spi/spi_flash.c assumes that it can probe the "ID code" of the SPI flash by sending the CMD_READ_ID (0x9F) command (in spi_flash_probe()). This works for SPI flashes, but not for Dataflashes. The identification of Dataflashes takes place with command GET_STATUS (0xD7) in drivers/mtd/at45.c, which has a different return value than the 0x9F command of SPI flashes. Am I missing something ? In terms of code infrastructure/organization, how do you suggest to handle this ? > i think the first step would be to convert the boards we can and > leave a #warning for the rest that the dataflash code is being killed > off. then after some time, if no one has fixed the remainders, we do > our best to convert them. -mike Ok. Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://lists.denx.de/pipermail/u-boot/attachments/20100609/7503683b/attachment.pgp