The timeout_clk calculation code for SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK case
is common and could be moved into common sdhci_do_set_ios, then platform code
which is not using sdhci_set_clock does not need to write the same code again.
Signed-off-by: Dong Aisheng <b29396@freescale.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The timeout_clk calculation code in sdhci_add_host is meaningless for
SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK.
So only execute them with no SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK set.
Signed-off-by: Dong Aisheng <b29396@freescale.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Currently the common code assume 0xE is the maximum timeout counter
value and use it to write into the timeout counter register.
However, it's fairly possible that some other SoCs may have different
max timeout register value. That means 0xE may be incorrect and
becomes meaningless.
It's also possible that other platforms has different timeout
calculation algorithm. To be flexible, this patch provides a .set_timeout
hook for those platforms to set the timeout on their way if they need.
Reviewed-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Dong Aisheng <b29396@freescale.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Currently the max timeout count is hardcode to 1 << 27 for calcuate
the max_busy_timeout, however, for some platforms the max timeout
count may not be 1 << 27, e.g. i.MX uSDHC is 1 << 28.
Thus 1 << 27 is not correct for such platform.
It is also possible that other platforms may have different values.
To be flexible, we add a get_max_timeout_count hook to get the correct
maximum timeout value for these platforms.
Reviewed-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Dong Aisheng <b29396@freescale.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
when SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK is set, timeout_clk is sdclk.
We need to update it when we change sdclk in sdhci_set_clock.
This allow to have a more precisse timeout and max_busy_timeout. This
can help for command that need a big busy wait (erase, ...).
Signed-off-by: Matthieu CASTET <matthieu.castet@parrot.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
When we wait for busy after sending a command, if there is
a timeout, we got SDHCI_INT_DATA_TIMEOUT flags.
Before this commit we got the message :
"Got data interrupt 0x00100000 even though no data operation was in progress."
and we need to wait 10s that sdhci_timeout_timer expires.
Signed-off-by: Matthieu CASTET <matthieu.castet@parrot.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
curr should use signed type since it will contain the returned
value which is possible to be a negative value. Using u32 will
make the returned value to be true even there is a negative result.
Change to use int instead of u32
Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
After the switch to the MMC core regulator infrastucture, we already
have a local "mmc" pointer in various functions. There is no longer a
need to access the data structure via host->mmc.
Signed-off-by: Markus Mayer <markus.mayer@linaro.org>
Reviewed-by: Matt Porter <mporter@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The MMC core in mmc_set_signal_voltage() already provides for the delay
required to switch to 1.8V, so there is no need for drivers to perform
this wait themselves.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
While merging the sdhci patchset from Russell King, somehow a blank
line was left behind. Let's correct the formatting.
Cc: Chris Ball <chris@printf.net>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
A standard compliant SDHCI can itself supply VDD at 1.8, 3.0, or 3.3v.
Several vendors ignore this and instead rely upon external regulators
to supply VDD. While the external regulators typically can supply one
of the standard SDHCI voltage levels, there is no real reason for this
to be a hard requirement.
This patch alters the SDHCI driver such that external VDD regulators
that provide voltages other than the three mentioned above may be used
so long as they can supply a voltage that meets the needs of the card.
In the case that an external VDD regulator is provided, it is reasonable
to ignore the voltage capabilities of the host controller and allow the
external regulator to set the OCR mask. Additionally, there is no need
to convert a VDD voltage request into one of the standard SDHCI voltage
levels or program it in the host controller's power control register.
Signed-off-by: Tim Kryger <tim.kryger@gmail.com>
Tested-by: Sachin Kamat <spk.linux@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Remove those unused ret variables to make it obvious that these function
will not return any errors in the current implementation.
Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Switch the common SDHCI code over to use mmc_host's regulator pointers
and remove the ones in the sdhci_host structure. Additionally, use the
common mmc_regulator_get_supply function to get the regulators and set
the ocr_avail mask.
This change sets the ocr_avail directly based upon the voltage ranges
supported which ensures ocr_avail is set correctly while allowing the
use of regulators that can't provide exactly 1.8v, 3.0v, or 3.3v.
Signed-off-by: Tim Kryger <tim.kryger@gmail.com>
Signed-off-by: Markus Mayer <markus.mayer@linaro.org>
Reviewed-by: Matt Porter <mporter@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The SD Host Controller spec states that the SD Host Controller can
request that the driver send up to 40 CMD19's while doing tuning
and that the total time the card spends responding must be < 150ms.
The sdhci_execute_tuning() function in sdhci.c that loops through
sending the CMD19's has multiple bugs. First it sets a "timeout"
variable to 150 and a loop counter variable to 40. It then decrements
both variables by 1 at the end of each loop. It tries to handle
violations of the count and time by doing a break when BOTH variables
are equal to zero, which can never happen because they we set to
different values and decremented by 1 at the same time. The timeout
variable is not based on time at all and is totally useless.
The routine also considers a loop counter of zero to be an error
which means that any controller that requests the max of 40 CMD19s
will cause tuning to fail and be disabled.
I've fixed these issues by allowing up to 40 CMD19's and I've removed
any attempt to handle the 150ms time limit. Removing timeout checking
seems safe here because each CMD19 is timeout protected and the max
loop counters insures we don't loop forever. Adding timeout checking
would not be as simple as snapping the time at the loop start and
checking for 150ms to pass because the loop queues the CMD19's and
uses events to wait for completion so the time would include
all the normal scheduler latencies.
Signed-off-by: Al Cooper <alcooperx@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
Track whether preset mode is currently enabled in hardware, and use that
when making decisions elsewhere in the code rather than reading the
register and checking the bit.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
Move the remaining parts of the power handling in sdhci_do_set_ios()
into sdhci_set_power().
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
Move the regulator handling into sdhci_set_power() rather than being in
sdhci_do_set_ios(). This wraps all power control up into this function.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
The only user (sdhci-of-esdhc) no longer uses these callbacks, so lets
remove them to discourage any further use.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
Clean up the code in sdhci_execute_tuning() so the decision whether
to execute tuning is clearer - and despite this reflecting what the
original code was doing, it shows that it may not be what the author
actually intended.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
Rather than reading back the timing information from the registers,
cache it locally. This allows implementations to translate the UHS
timing by overriding the set_uhs_signaling() method as required
without also having to emulate the SDHCI_HOST_CONTROL2 register.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
[Ulf Hansson] Resolved conflict
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
Add sdhci_set_uhs_signaling() and always call the set_uhs_signaling
method. This avoids quirks being added into sdhci_set_uhs_signaling().
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
[Ulf Hansson] Resolved conflict
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
Move the setting of mmc->actual_clock to zero into the set_clock
handlers themselves. This will allow us to clean up the calling
logic for the set_clock() method, and turn sdhci_set_clock() into
a library function.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
We don't need implementations to do this, since the only time it's
necessary is when we change the clock, and the only place that happens
is in sdhci_do_set_ios(). So, move it there, and remove it from the
iMX platform backend.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
Only one caller to sdhci_set_clock() needs to check whether the
requested clock frequency was the same as the currently set frequency,
yet we work around this in several other sites via sdhci_update_clock().
Rather than doing this, move those checks out into sdhci_do_set_ios(),
which then allows sdhci_update_clock() to be eliminated.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
Rather than using the streaming API, use the coherent allocator to
provide this memory, thereby eliminating cache flushing of it each
time we map and unmap it. This results in a 7.5% increase in
transfer speed with a UHS-1 card operating in 3.3v mode at a clock
of 49.5MHz.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
On read, we don't need to sync the whole scatterlist and then check
whether any segments need copying - if we check first, we avoid
potentially expensive cache handling.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
The Freescale esdhc driver is the only driver which needs the interrupt
registers restored after a reset. Move this quirk to be part of the
ESDHC driver implementation.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
Rather than having platform_reset_enter/platform_reset_exit methods,
turn the core of the reset handling into a library function which
platforms can call at the appropriate moment in their (new) reset
method.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
When we disable card detection interrupts, we should disable both the
insert and remove interrupts irrespective of the current state - this
avoids races between the hardware card detect changing state before
we've read that updated state and altered the interrupt mask.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
Rather than wasting cycles read-modify-writing the interrupt enable
registers, cache the value locally instead.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
Allow SDIO interrupts to be received while the SDHCI host is runtime
suspended. We do this by leaving the AHB clock enabled while the
host is runtime suspended so we can access the SDHCI registers, and
so read and raise the SDIO card interrupt.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
There's no requirement to have the card tasklet separate now that we
have a threaded interrupt handler, so kill this and move the called
code into the threaded part of the handler.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
Use a generic threaded interrupt handler for SDIO interrupt handling,
rather than allowing the SDIO core code to buggily spawn its own
thread. This results in host drivers to be more in control of how
SDIO interrupts are acknowledged in the hardware, rather than having
the internals of the SDIO core placed upon them, possibly resulting
in sub-standard handling.
At least one SDHCI implementation specifies a very specific sequence
to deal with a card interrupt.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
We don't need to change the SDHCI_SDIO_IRQ_ENABLED flag when we're
merely receiving an interrupt - IRQ handling thread in the MMC core
will either re-enable or disable the interrupt via the enable_sdio_irq
callback, which will update this status appropriately.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
sdhci interrupt handling is a mess; there is a lot of code doing very
similar things. Let's clean this up a bit:
1. set's clear down cmd, data and bus power interrupts in one go - we're
always going to handle these.
2. use a do { } while () loop for looping while there are pending
interrupts.
3. group clearing of bits in intmask into one place.
This results in the code becoming simpler and easier to read.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Tested-by: Markus Pargmann <mpa@pengutronix.de>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
This patch removes an unneccesary 1ms mdelay in the HS200 tuning
loop, called 40 times per retuning. Currently this causes a latency
of >40ms on any emmc accesses triggering wake from runtime PM,
which can occur for a significant portion of reads on a mostly idle system.
The delay is left in place for SD Cards, which use
MMC_SEND_TUNING_BLOCK rather than MMC_SEND_TUNING_BLOCK_HS200.
I'm not able to find evidence that this is required for SD in the
specs I have access to, however this delay has been present from
initial checkin for SD so I have preserved the original behavior for
compatibility.
This has been verified to fix observed glitching on local audio
playback and recording on apps with inbuilt assumptions on storage
latency.
Signed-off-by: Nick Sanders <nsanders@chromium.org>
Reviewed-by: Grant Grundler <grundler@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
When the host->tuning_count is zero it means that the retuning is
disabled. This is checked on the first run of sdhci_execute_tuning()
by the if statement below:
if (!(host->flags & SDHCI_NEEDS_RETUNING) && host->tuning_count &&
(host->tuning_mode == SDHCI_TUNING_MODE_1)) {
So only when tuning_count is non-zero it will set the host flag
SDHCI_USING_RETUNING_TIMER. The else statement is only for re-programming
the timer, which means that flag must be set. Because that is not checked
the else statement is executed in the first run when tuning_count is zero.
This was seen on a host controller which indicated SDHCI_TUNING_MODE_1 (0)
and tuning_count being zero. Suspect that (one of) these registers is not
properly set.
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Chris Ball <chris@printf.net>
If the SDHCI irq is shared with another device then the interrupt
handler can get called while SDHCI is runtime suspended. That is
harmless but the warning message is not useful so remove it. Also
returning IRQ_NONE is more appropriate.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Chris Ball <chris@printf.net>
To better reflect that the cmd_timeout_ms is directly related to the
busy detection timeout, let's rename it.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
Rename host->max_discard_to to host->max_busy_timeout, to reflect that
it tells the mmc core layer about the maximum supported busy detection
timeout by the host.
This timeout is at the moment only applicable to erase/trim/discard
commands. By the renaming we provide the option of make use of it for
other commands that cares about busy detection. In other words, those
commands that wants an R1B response, like for example the mmc switch
command.
Do note that the max_busy_timeout is supposed to be specified only by
hosts supporting MMC_CAP_WAIT_WHILE_BUSY.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
Add support for realtek rts5250 pci card reader. The card reader has
some problems with DDR50 mode, so add a new quirks2 for broken ddr50.
Signed-off-by: Micky Ching <micky_ching@realsil.com.cn>
Signed-off-by: Chris Ball <chris@printf.net>
The driver has a timer with a 10 second timeout to catch devices that stop
responding. However it is possible for commands to take even longer than
that. Change the timer timeout to reflect the command timeout.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Chris Ball <chris@printf.net>
In function sdhci_request(), it is possible to do the tuning execution
like below:
sdhci_request() {
spin_lock_irqsave(&host->lock, flags);
host->mrq = mrq;
...
spin_unlock_irqrestore(&host->lock, flags);
<=== Here it is possible one pending finish_tasklet get running
and it will operate the original mrq, and notified the mrq
is done, and causes memory corruption.
sdhci_execute_tuning(mmc, tuning_opcode);
spin_lock_irqsave(&host->lock, flags);
host->mrq = mrq;
...
}
In the above race place, the original mrq should not be finished wrongly,
so here before unlock the spinlock, we need to set the host->mrq to NULL
to avoid this case.
Signed-off-by: Liu, Chuansheng <chuansheng.liu@intel.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
The auto cmd settings bits should be cleared before sending new commands
or we may receive command timeout error for normal commands due to wrongly
pre-sent auto cmd.
e.g. we receive CMD13 timeout error due to ACMD23 is wrongly enabled
by former data commands.
mmc2: new high speed DDR MMC card at address 0001
mmcblk1: mmc2:0001 SEM08G 7.39 GiB
mmcblk1boot0: mmc2:0001 SEM08G partition 1 2.00 MiB
mmcblk1boot1: mmc2:0001 SEM08G partition 2 2.00 MiB
mmcblk1rpmb: mmc2:0001 SEM08G partition 3 128 KiB
mmcblk1: p1 p2 p3 p4 < p5 p6 p7 >
mmc2: Timeout waiting for hardware interrupt.
mmcblk1boot1: unknown partition table
mmc2: Timeout waiting for hardware interrupt.
mmcblk1boot0: unknown partition table
Signed-off-by: Dong Aisheng <b29396@freescale.com>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Ignore Card Interrupt bit in the interrupt status if we already
know that mmc_signal_sdio_irq() is going to be called at the end of
sdhci_irq(). This avoids a needless loop in sdhci_irq() repeatedly
reading interrupt status and doing nothing.
Signed-off-by: Alexey Neyman <stilor@att.net>
Acked-by: Dong Aisheng <b29396@freescale.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Suspend and resume of cards are being handled from the protocol layer
and consequently the mmc_suspend|resume_host APIs are deprecated.
This means we can simplify the suspend|resume callbacks by removing the
use of the deprecated APIs.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
The original code missed to report an error when the maximum tuning
loops exhausted or timeout, it will cause the upper layer to wrongly
think the tuning process is passed.
Signed-off-by: Dong Aisheng <b29396@freescale.com>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
It helps for platform code to use it send tuning commands.
Signed-off-by: Dong Aisheng <b29396@freescale.com>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
The tuning of some platforms may not follow the standard host control
spec v3.0, e.g. Freescale uSDHC on i.MX6Q/DL.
Add a hook here to allow execute platform specific tuning instead of
standard host controller tuning.
The hook only replaces the tuning process, so it's placed after tuning
checking and before the real tuning process.
Some notes for the tuning hook:
1) it needs handle lock itself if it wants to access host controller
according platform specific implementation.
2) do not need to handle runtime pm since it executes with runtime pm
get already.
Signed-off-by: Dong Aisheng <b29396@freescale.com>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Core:
- Support Allocation Units 8MB-64MB in SD3.0, previous max was 4MB.
- The slot-gpio helper can now handle GPIO debouncing card-detect.
- Read supported voltages from DT "voltage-ranges" property.
Drivers:
- dw_mmc: Add support for ARC architecture, and support exynos5420.
- mmc_spi: Support CD/RO GPIOs.
- sh_mobile_sdhi: Add compatibility for more Renesas SoCs.
- sh_mmcif: Add DT support for DMA channels.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
iQIcBAABAgAGBQJSLxu8AAoJEHNBYZ7TNxYMkV8P/RZMkP3L88wPmvdQ4IxVD/Bg
jphPsZTAlY8pLY7EcBVfbIGfBMMoVZ8CayuAbj9u5jFiMBNDUKRnKrky1m95F62n
xXiS5vUiKdWpByMpfKmrqvJr6eS8SWq5z/yug1c3s1Y9T363KgfypgJLvNgbMGiv
qbmjE+Zw65nMwHCk+4Rvq6s4aN6KosRZP0ABsn1foXt3kybSgemp5ShrlEyXohfS
E91EiYxHFC4fdmuWiZZvL1tyHFeV25omyZA90mpkioNItiwoyOM2rfjfEfNq+WBw
UrmdBesbGsF0Zi12CBa9LtzdRjYK8PugBWKW3mycS5++NX9KW6Ac/EpGqFeH9KgL
WZ2v4aQjkbnzQKUB2HcWAyXm88G9MkNvpLbIrmIPtson+q0UjgPYWe5BI3dy/Y1v
YS1JeseslVtSTKzGYsa1GJ7Nc1xYiILRz0RS4YGYXNjwvrl89i2UH7cglYDW36Xd
vxvRBaFpVsj1mfjjITEoG6nE0v5aYH6gSITY79XR+/kN871/99/oIUaWdpjcm9yv
SIYmK7ipcvxugkQ7BoMGbym/dvuUrZ+Vnf8dFlGPTJegZVsnfgrVAnRpvcVwW8+x
4Z79wUPSIETRqj2XX2I/Y0JnrXry+dLLVyeK1tELoeOKev73Ai2lcqPSz6J0tzJs
IErcz0hM1znL2RtgNwio
=+EYB
-----END PGP SIGNATURE-----
Merge tag 'mmc-updates-for-3.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc
Pull MMC updates from Chris Ball:
"MMC highlights for 3.12:
Core:
- Support Allocation Units 8MB-64MB in SD3.0, previous max was 4MB.
- The slot-gpio helper can now handle GPIO debouncing card-detect.
- Read supported voltages from DT "voltage-ranges" property.
Drivers:
- dw_mmc: Add support for ARC architecture, and support exynos5420.
- mmc_spi: Support CD/RO GPIOs.
- sh_mobile_sdhi: Add compatibility for more Renesas SoCs.
- sh_mmcif: Add DT support for DMA channels"
* tag 'mmc-updates-for-3.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc: (50 commits)
Revert "mmc: tmio-mmc: Remove .set_pwr() callback from platform data"
mmc: dw_mmc: Add support for ARC
mmc: sdhci-s3c: initialize host->quirks2 for using quirks2
mmc: sdhci-s3c: fix the wrong register value, when clock is disabled
mmc: esdhc: add support to get voltage from device-tree
mmc: sdhci: get voltage from sdhc host
mmc: core: parse voltage from device-tree
mmc: omap_hsmmc: use the generic config for omap2plus devices
mmc: omap_hsmmc: clear status flags before starting a new command
mmc: dw_mmc: exynos: Add a new compatible string for exynos5420
mmc: sh_mmcif: revision-specific CLK_CTRL2 handling
mmc: sh_mmcif: revision-specific Command Completion Signal handling
mmc: sh_mmcif: add support for Device Tree DMA bindings
mmc: sh_mmcif: move header include from header into .c
mmc: SDHI: add DT compatibility strings for further SoCs
mmc: dw_mmc-pci: enable bus-mastering mode
mmc: dw_mmc-pci: get resources from a proper BAR
mmc: tmio-mmc: Remove .set_pwr() callback from platform data
mmc: tmio-mmc: Remove .get_cd() callback from platform data
mmc: sh_mobile_sdhi: Remove .set_pwr() callback from platform data
...
We use host->ocr_mask to hold the voltage get from device-tree
node, In case host->ocr_mask was available, we use host->ocr_mask
as the final available voltage can be used by MMC/SD/SDIO card.
Signed-off-by: Haijun Zhang <haijun.zhang@freescale.com>
Reviewed-by: Anton Vorontsov <anton@enomsg.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Use regulator_get_optional() to tell the core that requests for regulators
can fail in a real system.
Signed-off-by: Mark Brown <broonie@linaro.org>
Acked-by: Chris Ball <cjb@laptop.org>
Add a card_event callback to sdhci so that clients can provide their
own card_event to be called when card_detect is triggered.
Signed-off-by: Christian Daudt <csd@broadcom.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
This patch fixes the HC ctrl_2 programming where, in case of
SDR104 and HS200, we have to write 100b in the the UHS Mode
bits. We wrote 101b that is reserved from Arasan Specs.
Reported-by: Youssef Triki <youssef.triki@st.com>
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Although the HC supports HS200 (eMMC) the caps2 are always zero; this
means there's no way to use the super speed mode (when init the card).
If the HC support SDR104, for SD3.0, so it also supports HS200 for eMMC
and this patch just sets the MMC_CAP2_HS200 in the host caps2 field.
Reported-by: Youssef Triki <youssef.triki@st.com>
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Reviewed-by: Philip Rakity <prakity@nvidia.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
The following error randomly appears on an imx6q board where gpio is
used to implement card-detection when mounting EXT4 rootfs during boot.
mmc1: Card removed during transfer!
mmc1: Resetting controller.
mmcblk0: unknown error -123 sending read/write command, card status 0x900
end_request: I/O error, dev mmcblk0, sector 106744
EXT4-fs error (device mmcblk0p2): ext4_find_entry:1312: inode #5011: comm swapper/0: reading directory lblock 0
It turns out that the error message comes from the card removal check
in function sdhci_card_event(). While we have a well implemented
function sdhci_do_get_cd() handling all the possible cases of
CD, the current code only checks controller internal CD case. That
causes problem for other CD cases like gpio on above imx6q board.
Improve the check by using sdhci_do_get_cd() to cover all possible CD
cases, so that above error on the imx6q board gets fixed.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
If card power is dependent on SD bus power then the host controller
must not be runtime suspended while the card is powered up. Add
the ability to stay runtime-resumed in that case and enable it with a new
quirk SDHCI_QUIRK2_CARD_ON_NEEDS_BUS_ON.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Fixes:
/git/arm-soc/drivers/mmc/host/sdhci.c: In function 'sdhci_add_host':
/git/arm-soc/drivers/mmc/host/sdhci.c:2910:19: warning: ignoring
return value of 'regulator_enable', declared with attribute
warn_unused_result [-Wunused-result]
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Chris Ball <cjb@laptop.org>
1. mmc_rescan will call get_cd to know whether the card is present
before mmc_rescan_try_freq to avoid useless trials during
card removal or start host is called when card is not present.
2. get_cd needs to be checked to resolve slow card removal issue.
Signed-off-by: Kevin Liu <kliu5@marvell.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
3714f4315354 ("mmc: sdhci: update signal voltage switch code") changed the
type of the second parameter of sdhci_do_start_signal_voltage_switch(),
from "struct mmc_ios *ios" to "int signal_voltage" which causes the
following build warning:
drivers/mmc/host/sdhci.c:2044:2: warning: initialization from incompatible pointer type [enabled by default]
drivers/mmc/host/sdhci.c:2044:2: warning: (near initialization for 'sdhci_ops.start_signal_voltage_switch') [enabled by default]
Use the previous type so that it matches the start_signal_voltage_switch()
definition from host.h.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Reviewed-by: Johan Rudholm <johan.rudholm@stericsson.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Some regulators don't report any voltage values, so checking supported
voltage range results in disabling all SDHCI_CAN_VDD_* flags and
registration failure. This patch finally provides a correct fix for the
registration of SDHCI driver with all possible voltage regulators:
dummy, fixed and regulated without using regulator_count_voltages()
hacks.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
4d55c5a1 ("mmc: sdhci: enable preset value after uhs initialization")
added preset value support and enabled it by default during sd card init.
Below are the enhancements introduced by this patch:
1. In current code, preset value is enabled after setting clock finished,
which means the clock is manually set by driver firstly and then suddenly
switched to preset value at this point. So the first setting is useless
and unnecessary. What's more, the first clock setting may differ from the
preset one. The better way is enable preset value just after switch to
UHS mode so the preset value can take effect immediately. So move preset
value enable from mmc_sd_init_card to sdhci_set_ios which will be called
during set timing.
2. In current code, preset value is disabled at the beginning of
mmc_attach_sd. It's too late since low freq (400khz) should be set in
mmc_power_up. So move preset value disable to sdhci_set_ios which will
be called during power up.
3. host->clock and ios->drv_type should also be updated according to the
preset value if it's enabled. Current code missed this.
4. This patch also introduce a quirk to disable preset value in case
preset value doesn't work.
This patch has been verified on sdhci-pxav3 platform with both preset
enabled and disabled.
Signed-off-by: Kevin Liu <kliu5@marvell.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
The protocol related code is moved to core stack. So update the host
driver accordingly.
Signed-off-by: Kevin Liu <kliu5@marvell.com>
Tested-by: Tim Wang <wangtt@marvell.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
The 8bit in the function name is misleading. When set, it will be
used to set the bus width, regardless of whether 8bit or another
bus width is requested, so change the function name to
platform_bus_width.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Tested-by: Dirk Behme <dirk.behme@de.bosch.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
There are three places where same piece of code is used. Let's split it
to a separate function.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Don't disable SD Host IRQ during suspend if it is wake up source.
Enable wakeup event during suspend.
Signed-off-by: Jialing Fu <jlfu@marvell.com>
Signed-off-by: Kevin Liu <kliu5@marvell.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Current code missed disabling interrupts before free irq which is shared.
Notice below comments for function free_irq (kernel/irq/manage.c):
On a shared IRQ the caller must ensure the interrupt is disabled
on the card it drives before calling this function.
Original code has below issue during suspend/resume when multiple SD
hosts share the same IRQ:
1. Assume there are two hosts (host1 for emmc while host2 for sd) share
the same mmc irq.
2. When system suspend, host2 will be suspended before host1.
So the sequence is below:
step1: irq handler for host2 removed ->
step2: irq handler for host1 removed and irq disabled ->
... system suspended ...
... system resumed ...
step3: irq enabled and the irq handler for host1 restored ->
step4: irq handler for host2 restored
3. So there is the buggy time slot that the irq is enabled but the irq
handler for host2 is removed. Then host2 interrupt can be triggered
but can't be handled at that moment.
Signed-off-by: Jialing Fu <jlfu@marvell.com>
Signed-off-by: Kevin Liu <kliu5@marvell.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Call mmc_gpio_get_cd() to query card presence from cd-gpio before
asking SDHCI. The rationale behind this change is that flag
SDHCI_QUIRK_BROKEN_CARD_DETECTION is designed for SDHCI controller to
tell that SDHCI_PRESENT_STATE is broken, and it should be used for this
case only. So when cd-gpio is being used, the controller should set
the flag to tell that SDHCI_PRESENT_STATE is not available.
However, the existing code will skip checking cd-gpio as long as flag
SDHCI_QUIRK_BROKEN_CARD_DETECTION is set. Change the querying order
between cd-gpio and SDHCI to support the rationale above.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Extracting a part of the SDHCI card tasklet into a .card_event()
implementation allows SDHCI hosts to use generic card-detection
services, e.g. the GPIO slot function.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Reviewed-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
A-003500: False ADMA Error might be reported when ADMA is used for
multiple block read command with Stop at Block Gap. If PROCTL[SABGREQ]
is set when the particular block's data is received by the System side
logic before entire block (with CRC) data is received by the SD side
logic, and also if ADMA descriptor line is fetched at the same time,
then DMA engine might report false ADMA error. eSDHC might not be able
to Continue (PROCTL[CREQ]=1) after Stop at Block Gap.
This issue will impact the eSDHC IP VVN2.3.
Signed-off-by: Haijun Zhang <Haijun.Zhang@freescale.com>
Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com>
Acked-by: Anton Vorontsov <cbouatmailru@gmail.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
The OLPC XO-1.75 laptop includes a SDHCI controller which is 1.8v
capable, and it truthfully reports so in its capabilities. This
alternate voltage is used for driving new "UHS-I" SD cards at their
full speed.
However, what the controller doesn't know is that the motherboard
physically doesn't have a 1.8v supply available.
Add a quirk so that systems such as this one can override disable
1.8v support, adding support for UHS-I cards (by running them at
3.3v).
This avoids a problem where the system would first try to run the
card at 1.8v, fail, and then not be able to fully reset the card
to retry at the normal 3.3v voltage.
This is more appropriate than using the MISSING_CAPS quirk, which
is intended for cases where the SDHCI controller is actually lying
about its capabilities, and would force us to somehow override both
caps words from another source.
Signed-off-by: Daniel Drake <dsd@laptop.org>
Reviewed-by: Philip Rakity <prakity@nvidia.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
For regulator vmmc/vmmcq, use voltage range as below
3.3v/3.0v: (2.7v, 3.6v)
1.8v: (1.7v, 1.95v)
Original code uses the precise value which may fail in regulator
driver if it does NOT support the precise voltage.
Signed-off-by: Jialing Fu <jlfu@marvell.com>
Signed-off-by: Kevin Liu <kliu5@marvell.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
The vmmc regulator enable in sdhci_add_host is NOT necessary since
it can be enabled during mmc_power_up by function mmc_regulator_set_ocr.
And this extra enable will make regulator_enable/regulator_disable
unbalanced. Consequently, vmmc can't be disabled during mmc_power_off.
Also, if the vqmmc regulator exists, it should be enabled regardless it
support 1.8v or not.
Signed-off-by: Kevin Liu <kliu5@marvell.com>
Signed-off-by: Philip Rakity <prakity@marvell.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Commit 473b095a72 ("mmc: sdhci: fix incorrect command used in tuning")
introduced a NULL dereference at resume-time if an SD 3.0 host controller
raises the SDHCI_NEEDS_TUNING flag while no card is inserted. Seen on an
OLPC XO-4 with sdhci-pxav3, but presumably affects other controllers too.
Signed-off-by: Chris Ball <cjb@laptop.org>
Cc: stable <stable@vger.kernel.org> [3.3+]
There are two problems here:
The check for vmmc was printing an unnecessary pr_info() when
host->vmmc is NULL.
The intent of the check for vqmmc was to only remove UHS if we have a
regulator that doesn't support the required voltage, but since IS_ERR()
doesn't catch NULL, we were actually removing UHS modes if vqmmc isn't
present at all -- since it isn't present for most users, this breaks
UHS for them. This patch fixes that UHS regression in 3.7-rc1.
Signed-off-by: Kevin Liu <kliu5@marvell.com>
Signed-off-by: Bin Wang <binw@marvell.com>
Reviewed-by: Philip Rakity <prakity@marvell.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
CMD23 causes lots of errors in kernel on some freescale SoCs
(P1020, P1021, P1022, P1024, P1025 and P4080) when MMC card used,
which is because these controllers does not support CMD23,
even on the SoCs which declares CMD23 is supported.
Therefore, we'll not use CMD23.
Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com>
Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
Acked-by: Anton Vorontsov <cbouatmailru@gmail.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
This patch fixes up the broken suspend sequence for eMMC with sleep
support. Additionally it reworks the eMMC4.5 Power Off Notification
feature so it fits together with the existing sleep feature.
The CMD0 based re-initialization of the eMMC at resume is re-introduced
to maintain compatiblity for devices using sleep.
A host shall use MMC_CAP2_POWEROFF_NOTIFY to enable the Power Off
Notification feature. We might be able to remove this cap later on,
if we think that Power Off Notification always is preferred over
sleep, even if the host is not able to cut the eMMC VCCQ power.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Saugata Das <saugata.das@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Previously to this patch, an SDHCI platform that uses a GPIO for
card detection instead of the internal SDHCI_CARD_PRESENT bit on
the presence register would fail to detect a new card.
Some drivers worked around this in various ways: esdhc-imx defines
an IO accessor to fake the presence bit being true, s3c turns on
polling (which stops the SDHCI driver from checking the bit) after
a card's inserted. But none of this should be necessary; the real
fix is to check whether we're using a GPIO and avoid relying on
the presence bit if so, as this patch implements.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Chris Ball <cjb@laptop.org>
The vmmc regulator should not rely on the platform code to enable it.
Expliciitly enable and disable the regulator inside the driver.
Signed-off-by: Philip Rakity <prakity@marvell.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
On some systems the host controller does not support vccq
signaling. This is supplied by a dedicated regulator (vqmmc).
Add support for this regulator.
Signed-off-by: Philip Rakity <prakity@marvell.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Host has different current capabilities at different voltages, we need
to record these settings seperately. The defined voltages are 1.8/3.0/3.3.
For other voltages, we do not touch current limit setting.
Before we set the current limit for the sd card, find out the host's
operating voltage first and then find out the current capabilities of
the host at that voltage to set the current limit.
Signed-off-by: Aaron Lu <aaron.lu@amd.com>
Reviewed-by: Philip Rakity <prakity@marvell.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Power needs to be removed from the card when switching to 1.8v fails.
If a regulator is used to control vmmc we need to turn the
regulator off and then back on otherwise power will not be
removed from the card.
Signed-off-by: Philip Rakity <prakity@marvell.com>
Reviewed-by: Aaron Lu <aaron.lu@amd.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
The Marvell CaFe is now marked as having bad card detection to fix
a problem during system resume.
Now on the OLPC XO-1 we are facing the issue that the card is marked
as logically unremovable (via MMC_UNSAFE_RESUME), which means that
mmc_card_is_removable considers the card non-removable. The existing
code logic decides not to poll for card presence in this case, and
card detection is also disabled because of the quirk being set.
This means that no SD cards are detected when inserted after boot.
Refine the logic to enable card presence polling in the case when
a card is logically unremovable, only avoiding the poll in the case
when the card is physically non-removable (denoted with
MMC_CAP_NONREMOVABLE).
Signed-off-by: Daniel Drake <dsd@laptop.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Add a new flag of SDHCI_USING_RETUNING_TIMER to represent if the host
is using a retuning timer for the card inserted.
This flag is set when the host does tuning the first time for the card
and the host's retuning mode is 1. This flag is used afterwards whenever
needs to decide if the host is currently using a retuning timer.
This flag is cleared when the card is removed in sdhci_reinit.
The set/clear of the flag and the start/stop of the retuning timer is
associated with the card's init/remove time, so there is no need to
touch it when the host is to be removed as at that time the card should
have already been removed.
Signed-off-by: Aaron Lu <aaron.lu@amd.com>
Reviewed-by: Girish K S <girish.shivananjappa@linaro.org>
Reviewed-by: Philip Rakity <prakity@marvell.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Some of the host settings are affected by different cards inserted, e.g.
when an UHS-I card is inserted, the SDHCI_NEEDS_RETUING flag might be
set when the tuning timer expired and host's max_blk_count will be
reduced to make sure the data transfer for a command does not exceed 4MiB
to meet the retuning mode 1's requirement.
When the card is removed, we should restore the original setting of the
host since we can't be sure the next card being inserted will still be
an UHS-I card that needs tuning. The original setting include its
max_blk_count and no set of the flag of SDHCI_NEEDS_RETUNING.
Signed-off-by: Aaron Lu <aaron.lu@amd.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
For SD hosts using retuning mode 1, when retuning timer expired, it will
need to do retuning in sdhci_request before processing the actual
request. But the retuning command is fixed: cmd19 for SD card and cmd21
for eMMC card, so we can't use the original request's command to do the
tuning.
And since the tuning command depends on the card type attached to the
host, we will need to know the card type to use the correct tuning
command.
Signed-off-by: Aaron Lu <aaron.lu@amd.com>
Reviewed-by: Philip Rakity <prakity@marvell.com>
Cc: stable <stable@vger.kernel.org> [3.3+]
Signed-off-by: Chris Ball <cjb@laptop.org>
For most error conditions sdhci_add_host() will print a diagnostic
message indicating why it failed but there are a few cases where this
does not happen. Add error messages in these cases to aid diagnosis.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Currently only the capability_0 register can be set if
SDHCI_QUIRK_MISSING_CAPS is defined. This is a problem when
the capability_1 register also needs changing. Use the quirk
SDHCI_QUIRK_MISSING_CAPS to allow both registers to be set.
Redefining caps[1] is useful when the board design does not
support 1.8v vccq so UHS modes are not available. The code that
calls sdhci_add_host can then detect this condition and adjust
the caps so the UHS mode will not be attempted on UHS cards.
Signed-off-by: Philip Rakity <prakity@marvell.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
If we are using a regulator the SD Host Controller and the
regulator should agree about the voltages supported. Use
the common subset that is supported.
Signed-off-by: Philip Rakity <prakity@marvell.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
max_current_caps can return 0 if not available from the sd controller.
If no regulator is present or the regulator specifies a current
less then 200ma, we no longer still set the 200mA caps bit anyway.
Signed-off-by: Philip Rakity <prakity@marvell.com>
Reviewed-by: Aaron Lu <aaron_lu@amd.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
The sd host controller spec indicates the the MAX_CURRENT value may
be returned as 0. In this case other methods need to be used to
return the current. If 0 is returned and there is a regulator,
ask the regulator for how much current is available.
Signed-off-by: Philip Rakity <prakity@marvell.com>
Signed-off-by: Mark F. Brown <mark.brown314@gmail.com>
Reviewed-by: Aaron Lu <aaron.lu@amd.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
3bdc9ba892 ("mmc: use really long write timeout to deal with crappy
cards") in 3.4 increased the write timeout that the core sends to host
drivers to 3 seconds. This makes sdhci's "requested timeout too large"
warning trigger on every write; so, change this pr_warning() to a DBG().
Reported-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Rather than just logging that we came up with an excessively large timeout
say what the timeout was, this may provide some clues as to what the issue
is.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Aisheng Dong