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>

Signed-off-by: NAlex Dubov <oakad@yahoo.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Signed-off-by: NAlex Dubov <oakad@yahoo.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

This patch introduces no semantic changes - it is here for estetic purposes.
Signed-off-by: NAlex Dubov <oakad@yahoo.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

In order to support correct suspend and resume several changes were needed:
1. Switch from work_struct to tasklet for command handling. When device
suspend is called workqueues are already frozen and can not be used.
2. Separate host initialization code from driver's probe and don't rely
on interrupts for host initialization. This, in turn, addresses two
problems:
 a) Resume needs to re-initialize the host, but can not assume that
    device interrupts were already re-armed.
 b) Previously, probe will return successfully before really knowing
    the state of the host, as host interrupts were not armed in time.
    Now it uses polling to determine the real host state before returning.
3. Separate termination code from driver's remove. Termination may be caused
by resume, if media changed type or became unavailable during suspend.
Signed-off-by: NAlex Dubov <oakad@yahoo.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

The register access order when setting hardware timeout was incorrect and
causing problems (wrong timeout intervals). This is now fixed.
Signed-off-by: NAlex Dubov <oakad@yahoo.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Two changes are introduced to software timeout handler in order to simplify
its management:
1. The implementation is switched from work_struct to timer
2. Previously, software timeout was rearmed with each interrupt. Now,
current request must complete entirely within timeout interval.
Signed-off-by: NAlex Dubov <oakad@yahoo.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Data buffer for PIO transfer used to be mapped in advance with kmap.
Abolish it in favor of on-demand kmap_atomic.
Signed-off-by: NAlex Dubov <oakad@yahoo.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Previously, stop command was issued right after BRS (block received/sent)
event. Stop command completion event could interfere with the card busy
event, causing miscount of the written blocks.
This patch ensures that stop command issued as last action for a
particular command, after DMA sompletion event and written block
count verification.
Signed-off-by: NAlex Dubov <oakad@yahoo.com>
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>

Support for these devices was broken for 2.6.18-rc1 and later by commit
146ad66e, which added voltage level support.

This restores the previous behaviour for these devices by ensuring that when
the voltage is changed, only one write to set the voltage is performed.

It may be that both writes are needed if the voltage is being changed between
two non-zero values or that it's safe to ensure that only one write is done
if the hardware only supports one voltage; I don't know whether either is the
case nor can I test since I have only the one SD reader (1524:0550), and it
supports just the one voltage.
Signed-off-by: NDarren Salt <linux@youmustbejoking.demon.co.uk>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Change the parent of cards to be a specific host (a class
device), not the physical controller. This is particularly
useful when the hardware has multiple slots, meaning
multiple hosts.
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>

au1xmmc: return error when encountering unhandled/unknown response type.
Signed-off-by: NManuel Lauss <mano@roarinelk.homelinux.net>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

au1xmmc: implement proper R/O switch detection.
Signed-off-by: NManuel Lauss <mano@roarinelk.homelinux.net>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

During development of SDHC support, it was discovered that the definition
for R6 was incorrect. This patch fixes that and patches the drivers that
do switch on the response type.
Signed-off-by: NPhilip Langdale <philipl@overt.org>
Cc: Alex Dubov <oakad@yahoo.com>
Cc: Pavel Pisa <ppisa@pikron.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

This patch is a fix in order to update MMC response types. This modification is
needed to allow SD card support on OMAP platforms.
Signed-off-by: NCarlos Eduardo Aguiar <carlos.aguiar@indt.org.br>
Signed-off-by: NYuha Yrjola <juha.yrjola@solidboot.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

The MMCI driver might end up aborting the initial command and leaving
the data part of the command sequence still in place.  Avoid this
problem by ensuring that any data sequence is properly cleared out
when a command completes.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Linker level tweaks for the AT91 MMC driver:

  - fix a wrongly-exported symbol
  - move probe() to init section
  - move remove() to exit section

When this driver is statically linked, this patch shrinks the driver's
runtime I-space footprint by over 20% (950 bytes).
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

fix OMAP MMC workqueue in recent workqueue change
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

The driver is usable on the newer SAM9 processors so replace all text
references to AT91RM9200 with just AT91.

The controller bug where all the words are byte-swapped is fixed on the
AT91SAM9 processors.  The byte-swapping work-around therefore only needs
to be done if cpu_is_at91rm9200().
[Original patch from Wojtek Kaniewski]

The AT91RM9200 and AT91SAM9260 processors support two MMC/SD slots - the
slot which is connected is now passed via the platform_data and the
correct slot selected in the AT91_MCI_SDCR register.

