linux.git/drivers/mmc/core, branch v3.1-rc2

mmc: core: use defined R1_STATE_PRG macro for card status

2011-08-13T18:50:31+00:00

Signed-off-by: Jaehoon Chung 
Signed-off-by: Kyungmin Park 
Signed-off-by: Chris Ball

mmc: core: Detect eMMC v4.5 ext_csd entries

2011-08-13T18:50:22+00:00

The eMMC v4.5 Spec is released now:

EXT_CSD_REV	Extended CSD Revision
255-7		Reserved
6		Revision 1.6 (for MMC v4.5)
5		Revision 1.5 (for MMV v4.41)
...

Signed-off-by: Kyungmin Park 
Signed-off-by: Chris Ball

notifiers: pm: move pm notifiers into suspend.h

2011-07-26T03:57:15+00:00

It is not necessary to share the same notifier.h.

Signed-off-by: WANG Cong 
Cc: David Miller 
Acked-by: "Rafael J. Wysocki" 
Cc: Greg KH 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mmc: print debug messages for runtime PM actions

2011-07-21T14:35:09+00:00

At http://www.mail-archive.com/linux-mmc@vger.kernel.org/msg08371.html
(thread: "mmc: sdio: reset card during power_restore") we found and
fixed a bug where mmc's runtime power management functions were not being
called. We have now also made improvements to the SDIO powerup routine
which could possibly mask this kind of issue in future.

Add debug messages to the runtime PM hooks so that it is easy to verify
if and when runtime PM is happening.

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

mmc: fix runtime PM with -ENOSYS suspend case

2011-07-21T14:35:09+00:00

In the case where a driver returns -ENOSYS from its suspend handler
to indicate that the device should be powered down over suspend, the
remove routine of the driver was not being called, leading to lots of
confusion during resume.

The problem is that runtime PM is disabled during this process,
and when we reach mmc_sdio_remove, calling the runtime PM functions here
(validly) return errors, and this was causing us to skip the remove
function.

Fix this by ignoring the error value of pm_runtime_get_sync(), which
can return valid errors. This also matches the behaviour of
pci_device_remove().

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

mmc: core: Set non-default Drive Strength via platform hook

2011-07-20T21:21:16+00:00

Non default Drive Strength cannot be set automatically.  It is a function
of the board design and only if there is a specific platform handler can
it be set.  The platform handler needs to take into account the board
design.  Pass to the platform code the necessary information.

For example:  The card and host controller may indicate they support HIGH
and LOW drive strength.  There is no way to know what should be chosen
without specific board knowledge.  Setting HIGH may lead to reflections
and setting LOW may not suffice.  There is no mechanism (like ethernet
duplex or speed pulses) to determine what should be done automatically.

If no platform handler is defined -- use the default value.

Signed-off-by: Philip Rakity 
Reviewed-by: Arindam Nath 
Signed-off-by: Chris Ball

mmc: core: add non-blocking mmc request function

2011-07-20T21:21:10+00:00

Previously there has only been one function mmc_wait_for_req()
to start and wait for a request. This patch adds:

 * mmc_start_req() - starts a request wihtout waiting
   If there is on ongoing request wait for completion
   of that request and start the new one and return.
   Does not wait for the new command to complete.

This patch also adds new function members in struct mmc_host_ops
only called from core.c:

 * pre_req - asks the host driver to prepare for the next job
 * post_req - asks the host driver to clean up after a completed job

The intention is to use pre_req() and post_req() to do cache maintenance
while a request is active. pre_req() can be called while a request is
active to minimize latency to start next job. post_req() can be used after
the next job is started to clean up the request. This will minimize the
host driver request end latency. post_req() is typically used before
ending the block request and handing over the buffer to the block layer.

Add a host-private member in mmc_data to be used by pre_req to mark the
data. The host driver will then check this mark to see if the data is
prepared or not.

Signed-off-by: Per Forlin 
Acked-by: Kyungmin Park 
Acked-by: Arnd Bergmann 
Reviewed-by: Venkatraman S 
Tested-by: Sourav Poddar 
Tested-by: Linus Walleij 
Signed-off-by: Chris Ball

mmc: queue: let host controllers specify maximum discard timeout

2011-07-20T21:21:03+00:00

Some host controllers will not operate without a hardware
timeout that is limited in value.  However large discards
require large timeouts, so there needs to be a way to
specify the maximum discard size.

A host controller driver may now specify the maximum discard
timeout possible so that max_discard_sectors can be calculated.

However, for eMMC when the High Capacity Erase Group Size
is not in use, the timeout calculation depends on clock
rate which may change.  For that case Preferred Erase Size
is used instead.

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

mmc: core: Bus width testing needs to handle suspend/resume

2011-07-13T18:54:37+00:00

On reading the ext_csd for the first time (in 1 bit mode), save the
ext_csd information needed for bus width compare.

On every pass we make re-reading the ext_csd, compare the data
against the saved ext_csd data.

This fixes a regression introduced in 3.0-rc1 by 08ee80cc397ac1a3
("mmc: core: eMMC bus width may not work on all platforms"), which
incorrectly assumed we would be re-reading the ext_csd at resume-
time.

Signed-off-by: Philip Rakity 
Tested-by: Jaehoon Chung 
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