| Age | Commit message (Collapse) | Author |
|---|
|
SD card can't be recognized after the very quick
extraction/insertion operations.
Kernel dump when re-insert some kinds of cards
during the suspend/resume
Signed-off-by: Richard Zhu <r65037@freescale.com>
|
|
Detect board id, if EVK1.0 set mach SD clock is 12M.
Signed-off-by: Frank Li <Frank.Li@freescale.com>
|
|
reduce the time in card detction, and
enhanced the robustness in the unsafe card removal.
Signed-off-by: Richard Zhu <r65037@freescale.com>
|
|
The MX25-3DS used a GPIO pin as detect_irq, when system suspend,
mxc_free_gpio() will disable this GPIO irq, but the mxc_request_gpio()
don't enable this GPIO irq, so the insertting and removing SD/MMC
can not be detected after suspend and resume operations. This fixed it.
Signed-off-by: Xie Xiaobo <X.Xie@freescale.com>
(cherry picked from commit 12fa5453b651c906a572792e39f6b667314ff723)
|
|
Eanble the MMC HIGHSPEED, make a double check to
enter the data_irq server, add multi-process data
protection when issue one cmd with internal DMA is used.
Signed-off-by: Richard Zhu <r65037@freescale.com>
|
|
1. Remove CONFIG_NET_SCHED. Because unifiV6's using old QoS interface.
2. imx31: set gpo1 boot on.
3. fs_lx.c: always set 1.5v regulators. Because they need to be strictly 1.5v.
4. mx_sdhci.c: fix sdio block write lock up issue on imx37.
Signed-off-by: Richard Zhao <b20223@freescale.com>
|
|
The wifi connection would be failed in a mass data transmission.
The root cause is that the clock of the host controller isn't
gated on/off properly in SDHC driver.
Signed-off-by: Richard Zhu <r65037@freescale.com>
|
|
Enable MXC SIM module driver
Signed-off-by: Richard Zhu <r65037@freescale.com>
|
|
This is from EA P4 release with the following changes:
Ported to 2.6.28
UBI support is stock 2.6.28.
USB is not integrated
Regulator code is not yet ported.
Removed 3700 specific files
Fix copyrights
Signed-off-by: Rob Herring <r.herring@freescale.com>
|
|
When rmmod, driver will try to poweroff wifi chip, so it may be in a wrong
state when insmod it again.
When insert unifi_sdio module, it will first pull down reset pin to remove
sdio device if it exists and add sdio device, init it again.
Signed-off-by: Richard Zhao <b20223@freescale.com>
|
|
The structure pmic_platform_data is used to specify the init function instead of
conditional compilations. pmic_alloc_data is added instead of regulator
specific initialization. Checks are made before getting and enabling regulators.
Signed-off-by: Ann Thornton <Ann.Thornton@freescale.com>
|
|
On MX51 3DS platform, these two esdhc share a global struct
in linux driver, this sharing would cause the unexpected
clock gate on/off operations, that would make one esdhc
port can't generate the INT normally. So let each esdhc
port has its own global private struct.
Signed-off-by: Richard Zhu <r65037@freescale.com>
|
|
The suspend/resume sequence is class.suspend/bus.suspend/disable_irq/
bus.suspend_late -> ...-> bus.resume_early/enable_irq/bus.resume/
class.resume
MX35 platform: SD card interrupt is pseudo irq generated by mcu while mcu
is controlled through I2C interface. Now I2C suspend is before disable_irq
and I2C resume is after enable_irq. When SD card is inserted in suspend state,
after system resume, the card detect interrupt will be handled by mcu interrupt
handler before I2C driver resume. That will cause i2c error and can't get
correct card status.
Changing I2C driver suspend/resume to suspend_late/resume_early can
make I2C resume before enable_irq.
Remove ENGR00098769 fix, That card detection issue is also caused by
missed interrupt
Signed-off-by: Wallace Wang <r59996@freescale.com>
|
|
System may run into a dead-loop after remove the sd card when
the data write operation is in progress.
Solution:reset the entire controller after the sd card is removed.
Signed-off-by: Richard Zhu <r65037@freescale.com>
|
|
The sd/mmc driver would be halt after the card has been
removed when there is a data transmission in progress.
Reset all the controller when there are any errors.
Signed-off-by: Richard Zhu <r65037@freescale.com>
|
|
Update drivers for mainline regulator support.
Signed-off-by: Ann Thornton <Ann.Thornton@freescale.com>
|
|
Port rel_imx_2.6.26_3.3.0 to 2.6.28.
PMIC Regulator and ASoC drivers are removed and not yet ported.
Updated asm/arch headers for move to plat-mxc/include/mach
device_create parameters changed.
sysdev attribute functions changed.
Adopt mainline MX3 timer code and update clock init flow.
Signed-off-by: Rob Herring <r.herring@freescale.com>
|
|
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-Off-By: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|
|
Fix fastpath issues
Since mmci_request() can be called from a non-interrupt
context, and does, during kernel init, causing a host
of debug messages during boot if you enable spinlock debugging,
we need to use the spinlock calls that save IRQ flags and
restore them.
Signed-off-by: Linus Walleij <triad@df.lth.se>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc:
s3cmci: Add Ben Dooks/Simtec Electronics to header & copyright
s3cmci: fix continual accesses to host->pio_ptr
s3cmci: Support transfers which are not multiple of 32 bits.
s3cmci: cpufreq support
s3cmci: Make general protocol errors less noisy
mmc_block: tell block layer there is no seek penalty
|
|
Conflicts:
arch/arm/mach-versatile/core.c
|
|
Since the original authour (Thomas Kleffel) has been too busy to
merge the s3cmci driver and keep it up to date, I (mostly as part
of my role with Simtec Electronics) got the driver to a mergable
state and have been maintaining it since I think that I should
be added to the header. Also add a copyright statement for the
new work.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|
|
The s3cmci driver uses the host->pio_ptr field to
point to the current position into the buffer for data
transfer. During the transfers it does the following:
while (fifo_words--)
*(host->pio_ptr++) = readl(from_ptr);
This is inefficent, as host->pio_ptr is not used in any
other part of the transfer but the compiler emits code
which does the following:
while (fifo_words--) {
u32 *ptr = host->pio_ptr;
*ptr = readl(from_ptr);
ptr++;
host->pio_ptr = ptr;
}
This is obviously a waste of a load and store each time
around the loop, which could be up to 16 times depending
on how much needs to be transfered.
Move the ptr accesses to outside the while loop so that
we do not end up reloading/re-writing the pointer.
Note, this seems to make the code 16 bytes larger.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|
|
To be able to do SDIO the s3cmci driver has to support non-word-sized
transfers. Change pio_words into pio_bytes and fix up all the places
where it is used.
This variant of the patch will not overrun the buffer when reading an
odd number of bytes. When writing, this variant will still read past
the end of the buffer, but since the driver can't support non-word-
aligned transfers anyway, this should not be a problem, since a
word-aligned transfer will never cross a page boundary.
This has been tested with a CSR SDIO Bluetooth Type A device on a
Samsung S3C24A0 processor.
Signed-off-by: Christer Weinigel <christer@weinigel.se>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|
|
Support for cpu frequency changing.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|
|
General errors, such as timeouts during probe do not need to
be sent to the console, so move them down to be included if the
debug is enabled.
Such errors include:
s3c2440-sdi s3c2440-sdi: s3cmci_request: no medium present
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|
|
Conflicts:
arch/arm/mach-versatile/core.c
|
|
Conflicts:
arch/arm/mach-omap2/gpmc.c
arch/arm/mach-omap2/irq.c
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
Conflicts:
include/asm-x86/statfs.h
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc: (24 commits)
MMC: Use timeout values from CSR
MMC: CSD and CID timeout values
sdhci: 'scratch' may be used uninitialized
mmc: explicitly mention SDIO support in Kconfig
mmc: remove redundant "depends on"
Fix comment in include/linux/mmc/host.h
sdio: high-speed support
mmc_block: hard code 512 byte block size
sdhci: force high speed capability on some controllers
mmc_block: filter out PC requests
mmc_block: indicate strict ordering
mmc_block: inform block layer about sector count restriction
sdio: give sdio irq thread a host specific name
sdio: make sleep on error interruptable
sdhci: reduce card detection delay
sdhci: let the controller wait for busy state to end
atmel-mci: Add missing flush_dcache_page() in PIO transfer code
atmel-mci: Don't overwrite error bits when NOTBUSY is set
atmel-mci: Add experimental DMA support
atmel-mci: support multiple mmc slots
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/hskinnemoen/atmel-mci-2.6.28
Conflicts:
drivers/mmc/host/atmel-mci.c
|
|
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>
|
|
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
|
|
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>
|
|
* 'for-linus' of master.kernel.org:/home/rmk/linux-2.6-arm: (236 commits)
[ARM] 5300/1: fixup spitz reset during boot
[ARM] 5295/1: make ZONE_DMA optional
[ARM] 5239/1: Palm Zire 72 power management support
[ARM] 5298/1: Drop desc_handle_irq()
[ARM] 5297/1: [KS8695] Fix two compile-time warnings
[ARM] 5296/1: [KS8695] Replace macro's with trailing underscores.
[ARM] pxa: allow multi-machine PCMCIA builds
[ARM] pxa: add preliminary CPUFREQ support for PXA3xx
[ARM] pxa: add missing ACCR bit definitions to pxa3xx-regs.h
[ARM] pxa: rename cpu-pxa.c to cpufreq-pxa2xx.c
[ARM] pxa/zylonite: add support for USB OHCI
[ARM] ohci-pxa27x: use ioremap() and offset for register access
[ARM] ohci-pxa27x: introduce pxa27x_clear_otgph()
[ARM] ohci-pxa27x: use platform_get_{irq,resource} for the resource
[ARM] ohci-pxa27x: move OHCI controller specific registers into the driver
[ARM] ohci-pxa27x: introduce flags to avoid direct access to OHCI registers
[ARM] pxa: move I2S register and bit definitions into pxa2xx-i2s.c
[ARM] pxa: simplify DMA register definitions
[ARM] pxa: make additional DCSR bits valid for PXA3xx
[ARM] pxa: move i2c register and bit definitions into i2c-pxa.c
...
Fixed up conflicts in
arch/arm/mach-versatile/core.c
sound/soc/pxa/pxa2xx-ac97.c
sound/soc/pxa/pxa2xx-i2s.c
manually.
|
|
Conflicts:
arch/arm/mach-pxa/Kconfig
arch/arm/mach-pxa/pxa25x.c
arch/arm/mach-pxa/pxa27x.c
|
|
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>
|
|
Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
|
|
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>
|
|
1. add a CPUID table in the comment
2. make cpu_is_pxa25x() true for PXA210/250/255/26x
3. PXA210 is treated as PXA25x, all related code modified to
reflect this
Signed-off-by: Eric Miao <eric.miao@marvell.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
