Signed-off-by: NMichal Miroslaw <mirq-linux@rere.qmqm.pl>
Cc: Adrian Hunter <adrian.hunter@nokia.com>
Cc: Chris Ball <cjb@laptop.org>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This series adds support for SD combo cards to MMC/SD driver stack.

SD combo consists of SD memory and SDIO parts in one package.  Since the
parts have a separate SD command sets, after initialization, they can be
treated as independent cards on one bus.

Changes are divided into two patches.  First is just moving initialization
code around so that SD memory part init can be called from SDIO init.
Second patch is a proper change enabling SD memory along SDIO.  I tried to
move as much no-op changes to the first patch so that it's easier to
follow the required changes to initialization flow for SDIO cards.

This is based on Simplified SDIO spec v.2.00.  The init sequence is
slightly modified to follow current SD memory init implementation.
Command sequences, assuming SD memory and SDIO indeed ignore unknown
commands, are the same as before for both parts.

This patch:

Prepare for SD-combo (IO+mem) support by splitting SD memory
card init and related functions.
Signed-off-by: NMichal Miroslaw <mirq-linux@rere.qmqm.pl>
Cc: Adrian Hunter <adrian.hunter@nokia.com>
Cc: Chris Ball <cjb@laptop.org>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

MX3 SoCs have a silicon bug which corrupts CRC calculation of
multi-block transfers when connected SDIO peripheral doesn't drive the
BUSY line as required by the specs.

One way to prevent this is to only allow 1-bit transfers.

Another way is playing tricks with the DMA engine, but this isn't
mainline yet. So for now, we live with the performance drawback of 1-bit
transfers until a nicer solution is found.

This patch introduces a new host controller callback 'init_card' which
is for now only called from mmc_sdio_init_card().
Signed-off-by: NDaniel Mack <daniel@caiaq.de>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Volker Ernst <volker.ernst@txtr.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Michał Mirosław <mirqus@gmail.com>
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>

And bring them back to 4-bit mode during resume.
Signed-off-by: NDaniel Drake <dsd@laptop.org>
Signed-off-by: NNicolas Pitre <nico@marvell.com>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Some SDIO cards may suspend while keeping function interrupts active
especially in the powered suspend case.  Upon resume we need to kick the
SDIO interrupt thread to check for pending interrupts and to restart card
IRQ detection at the host controller level.
Signed-off-by: NNicolas Pitre <nico@marvell.com>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Seen on a Marvell 8686 SDIO card and Via VX855 controller: we must avoid
sending CMD3/5/7 on a resume where power has been maintained, because the
8686 will refuse to respond to them and the MMC stack will give up on the
card.
Signed-off-by: NChris Ball <cjb@laptop.org>
Signed-off-by: NNicolas Pitre <nico@marvell.com>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Daniel Drake noticed a crash in the error path of mmc_attach_sdio().  This
bug is discussed at http://dev.laptop.org/ticket/9707.

BUG: unable to handle kernel paging request at 6b6b6c57
IP: [<b066d6e2>] sdio_remove_func+0x9/0x27
Call Trace:
[<b066cfb4>] ? mmc_sdio_remove+0x34/0x65
[<b066d1fc>] ? mmc_attach_sdio+0x217/0x240
[<b066a22f>] ? mmc_rescan+0x1a2/0x20f
[<b042e9a0>] ? worker_thread+0x156/0x1e

We need to accurately track how many SDIO functions have been initialised
(and keep card->sdio_funcs in sync) so that we don't try to remove more
functions than we initialised if we hit the error path in
mmc_attach_sdio().

Without this patch if we hit the error path in mmc_attach_sdio() we run
the risk of deferencing invalid memory in sdio_remove_func(), leading to a
crash.
Signed-off-by: NMatt Fleming <matt@console-pimps.org>
Cc: Daniel Drake <dsd@laptop.org>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Especially for SDIO drivers which may have special conditions/errors to
report, it is a good thing to relay the returned error code back to upper
layers.

This also allows for the rationalization of the resume path where code to
"remove" a no-longer-existing or replaced card was duplicated into the
MMC, SD and SDIO bus drivers.

In the SDIO case, if a function suspend method returns an error, then all
previously suspended functions are resumed and the error returned.  An
exception is made for -ENOSYS which the core interprets as "we don't
support suspend so just kick the card out for suspend and return success".

When resuming SDIO cards, the core code only validates the manufacturer
and product IDs to make sure the same kind of card is still present before
invoking functions resume methods.  It's the function driver's
responsibility to perform further tests to confirm that the actual same
card is present (same MAC address, etc.) and return an error otherwise.
Signed-off-by: NNicolas Pitre <nico@marvell.com>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Currently, all SDIO cards are virtually removed upon a suspend, and
completely reprobed upon a resume.  This adds the suspend and resume
methods to the SDIO bus driver so to be able to dispatch those events to
the actual SDIO function drivers for real suspend/resume instead.

