Implement a suggestion from Russell to drop the use of blockend
interrupts altogether and instead rely on the data counter.

Tested with error-free cards on U300, U8500 and RealView PB1176.
Signed-off-by: NUlf Hansson <ulf.hansson@stericsson.com>
Signed-off-by: NLinus Walleij <linus.walleij@stericsson.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

On the U300 the MCI_DATAEND and MCI_DATABLOCKEND IRQs can arrive
out-of-order. Replace an ugly #ifdef hack with a proper runtime
solution which models what is really happening.

In the U300 DMA mode and on all Ux500 models, the MCI_DATABLOCKEND
flag isn't properly cleared in hardware following and ACK leading
to all kind of weird behaviour when the flag is still up in
subsequent interrupts, so we add two flags indicating the
error and handle this runtime.

Cc: Rabin Vincent <rabin.vincent@stericsson.com>
Signed-off-by: NLinus Walleij <linus.walleij@stericsson.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The DBx500 variants have only one IRQ line hooked up.  Allow these (and
any other implementations which choose to use only one irq) to work by
directing the PIO interrupts also to the first IRQ line.
Signed-off-by: NRabin Vincent <rabin.vincent@stericsson.com>
Signed-off-by: NLinus Walleij <linus.walleij@stericsson.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This adds a few registers to the MMCI/PL180 derivates that
is used for some odd control stuff like SDIO.
Signed-off-by: NMarcin Mielczarczyk <marcin.mielczarczyk@tieto.com>
Signed-off-by: NLinus Walleij <linus.walleij@stericsson.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

If an IRQ can be requested on the card detected GPIO, use it instead of
polling.
Acked-by: NLinus Walleij <linus.walleij@stericsson.com>
Signed-off-by: NRabin Vincent <rabin.vincent@stericsson.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The Ux500 variant has a 32-word FIFO (TXFIFOEMPTY is asserted when it
has 2 left) and TXFIFOHALFEMPTY is repurposed as TXFIFOBURSTWRITEABLE,
with a burst being defined as 8-words.  Likewise for RX.
Acked-by: NLinus Walleij <linus.walleij@stericsson.com>
Signed-off-by: NRabin Vincent <rabin.vincent@stericsson.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Although both the U300 and Ux500 use ST variants, the HWFCEN bits are at
different positions, so use the variant_data to store the information.
Acked-by: NLinus Walleij <linus.walleij@stericsson.com>
Signed-off-by: NRabin Vincent <rabin.vincent@stericsson.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Add a variant_data structure to handle the differences between the
various variants of this peripheral.  Add a first quirk for a default
MCICLOCK value, required on the Ux500 variant where the enable bit needs
to be always set, since it controls access to some registers.
Acked-by: NLinus Walleij <linus.walleij@stericsson.com>
Signed-off-by: NRabin Vincent <rabin.vincent@stericsson.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The mmci driver's SG list iteration logic assumes that each SG entry
spans only one page, and only maps and flushes one page of the sg.  This
is not a valid assumption.  Fix it by converting the driver to the
sg_miter API, which correctly handles sgs which span multiple pages.
Acked-by: NLinus Walleij <linus.walleij@stericsson.com>
Signed-off-by: NRabin Vincent <rabin.vincent@stericsson.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This adds support for an 8bit wide bus to the card (data lines
MCIDAT0 through 7 exist) on the ST Micro version and alters the
U300 platform to support this. Also add some ST_ prefix to the
ST-specific registers.
Signed-off-by: NLinus Walleij <linus.walleij@stericsson.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This enables the use of a regulator to power the MMCI/PL180
PrimeCell. The OCR mask is calculated and voltage is set using
the new MMC core functions for discovering voltage ranges
in regulators. The platform translate_vdd function which basically
controls the 4 lines out of the PL180 is disabled if you use a
regulator instead.
Signed-off-by: NLinus Walleij <linus.walleij@stericsson.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This moves the mmci platform data definition struct away from
arch/arm/include/asm/mach/mmc.h into the more proper place among
the other primecells in include/linux/amba/mmci.h and at the same
time renames it to "mmci.h", and also the struct in this file
confusingly named mmc_platform_data has been renamed
mmci_platform_data for clarity.

Cc: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NLinus Walleij <linus.walleij@stericsson.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Use gpiolib where available (and when valid GPIOs are provided) for
write protect/card detect status reporting.  We fall back to the old
'status' method where gpiolib support is not available.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This patch adds support for the ST Microelectronics version of
the PL180 PrimeCell. They use designer ID 0x80 and have a few
alterations/bugfixes related to open drain and HW flow control.
They also add some SDIO registers, I am unsure if these are
in ST HW only or if this is things also added in later ARM
revisions, but they are included in the mmci.h file for
completeness.
Signed-off-by: NLinus Walleij <linus.walleij@ericsson.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Signed-off-by: NEmil Medve <Emilian.Medve@Freescale.com>
Signed-off-by: NJens Axboe <jens.axboe@oracle.com>

Make sure all headers in the files reflect their true position
in the tree.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Clean up the drivers/mmc directory by moving card and host drivers
into subdirectories.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Signed-off-by: NEvgeniy Polyakov <johnpol@2ka.mipt.ru>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!