This patch adds support for setting driver strength during UHS-I
initialization procedure. Since UHS-I cards set S18A (bit 24) in
response to ACMD41, we use this as a base for UHS-I initialization.
We modify the parameter list of mmc_sd_get_cid() so that we can
save the ROCR from ACMD41 to check whether bit 24 is set.
We decide whether the Host Controller supports A, C, or D driver
type depending on the Capabilities register. Driver type B is
suported by default. We then set the appropriate driver type for
the card using CMD6 mode 1. As per Host Controller spec v3.00, we
set driver type for the host only if Preset Value Enable in the
Host Control2 register is not set. SDHCI_HOST_CONTROL has been
renamed to SDHCI_HOST_CONTROL1 to conform to the spec.
Tested by Zhangfei Gao with a Toshiba uhs card and general hs card,
on mmp2 in SDMA mode.
Signed-off-by: Arindam Nath <arindam.nath@amd.com>
Reviewed-by: Philip Rakity <prakity@marvell.com>
Tested-by: Philip Rakity <prakity@marvell.com>
Acked-by: Zhangfei Gao <zhangfei.gao@marvell.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Host Controller v3.00 adds another Capabilities register. Apart
from other things, this new register indicates whether the Host
Controller supports SDR50, SDR104, and DDR50 UHS-I modes. The spec
doesn't mention about explicit support for SDR12 and SDR25 UHS-I
modes, so the Host Controller v3.00 should support them by default.
Also if the controller supports SDR104 mode, it will also support
SDR50 mode as well. So depending on the host support, we set the
corresponding MMC_CAP_* flags. One more new register. Host Control2
is added in v3.00, which is used during Signal Voltage Switch
procedure described below.
Since as per v3.00 spec, UHS-I supported hosts should set S18R
to 1, we set S18R (bit 24) of OCR before sending ACMD41. We also
need to set XPC (bit 28) of OCR in case the host can supply >150mA.
This support is indicated by the Maximum Current Capabilities
register of the Host Controller.
If the response of ACMD41 has both CCS and S18A set, we start the
signal voltage switch procedure, which if successfull, will switch
the card from 3.3V signalling to 1.8V signalling. Signal voltage
switch procedure adds support for a new command CMD11 in the
Physical Layer Spec v3.01. As part of this procedure, we need to
set 1.8V Signalling Enable (bit 3) of Host Control2 register, which
if remains set after 5ms, means the switch to 1.8V signalling is
successfull. Otherwise, we clear bit 24 of OCR and retry the
initialization sequence. When we remove the card, and insert the
same or another card, we need to make sure that we start with 3.3V
signalling voltage. So we call mmc_set_signal_voltage() with
MMC_SIGNAL_VOLTAGE_330 set so that we are back to 3.3V signalling
voltage before we actually start initializing the card.
Tested by Zhangfei Gao with a Toshiba uhs card and general hs card,
on mmp2 in SDMA mode.
Signed-off-by: Arindam Nath <arindam.nath@amd.com>
Reviewed-by: Philip Rakity <prakity@marvell.com>
Tested-by: Philip Rakity <prakity@marvell.com>
Acked-by: Zhangfei Gao <zhangfei.gao@marvell.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
On HP laptops with JMicron 388 chip, the write-locked SD card isn't
detected correctly as read-only in many cases. This is because the
PRESENT_STATE register becomes unsable just after plugging, and it
returns the WRITE_PROTECT bit wrongly at the first read.
This patch fixes the read-only detection by adding a new sdhci quirk
indicating to check the register more intensively with a relatively
long delay.
The patch is tested with 2.6.39-rc4 kernel.
Cc: Aries Lee <arieslee@jmicron.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Chris Ball <cjb@laptop.org>
Marvell pxa controllers have private registers that may need to be
modified before and after a reset is done.
For example, the SD reset operation, RESET_ALL, will reset the private
registers to their default state. This will cause the clock adjustment
registers that may have been programmed to have incorrect values.
RESET_DATA sometimes needs to be delayed before the reset is done
(depending on SoC) to enable any transactions being handled by the
SDIO card to be completed. Needed in pre SD 3.0 silicon to handle
clock gating.
Implement hooks to allow this to happen.
Signed-off-by: Philip Rakity <prakity@marvell.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Commit 373e6a (mmc: sdhci: R1B command handling + MMC_CAP_ERASE) moved the
handling of SDHCI_QUIRK_TIMEOUT_USES_SDCLK from sdhci_calc_timeout() to
sdhci_add_host(). This causes division by zero errors on at least the S3C
SDHCI controller as the quirk implementation needs host->clock set to work
but host->clock has not been set when sdhci_add_host() is called.
Fix this by backing out that portion of the change, the clock may vary at
runtime anyway. It does occur to me that we may want to move the quirk to
where we set the clock but this seems more invasive and I'm concerned
about undesirable side effects.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Andrei Warkentin <andreiw@motorola.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Some SD host controllers (noticed on an integrated JMicron SD reader on an
HP Pavilion dv5-1250eo laptop) don't update the dma address register before
signaling a dma interrupt due to a dma boundary. Update the register
manually to the next boundary (by default 512KiB), at which the transfer
stopped.
As long as each transfer is at most 512KiB in size (guaranteed by a BUG_ON
in sdhci_prepare_data()) and the boundary is kept at the default value,
this fix is needed at most once per transfer. Smaller boundaries are taken
care of by counting the transferred bytes.
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=28462
Signed-off-by: Mikko Vinni <mmvinni@yahoo.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
ERASE command needs R1B response, so fix R1B-type command
handling for SDHCI controller. For non-DAT commands using a busy
response, the cmd->cmd_timeout_ms (in ms) field is used for timeout
calculations.
Based on patch by Chuanxiao Dong <chuanxiao.dong@intel.com>
Signed-off-by: Andrei Warkentin <andreiw@motorola.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
It seems that under certain circumstances the sdhci_tasklet_finish()
call can be entered with mrq set to NULL, causing the system to crash
with a NULL pointer de-reference.
Seen on S3C6410 system. Based on a patch by Dimitris Papastamos.
Reported-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com>
Cc: <stable@kernel.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
It seems that under certain circumstances that the sdhci_tasklet_finish()
call can be entered with mrq->cmd set to NULL, causing the system to crash
with a NULL pointer de-reference.
Unable to handle kernel NULL pointer dereference at virtual address 00000000
PC is at sdhci_tasklet_finish+0x34/0xe8
LR is at sdhci_tasklet_finish+0x24/0xe8
Seen on S3C6410 system.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: <stable@kernel.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Some controllers misparse segment length 0 as being 0, not 65536. Add
a quirk to deal with it.
Signed-off-by: Olof Johansson <olof@lixom.net>
Reviewed-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Some old MMC devices fail with the 4/8 bits the driver tries to use
exclusively. This patch adds a test for the given bus setup and falls
back to the lower bit mode (until 1-bit mode) when the test fails.
[Major rework and refactoring by tiwai]
[Quirk addition and many fixes by prakity]
Signed-off-by: Aries Lee <arieslee@jmicron.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Philip Rakity <prakity@marvell.com>
Tested-by: Philip Rakity <prakity@marvell.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
JMicron 388 SD/MMC combo controller supports the 1.8V low-voltage for
SD, but MMC doesn't work with the low-voltage, resulting in an error
at probing.
This patch adds the support for multiple voltage mask per device type,
so that SD works with 1.8V while MMC forces 3.3V. Here new ocr_avail_*
fields for each device are introduced, so that the actual OCR mask is
switched dynamically.
Also, the restriction of low-voltage in core/sd.c is removed when the
bit is allowed explicitly via ocr_avail_sd mask.
This patch was rewritten from scratch based on Aries' original code.
Signed-off-by: Aries Lee <arieslee@jmicron.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
More information should be shown when sdhci_dumpregs is called.
Knowing the command is useful for debugging, and Capability 1
is useful for SD v3.
Signed-off-by: Philip Rakity <prakity@marvell.com>
Reviewed-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
We now:
* check for a v3 controller before setting 8-bit bus width
* offer a callback for platform code to switch to 8-bit mode, which
allows non-v3 controllers to support it
* rely on mmc->caps |= MMC_CAP_8_BIT_DATA; in platform code to specify
that the board designers have indeed brought out all the pins for
8-bit to the slot.
We were previously relying only on whether the *controller* supported
8-bit, which doesn't tell us anything about the pin configuration in
the board design.
This fixes the MMC card regression reported by Maxim Levitsky here:
http://thread.gmane.org/gmane.linux.kernel.mmc/4336
by no longer assuming that 8-bit works by default.
Signed-off-by: Philip Rakity <prakity@marvell.com>
Tested-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
A little more work was needed for SDIO IRQ wakeups to be functional.
Wake-on-WLAN on the SD WiFi adapter in the XO-1.5 laptop is now working.
Signed-off-by: Daniel Drake <dsd@laptop.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Some controllers handle their write-protection differently. Introduce a
callback to be able to handle it, ensuring the same locking takes place
for it. Rename the status variable to make it more obvious why the read
from the registers needs to be inverted.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Tested-by: Eric Bénard <eric@eukrea.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Snippet of code for how adaptation layer should handle the call:
/*
* eMMC spec calls for the host to send 74 clocks to the card
* during initialization, right after voltage stabilization.
* create the clocks manually right here.
*/
void generate_init_clocks_A0(struct sdhci_host *host, u8 power_mode)
{
struct sdhci_mmc_slot *slot = sdhci_priv(host);
if (slot->power_mode == MMC_POWER_UP &&
power_mode == MMC_POWER_ON) {
/* controller specific code here */
/* slot->power_mode holds previous power setting */
}
slot->power_mode = power_mode;
}
Signed-off-by: Philip Rakity <prakity@marvell.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
The SD and MMC code set highspeed using different constants.
Change the sd driver to recognize this and switch to high speed.
Validated code when testing eMMC dual data rate.
Signed-off-by: Philip Rakity <prakity@marvell.com>
[cjb: changelog + indentation fixes]
Signed-off-by: Chris Ball <cjb@laptop.org>
This patch fixes a warning when compiling the sdhci driver:
pwr may be used uninitialized in sdhci_set_power
Tested with the following compiler versions: 4.2.4 and 4.4.4
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Reviewed-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Chris Ball <cjb@laptop.org>
When a controller requires SDHCI_QUIRK_BROKEN_CARD_DETECTION, we poll
for card insertion/removal, and that creates interrupts. There's no
need to be doing this if we have a non-removable card.
This patch requires cards to be removable before we're willing to set
MMC_CAP_NEEDS_POLL.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Matt Fleming <matt@console-pimps.org>
Acked-by: Wolfram Sang <w.sang@pengutronix.de>
[cjb: modified changelog and code indentation]
Signed-off-by: Chris Ball <cjb@laptop.org>
In a multi-controller environment it is helpful to know which controller
has problems.
Signed-off-by: Philip Rakity <prakity@marvell.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
This patch is necessary to gain the performance boost from 8-bit data
with the sdhci-stm driver.
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
MMC_CAP_MMC_HIGHSPEED allows MMC and eMMC to negotiate up to 50M
instead of the previous limit of 25M.
Signed-off-by: Zhangfei Gao <zgao6@marvell.com>
Acked-by: Matt Fleming <matt@console-pimps.org>
Acked-by: Kyungmin Park <kmpark@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
While we're at it, add symbols for SDHCI_MAX_DIV_SPEC_{200,300}.
Signed-off-by: Zhangfei Gao <zhangfei.gao@marvell.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
SDHC Spec 3.0: Capabilities Register bits[15-08] are Base Clock Frequency
1.0/2.0: Capabilities Register bits[13-08] are Base Clock Frequency
Signed-off-by: Zhangfei Gao <zgao6@marvell.com>
Cc: David Vrabel <david.vrabel@csr.com>
Cc: Matt Fleming <matt@console-pimps.org>
Cc: Michal Miroslaw <mirqus@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Zhangfei Gao <zgao6@marvell.com>
Cc: Michał Mirosław <mirqus@gmail.com>
Cc: David Vrabel <david.vrabel@csr.com>
Reviewed-by: Matt Fleming <matt@console-pimps.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
The "6882a8c sdhci: Add better ADMA error reporting" commit added
sdhci_show_adma_error() which is built when DEBUG is defined. Since we
already have CONFIG_MMC_DEBUG used elsewhere in this driver, may as well
make consistent use of that config knob instead.
Signed-off-by: George G. Davis <gdavis@mvista.com>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
We have deprecated the distinction between hardware and physical
segments in the block layer. Consolidate the two limits into one in
drivers/mmc/.
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Some SDHCI controllers like s5pc110 don't have an HISPD bit in the HOSTCTL
register.
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Add auto CMD12 command support for eSDHC driver. This is needed by P4080
and P1022 for block read/write. Manual asynchronous CMD12 abort operation
causes protocol violations on these silicons.
Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com>
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Kumar Gala <galak@gate.crashing.org>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This patch adds support for regulator API to sdhci core driver.
Regulators can be used to disable power in suspended state to reduce
dissipated energy.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
S3C SDHCI host controller can change the source for generating mmc clock.
By default host bus clock is used, what causes some problems on machines
with 133MHz bus, because the SDHCI divider cannot be as high get proper
clock value for identification mode. This is not a problem for the
controller, because it can generate lower frequencies from other clock
sources. This patch changes sdhci driver to use get_min_clock() call if
it has been provided.
This fixes the flood of the following warnings on Samsung S5PV210 SoCs:
mmc0: Minimum clock frequency too high for identification mode
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Some host controllers can set mmc->caps before sdhci_add_host().
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Some host controllers such as s5pc110 support the WIDE8 feature.
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When using QUIRK_NONSTANDARD_CLOCK, it checks the set_clock() function
which is not used actually. So delete it.
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The current way of disabling it is not well tested by vendor and has all
kinds of bugs that show up on resume from ram/disk. A very good example
is a dead SDHCI controller.
Old way of disabling is still supported by continuing to use
CONFIG_MMC_RICOH_MMC.
Based on 'http://list.drzeus.cx/pipermail/sdhci-devel/2007-December/002085.html'
Therefore most of the credit for this goes to Andrew de Quincey
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: Andrew de Quincey <adq_dvb@lidskialf.net>
Acked-by: Philip Langdale <philipl@overt.org>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Even though many mmc host drivers pass a pm_message_t argument to
mmc_suspend_host() that argument isn't used the by MMC core. As host
drivers are converted to dev_pm_ops they'll have to construct
pm_message_t's (as they won't be passed by the PM subsystem any more) just
to appease the mmc suspend interface.
We might as well just delete the unused paramter.
Signed-off-by: Matt Fleming <matt@console-pimps.org>
Acked-by: Anton Vorontsov <cbouatmailru@gmail.com>
Acked-by: Michal Miroslaw <mirq-linux@rere.qmqm.pl>ZZ
Acked-by: Sascha Sommer <saschasommer@freenet.de>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The s3c6410 sdhci controller does not support the 'End' attribute and NOP
attribute in the same 8-Byte ADMA descriptor. This patch adds a new quirk
to identify sdhci host contollers with such behaviour. In addition to
this, for controllers using the new quirk, the last entry in the ADMA
descritor table is marked with the 'End' attribute (instead of using a NOP
descriptor with 'End' attribute).
Signed-off-by: Maurus Cuelenaere <mcuelenaere@gmail.com>
Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
Acked-by: Ben Dooks <ben-linux@fluff.org>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Some hosts (e.g. as found in CNS3xxx SOCs) report wrong value in
CLOCK_BASE capability field, and currently there is no way to force the
SDHCI core to use the platform-provided base clock value.
This patch implements CAP_CLOCK_BASE_BROKEN quirk. When enabled, the
SDHCI core will always use base clock frequency provided by the platform.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Cc: Richard Röjfors <richard.rojfors@pelagicore.com>
Cc: David Vrabel <david.vrabel@csr.com>
Cc: Pierre Ossman <pierre@ossman.eu>
Cc: Ben Dooks <ben@simtec.co.uk>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Tested with an XO v1.5 from OLPC.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
sdhci_set_adma_desc() is using byte-writes to write data in a specified
order into memory. Change to using __le16 for the two byte and __le32 for
the four byte cases and use the cpu_to_{le16,le32} to do the conversion
before writing.
This will reduce the size of the code and the number of writes as we no
longer need to chop the data up before writing.
As an example on ARM S3C64XX SoC, in little-endian configuration:
000000d4 <sdhci_set_adma_desc>:
- d8: e1a0c423 lsr ip, r3, #8
- dc: e1a0ec21 lsr lr, r1, #24
- e0: e1a04821 lsr r4, r1, #16
- e4: e1a05421 lsr r5, r1, #8
- e8: e1a06442 asr r6, r2, #8
- ec: e5c0c001 strb ip, [r0, #1]
- f0: e5c0e007 strb lr, [r0, #7]
- f4: e5c04006 strb r4, [r0, #6]
- f8: e5c05005 strb r5, [r0, #5]
- fc: e5c01004 strb r1, [r0, #4]
- 100: e5c06003 strb r6, [r0, #3]
- 104: e5c02002 strb r2, [r0, #2]
- 108: e5c03000 strb r3, [r0]
+ d4: e5801004 str r1, [r0, #4]
+ d8: e1c030b0 strh r3, [r0]
+ dc: e1c020b2 strh r2, [r0, #2]
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Cc: Pierre Ossman <pierre@ossman.eu>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The code to write the ADMA descriptor into memory is repeated several
times throughout sdhci_adma_table_pre, and thus should be moved into a
common function. This will also be useful if the patch to make the write
more efficient is accepted.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Cc: Pierre Ossman <pierre@ossman.eu>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
On an OLPC XO-1.5 development board with Via VX855 chipset, the sdhci
controller can take up to 12ms to stabilize its clock, but the current
timeout at which we give up on the controller is 10ms.
The patch increases the timeout delay rather than using a device-specific
quirk -- since we exit the loop when the clock comes up, increasing the
timeout value will only make us mdelay() longer in the errant case of a
device with a clock that is not stabilizing, which it seems worth waiting
a little longer for in general.
Signed-off-by: Chris Ball <cjb@laptop.org>
Cc: Harald Welte <HaraldWelte@viatech.com>
Acked-by: Pierre Ossman <pierre@ossman.eu>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Add support for ADMA on SDHCI hosts, not supporting SDMA.
According to the SDHCI specifications a host can support ADMA but not SDMA
Signed-off-by: Richard Röjfors <richard.rojfors@mocean-labs.com>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
eSDHC fails to recognize some SDHS cards, throwing timeout errors:
mmc0: error -110 whilst initialising SD card
That's because we calculate timeout value in a wrong way: on eSDHC hosts
the timeout clock is derivied from the SD clock, which is set dynamically.
As David Vrabel suggested, deriving timeout clock from SD clock is a
common scheme, so let's implement DATA_TIMEOUT_USES_SDCLK quirk and use it
for eSDHC hosts.
Also, from now on we don't need esdhc_get_timeout_clock() callback, so
remove it.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Cc: Pierre Ossman <pierre@ossman.eu>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: David Vrabel <david.vrabel@csr.com>
Cc: Ben Dooks <ben@fluff.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
get_min_clock() makes sense only with NONSTANDARD_CLOCK quirk and when
set_clock() callback is specified.
The patch should cause no functional changes, it just makes the code
self-documented and avoids any possible misuse of get_min_clock().
Suggested-by: Pierre Ossman <pierre@ossman.eu>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Cc: Ian Molton <ian@mnementh.co.uk>
Cc: Matt Fleming <matt@console-pimps.org>
Cc: Philip Langdale <philipl@overt.org>
Cc: Pierre Ossman <pierre@ossman.eu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
so the page will be flushed on unmap on ARCH which need it.
Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
Signed-off-by: Pierre Ossman <pierre@ossman.eu>
Since commit 8dfd0374be ("MMC core: limit
minimum initialization frequency to 400kHz") MMC core checks for minimum
frequency, and that causes following messages flood when using eSDHC
controllers:
...
mmc0: Minimum clock frequency too high for identification mode
mmc0: Minimum clock frequency too high for identification mode
...
The warnings are legitimate, since if we'd use 133 MHz clocks for standard
SDHCI controllers, we'd not able to scale frequency down to 400 kHz.
But eSDHC controllers have a non-standard SD clock management, so we can
divide clock by 256 * 16, not just 256.
This patch introduces get_min_clock() callback for sdhci core and
implements it for sdhci-of driver, and thus fixes the issue.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Cc: Matt Fleming <matt@console-pimps.org>
Cc: Ian Molton <ian@mnementh.co.uk>
Cc: "Roberto A. Foglietta" <roberto.foglietta@gmail.com>
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 SDHCI controller found in the VX855ES requires 10ms
delay between applying power and applying clock.
This issue has been discovered and documented by the OLPC XO1.5 team.
Signed-off-by: Harald Welte <HaraldWelte@viatech.com>
Signed-off-by: Pierre Ossman <pierre@ossman.eu>
Some hosts (hardware configurations, or particular SD/MMC slots) may
not support 4-bit bus. For example, on MPC8569E-MDS boards we can
switch between serial (1-bit only) and nibble (4-bit) modes, thought
we have to disable more peripherals to work in 4-bit mode.
Along with some small core changes, this patch modifies sdhci-of
driver, so that now it looks for "sdhci,1-bit-only" property in the
device-tree, and if specified we enable a proper quirk.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Pierre Ossman <pierre@ossman.eu>
Add quirk to show the controller cannot do multi-block IO.
This is mainly for the Samsung SDHCI controller that currently
cannot manage to do multi-block PIO without timing out.
Signed-off-by: Ben Dooks <ben@simtec.co.uk>
Signed-off-by: Pierre Ossman <pierre@ossman.eu>
Update the ADMA error reporting to not only show the
overall controller state but also to print the ADMA
descriptor list.
Signed-off-by: Ben Dooks <ben@simtec.co.uk>
Signed-off-by: Pierre Ossman <pierre@ossman.eu>
If using ADMA, then we should print the ADMA error
and current pointer in sdhci_dumpregs() when any
debug is requested.
Signed-off-by: Ben Dooks <ben@simtec.co.uk>
Signed-off-by: Pierre Ossman <pierre@ossman.eu>
Because of granularity issues, sometimes we told the hardware to change
to the voltage we were already at. Rework the logic so this doesn't
happen.
Signed-off-by: Pierre Ossman <pierre@ossman.eu>
FSL eSDHC controllers can support maximum block size up to 4096 bytes,
the MBL (Maximum Block Length) field in the capabilities register
extended by one bit, and is set to 0x3.
But the SDHCI core doesn't support blocks of 4096 bytes, and thus
forces blksz to the lowest value -- 512 bytes. With this patch we can
pin up the blksz to the maximum supported block size, i.e. 2048 bytes.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
FSL eSDHC controllers losing signal/interrupt enable states after
reset, so we should re-enable them.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Small udelay is needed to make eSDHC work in PIO mode. Without
the delay reading causes endless interrupt storm, and writing
corrupts data. The first guess would be that we must wait for
some bit in some register, but I didn't find any reliable bits
that change before and after the delay.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
FSL eSDHC hosts have incompatible register map to manage the SDCLK.
This patch adds set_clock callback so that drivers could overwrite
set_clock behaviour.
Similar patch[1] was posted by Ben Dooks, though in Ben's version the
callback is named change_clock, plus the patch has some unrelated bits
that makes the patch difficult to reuse.
[1] http://lkml.org/lkml/2008/12/2/160
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Some controllers do not provide clock information in their capabilities
(in the Samsung case, it is because there are multiple clock sources
available to the controller). Add hooks to allow the system to supply
clock information.
p.s.
In the original Ben's patch there was a bug that makes sdhci_add_host()
return -ENODEV even if callbacks were specified. This is fixed now.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
This patch adds SDHCI_QUIRK_INVERTED_WRITE_PROTECT quirk. When
specified, the sdhci driver will invert WP state.
p.s. Actually, the quirk is more board-specific than
controller-specific.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
This patch adds SDHCI_QUIRK_BROKEN_CARD_DETECTION quirk. When specified,
sdhci driver will set MMC_CAP_NEEDS_POLL MMC host capability, and won't
enable card insert/remove interrupts.
This is needed for hosts with unreliable card detection, such as FSL
eSDHC. The original eSDHC driver was tring to "debounce" card-detection
IRQs by reading present state and disabling particular interrupts. But
with this debouncing scheme I noticed that sometimes we miss card
insertion/removal events.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Some hosts (that is, FSL eSDHC) throw PIO interrupts during DMA
transfers, this causes tons of unneeded interrupts, and thus highly
degraded speed.
This patch modifies the driver so that now we only enable relevant
(DMA or PIO) interrupts during transfers.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Card detection interrupts should be handled separately as they should
not be enabled before mmc_add_host() returns and should be disabled
before calling mmc_remove_host(). The same is for suspend and resume
routines.
sdhci_init() no longer enables card-detection irqs. Instead, two new
functions implemented: sdhci_enable_card_detection() and
sdhci_disable_card_detection().
New sdhci_reinit() call implemented to behave the same way as the old
sdhci_init().
Also, this patch implements and uses few new helpers to manage IRQs in
a more conveinient way, that is:
- sdhci_clear_set_irqs()
- sdhci_unmask_irqs()
- sdhci_mask_irqs()
- SDHCI_INT_ALL_MASK constant
sdhci_enable_sdio_irq() converted to these new helpers, plus the
helpers will be used by the subsequent patches.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Pierre 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: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
The Samsung SDHCI (and FSL eSDHC) controller block seems to fail
to generate an INT_DATA_END after the transfer has completed and
the bus busy state finished.
Changes in e809517f6f to use the
new busy method are the cause of the behaviour change.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Fix the led device naming for the sdhci driver.
The led class documentation defines the led name to have the
form "devicename:colour:function" while not applicable sections
should be left blank.
To comply with the documentation the led device name is changed
from "mmc*" to "mmc*::".
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
This reverts commit a4b7619377.
It turned out that the controller had problem running at the
higher speed, so go back to trusting the hardware capability
bits.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
As reported by Randy Dunlap, having sdhci built-in and LEDs class
as a module resulted in undefined symbols. Change the code to handle
that case properly (by not having LEDs class support in sdhci).
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
CONFIG_LEDS_CLASS is defined only if led-class is built-in, otherwise
when it is a module the option is called CONFIG_LEDS_CLASS_MODULE. Led
support should also be activated in this case.
Signed-off-by: Eric Piel <eric.piel@tremplin-utc.net>
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 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>
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>
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>
The ADMA code path assumes that the 3 byte alignment fix doesn't cross
a page boundary. I'm not convinced this is worth supporting, but at
least print a warning in the off chance we'll actually see such a request.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
This comment update got lost in the great floo^Wmerge. As Pierre
pointed out, no one knows what 'CaFe' is.
Signed-off-by: Andres Salomon <dilinger@debian.org>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Add support for the scatter-gather DMA mode present on newer controllers.
As the mode requires 32-bit alignment, non-aligned chunks are handled by
using a bounce buffer.
Also add some new quirks to handle controllers that have bugs in the
ADMA engine.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Gracefully handle when the device is suddenly removed. Do a test read
and avoid any further access if that read returns -1.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Give the quirk for broken timeout handling a better chance of handling
more controllers by simply classifying the system as broken and setting
a fixed value.
Signed-off-by: Pierre 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: Pierre Ossman <drzeus@drzeus.cx>
The specification is insufficiently strict when it comes to how the
hardware should update the block count register, making it useless
for checking transfer progress.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Even the newer ENE controllers have bugs in their DMA engine that make
it too dangerous to use. Disable it until someone has figured out under
which conditions it corrupts data.
This has caused problems at least once, and can be found as bug report
10925 in the kernel bugzilla.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The CaFe chip has a hardware bug that ends up with us getting a timeout
value that's too small, causing the following sorts of problems:
[ 60.525138] mmcblk0: error -110 transferring data
[ 60.531477] end_request: I/O error, dev mmcblk0, sector 1484353
[ 60.533371] Buffer I/O error on device mmcblk0p2, logical block 181632
[ 60.533371] lost page write due to I/O error on mmcblk0p2
Presumably this is an off-by-one error in the hardware. Incrementing
the timeout count value that we stuff into the TIMEOUT_CONTROL register
gets us a value that works. This bug was originally discovered by
Pierre Ossman, I believe.
[thanks to Robert Millan for proving that this was still a problem]
Signed-off-by: Andres Salomon <dilinger@debian.org>
Cc: Pierre Ossman <drzeus-list@drzeus.cx>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This has been sitting around unloved for way too long..
The Marvell CaFe chip's SD implementation chokes during card insertion
if one attempts to set the voltage and power up in the same
SDHCI_POWER_CONTROL register write. This adds a quirk that does
that particular dance in two steps.
It also adds an entry to pci_ids.h for the CaFe chip's SD device.
Signed-off-by: Andres Salomon <dilinger@debian.org>
Cc: Pierre Ossman <drzeus-list@drzeus.cx>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The quirk was meant to just inhibit some resets, but ended up blocking
all of them. Fortunately, this was just what was needed. Change the
comment to reflect reality.
Also, this issue has just been observed on Samsung laptops, so reduce
the number of chips the quirk affects.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Hook up the controller LED to the LED subsystem, allowing more flexible
control than simply indicating an ongoing request.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Some devices have several controllers; need add the index info to
device slot name host->slot_desc[]
Signed-off-by: Feng Tang <feng.tang@intel.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
The JMicron JMB38x chip doesn't support transfers that aren't 32-bit
aligned (both size and start address). It also doesn't like switching
between PIO and DMA mode, so it needs to be reset after each request.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Some controllers have been designed on the assumption that all transfers
will be 32-bit aligned, both in start address and in size. This is not a
guarantee the SDHCI specification provides and not one we can provide.
Revert back to PIO for individual requests in order to work around the
hardware bug.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Do a full scan of the directory to try and be a bit more proactive,
instead of waiting for things to break.
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Commits
58b053e4ce ("Update arch/ to use sg helpers")
45711f1af6 ("[SG] Update drivers to use sg helpers")
fa05f1286b ("Update net/ to use sg helpers")
converted many files to use the scatter gather helpers without ensuring
that the necessary headerfile <linux/scatterlist> is included. This
happened to work for ia64, powerpc, sparc64 and x86 because they
happened to drag in that file via their <asm/dma-mapping.h>.
On most of the others this probably broke.
Instead of increasing the header file spider web I choose to include
<linux/scatterlist.h> directly into the affectes files.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The forcedma and nodma module parameters can be replaced with the quirks
parameter, so remove the redundancy.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Some controllers like ENE712 can't work properly with DMA mode,
add this quirk to force these kinds of HW work with PIO mode
Signed-off-by: Feng Tang <feng.tang@intel.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Many host controllers don't fully follow the PCI spec to claim
whether they support DMA in PCI class register. Leave the driver
to judge it from the Capability register, quirks and module parameter
Signed-off-by: Feng Tang <feng.tang@intel.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
It is fully legal for a controller to start issuing data related
interrupts before it has signalled that the command has completed.
Make sure the driver actually can handle this.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Some SDHC cards report an invalid maximum block size, in these cases
assume they support block sizes up to 512 bytes instead of returning
an error.
Signed-off-by: David Vrabel <david.vrabel@csr.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
The block count register shouldn't be trusted for single block transfers,
so avoid using it completely when calculating transferred bytes.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Added its pci_id and implemented a quirk for it because this
controller needs to reset cmd and data when setting ios.
Signed-off-by: Leandro Dorileo <dorileo@ossystems.com.br>
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Some controllers signal "command complete" even on failures (which
they are allowed to do according to the spec). Make sure we check
the error bits first so we don't get any false positives.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
The controller has a bit indicating that one of the higher bits (the
error bits) are set. A previous bug caused this bit to be masked, but
since that bug has been fixed we have to clear it explicictly.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Whenever a power interrupt is signaled it is also reported as an unexpected
one. All other unexpected interrupts get lost. Cause is a not inversed
bitmask to remove power interrupts from the status.
Signed-off-by: Rolf Eike Beer <eike-kernel@sf-tec.de>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
ENE has a very weird design where an SDHCI device (0805) is presented
on the PCI bus, but that device is non-functional, and the real device
is hidden as a more generic device.
Signed-off-by: Milko Krachounov <milko@3mhz.net>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
When the device hits certain memory boundaries, it signals an
interrupt and expects to be serviced. We don't need the feature
but we need to make sure the device doesn't stall.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Fix handling of low voltage MMC cards.
The latest MMC and SD specs both agree that support for
low-voltage operations is indicated by bit 7 in the OCR.
The MMC spec states that the low voltage range is
1.65-1.95V while the SD spec leaves the actual voltage
range undefined - meaning that there is still no such
thing as a low voltage SD card.
However, an old Sandisk spec implied that bits 7.0
represented voltages below 2.0V in 1V or 0.5V increments,
and the code was accordingly written with that expectation.
This confusion meant that host drivers attempting to support
the typical low voltage (1.8V) would set the wrong bits in
the host OCR mask (usually bits 5 and/or 6) resulting in the
the low voltage mode never being used.
This change corrects the low voltage range and adds sanity
checks on the reserved bits (0-6) and for SD cards that
claim to support low-voltage operations.
Signed-off-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Consolidate the list of available voltages.
Up until now, a separate set of defines has been
used for host->vdd than that used for the OCR
voltage mask values. Having two sets of defines
allows them to get out of sync and the current
sets are already inconsistent with one claiming
to describe ranges and the other specific voltages.
Only the SDHCI driver uses the host->vdd defines and
it is easily fixed to use the OCR defines.
Signed-off-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
