Signed-off-by: NMatt LaPlante <kernel1@cyberdogtech.com>
Acked-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This patch adds a new driver: sdhci-of. The driver is similar to
the sdhci-pci, it contains common probe code, and controller-specific
ops and quirks.

So far there are only Freescale eSDHC ops and quirks.
Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Currently the SDHCI driver works with PCI accessors (write{l,b,w} and
read{l,b,w}).

With this patch drivers may change memory accessors, so that we can
support hosts with "weird" IO memory access requirments.

For example, in "FSL eSDHC" SDHCI hardware all registers are 32 bit
width, with big-endian addressing. That is, readb(0x2f) should turn
into readb(0x2c), and readw(0x2c) should be translated to
le16_to_cpu(readw(0x2e)).
Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

This supports MMC/SD/SDIO currently found on the Kirkwood 88F6281 and
88F6192 SoC controllers.
Signed-off-by: NNicolas Pitre <nico@marvell.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

This patch adds a MX2/MX3 specific SDHC driver. The hardware is basically
the same as in the MX1, but unlike the MX1 controller the MX2
controller just works as expected. Since the MX1 driver has more
workarounds for bugs than anything else I had no success with supporting
MX1 and MX2 in a sane way in one driver.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Add omap hsmmc controller for 2430 and 34xx.

Note that this controller has different registers compared to
the earlier omap MMC controller, so sharing code currently is
not possible.

Various updates and fixes from linux-omap list have been
merged into this patch.

Signed-off-by: Madhusudhan Chikkature<madhu.cr@ti.com>
Acked-by: NPierre Ossman <drzeus@drzeus.cx>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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

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

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 TMIO chips are only found (and thus tested) on ARM machines.
Moreover, we don't want the TMIO cells to be built if one of the TMIO
driver is not selected (which indirectly make the TMIO cells drivers
depend on ARM as well).
Signed-off-by: NSamuel Ortiz <sameo@openedhand.com>

This patch adds support for the MMC subdevice 'cell' commonly found in
TMIO based MFDs.
Signed-off-by: NIan Molton <spyro@f2s.com>
Acked-by: NPierre Ossman <drzeus@drzeus.cx>
Signed-off-by: NSamuel Ortiz <sameo@openedhand.com>

Signed-off-by: NSascha Sommer <saschasommer@freenet.de>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

This is a driver for the MMC controller on the AP7000 chips from
Atmel. It should in theory work on AT91 systems too with some
tweaking, but since the DMA interface is quite different, it's not
entirely clear if it's worth merging this with the at91_mci driver.

This driver has been around for a while in BSPs and kernel sources
provided by Atmel, but this particular version uses the generic DMA
Engine framework (with the slave extensions) instead of an
avr32-only DMA controller framework.

This driver can also use PIO transfers when no DMA channels are
available, and for transfers where using DMA may be difficult or
impractical for some reason (e.g. the DMA setup overhead is usually
not worth it for very short transfers, and badly aligned buffers or
lengths are difficult to handle.)

Currently, the driver only support PIO transfers. DMA support has been
split out to a separate patch to hopefully make it easier to review.

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 3.5 MiB/s on fast cards with debugging disabled.

The driver has also been tested using the mmc_test module on the same
cards. All tests except 7, 9, 15 and 17 succeed. The first two are
unsupported by all the cards I have, so I don't know if the driver
handles this correctly. The last two fail because the hardware flags a
Data CRC Error instead of a Data Timeout error. I'm not sure how to deal
with that.

Documentation for this controller can be found in many data sheets from
Atmel, including the AT32AP7000 data sheet which can be found here:

http://www.atmel.com/dyn/products/datasheets.asp?family_id=682Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

This is the latest S3C MMC/SD driver by Thomas Kleffel
with cleanups as suggested by AKPM done by Ben Dooks.
Signed-off-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NThomas Kleffel <tk@maintech.de>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

The SDHCI interface is not PCI specific, yet the Linux driver was
intimitely connected to the PCI bus. This patch properly separates
the PCI specific portion from the bus independent code.

This patch is based on work by Ben Dooks but he did not have time
to complete it.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Both of these drivers work well (although some hardware still has
its problems) and are not in the "alpha" quality that EXPERIMENTAL
suggests.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Thanks to Matt Domsch and Rezwanul Kabir at Dell, we know how to disable the
MMC controller on the multi-function Ricoh R5C832. The MMC controller needs
to be disabled or it will steal MMC cards from the SD controller where they
would otherwise be supported by the Linux SDHCI driver.
Signed-off-by: NPhilipl Langdale <philipl@overt.org>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

This is the latest version of the MMC-over-SPI support.  It works
on 2.6.23-rc2 plus git-mmc (from rc1-mm2), along with the preceding
patches which teach the rest of the MMC stack about SPI.

The main issue of note is that sometimes cards need to be power cycled
to recover after certain faults.  Also, it may sometimes be necessary
to disable CRCs.  ("modprobe mmc_core use_spi_crc=n")
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Cc: mikael.starvik@axis.com,
Cc: Hans-Peter Nilsson <hp@axis.com>
Cc: Jan Nikitenko <jan.nikitenko@gmail.com>
Cc: Mike Lavender <mike@steroidmicros.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Change Kconfig objects from "menu, config" into "menuconfig" so
that the user can disable the whole feature without having to
enter the menu first.
Signed-off-by: NJan Engelhardt <jengelh@gmx.de>
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: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

