From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Frysinger Date: Thu, 26 Aug 2010 02:12:20 -0400 Subject: [U-Boot] [PATCH] MTD/SPI/FLASH: add support for Ramtron FRAMs using SPI In-Reply-To: <4C760243.6030102@emk-elektronik.de> References: <1282740439-7910-1-git-send-email-u-boot@emk-elektronik.de> <201008252231.15014.vapier@gentoo.org> <4C760243.6030102@emk-elektronik.de> Message-ID: <201008260212.20777.vapier@gentoo.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Thursday, August 26, 2010 01:57:23 Reinhard Meyer wrote: > Dear Mike Frysinger, > > #if defined(CONFIG_SPI_FRAM_RAMTRON) > > # define IDCODE_LEN 10 > > #else > > # define IDCODE_LEN 5 > > #endif > > OK, see below. Can't we have it 10 generally? The impact should be > negligible? hrm, i guess ... but i didnt even really like raising it to the 5 for one specific family ... > > for the second, what do you get back when you issue the idcode ? 0xff ? > > we already have a fall back case for this with stmicro, so perhaps we > > should > > > > generalize this further too. after the vendor id switch statement, we do: > > If MISO has no pull-up the result is indeterminate, the chip simply lets > MISO float when it does not honor the read-id command. > > I'll add a comment to that file that a pull-up is required for non-standard > devices to be detected. Otherwise, depending on random noise, a false > detection of a standard device is not entirely impossible. that sounds reasonable to me -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. Url : http://lists.denx.de/pipermail/u-boot/attachments/20100826/10488897/attachment.pgp