This patch makes the following needlessly global functions static:
- sd_ops.c: mmc_app_cmd()
- core.c: __mmc_release_bus()
- core.c: mmc_start_request()
Signed-off-by: NAdrian Bunk <bunk@stusta.de>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Make sure that the debugging output in the core is complete.
This should allow us to clean up all the extra debug output
that each and every other host driver seems to contain.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

In the normal case, the host lock can be claimed directly.
When it cannot, the caller will sleep. Make sure we don't
have any latent bugs by always calling might_sleep().
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Make sure the kerneldoc comments are up to date and relevant.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Move basic host class device handling to its own file for clarity.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Move bus operations to its own file for the sake of clarity. Also
delegate sysfs attributes to bus handlers in preparation for other
more exotic types.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Cc: Pierre Ossman <drzeus@drzeus.cx>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

As mmc_detect_change() can be called from irq context, using
claim (which can sleep) is inherently unsafe. Use the host
spinlock instead, which also is faster.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Since many have the system root on MMC/SD we must allow some foot
shooting when it comes to resume.

We cannot detect if a card is removed and reinserted during suspend,
so the safe approach would be to assume it was, avoiding potential
filesystem corruption. This will of course not work if you cannot
release the card before suspend.

This commit adds a compile time option that makes the MMC layer
assume the card wasn't touched if it is redetected upon resume.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Delegate protocol handling to "bus handlers". This allows the core to
just handle the task of arbitrating the bus. Initialisation and
pampering of cards is now done by the different bus handlers.

This design also allows MMC and SD (and later SDIO) to be more cleanly
separated, allowing easier maintenance.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Move protocol operations and definitions into their own files
in an effort to separate protocol handling and bus
arbitration more clearly.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Create a "core" subdirectory to house the central bus handling
functions.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

The classic MMC bus was defined as multi card bus
system, which is reflected in the design in the MMC
layer.

When SD showed up, the bus topology was abandoned
and a star topology (one card per host) was mandated.
MMC version 4 has followed this, officially deprecating
the bus topology.

As we do not have any known users of the bus
topology we can remove support for it. This will
simplify the code and rectify some incorrect
assumptions in the newer additions.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Suspending MMC/SD cards (versus removing and readding them) is an
inherently unsafe operation and has even been broken for some time.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Make sure we kill of any pending detection runs when the host
is removed instead of when it is freed. Also add some debugging
to make sure the driver doesn't queue up more detection after it
has removed the host.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

The "present" state indicates that the card is a registered device, so
it is more clear to put it together with the actual registration.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Split out the type of card into its own field as it hardly
qualifies as a state.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Support for MMC 4.2 sector based cards. This tweaks the init a
bit and reads a new field out of the EXT_CSD.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Fix copy-n-paste error.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Now that we've fixed our only offender when it comes to strange sg
list, add a check so that future users keep the sg list proper with
regard to transfer size.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

The new high-speed timings are similar to each other and the old
system, but not identical. And although things "just work" most of
the time, sometimes it does not. So we need to start marking which
hosts are known to fully comply with the new timings.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

MMC high-speed, wide bus support and SD high-speed
are functions that aren't critical for correct
operation of the card. As such, they shouldn't mark
the card as bad or dead when there is a failure
activating these features.

This is needed in particular on some really stupid
hardware (e.g. Winbond's) where not all data transfer
commands are supported.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Many controllers have an upper limit on the number of blocks that can be
transferred in one request. Allow the host drivers to specify this and make
sure we avoid hitting this limit.

Also change the max_sectors field to avoid confusion. This makes it map
less directly to the block layer limits, but as they didn't apply directly
on MMC cards anyway, this isn't a great loss.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Most controllers have an upper limit on the block size. Allow the host
drivers to specify this and make sure we avoid hitting this limit.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Thanks to the generous donation of an SDHC card by John Gilmore, and
the surprisingly enlightened decision by the SD Card Association to
publish useful specs, I've been able to bash out support for SDHC. The
changes are not too profound:

i) Add a card flag indicating the card uses block level addressing and
check it in the block driver. As we never took advantage of byte-level
addressing, this simply involves skipping the block -> byte
translation when sending commands.

ii) The layout of the CSD is changed - a set of fields are discarded
to make space for a larger C_SIZE. We did not reference any of the
discarded fields except those related to the C_SIZE.

