u-boot.git/drivers/mmc, branch v2013.07-rc2

Fix block device accesses beyond 2TiB

2013-06-26T14:26:06Z

With CONFIG_SYS_64BIT_LBA, lbaint_t gets defined as a 64-bit type, which is required to represent block numbers for storage devices that exceed 2TiB (the block size usually is 512B), e.g. recent hard drives. For some obscure reason, the current U-Boot code uses lbaint_t for the number of blocks to read (a rather optimistic estimation of how RAM sizes will evolve), but not for the starting address. Trying to access blocks beyond the 2TiB boundary will simply wrap around and read a block within the 0..2TiB range. We now use lbaint_t for block start addresses, too. This required changes to all block drivers as the signature of block_read(), block_write() and block_erase() in block_dev_desc_t changed. Signed-off-by: Sascha Silbe

Merge branch 'master' of git://git.denx.de/u-boot-arm

2013-06-22T11:38:12Z

Merge branch 'u-boot-samsung/master' into 'u-boot-arm/master'

2013-06-19T10:53:59Z

Conflicts: spl/Makefile

MMC: DWMMC: Fix FIFO_DEPTH calculation

2013-06-17T02:03:42Z

Current DWMMC driver used to give FIFO underrun/overrun error every 3rd time for mmc rescan command. In current code FIFO_DEPTH is getting calculated after reading the default FIFOTH register and extracting the RX_WMARK bits from it i.e (RX_WMARK = FIFO_DEPTH/2 -1). Instead of storing the correct value, we were recalculating the FIFO_DEPT each time which is not correct. Based on "[PATCH V9 3/9] DWMMC: Initialise dwmci and resolve EMMC read write issues" http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/160247 Signed-off-by: Hatim Ali Signed-off-by: Rajeshwari Shinde Acked-by: Simon Glass Tested-by: Simon Glass Acked-by: Jaehoon Chung Acked-by: Andy Fleming Signed-off-by: Minkyu Kang

Merge branch 'master' of git://www.denx.de/git/u-boot-mmc

2013-06-14T20:06:49Z

mmc: report capacity for the selected partition

2013-06-13T21:52:19Z

Enhance the MMC core to calculate the size of each MMC partition, and update mmc->capacity whenever a partition is selected. This causes: mmc dev 0 1 ; mmcinfo ... to report the size of the currently selected partition, rather than always reporting the size of the user partition. Signed-off-by: Stephen Warren Signed-off-by: Andy Fleming

fsl_esdhc: Do not clear interrupt status bits until data processed

2013-06-13T21:52:19Z

After waiting for the command completion event, the interrupt status bits, that occured to be set by that time, are cleared by writing them back. It is supposed, that it should be command related bits (command complete and may be command errors). However, in some cases the DMA already completes by that time before the full transaction completes. The corresponding DINT bit gets set and then cleared before even entering the loop, waiting for data part completion. That waiting loop never gets this bit set, causing the operation to hang. This is reported to happen, for example, for write operation of 1 sector to upper area (block #7400000) of SanDisk Ultra II 8GB card. The solution could be to explicitly clear only command related interrupt status bits. However, since subsequent processing does not rely on any command bits state, it could be easier just to remove clearing of any bits at that point, leaving them all until all data processing completes. After that the whole register will be cleared at once. Also, on occasion, interrupts masking moved to before writing the command, just for the case there should be no chance of interrupt between the first command and interrupts masking. Reported-by: Dirk Behme Signed-off-by: Andrew Gabbasov Acked-by: Dirk Behme Signed-off-by: Andy Fleming

mmc: fsl_esdhc: Fix hang after 'save' command

2013-06-13T21:52:19Z

Since commit 48e0b2bd (powerpc/esdhc: Correct judgement for DATA PIO mode) we see mx6 systems to hang after doing a 'save' command. Revert this commit since the original 'ifdef' logic from 7b43db92 (drivers/mmc/fsl_esdhc.c: fix compiler warnings) was the correct one. Reported-by: Tapani Utriainen Signed-off-by: Fabio Estevam Signed-off-by: Andy Fleming

mmc write bug fix

2013-06-13T21:46:57Z

This patch fixes a bug related to mmc writes. When doing fatwrites on an SD-Card, MMC bus problems can occur. Depending on the size of the file, "MMC0: Bus busy timeout!" is reported, resulting in an SD-Card that is no longer responding. It appears to be, that set_cluster can be called with a size being zero. That can be with a file that has a size being an exact multiple (including 0) of the clustersize, but also for files that are smaller than the size of one cluster. The same problem occurs if the "mmc write" command is given with a block count being 0. By adding a check for the block count being zero in mmc_write_blocks (drivers/mmc.c), this problem is solved. Signed-off-by: Ruud Commandeur Cc: Tom Rini Cc: Benoît Thébaudeau Cc: Mats Karrman Cc: Andy Fleming Signed-off-by: Andy Fleming

mmc: sdhci: Enable 8-bit bus width only for 3.0 spec onwards

2013-06-13T21:44:49Z

CAP register don't have any information for 8-bit buswidth support on 2.0 sdhci spec, only from 3.0 onwards bit[18] got this information. Due to this misassignment in sdhci, mmc is setting 8-bit buswidth using mmc_set_bus_width even if controller doesn't support. Below change has code information. "mmc: Properly determine maximum supported bus width" (sha1: 7798f6dbd5e1a3030ed81a81da5dfb57c3307cac) Bug log: mmcinfo Error detected in status(0x208100)! Device: zynq_sdhci Manufacturer ID: fe ..... So enable 8-bit support only for 3.0 spec using CAP and for below 3.0 assign mmc->host_caps = MMC_MODE_8BIT on respective platform driver if host have a support. Signed-off-by: Jagannadha Sutradharudu Teki Signed-off-by: Andy Fleming