linux.git/drivers/mmc, branch v3.0-rc5

mmc: queue: bring discard_granularity/alignment into line with SCSI

2011-06-25T22:53:05+00:00

SCSI defines discard alignment as the offset to the first
optimal discard.  In the case of SD/MMC, that is always zero
which is the default.

SCSI defines discard granularity as a hint of a optimal
discard size.  That is much better expressed by the MMC
"preferred erase size" (pref_erase) field.

Signed-off-by: Adrian Hunter 
Signed-off-by: Chris Ball

mmc: queue: append partition subname to queue thread name

2011-06-25T22:52:57+00:00

For example, an eMMC with 2 boot partitions will have 3 threads.
The names change from:

   40 ?        00:00:00 mmcqd/0
   41 ?        00:00:00 mmcqd/0
   42 ?        00:00:00 mmcqd/0

to:

   40 ?        00:00:00 mmcqd/0
   41 ?        00:00:00 mmcqd/0boot0
   42 ?        00:00:00 mmcqd/0boot1

Signed-off-by: Adrian Hunter 
Cc: Andrei Warkentin 
Signed-off-by: Chris Ball

mmc: core: make erase timeout calculation allow for gated clock

2011-06-25T22:52:53+00:00

The erase timeout calculation may depend on clock rate
which is zero if the clock is gated, so use
mmc_host_clk_rate() which allows for that case.

Signed-off-by: Adrian Hunter 
Signed-off-by: Chris Ball

mmc: block: switch card to User Data Area when removing the block driver

2011-06-25T22:52:49+00:00

The MMC block driver and other drivers (e.g. mmc-test) will expect
the card to be switched to the User Data Area eMMC partition when
they start.  Hence the MMC block driver should ensure it is that
way when it is removed.

Signed-off-by: Adrian Hunter 
Cc: Andrei Warkentin 
Signed-off-by: Chris Ball

mmc: sdio: reset card during power_restore

2011-06-25T22:52:44+00:00

mmc_sdio_power_restore() skips some steps that are performed in other
power-related codepaths which are necessary to fully reset the card.
Without this, runtime PM fails for SD8686 SDIO wifi on OLPC XO-1.5.

Signed-off-by: Daniel Drake 
Signed-off-by: Chris Ball

mmc: sdhi: DMA slave ID 0 is invalid

2011-06-25T22:52:20+00:00

Don't try to allocate DMA resources if the platform didn't specify
positive DMA slave IDs.

Signed-off-by: Guennadi Liakhovetski 
Signed-off-by: Chris Ball

mmc: tmio: fix regression in TMIO_MMC_WRPROTECT_DISABLE handling

2011-06-25T22:52:15+00:00

Commit b6147490e6aac82 ("mmc: tmio: split core functionality, DMA and
MFD glue") broke handling of the TMIO_MMC_WRPROTECT_DISABLE flag by
the tmio-mmc driver. This patch restores the original behaviour.

Signed-off-by: Guennadi Liakhovetski 
Cc: 
Signed-off-by: Chris Ball

mmc: omap_hsmmc: use original sg_len for dma_unmap_sg

2011-06-25T22:51:28+00:00

Don't use the returned sg_len from dma_map_sg() as inparameter
to dma_unmap_sg(). Use the original sg_len for both dma_map_sg
and dma_unmap_sg according to the documentation in DMA-API.txt.

Signed-off-by: Per Forlin 
Reviewed-by: Venkatraman S 
Signed-off-by: Chris Ball

mmc: omap_hsmmc: fix ocr mask usage

2011-06-25T22:50:17+00:00

The OMAP HSMMC driver uses an ocr_mask to determine the list of voltages
supported by the card. It populates this mask based on the list of
voltages supported by the regulator that supplies the voltage.

Commit 64be97822b (omap4 hsmmc: Update ocr mask for MMC2 for regulator
to use) passed a fixed ocr_mask from the OMAP4 SDP board file to limit
the voltage to 2.9-3.0 Volts, and updated the driver to use this mask
if provided, instead of using the regulator's supported voltages.

However the commit is buggy - the ocr_mask is overridden by the
regulator's capabilities anyway. Fix this.

(The bug shows up when a system-wide suspend is attempted on the OMAP4
SDP/Blaze platforms. The eMMC card comes up at 3V, but drops to 1.65V
after the system resumes).

Signed-off-by: Anand Gadiyar 
Acked-by: Balaji T K 
Acked-by: Venkatraman S 
Tested-by: Kishore Kadiyala 
Signed-off-by: Sourav Poddar 
Signed-off-by: Chris Ball

mmc: sdio: fix runtime PM path during driver removal

2011-06-25T22:49:55+00:00

After commit e1866b3 "PM / Runtime: Rework runtime PM handling
during driver removal" was introduced, the driver core stopped
incrementing the runtime PM usage counter of the device during
the invocation of the ->remove() callback.

This indirectly broke SDIO's runtime PM path during driver removal,
because no one calls _put_sync() anymore after ->remove() completes.

This means that the power of runtime-PM-managed SDIO cards is kept
high after their driver is removed (even if it was powered down
beforehand).

Fix that by directly calling _put_sync() when the last usage
counter is downref'ed by the SDIO bus.

Reported-and-tested-by: Daniel Drake 
Signed-off-by: Ohad Ben-Cohen 
Signed-off-by: Chris Ball