iii) Read and write timeouts are fixed values and not calculated from
CSD values.

iv) Before invoking SEND_APP_OP_COND, we must invoke the new
SEND_IF_COND to inform the card we support SDHC.
Signed-off-by: NPhilipl Langdale <philipl@overt.org>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

As card_busy was only used to indicate if the host was exclusively
claimed and not really used to identify a particular card, replacing
it with just a boolean makes things a lot more easily understandable.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Modern SD cards support a clock speed of 50 MHz. Make sure we test for
this capability and do the song and dance required to activate it.

Activating high speed support actually modifies the TRAN_SPEED field
of the CSD. But as the spec says that the cards must report 50 MHz,
we might as well skip re-reading the CSD.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Several fixes for mmc_delay():

 * Repair if-clause that was supposed to detect sub-hz delays.
 * Change yield() to cond_resched() as yield() no longer has the
   semantics we desire.
 * mmc_delay() is used to guarantee protocol delays, so we cannot
   return early (i.e. use _interruptable).

Based on patch by Amol Lad.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

This change adds support for the mmc4 4-bit wide-bus mode.

The mmc4 spec defines 8-bit and 4-bit transfer modes. As we do not support
any 8-bit hardware, this patch only adds support for the 4-bit mode, but
it can easily be built upon when the time comes.

The 4-bit mode is electrically compatible with SD's 4-bit mode but the
procedure for turning it on is different. This patch implements only
the essential parts of the procedure as defined by the spec. Two additional
steps are recommended but not compulsory. I am documenting them here so
that there's a record.

1) A bus-test mechanism is implemented using dedicated mmc commands which allow
for testing the functionality of the data bus at the electrical level. This is
pretty paranoid and they way the commands work is not compatible with the mmc
subsystem (they don't set valid CRC values).

2) MMC v4 cards can indicate they would like to draw more than the default
amount of current in wide-bus modes. We currently will never switch the card
into a higher draw mode. Supposedly, allowing the card to draw more current
will let it perform better, but the specs seem to indicate that the card will
function correctly without the mode change. Empirical testing supports this
interpretation.
Signed-off-by: NPhilip Langdale <philipl@overt.org>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

This adds support for the high-speed modes defined by mmc v4
(assuming the host controller is up to it). On a TI sdhci controller,
it improves read speed from 1.3MBps to 2.3MBps. The TI controller can
only go up to 24MHz, but everything helps. Another person has taken
this basic patch and used it on a Nokia 770 to get a bigger boost
because that controller can run at 48MHZ.
Signed-off-by: NPhilip Langdale <philipl@overt.org>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Fix up for make allyesconfig.
Signed-Off-By: NDavid Howells <dhowells@redhat.com>

The card might go to inactive state (according to specification), if
there are unsupported bits set in the OCR.
Signed-off-by: NTimo Teras <timo.teras@solidboot.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Some broken cards seem to process CMD1 even in stand-by state. The result is
that the card replies with ILLEGAL_COMMAND error for the next command sent
after rescanning. Currently the next command is select card, which would
return the error. But CMD7 does actually succeed and retries of the command
will timeout. The workaround is to poll card status after CMD1 to clear the
pending error.
Signed-off-by: NTimo Teras <timo.teras@solidboot.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

The MMC layer uses the standard work queue for doing card detection.  As this
queue is shared with other crucial subsystems, the effects of a long (and
perhaps buggy) detection can cause the system to be unusable.  E.g.  the
keyboard stops working while the detection routine is running.

The solution is to add a specific mmc work queue to run the detection code in.
This is similar to how other subsystems handle detection (a full kernel
thread is the most common theme).
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
Cc: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

data->blksz_bits is unused now - remove it.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Rather than having two places which independently calculate the
timeout for data transfers, make it a library function instead.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Acked-by: NPierre Ossman <drzeus@drzeus.cx>

Secure Digital cards use a different algorithm to calculate the timeout
for data transfers. Using the MMC one works often, but not always.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

lockdep needs to have the waitqueue lock initialized for on-stack
waitqueues implicitly initialized by DECLARE_COMPLETION().

Annotate mmc_wait_for_req()'s on-stack completion accordingly.

Has no effect on non-lockdep kernels.
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Signed-off-by: NJörn Engel <joern@wohnheim.fh-wedel.de>
Signed-off-by: NAdrian Bunk <bunk@stusta.de>