linux-stable.git/include/linux/mmc/host.h, branch linux-2.6.37.y

mmc: sdio: fix runtime PM anomalies by introducing MMC_CAP_POWER_OFF_CARD

2010-11-19T22:07:01+00:00

Some board/card/host configurations are not capable of powering off the
card after boot.

To support such configurations, and to allow smoother transition to
runtime PM behavior, MMC_CAP_POWER_OFF_CARD is added, so hosts need to
explicitly indicate whether it's OK to power off their cards after boot.

SDIO core will enable runtime PM for a card only if that cap is set.
As a result, the card will be powered down after boot, and will only
be powered up again when a driver is loaded (and then it's up to the
driver to decide whether power will be kept or not).

This will prevent sdio_bus_probe() failures with setups that do not
support powering off the card.

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

mmc: propagate power save/restore ops return value

2010-10-23T13:11:17+00:00

Allow power save/restore and their relevant mmc_bus_ops handlers
exit with a return value.

Signed-off-by: Ohad Ben-Cohen 
Tested-by: Luciano Coelho 
Signed-off-by: Chris Ball

mmc: refine DDR support

2010-10-23T13:11:16+00:00

One flaw with DDR support is that MMC core does not inform the driver
which DDR mode it has selected.  This patch expands the ios->ddr flag
to do that.

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

mmc: Fixes for Dual Data Rate (DDR) support

2010-10-23T13:11:16+00:00

The DDR support patch needs the following fixes:

- The block driver does not need to know about DDR, any more
  than it needs to know about bus width.
- Not only the card must be switched to DDR mode.  The host
  controller must also be configured, which is done through
  the 'set_ios()' function.
- Do not set the DDR mode state until after the switch command
  is successful.
- Setting block length is not supported in DDR mode.  Make that
  a core function and change the other place it is used (mmc_test)
  also.

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

mmc: MMC 4.4 DDR support

2010-10-23T13:11:16+00:00

Add support for Dual Data Rate MMC cards as defined in the 4.4
specification.

Signed-off-by: Hanumath Prasad 
Cc: linux-mmc@vger.kernel.org
Acked-by: Linus Walleij 
Tested-by Zhangfei Gao 
Signed-off-by: Chris Ball

mmc: Move regulator handling closer to core

2010-10-23T13:11:16+00:00

After discovering a problem in regulator reference counting I took Mark
Brown's advice to move the reference count into the MMC core by making the
regulator status a member of struct mmc_host.

I took this opportunity to also implement NULL versions of
the regulator functions so as to rid the driver code from
some ugly #ifdef CONFIG_REGULATOR clauses.

Signed-off-by: Linus Walleij 
Reviewed-by: Mark Brown 
Cc: Liam Girdwood 
Cc: Tony Lindgren 
Cc: Adrian Hunter 
Cc: Robert Jarzmik 
Cc: Sundar Iyer 
Cc: Daniel Mack 
Cc: Pierre Ossman 
Cc: Matt Fleming 
Cc: David Brownell 
Cc: Russell King 
Cc: Eric Miao 
Cc: Cliff Brake 
Cc: Jarkko Lavinen 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Chris Ball

mmc: Make ID freq configurable

2010-10-23T13:11:15+00:00

In the latest releases of the mmc driver, the freq during initialization
is set to a fixed 400 Khz.  This was reportedly too fast for several
users.  As there doesn't seem to be an ideal frequency
which-works-for-all, Pierre suggested to let the driver try several
frequencies.

This patch implements that idea. It will try mmc-initialization using
several frequencies from an array 400, 300, 200 and 100.

In case SDIO is broken, it'll still try to detect SDMEM, also at different
freqs.

Signed-off-by: Hein Tibosch 
Cc: Pierre Ossman 
Reviewed-by: Chris Ball 
Tested-by: Chris Ball 
Cc: Ben Nizette 
Cc: Sascha Hauer 
Cc: Adrian Hunter 
Cc: Matt Fleming 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Chris Ball

mmc: Add helper function to check if a card is removable

2010-10-23T13:11:15+00:00

There are two checks that need to be made when determining whether a
card is removable. A host controller may set MMC_CAP_NONREMOVABLE if the
controller does not support removing cards (e.g. eMMC), in which case
the card is physically non-removable. Also the 'mmc_assume_removable'
module parameter can be configured at module load time, in which case
the card may be logically non-removable.

A helper function keeps the logic in one place so that code always
checks both conditions.

Because this new function is likely to be called from modules we now
need to export the mmc_assume_removable symbol.

Signed-off-by: Matt Fleming 
Acked-by: Kyungmin Park 
Tested-by: Jaehoon Chung 
Acked-by: Wolfram Sang 
Signed-off-by: Chris Ball

mmc: Remove distinction between hw and phys segments

2010-10-23T13:11:11+00:00

We have deprecated the distinction between hardware and physical
segments in the block layer.  Consolidate the two limits into one in
drivers/mmc/.

Signed-off-by: Martin K. Petersen 
Signed-off-by: Chris Ball

mmc: add erase, secure erase, trim and secure trim operations

2010-08-12T15:43:30+00:00

SD/MMC cards tend to support an erase operation.  In addition, eMMC v4.4
cards can support secure erase, trim and secure trim operations that are
all variants of the basic erase command.

SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
added.

"erase_size" is the minimum size, in bytes, of an erase operation.  For
MMC, "erase_size" is the erase group size reported by the card.  Note that
"erase_size" does not apply to trim or secure trim operations where the
minimum size is always one 512 byte sector.  For SD, "erase_size" is 512
if the card is block-addressed, 0 otherwise.

SD/MMC cards can erase an arbitrarily large area up to and
including the whole card.  When erasing a large area it may
be desirable to do it in smaller chunks for three reasons:

    1. A single erase command will make all other I/O on the card
       wait.  This is not a problem if the whole card is being erased, but
       erasing one partition will make I/O for another partition on the
       same card wait for the duration of the erase - which could be a
       several minutes.

    2. To be able to inform the user of erase progress.

    3. The erase timeout becomes too large to be very useful.
       Because the erase timeout contains a margin which is multiplied by
       the size of the erase area, the value can end up being several
       minutes for large areas.

"erase_size" is not the most efficient unit to erase (especially for SD
where it is just one sector), hence "preferred_erase_size" provides a good
chunk size for erasing large areas.

For MMC, "preferred_erase_size" is the high-capacity erase size if a card
specifies one, otherwise it is based on the capacity of the card.

For SD, "preferred_erase_size" is the allocation unit size specified by
the card.

"preferred_erase_size" is in bytes.

Signed-off-by: Adrian Hunter 
Acked-by: Jens Axboe 
Cc: Kyungmin Park 
Cc: Madhusudhan Chikkature 
Cc: Christoph Hellwig 
Cc: Ben Gardiner 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds