The support is implemented via platform data accessors, new module
(of_mmc_spi) will be created automatically when the driver compiles
on OpenFirmware platforms. Link-time dependency will load the module
automatically.
Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

dma_unmap_sg should be given the same length as dma_map_sg, not the
value returned from dma_map_sg
Signed-off-by: NVernon Sauder <vsauder@inhand.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

In each case, if the NULL test is necessary, then the dereference should be
moved below the NULL test.

The semantic patch that makes this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)

// <smpl>
@@
type T;
expression E;
identifier i,fld;
statement S;
@@

- T i = E->fld;
+ T i;
  ... when != E
      when != i
  if (E == NULL) S
+ i = E->fld;
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

As reported by Randy Dunlap, having sdhci built-in and LEDs class
as a module resulted in undefined symbols. Change the code to handle
that case properly (by not having LEDs class support in sdhci).
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

balance pci_iomap with pci_iounmap, not iounmap
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

The latest generation of laptops are shipping with a newer
model of Ricoh chip where the firewire controller is the
primary PCI function but a cardbus controller is also present.

The existing code assumes that if a cardbus controller is,
present, then it must be the one to manipulate - but the real
rule is that you manipulate PCI function 0. This patch adds an
additional constraint that the target must be function 0.
Signed-off-by: NPhilip Langdale <philipl@overt.org>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

CONFIG_LEDS_CLASS is defined only if led-class is built-in, otherwise
when it is a module the option is called CONFIG_LEDS_CLASS_MODULE. Led
support should also be activated in this case.
Signed-off-by: NEric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Use the new pci_ioremap_bar() function in drivers/mmc.
pci_ioremap_bar() just takes a pci device and a bar number, with the goal
of making it really hard to get wrong, while also having a central place
to stick sanity checks.
Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Use readl/writel instead of direct pointer deref.
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>

This removes clkrt and cmdat from struct imxmci_host, they are
unused.
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>

This cleans up the warnings issued by the checkpatch script
and remove the file history from the header
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>

Add low-level initialization for hsmmc controller. Merged into
this patch patch are various improvments and board support by
Grazvydas Ignotas and David Brownell.

Also change wire4 to be wires, as some newer controllers support
8 data lines.

Cc: Pierre Ossman <drzeus-mmc@drzeus.cx>
Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NTony Lindgren <tony@atomide.com>

This will simplify the MMC low-level init, and make it more
flexible to add support for a newer MMC controller in the
following patches.

The patch rearranges platform data and gets rid of slot vs
controller confusion in the old data structures. Also fix
device id numbering in the clock code.

Some code snippets are based on an earlier patch by
Russell King <linux@arm.linux.org.uk>.

Cc: Pierre Ossman <drzeus-mmc@drzeus.cx>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Where devices only have one consumer, passing a consumer clock ID
has no real benefit, and it only encourages wrong implementations of
the clk API.  Remove it.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

When ISA_DMA_API is unset, we're not implementing the ISA DMA API,
so there's no point in publishing the prototypes via asm/dma.h, nor
including the machine dependent parts of that API.

This allows us to remove a lot of mach/dma.h files which don't contain
any useful code.  Unfortunately though, some platforms put their own
private non-ISA definitions into mach/dma.h, so we leave these behind
and fix the appropriate #include statments.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Avoid unnecessarily pollution of the kernel's namespace by avoiding
mach/hardware.h.  Include this header file where necessary.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Where devices only have one consumer, passing a consumer clock ID
has no real benefit.  Remove it.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-Off-By: NKay Sievers <kay.sievers@vrfy.org>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Move mci.h to new position in arch/arm/plat-s3c24xx/include/plat
ready to clean out old include directories.
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

Fix fastpath issues

Since mmci_request() can be called from a non-interrupt
context, and does, during kernel init, causing a host
of debug messages during boot if you enable spinlock debugging,
we need to use the spinlock calls that save IRQ flags and
restore them.
Signed-off-by: NLinus Walleij <triad@df.lth.se>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Since the original authour (Thomas Kleffel) has been too busy to
merge the s3cmci driver and keep it up to date, I (mostly as part
of my role with Simtec Electronics) got the driver to a mergable
state and have been maintaining it since I think that I should
be added to the header. Also add a copyright statement for the
new work.
Signed-off-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

The s3cmci driver uses the host->pio_ptr field to
point to the current position into the buffer for data
transfer. During the transfers it does the following:

	while (fifo_words--)
		*(host->pio_ptr++) = readl(from_ptr);

This is inefficent, as host->pio_ptr is not used in any
other part of the transfer but the compiler emits code
which does the following:

	while (fifo_words--) {
		u32 *ptr = host->pio_ptr;
		*ptr = readl(from_ptr);
		ptr++;
		host->pio_ptr = ptr;
	}

This is obviously a waste of a load and store each time
around the loop, which could be up to 16 times depending
on how much needs to be transfered.

Move the ptr accesses to outside the while loop so that
we do not end up reloading/re-writing the pointer.

Note, this seems to make the code 16 bytes larger.
Signed-off-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

To be able to do SDIO the s3cmci driver has to support non-word-sized
transfers.  Change pio_words into pio_bytes and fix up all the places
where it is used.

This variant of the patch will not overrun the buffer when reading an
odd number of bytes.  When writing, this variant will still read past
the end of the buffer, but since the driver can't support non-word-
aligned transfers anyway, this should not be a problem, since a
word-aligned transfer will never cross a page boundary.

