Re: [U-Boot] [PATCH 0/4] generic mmc_spi driver
On Tue, Apr 12, 2011 at 1:58 AM, Mike Frysinger vap...@gentoo.org wrote: On Friday, December 24, 2010 02:16:05 Thomas Chou wrote: This is the v9 update of the mmc_spi driver. Please enable DEBUG on the top of mmc_spi.c and help me perform the tests. A new spi_set_speed() is added to meet the 400KHz clock requirement during mmc card initialization. An example update to bfin_spi is included. The altera_spi core does not support speed change, so I am going to post a new opencore ip for this. The driver now claims and releases the spi bus for each mmc command, as Mike suggested. Thomas Chou (4): lib: add crc7 from Linux spi: add spi_set_speed func bfin_spi: add spi_set_speed mmc: add generic mmc spi driver Andy: i think we've hit a fairly stable point. could you merge this now ? I'm going to merge this, but I'll note that the reason you had to run mmcinfo before this will work is because this code never invoks mmc_init(). If you look at the mmc command in common/cmd_mmc.c, and see how the various sub-commands operate (under GENERIC_MMC), all of them call mmc_init() before running the command. It's suboptimal in terms of performance, but has the advantage of being robust and actually detecting if you put a card in, or took one out. If someone could find the appropriate places to call mmc_init(mmc), I'll be happy to also merge in the follow-up patch. Also, I'm assuming, at the moment, that this supersedes the legacy mmc_spi patch you submitted earlier? If not, I'll put that in, now, too. Andy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] generic mmc_spi driver
On Wednesday, April 13, 2011 06:17:43 Andy Fleming wrote: On Tue, Apr 12, 2011 at 1:58 AM, Mike Frysinger vap...@gentoo.org wrote: On Friday, December 24, 2010 02:16:05 Thomas Chou wrote: This is the v9 update of the mmc_spi driver. Please enable DEBUG on the top of mmc_spi.c and help me perform the tests. A new spi_set_speed() is added to meet the 400KHz clock requirement during mmc card initialization. An example update to bfin_spi is included. The altera_spi core does not support speed change, so I am going to post a new opencore ip for this. The driver now claims and releases the spi bus for each mmc command, as Mike suggested. Thomas Chou (4): lib: add crc7 from Linux spi: add spi_set_speed func bfin_spi: add spi_set_speed mmc: add generic mmc spi driver Andy: i think we've hit a fairly stable point. could you merge this now ? I'm going to merge this, but I'll note that the reason you had to run mmcinfo before this will work is because this code never invoks mmc_init(). If you look at the mmc command in common/cmd_mmc.c, and see how the various sub-commands operate (under GENERIC_MMC), all of them call mmc_init() before running the command. It's suboptimal in terms of performance, but has the advantage of being robust and actually detecting if you put a card in, or took one out. If someone could find the appropriate places to call mmc_init(mmc), I'll be happy to also merge in the follow-up patch. i hope Thomas can do that :) Also, I'm assuming, at the moment, that this supersedes the legacy mmc_spi patch you submitted earlier? If not, I'll put that in, now, too. correct, the legacy mmc_spi code is hopefully no longer needed -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] generic mmc_spi driver
On Friday, December 24, 2010 02:16:05 Thomas Chou wrote: This is the v9 update of the mmc_spi driver. Please enable DEBUG on the top of mmc_spi.c and help me perform the tests. A new spi_set_speed() is added to meet the 400KHz clock requirement during mmc card initialization. An example update to bfin_spi is included. The altera_spi core does not support speed change, so I am going to post a new opencore ip for this. The driver now claims and releases the spi bus for each mmc command, as Mike suggested. Thomas Chou (4): lib: add crc7 from Linux spi: add spi_set_speed func bfin_spi: add spi_set_speed mmc: add generic mmc spi driver Andy: i think we've hit a fairly stable point. could you merge this now ? -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] generic mmc_spi driver
On Friday, December 24, 2010 02:16:05 Thomas Chou wrote: This is the v9 update of the mmc_spi driver. Please enable DEBUG on the top of mmc_spi.c and help me perform the tests. A new spi_set_speed() is added to meet the 400KHz clock requirement during mmc card initialization. An example update to bfin_spi is included. The altera_spi core does not support speed change, so I am going to post a new opencore ip for this. this seems to work much nicer for me. only odd thing is that 'fatls' does not work if i dont 'mmcinfo' first. do you see the same ? maybe this is (currently) expected behavior ? from cold boot: bfin mmc_spi 4 MMC_SPI: 0 at 0:4 hz 2500 mode 0 bfin fatls mmc 0:1 MMC: block number 0x1 exceeds max(0x0) ** Can't read from device 0 ** ** Unable to use mmc 0:1 for fatls ** bfin mmcinfo Device: MMC_SPI Manufacturer ID: 0 OEM: 2 Name: card Tran Speed: 2500 Rd Block Len: 512 SD version 1.0 High Capacity: No Capacity: 31326208 Bus Width: 1-bit bfin fatls mmc 0:1 private/ bootmii/ 3041 installer.log apps/ 5213 readme-bootmii.txt 7273 readme-hbc.txt config/ 3 file(s), 4 dir(s) -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] generic mmc_spi driver
Dear Mike Frysinger, this seems to work much nicer for me. only odd thing is that 'fatls' does not work if i dont 'mmcinfo' first. do you see the same ? maybe this is (currently) expected behavior ? Currently it is like that with the common MMC framework. Same behavior with gen_atmel_mci. I'd think its normal that you have to init such a block device first, isn't it the same with USB? Otherwise you'd have to implement automated init on first block read, and detection of removal and insertion of a new device to re-read the info. Season's Greetings, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] generic mmc_spi driver
On Friday, December 24, 2010 14:06:34 Reinhard Meyer wrote: Dear Mike Frysinger, this seems to work much nicer for me. only odd thing is that 'fatls' does not work if i dont 'mmcinfo' first. do you see the same ? maybe this is (currently) expected behavior ? Currently it is like that with the common MMC framework. Same behavior with gen_atmel_mci. I'd think its normal that you have to init such a block device first, isn't it the same with USB? Otherwise you'd have to implement automated init on first block read, and detection of removal and insertion of a new device to re-read the info. my gripe is that it's called mmcinfo and not mmc init. if it were the latter, i wouldnt be surprised at all. but it seems odd that i have to query the device and print its extended info rather than initialize the mmc card. perhaps i'm just whining semantics though. if this is currently the standard/expected behavior for the generic mmc framework, then that's OK from the mmc_spi perspective. i'll merge this into the Blackfin tree and let our testers validate it with our regression tests. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] generic mmc_spi driver
On 12/25/2010 03:45 AM, Mike Frysinger wrote: if this is currently the standard/expected behavior for the generic mmc framework, then that's OK from the mmc_spi perspective. i'll merge this into the Blackfin tree and let our testers validate it with our regression tests. -mike Yes. It is the current behaviour. I just added an update to run the initialization clock at 400KHz which should improve compatibility. Please try out. Thank you very much. Merry Xmas! - Thomas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot