Freescale eSDHC controller has the special order for
the HOST version register. that is not same as the other's
registers. The address of HOSTVER in spec is 0xFE, and
we need use the in_be16(0xFE) to access it, not in_be16(0xFC).
Signed-off-by: Dave Liu <daveliu@freescale.com>
Acked-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Pierre Ossman <pierre@ossman.eu>
Especially with Sandisk SDHC cards, the second SWITCH command was failing
with a timeout and the card was not recognized at all. However if the
system was busy, or debugging was enabled, or a udelay(100) was inserted
before the second SWITCH command in the core code, then the timing was
so that the card started to work.
With some unusual block sizes, the data FIFO status doesn't indicate a
"empty" state right away when the data transfer is done. Queuing
another data transfer in that condition results in a transfer timeout.
The empty FIFO bit eventually get set by itself in less than 50 usecs
when it is not set right away. So let's just poll for that bit before
configuring the controller with a new data transfer.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Signed-off-by: Pierre Ossman <pierre@ossman.eu>
Empirical evidences show that this is causing far more problems than it
solves when this mode is enabled in the host hardware. Amongst those
cards that are known to be non functional when this bit is set are:
A-Data "Speedy" 2GB SD card
Kodak 512MB SD card
Ativa 1GB MicroSD card
Marvell 8688 (WIFI/Bluetooth) SDIO card
Since those cards do work on other host controllers which do honnor the
hs timing, the issue must be with this particular host hardware.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Signed-off-by: Pierre Ossman <pierre@ossman.eu>
disable_irq() should wait for all running handlers to complete
before returning. As such, if it's used to disable an interrupt
from that interrupt's handler it will deadlock. This replaces
the dangerous instances with the _nosync() variant which doesn't
have this problem.
Signed-off-by: Ben Nizette <bn@niasdigital.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Pierre Ossman <pierre@ossman.eu>
We plan to use fsl,esdhc going forward as the base compatible so update
the driver to bind against it.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Pierre Ossman <pierre@ossman.eu>
When a software timeout occurs in polling mode hardware was left in
an indeterminate state causing subsequent operations to block.
Signed-off-by: Martin Fuzzey <mfuzzey@gmail.com>
This is a temporary workaround until the MMC stack can be fixed.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Pierre Ossman <pierre@ossman.eu>
The second argument of the probe method points to the amba_id
structure, so it's better passed with the correct type. None of the
current in-tree drivers uses the pointer, so they have only been
checked for a clean compile.
Change suggested by Russell King.
Signed-off-by: Alessandro Rubini <rubini@unipv.it>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc:
mvsdio: fix CONFIG_PM=y build
mmci: fix crash with debug enabled
sdhci: catch ADMA errors
mmc: increase power up delay
sdhci-pci: bad error handling in probe function
mmc_block: be prepared for oversized requests
Fix usage of obsolete parameters and functions in the driver's PM
callbacks.
Signed-off-by: Rabin Vincent <rabin@rab.in>
Acked-by: Nicolas Pitre <nico@marvell.com>
Signed-off-by: Pierre Ossman <pierre@ossman.eu>
If MMC debugging is enabled, the mmci driver oopses because the DBG
macro uses host->mmc before it is set. Set it earlier.
Signed-off-by: Rabin Vincent <rabin@rab.in>
Signed-off-by: Pierre Ossman <pierre@ossman.eu>
The TI controller on Toshiba Tecra M5 needs more time to power up or
the cards will init incorrectly or not at all.
Signed-off-by: José M. Fernández <josemariafg@gmail.com>
Signed-off-by: Pierre Ossman <pierre@ossman.eu>
The goto unmap is too early, we haven't allocated host or done the
request_region().
Found by smatch (http://repo.or.cz/w/smatch.git).
[ Second error path fix by Pierre Ossman ]
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Pierre Ossman <pierre@ossman.eu>
The block layer does not support very low sector count restrictions
so we need to be prepared to handle bigger requests than we can send
directly to the controller.
Problem found by Manuel Lauss.
Signed-off-by: Pierre Ossman <pierre@ossman.eu>
A very large subset of SD cards in the market send their
responses and data non-byte-aligned. So add logic to the
mmc spi driver to handle this mess.
Signed-off-by: Wolfgang Muees <wolfgang.mues@auerswald.de>
Signed-off-by: Pierre Ossman <pierre@ossman.eu>
With spurious interrupt cmd can be null even when we have CC
set in irq status.
Fixes: NB#106295 - prevent potential kernel crash in the MMC driver
Signed-off-by: Jarkko Lavinen <jarkko.lavinen@nokia.com>
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Signed-off-by: Pierre Ossman <pierre@ossman.eu>
This fixes the issue noted by Russell King:
drivers/mmc/host/omap_hsmmc.c: In function 'mmc_omap_xfer_done':
drivers/mmc/host/omap_hsmmc.c:301: error: implicit declaration of function 'mmc_omap_fclk_lazy_disable'
This got broken by 4a694dc915.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Pierre Ossman <pierre@ossman.eu>
SD/MMC card timeouts can be very high. So avoid busy-waiting,
using the scheduler. Calculate all timeouts in jiffies units,
because this will give us the correct sign when to involve
the scheduler.
Signed-off-by: Wolfgang Muees <wolfgang.mues@auerswald.de>
Signed-off-by: Pierre Ossman <pierre@ossman.eu>
Some cards are not able to calculate a valid CRC16 value
for CID and CSD reads (CRC for 512 byte data blocks is OK).
By moving the CRC enable after the read of CID and CSD, these
cards can be used. This patch was tested with a faulty 8 GByte
takeMS Class 6 SDHC card. This patch was suggested by
Pierre Ossman.
Signed-off-by: Wolfgang Muees <wolfgang.mues@auerswald.de>
Signed-off-by: Pierre Ossman <pierre@ossman.eu>
Spurious IRQs seen on MMC after 2.6.29. Flush posted write in IRQ
handler.
The interrupt line is released by clearing the error status bits
in the MMCHS_STAT register, which must occur before the interrupt
handler returns to avoid unwanted irqs. Hence the need to flush
the posted write.
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Acked-by: Tony Lindgen <tony@atomide.com>
Signed-off-by: Pierre Ossman <pierre@ossman.eu>