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: Matthew Fleming <matthew.fleming@imgtec.com>
Signed-off-by: Pierre 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: Steven Noonan <steven@uplinklabs.net>
Signed-off-by: Pierre 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: Pierre 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: Pierre 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: Pierre 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: Hein_Tibosch <hein_tibosch@yahoo.es>
Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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: Haavard 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: Haavard 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: Haavard 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: Haavard 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: Haavard 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: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
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: Hein_Tibosch <hein_tibosch@yahoo.es>
Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
This allows the mmc core to detect card insertion/removal for slots that
don't have any CD pin wired up.
Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
We used to store a binary register snapshot in the "regs" file, so we
set the file size to be the size of this snapshot. This is no longer
valid since we switched to using seq_file.
Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
The debugfs hook atmci_regs_show allocates a temporary buffer for
storing a register snapshot, but it doesn't free it before returning.
Plug this leak.
Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Make sure that the peripheral clock is enabled before reading the MMIO
registers for the debugfs "regs" dump.
Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
At91_mci is abusing dma_free_coherent(), which may not be called with IRQs
disabled. I saw "mkfs.ext3" on an MMC card objecting voluminously as each
write completed:
WARNING: at arch/arm/mm/consistent.c:368 dma_free_coherent+0x2c/0x224()
[<c002726c>] (dump_stack+0x0/0x14) from [<c00387d4>] (warn_on_slowpath+0x4c/0x68)
[<c0038788>] (warn_on_slowpath+0x0/0x68) from [<c0028768>] (dma_free_coherent+0x2c/0x224)
r6:00008008 r5:ffc06000 r4:00000000
[<c002873c>] (dma_free_coherent+0x0/0x224) from [<c01918ac>] (at91_mci_irq+0x374/0x420)
[<c0191538>] (at91_mci_irq+0x0/0x420) from [<c0065d9c>] (handle_IRQ_event+0x2c/0x6c)
...
This bug has been around for a LONG time. The MM warning is from late
2005, but the driver merged a year later ... so I'm puzzled why nobody
noticed this before now.
The fix involves noting that this buffer shouldn't be DMA-coherent; it's
just used for normal DMA writes. So replace it with standard kmalloc()
buffering and DMA mapping calls.
This is the quickie fix. A better one would not rely on allocating large
bounce buffers. (Note that dma_alloc_coherent could have failed too, but
that case was ignored... kmalloc is a bit more likely to fail though.)
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Acked-by: Pierre Ossman <drzeus-mmc@drzeus.cx>
Cc: Andrew Victor <linux@maxim.org.za>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The drivers below do not use LINUX_VERSION_CODE nor KERNEL_VERSION.
drivers/mmc/host/sdricoh_cs.c
This patch removes the said #include <version.h>.
Signed-off-by: Huang Weiyi <weiyi.huang@gmail.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Attach the routine to get_cd to allow the MMC core to find out whether
there is a card present or not without the tedious process of trying to
send commands to the card or not.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Fix the following sparse errors by making the functions
static and fixing the check for host->base.
598:6: warning: symbol 's3cmci_dma_done_callback' was not declared. Should it be static?
744:6: warning: symbol 's3cmci_dma_setup' was not declared. Should it be static?
1209:20: warning: Using plain integer as NULL pointer
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
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: Samuel Ortiz <sameo@openedhand.com>
This patch adds support for the MMC subdevice 'cell' commonly found in
TMIO based MFDs.
Signed-off-by: Ian Molton <spyro@f2s.com>
Acked-by: Pierre Ossman <drzeus@drzeus.cx>
Signed-off-by: Samuel Ortiz <sameo@openedhand.com>
There are 43 includes of asm/mach-types.h by files that don't
reference anything from that file. Remove these unnecessary
includes.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Update all avr32-specific files to use the new platform-specific header
locations. Drivers shared with ARM are left alone for now.
Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
Raise the DMA block size limit from 2048 bytes to the maximum supported
by the DMA controllers on the chip (64KB on Au1100, 4MB on Au1200).
This gives a very small performance boost and apparently fixes an oops
when MMC-DMA and network traffic are active at the same time.
Signed-off-by: Manuel Lauss <mano@roarinelk.homelinux.net>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
The wrong flag was manipulated when an invalid sg list was given, turning
off DMA on the next (and all subsequent) request instead of the current
one.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Minor cleanups for the MMC/SD support on avr32:
- Make at32_add_device_mci() properly initialize "missing"
platform data ... so boards like STK1002 won't try GPIO 0.
- Switch over to gpio_is_valid() instead of testing for only
one designated value.
- Provide STK1002 platform data for the unlikely case that
switches are set so first Ethernet controller isn't in use.
(That's the only way to get card detect and writeprotect
switch sensing on the STK1000.)
And get rid of one "unused variable" warning.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc:
atmel-mci: debugfs support
mmc: Add per-card debugfs support
mmc: Export internal host state through debugfs
imxmmc: fix crash when no platform data is provided
imxmmc: fix platform resources
imxmmc: remove DEBUG definition
mmc_spi: put signals to low power off fix
Don't crash if no platform data is provided.
In this case assume that card is present.
Signed-off-by: Paulius Zaleckas <paulius.zaleckas@teltonika.lt>
Acked-by: Pavel Pisa <pisa@cmp.felk.cvut.cz>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Fixup platform resources handling.
Signed-off-by: Paulius Zaleckas <paulius.zaleckas@teltonika.lt>
Acked-by: Pavel Pisa <pisa@cmp.felk.cvut.cz>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Removed DEBUG #define #undef, because module is automaticaly
compiled with -DDEBUG when CONFIG_MMC_DEBUG is defined.
Currently it just generates compiler warning about redefinition.
Signed-off-by: Paulius Zaleckas <paulius.zaleckas@teltonika.lt>
Acked-by: Pavel Pisa <pisa@cmp.felk.cvut.cz>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Add per-device dma_mapping_ops support for CONFIG_X86_64 as POWER
architecture does:
This enables us to cleanly fix the Calgary IOMMU issue that some devices
are not behind the IOMMU (http://lkml.org/lkml/2008/5/8/423).
I think that per-device dma_mapping_ops support would be also helpful for
KVM people to support PCI passthrough but Andi thinks that this makes it
difficult to support the PCI passthrough (see the above thread). So I
CC'ed this to KVM camp. Comments are appreciated.
A pointer to dma_mapping_ops to struct dev_archdata is added. If the
pointer is non NULL, DMA operations in asm/dma-mapping.h use it. If it's
NULL, the system-wide dma_ops pointer is used as before.
If it's useful for KVM people, I plan to implement a mechanism to register
a hook called when a new pci (or dma capable) device is created (it works
with hot plugging). It enables IOMMUs to set up an appropriate
dma_mapping_ops per device.
The major obstacle is that dma_mapping_error doesn't take a pointer to the
device unlike other DMA operations. So x86 can't have dma_mapping_ops per
device. Note all the POWER IOMMUs use the same dma_mapping_error function
so this is not a problem for POWER but x86 IOMMUs use different
dma_mapping_error functions.
The first patch adds the device argument to dma_mapping_error. The patch
is trivial but large since it touches lots of drivers and dma-mapping.h in
all the architecture.
This patch:
dma_mapping_error() doesn't take a pointer to the device unlike other DMA
operations. So we can't have dma_mapping_ops per device.
Note that POWER already has dma_mapping_ops per device but all the POWER
IOMMUs use the same dma_mapping_error function. x86 IOMMUs use device
argument.
[akpm@linux-foundation.org: fix sge]
[akpm@linux-foundation.org: fix svc_rdma]
[akpm@linux-foundation.org: build fix]
[akpm@linux-foundation.org: fix bnx2x]
[akpm@linux-foundation.org: fix s2io]
[akpm@linux-foundation.org: fix pasemi_mac]
[akpm@linux-foundation.org: fix sdhci]
[akpm@linux-foundation.org: build fix]
[akpm@linux-foundation.org: fix sparc]
[akpm@linux-foundation.org: fix ibmvscsi]
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: Muli Ben-Yehuda <muli@il.ibm.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Avi Kivity <avi@qumranet.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
alpha:
drivers/mmc/host/sdhci.h:242: error: field 'sg_miter' has incomplete type
Cc: Pierre Ossman <drzeus@drzeus.cx>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The original intention was to write a zero byte to mmc to force spi
signals to low when doing power off. Somehow the spi_w8r8 call got there
so a read followed the write of single zero byte. This patch changes
that to simple write of zero byte without the following read.
This way the power off is more reliable and completely sufficient.
Signed-off-by: Jan Nikitenko <jan.nikitenko@gmail.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Commit c8b3e02 renamed a variable, but missed one reference to it
inside a WARN_ON, causing it to incorrectly trigger.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