PXA MMC driver supports not only PXA255 but also PXA250 and newer ones
Signed-off-by: NMarcin Juszkiewicz <hrw@openembedded.org>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

A number of configuration file changes.

These are mainly to replace references to ARCH_AT91RM9200 and
ARCH_AT91SAM9261 with the common/generic ARCH_AT91.  That way we don't
need to mention every specific AT91 processor explicitly.

Also adds the configuration option for AT91SAM9260-EK and AT91SAM9261-EK
boards.
Signed-off-by: NAndrew Victor <andrew@sanpeople.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NAlex Dubov <oakad@yahoo.com>
Cc: Daniel Qarras <dqarras@yahoo.com>
Acked-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>

Make it possible to disable the block layer.  Not all embedded devices require
it, some can make do with just JFFS2, NFS, ramfs, etc - none of which require
the block layer to be present.

This patch does the following:

 (*) Introduces CONFIG_BLOCK to disable the block layer, buffering and blockdev
     support.

 (*) Adds dependencies on CONFIG_BLOCK to any configuration item that controls
     an item that uses the block layer.  This includes:

     (*) Block I/O tracing.

     (*) Disk partition code.

     (*) All filesystems that are block based, eg: Ext3, ReiserFS, ISOFS.

     (*) The SCSI layer.  As far as I can tell, even SCSI chardevs use the
     	 block layer to do scheduling.  Some drivers that use SCSI facilities -
     	 such as USB storage - end up disabled indirectly from this.

     (*) Various block-based device drivers, such as IDE and the old CDROM
     	 drivers.

     (*) MTD blockdev handling and FTL.

     (*) JFFS - which uses set_bdev_super(), something it could avoid doing by
     	 taking a leaf out of JFFS2's book.

 (*) Makes most of the contents of linux/blkdev.h, linux/buffer_head.h and
     linux/elevator.h contingent on CONFIG_BLOCK being set.  sector_div() is,
     however, still used in places, and so is still available.

 (*) Also made contingent are the contents of linux/mpage.h, linux/genhd.h and
     parts of linux/fs.h.

 (*) Makes a number of files in fs/ contingent on CONFIG_BLOCK.

 (*) Makes mm/bounce.c (bounce buffering) contingent on CONFIG_BLOCK.

 (*) set_page_dirty() doesn't call __set_page_dirty_buffers() if CONFIG_BLOCK
     is not enabled.

 (*) fs/no-block.c is created to hold out-of-line stubs and things that are
     required when CONFIG_BLOCK is not set:

     (*) Default blockdev file operations (to give error ENODEV on opening).

 (*) Makes some /proc changes:

     (*) /proc/devices does not list any blockdevs.

     (*) /proc/diskstats and /proc/partitions are contingent on CONFIG_BLOCK.

 (*) Makes some compat ioctl handling contingent on CONFIG_BLOCK.

 (*) If CONFIG_BLOCK is not defined, makes sys_quotactl() return -ENODEV if
     given command other than Q_SYNC or if a special device is specified.

 (*) In init/do_mounts.c, no reference is made to the blockdev routines if
     CONFIG_BLOCK is not defined.  This does not prohibit NFS roots or JFFS2.

 (*) The bdflush, ioprio_set and ioprio_get syscalls can now be absent (return
     error ENOSYS by way of cond_syscall if so).

 (*) The seclvl_bd_claim() and seclvl_bd_release() security calls do nothing if
     CONFIG_BLOCK is not set, since they can't then happen.
Signed-Off-By: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NJens Axboe <axboe@kernel.dk>

The driver is selectable on other than Au1200 Alchemy systems but won't
build nor work - there is no MMC hw.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from Pavel Pisa

This patch adds support of i.MX/MX1 SD/MMC controller.
It has been significantly redesigned from the original Sascha Hauer's
version to support scatter-gather DMA, to conform to latest Pierre Ossman's
and Russell King's MMC-SD Linux 2.6.x infrastructure.
The handling of all events has been moved to the softirq context
and is designed with no busy-looping in mind. Unfortunately
some controller bugs has to be overcome by limited looping
about 2-20 usec but these are observed only for initial card
recognition phase.

There are still some missing/missed IRQs problems under heavy load.
Help of somebody with access to the full SDHC design information
is probably necessary.

Regenerated against 2.6.16-git-060402 to solve clash with other patches.
Signed-off-by: NPavel Pisa <pisa@cmp.felk.cvut.cz>
Acked-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from Andrew Victor

This patch adds support for the MMC/SD card interface on the Atmel
AT91RM9200 processor.

Original driver was by Nick Randell, but a number of people have
subsequently worked on it. It's currently maintained by Malcolm Noyes.
Signed-off-by: NAndrew Victor <andrew@sanpeople.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Adds OMAP MMC driver.
Signed-off-by: NJuha Yrjl <juha.yrjola@nokia.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NCarlos Aguiar <carlos.aguiar@indt.org.br>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Driver for the Secure Digital Host Controller Interface specification.
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>

An obvious vi fat finger on my part.
Signed-off-by: NJordan Crouse <jordan.crouse@amd.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

it should work on the Au1100 as well. Updated defconfig to include driver.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Updates to the wbsd driver.
                                                                                
* Fix to handle DAT3 card detection.
* Fixed bug which could cause large writes to stall in FIFO mode.
* Plug 'n Play support. In most cases you need ACPI PNP for this to work.
* Uses generic DMA API (ISA dependency removed).

Drivers that expect ISA DMA API are marked as such in Kconfig.
Signed-off-by: NAl Viro <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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!