summaryrefslogtreecommitdiff
path: root/drivers/mmc/host/sdhci.c
AgeCommit message (Collapse)AuthorFilesLines
2014-11-10mmc: sdhci: Fix incorrect ADMA2 descriptor table sizeAdrian Hunter1-1/+7
The ADMA2 descriptor table size was being calculated incorrectly Fix it. Note that it has been wrong for a long time and likely has not caused any problems because of a combination of 1) not needing alignment descriptors for block operations 2) more memory being allocated than was requested 3) the use of SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC which does not use an extra descriptor for the end marker. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2014-11-10mmc: sdhci: fix error conditions for controller resetAndrew Gabbasov1-3/+4
Add the case of SET_BLOCK_COUNT command error to the error conditions check for making a controller reset at request handling finish. Otherwise, if the SET_BLOCK_COUNT command failed, e.g. with a timeout, the controller state was not reset, and the next command failed too. In the case of data error the controller reset is already done in finish_data() function before sending stop command (if present), so the finish tasklet should make a reset after data error only if no stop command existed in the request. Also, fix the indentation of this condition check to make it more logical. Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2014-11-10mmc: sdhci: Balance vmmc regulator_disable()Andrew Gabbasov1-3/+0
As a follow-up of commit "mmc: sdhci: Balance vmmc regulator_enable(), and always enable vqmmc" vmmc regulator disable is also not needed in sdhci_remove_host. The regulator is completely controlled by mmc_power_up and mmc_power_off functions and is already disabled by the time of removing the host. Extra regulator_disable call in sdhci_remove_host is unbalanced and causes a warning reported by regulator core, so should be removed. Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2014-10-03mmc: sdhci: Let a driver override timeout clock frequencyAdrian Hunter1-0/+6
Let a driver override the timeout clock frequency by populating it before calling sdhci_add_host(). Note the value will otherwise be zero because sdhci_host is zeroed when allocated. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2014-10-03mmc: sdhci: Add quirk for always getting TC with stop cmdAdrian Hunter1-2/+6
Add a quirk for a host controller that always sets a Transfer Complete interrupt status for the stop command even when a busy response is not indicated. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2014-09-24mmc: sdhci: execute tuning when device is not busyYi Sun1-3/+4
We find tuning timeout because of the secure erase operation lasts too long, so don't do tuning when device is busy. Signed-off-by: Yi Sun <yi.y.sun@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2014-09-24mmc: Convert pr_warning to pr_warnJoe Perches1-18/+16
Use the much more common pr_warn instead of pr_warning. Other miscellanea: o Coalesce formats o Realign arguments o Remove extra spaces when coalescing formats Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2014-09-09mmc: sdhci: check 1.2v IO capability for SDHC hostChuanxiao.Dong1-1/+6
Right now enable 1.2v IO voltage for SDHC is by using vqmmc. Thus for the host which doesn't have vqmmc, or its vqmmc does not support 1.2v, directly use MMC_CAP2_HS200 may cause HS200 failure. So needs to check if vqmmc is able to support 1.2v. If it does not support, disable 1.2v IO for HS200. Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2014-09-09mmc: sdhci: handle busy-end interrupt during commandChanho Min1-2/+15
It is fully legal for a controller to start handling busy-end interrupt before it has signaled that the command has completed. So make sure we do things in the proper order, Or it results that command interrupt is ignored so it can cause unexpected operations. This is founded at some toshiba emmc with the bellow warning. "mmc0: Got command interrupt 0x00000001 even though no command operation was in progress." This issue has been also reported by Youssef TRIKI: It is not specific to Toshiba devices, and happens with eMMC devices as well as SD card which support Auto-CMD12 rather than CMD23. Also, similar patch is submitted by: Gwendal Grignou <gwendal@chromium.org> Changes since v1: Fixed conflict with the next of git.linaro.org/people/ulf.hansson/mmc.git and Tested if issue is fixed again. Signed-off-by: Hankyung Yu <hankyung.yu@lge.com> Signed-off-by: Chanho Min <chanho.min@lge.com> Tested-by: Youssef TRIKI <youssef.triki@st.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2014-09-09sdhci: Make sdhci_disable_irq_wakeups() staticFabio Estevam1-2/+1
sdhci_disable_irq_wakeups() is exported, but it is not called outside sdhci.c. Make it static and do not export it, so that the following sparse warning is fixed: drivers/mmc/host/sdhci.c:2548:6: warning: symbol 'sdhci_disable_irq_wakeups' was not declared. Should it be static? Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2014-09-09mmc: sdhci: move timeout_clk dynamically calculation code into common codeAisheng Dong1-11/+13
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>
2014-09-09mmc: sdhci: calculate timeout_clk conditionally in sdhci_add_hostAisheng Dong1-17/+17
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>
2014-09-09mmc: sdhci: add platform set_timeout hookAisheng Dong1-5/+14
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>
2014-09-09mmc: sdhci: add platform get_max_timeout_count hookAisheng Dong1-2/+7
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>
2014-09-09sdhci : recompute timeout_clk when neededMatthieu CASTET1-1/+7
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>
2014-09-09sdhci : handle busy timeout irqMatthieu CASTET1-0/+5
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>
2014-09-09mmc: sdhci: fix the wrong type of currChuanxiao.Dong1-1/+1
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>
2014-07-09mmc: sdhci: Replace host->mmc with mmc where possibleMarkus Mayer1-15/+15
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>
2014-07-09mmc: sdhci: avoid double-delay while transitioning to 1.8VRussell King1-3/+0
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>
2014-07-09mmc: sdhci: Remove blank lineUlf Hansson1-1/+0
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>
2014-07-09mmc: sdhci: Improve external VDD regulator supportTim Kryger1-7/+9
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>
2014-07-09mmc: sdhci: Remove unused ret variablesMarkus Pargmann1-4/+3
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>
2014-07-09mmc: sdhci: Use mmc core regulator infrastuctureTim Kryger1-61/+36
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>
2014-05-22mmc: sdhci: SD tuning is broken for some controllersAl Cooper1-15/+9
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>
2014-05-22mmc: sdhci: track whether preset mode is currently enabled in hardwareRussell King1-18/+26
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>
2014-05-22mmc: sdhci: move remaining power handling into sdhci_set_power()Russell King1-9/+7
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>
2014-05-22mmc: sdhci: move regulator handling into sdhci_set_power()Russell King1-37/+35
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>
2014-05-22mmc: sdhci: remove platform_suspend/platform_resume callbacksRussell King1-6/+0
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>
2014-05-22mmc: sdhci: clean up sdhci_execute_tuning() decisionRussell King1-16/+15
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>
2014-05-22mmc: sdhci: cache timing information locallyRussell King1-11/+12
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>
2014-05-22mmc: sdhci: convert sdhci_set_uhs_signaling() into a library functionRussell King1-20/+24
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>
2014-05-22mmc: sdhci: convert sdhci_set_clock() into a library functionRussell King1-11/+6
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>
2014-05-22mmc: sdhci: move setting mmc->actual_clock into set_clock handlersRussell King1-2/+2
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>
2014-05-22mmc: sdhci: move setting host->clock into sdhci_do_set_ios()Russell King1-5/+4
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>
2014-05-22mmc: sdhci: clean up sdhci_update_clock()/sdhci_set_clock()Russell King1-16/+5
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>
2014-05-22mmc: sdhci: convert ADMA descriptors to a coherent allocationRussell King1-21/+22
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>
2014-05-22mmc: sdhci: avoid sync'ing the SG if there's no misalignmentRussell King1-1/+10
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>
2014-05-22mmc: sdhci: move FSL ESDHC reset handling quirk into esdhc codeRussell King1-5/+0
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>
2014-05-22mmc: sdhci: convert reset into a library functionRussell King1-23/+24
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>
2014-05-22mmc: sdhci: convert generic bus width setup to library functionRussell King1-23/+22
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>
2014-05-22mmc: sdhci: plug hole in disabling card detection interruptsRussell King1-8/+9
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>
2014-05-22mmc: sdhci: more efficient interrupt enable register handlingRussell King1-51/+47
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>
2014-05-22mmc: sdhci: allow sdio interrupts while sdhci runtime suspendedRussell King1-4/+3
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>
2014-05-22mmc: sdhci: push card_tasklet into threaded irq handlerRussell King1-14/+9
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>
2014-05-22mmc: sdhci: convert to new SDIO IRQ handlingRussell King1-23/+39
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>
2014-05-22mmc: sdhci: clean up sdio interrupt enable handlingRussell King1-18/+17
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>
2014-05-22mmc: sdhci: clean up interrupt handlingRussell King1-66/+58
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>
2014-05-14mmc: sdhci: remove mdelay in eMMC tuningNick Sanders1-1/+4
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>
2014-04-21mmc: sdhci: clarify DDR timing mode between SD-UHS and eMMCSeungwon Jeon1-1/+3
Added MMC_DDR52 as eMMC's DDR mode is distinguished from SD-UHS. Signed-off-by: Seungwon Jeon <tgih.jun@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Chris Ball <chris@printf.net>
2014-03-26sdhci: only reprogram retuning timer when flag is setArend van Spriel1-4/+3
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>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-24 03:35:11 +0300