This has been tested with a CSR SDIO Bluetooth Type A device on a
Samsung S3C24A0 processor.
Signed-off-by: NChrister Weinigel <christer@weinigel.se>
Signed-off-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Support for cpu frequency changing.
Signed-off-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

General errors, such as timeouts during probe do not need to
be sent to the console, so move them down to be included if the
debug is enabled.

Such errors include:
s3c2440-sdi s3c2440-sdi: s3cmci_request: no medium present
Signed-off-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Hard-coded timeout values of 250ms for writes and 100ms for reads are
currently used for MMC transactions over SPI. The spec states that the
timeout values from the card should be used.
Signed-off-by: NMatthew Fleming <matthew.fleming@imgtec.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

The variable 'scratch' is always initialized before it's used. The
conditional which is responsible for initialization of 'scratch' will
always evaluate 'true' when the first loop iteration occurs, and thus,
it's properly initialized. GCC doesn't see this, of course, so using
the uninitialized_var() macro seems to work for silencing this case.
Signed-off-by: NSteven Noonan <steven@uplinklabs.net>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

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

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

Some high speed capable controllers forget to set the high speed
capability bit. Make sure we enable the functionality anyway.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

The card detection delay was added early when the behaviour of the
card interrupt was still very much unknown (i.e. before there was a
public specification). As it is now known that it is a debounced signal,
reduce the delay to something more sensible.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

The sdhci controllers can interrupt us when the busy state from the
card has ended, saving CPU cycles and power.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

The atmel-mci driver sometimes fails data transfers like this:

   mmcblk0: error -5 transferring data
   end_request: I/O error, dev mmcblk0, sector 2749769
   end_request: I/O error, dev mmcblk0, sector 2749777

It turns out that this might be caused by the BLKR register (which
contains the block size and the number of blocks being transfered) being
initialized too late. This patch moves the initialization of BLKR so
that it contains the correct value before the block transfer command is
sent.

This error is difficult to reproduce, but if you insert a long delay
(mdelay(10) or thereabouts) between the calls to atmci_start_command()
and atmci_submit_data(), all transfers seem to fail without this patch,
while I haven't seen any failures with this patch.
Reported-by: NHein_Tibosch <hein_tibosch@yahoo.es>
Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>

After a data error, we wait for the NOTBUSY bit to be set so that we can
be sure the data transfer is completely finished. However, when NOTBUSY
is set, the interrupt handler copies the contents of SR into
data_status, overwriting any error bits we may have detected earlier.

To avoid this, initialize data_status to 0 before starting a request, and
don't overwrite it unless it still contains 0.
Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>

This adds support for DMA transfers through the generic DMA engine
framework with the DMA slave extensions.

The driver has been tested using mmc-block and ext3fs on several SD,
SDHC and MMC+ cards. Reads and writes work fine, with read transfer
rates up to 7.5 MiB/s on fast cards with debugging disabled.

Unfortunately, the driver has been known to lock up from time to time
with DMA enabled, so DMA support is currently optional and marked
EXPERIMENTAL. However, I didn't see any problems while testing 13
different cards (MMC, SD and SDHC of different brands and sizes), so I
suspect the "Initialize BLKR before sending data transfer command" fix
that was posted earlier fixed this as well.
Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>

The Atmel MCI controller can drive multiple cards through separate sets
of pins, but only one at a time. This patch adds support for
multiplexing access to the controller so that multiple card slots can be
used as if they were hooked up to separate mmc controllers.

The atmel-mci driver registers each slot as a separate mmc_host. Both
access the same common controller state, but they also have some state
on their own for card detection/write protect handling, and separate
shadows of the MR and SDCR registers.

When one of the slots receives a request from the mmc core, the common
controller state is checked. If it's idle, the request is submitted
immediately. If not, the request is added to a queue. When a request is
done, the queue is checked and if there is a queued request, it is
submitted before the completion callback is called.

This patch also includes a few cleanups and fixes, including a locking
overhaul. I had to change the locking extensively in any case, so I
might as well try to get it right. The driver no longer takes any
irq-safe locks, which may or may not improve the overall system
performance.

This patch also adds a bit of documentation of the internal data
structures.
Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>

Add the necessary platform infrastructure to support multiple mmc/sdcard
slots all at once through a single controller. Currently, the driver
will use the first valid slot it finds and stick with that, but later
patches will add support for switching between several slots on the fly.

Extend the platform data structure with per-slot information: MMC/SDcard
bus width and card detect/write protect pins. This will affect the pin
muxing as well as the capabilities announced to the mmc core.

Note that board code is now required to supply a mci_platform_data
struct to at32_add_device_mci().
Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>

Some cards might get upset if we turn off the clock for extended periods
of time. So keep the clock running until the mmc core tells us to turn
it off.

Also, don't reset the controller between each transfer. That was an
attempt to work around earlier bugs, and it never really worked very
well.
Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>

With the current system of completed/pending events, things may get
handled in different order depending on which event triggers first. For
example, if the data transfer is complete before the command, the stop
command must be sent after the command is complete, not the data. This
creates a bit of complexity around the stop command.

By having the tasklet go through a sequence of clearly defined states,
things always happen in a certain order even if the events come at
different times, so the stop command can simply be sent when we exit the
"sending data" state because we will never enter that state before the
command has been sent successfully.
Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>