All active functions on a card must have a driver with both a suspend and
a resume method though.  Failing that, we fall back to the current
behavior of simply "removing" the card when suspending.

When resuming, we make sure the same card is still inserted by comparing
the vendor and product IDs.  If there is a mismatch, or if there is simply
no card anymore in the slot, then the previous card is "removed" and the
new card is detected.  This is further enhanced with the next patch.

[akpm@linux-foundation.org: fix warnings]
Signed-off-by: NNicolas Pitre <nico@marvell.com>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Add support to disconnect the pull-up resistor on CD/DAT[3] (pin 1)
of the card. This may be desired on certain setups of boards,
controllers and embedded sdio devices which do not need the card's
pull-up. As a result, card detection is disabled and power is saved.

[akpm@linux-foundation.org: simplify sdio_disable_cd() a bit]
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Acked-by: NMatt Fleming <matt@console-pimps.org>
Cc: Ian Molton <ian@mnementh.co.uk>
Cc: "Roberto A. Foglietta" <roberto.foglietta@gmail.com>
Cc: Philip Langdale <philipl@overt.org>
Cc: Pierre Ossman <pierre@ossman.eu>
Cc: David Vrabel <david.vrabel@csr.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This is needed for 1.8V embedded SDIO devices and supporting host controllers
(e.g. TI 127x and ZOOM2 boards)
Signed-off-by: NOhad Ben-Cohen <ohad@bencohen.org>
Acked-by: NMatt Fleming <matt@console-pimps.org>
Cc: Ian Molton <ian@mnementh.co.uk>
Cc: Pierre Ossman <pierre@ossman.eu>
Cc: Ian Molton <ian@mnementh.co.uk>
Cc: "Roberto A. Foglietta" <roberto.foglietta@gmail.com>
Cc: Philip Langdale <philipl@overt.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

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

Suppressing uevents turned out to be a bad idea as it screws up the
order of events, making user space very confused. Change the system to
use sysfs groups instead.

This is a regression that, for some odd reason, has gone unnoticed for
some time. It confuses hal so that the block devices (which have the
mmc device as a parent) are not registered. End result being that
desktop magic when cards are inserted won't work.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Teach the MMC/SD/SDIO core about using SPI mode.

 - Use mmc_host_is_spi() so enumeration works through SPI signaling
   and protocols, not just the native versions.

 - Provide the SPI response type flags with each request issued,
   including requests from the new lock/unlock code.

 - Understand that cmd->resp[0] and mmc_get_status() results for SPI
   return different values than for "native" MMC/SD protocol; this
   affects resetting, checking card lock status, and some others.

 - Understand that some commands act a bit differently ... notably:
     * OP_COND command doesn't return the OCR
     * APP_CMD status doesn't have an R1_APP_CMD analogue

Those changes required some new and updated primitives:

 - Provide utilities to access two SPI-only requests, and one
   request that wasn't previously needed:
     * mmc_spi_read_ocr() ... SPI only
     * mmc_spi_set_crc() ... SPI only (override by module parm)
     * mmc_send_cid() ... for use without broadcast mode

 - Updated internal routines:
     * Previous mmc_send_csd() modified into mmc_send_cxd_native();
       it uses native "R2" responses, which include 16 bytes of data.
     * Previous mmc_send_ext_csd() becomes new mmc_send_cxd_data()
       helper for command-and-data access
     * Bugfix to that mmc_send_cxd_data() code:  dma-to-stack is
       unsafe/nonportable, so kmalloc a bounce buffer instead.

 - Modified mmc_send_ext_csd() now uses mmc_send_cxd_data() helper

 - Modified mmc_send_csd(), and new mmc_spi_send_cid(), routines use
   those helper routines based on whether they're native or SPI

The newest categories of cards supported by the MMC stack aren't expected
to work yet with SPI:  MMC or SD cards with over 4GB data, and SDIO.
All those cards support SPI mode, so eventually they should work too.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Replace all cases of BUG_ON with WARN_ON where there is a chance
(with varying degrees of slim) that the kernel can continue without
incidence.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Signed-off-by: NDavid Vrabel <david.vrabel@csr.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Enable 4-bit data bus mode, according to host and card
capabilities.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Change clock speed to the highest supported by the card.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Add a more clean separation between global, common CIS information
and the function specific one as we need the common information in
places where no specific function is specified.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Signed-off-by: NNicolas Pitre <npitre@mvista.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

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

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

Add the sdio bus type and basic device handling.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Really basic init sequence for SDIO cards.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>