The driver should not be calling at91_set_gpio_output() since the VCC
pin should have already been configured as an output in the
processor/board setup code.  The driver should call
at91_set_gpio_value().
Signed-off-by: NAndrew Victor <andrew@sanpeople.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Some controllers report an invalid iomem size, but seem to work
correctly anyway. Change our current error to just a warning and
hope it doesn't cause too much problems.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Currently on SD/MMC card removal the system exhibits the following message (the platform is ARM Versatile):

    prev->state: 2 != TASK_RUNNING??
    mmcqd/762[CPU#0]: BUG in __schedule at linux-2.6/kernel/sched.c:3826

(akpm: someone tried to fix this, but it's still wrong)
Signed-off-by: NVitaly Wool <vitalywool@gmail.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

A number of small cleanups to the AT91RM9200 MMC driver:
 - fix warnings generated by pr_debug().
 - prepend "AT91 MMC:" to printk() messages.
Signed-off-by: NAndrew Victor <andrew@sanpeople.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

This patch simplifies the AT91RM9200 MMC interrupt handler code so that
it doesn't re-read the Interrupt Status and Interrupt Mask registers
multiple times.

Also defined AT91_MCI_ERRORS instead of using the hard-coded 0xffff0000.
Signed-off-by: NAndrew Victor <andrew@sanpeople.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Move the global 'mci_clk' variable into the local 'at91mci_host'
structure.
Signed-off-by: NAndrew Victor <andrew@sanpeople.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Use the I/O base-address and IRQ passed to the driver via the
platform_device resources instead of using hardcoded values.
Signed-off-by: NAndrew Victor <andrew@sanpeople.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

The I/O base address is now stored in the 'at91mci_host' structure.  We
therefore have to pass this structure to at91_mci_read() and
at91_mci_write().
Signed-off-by: NAndrew Victor <andrew@sanpeople.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

This facility provides three entry points:

	ilog2()		Log base 2 of unsigned long
	ilog2_u32()	Log base 2 of u32
	ilog2_u64()	Log base 2 of u64

These facilities can either be used inside functions on dynamic data:

	int do_something(long q)
	{
		...;
		y = ilog2(x)
		...;
	}

Or can be used to statically initialise global variables with constant values:

	unsigned n = ilog2(27);

When performing static initialisation, the compiler will report "error:
initializer element is not constant" if asked to take a log of zero or of
something not reducible to a constant.  They treat negative numbers as
unsigned.

When not dealing with a constant, they fall back to using fls() which permits
them to use arch-specific log calculation instructions - such as BSR on
x86/x86_64 or SCAN on FRV - if available.

[akpm@osdl.org: MMC fix]
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: David Howells <dhowells@redhat.com>
Cc: Wojtek Kaniewski <wojtekka@toxygen.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This patch has fixed the following build error abou au1xmmc.

drivers/mmc/au1xmmc.c: In function `au1xmmc_poll_event':
drivers/mmc/au1xmmc.c:835: warning: unused variable `status'
drivers/mmc/au1xmmc.c: At top level:
drivers/mmc/au1xmmc.c:878: error: parse error before "const"
drivers/mmc/au1xmmc.c: In function `au1xmmc_probe':
drivers/mmc/au1xmmc.c:909: error: `au1xmmc_ops' undeclared (first use in this function)
drivers/mmc/au1xmmc.c:909: error: (Each undeclared identifier is reported only once
drivers/mmc/au1xmmc.c:909: error: for each function it appears in.)
drivers/mmc/au1xmmc.c: At top level:
drivers/mmc/au1xmmc.c:659: warning: 'au1xmmc_request' defined but not used
drivers/mmc/au1xmmc.c:719: warning: 'au1xmmc_set_ios' defined but not used
make[2]: *** [drivers/mmc/au1xmmc.o] Error 1
make[1]: *** [drivers/mmc] Error 2
make: *** [drivers] Error 2
Signed-off-by: NYoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

since commit fcaf71fd
struct mmc_host does not have a dev field. Retrieve the device with
mmc_dev() instead.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Converts from using struct "class_device" to "struct device" making
everything show up properly in /sys/devices/ with symlinks from the
/sys/class directory.
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

We need to jump to the part of just flushing the request
when we cannot claim the bus. Sending commands to a bus
we do not own will give unpredictable results.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

After mmc_block's remove function has exited, we must not
touch the card structure in any way. This means we not only
must remove the gendisk, we must also flush out any
remaning requests already queued up.

We previously removed the disk, but didn't flush it,
causing oops:es when removing a card in the middle of a
transfer.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

The SDHCI spec implies that is is incorrect to set a clock
frequency above 25 MHz without setting the high speed bit.
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>