summaryrefslogtreecommitdiffstats
path: root/drivers/mmc/host/sdhci.c
Commit message (Collapse)AuthorAgeFilesLines
* mmc: core: Fixup broken suspend and eMMC4.5 power off notifyUlf Hansson2012-10-071-9/+0
| | | | | | | | | | | | | | | | | | | 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>
* mmc: sdhci: Test cd-gpio instead of SDHCI presence when probingGuennadi Liakhovetski2012-09-191-0/+8
| | | | | | | | | | | | | | | | 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>
* mmc: sdhci: vmmc regulator should be explicitly enabled/disabledPhilip Rakity2012-09-041-2/+5
| | | | | | | | 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>
* mmc: sdhci: Add regulator support for vccq (voltage regualor)Philip Rakity2012-09-041-65/+116
| | | | | | | | | 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>
* mmc: sd: Fix sd current limit settingAaron Lu2012-07-221-28/+3
| | | | | | | | | | | | | | 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>
* mmc: sdhci: When a UHS switch fails, cycle power if regulator is usedPhilip Rakity2012-07-221-0/+4
| | | | | | | | | | | | 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>
* mmc: sdhci: poll for card even when card is logically unremovableDaniel Drake2012-07-221-1/+1
| | | | | | | | | | | | | | | | | | | | 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>
* mmc: sdhci: Introduce new flag SDHCI_USING_RETUNING_TIMERAaron Lu2012-07-221-18/+12
| | | | | | | | | | | | | | | | | | | | | 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>
* mmc: sdhci: restore host settings when card is removedAaron Lu2012-07-221-0/+12
| | | | | | | | | | | | | | | | 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>
* mmc: sdhci: fix incorrect command used in tuningAaron Lu2012-07-221-1/+7
| | | | | | | | | | | | | | | | | 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>
* mmc: sdhci: Report failure reasons for all cases in sdhci_add_host()Mark Brown2012-07-221-2/+8
| | | | | | | | | 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>
* mmc: sdhci: Allow caps[1] to be set via SDHCI_QUIRK_MISSING_CAPSPhilip Rakity2012-07-221-3/+5
| | | | | | | | | | | | | | | 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>
* mmc: only support voltage (vdd) that regulator agrees withPhilip Rakity2012-07-211-0/+17
| | | | | | | | | 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>
* mmc: sdhci: only set 200mA support for 1.8v if 200mA is availablePhilip Rakity2012-07-211-1/+1
| | | | | | | | | | 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>
* mmc: sdhci: if MAX_CURRENT is 0, try getting current from regulatorPhilip Rakity2012-07-211-6/+22
| | | | | | | | | | | | 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>
* mmc: sdhci: Use DBG() instead of pr_warning() on large timeoutChris Ball2012-06-061-2/+2
| | | | | | | | | | 3bdc9ba892d6 ("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>
* mmc: sdhci: Log what timeout was set if the timeout is too largeMark Brown2012-04-221-2/+2
| | | | | | | | | 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>
* mmc: sdhci: refine non-removable card checking for card detectionDaniel Drake2012-04-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Commit c79396c191bc19 ("mmc: sdhci: prevent card detection activity for non-removable cards") disables card detection where the cards are marked as non-removable. This makes sense, but the implementation detail of calling mmc_card_is_removable() causes some problems, because mmc_card_is_removable() is overloaded with CONFIG_MMC_UNSAFE_RESUME semantics. In the OLPC XO case, we need CONFIG_MMC_UNSAFE_RESUME because our root filesystem is stored on SD, but we also have external SD card slots where we want automatic card detection. Refine the check to only apply to hosts marked as MMC_CAP_NONREMOVABLE, which is defined to mean that the card is *really* nonremovable. This could be revisited in future if we find a way to improve CONFIG_MMC_UNSAFE_RESUME semantics. Signed-off-by: Daniel Drake <dsd@laptop.org> Acked-by: Chuanxiao Dong <chuanxiao.dong@intel.com> [stable@: please apply to 3.3-stable] Cc: stable <stable@vger.kernel.org> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: Prevent 1.8V switch for SD hosts that don't support UHS modes.Al Cooper2012-04-051-2/+3
| | | | | | | | | | | | | | | | | The driver should not try to switch to 1.8V when the SD 3.0 host controller does not have any UHS capabilities bits set (SDR50, DDR50 or SDR104). See page 72 of "SD Specifications Part A2 SD Host Controller Simplified Specification Version 3.00" under "1.8V Signaling Enable". Instead of setting SDR12 and SDR25 in the host capabilities data structure for all V3.0 host controllers, only set them if SDR104, SDR50 or DDR50 is set in the host capabilities register. This will prevent the switch to 1.8V later. Signed-off-by: Al Cooper <acooper@gmail.com> Acked-by: Arindam Nath <arindam.nath@amd.com> Acked-by: Philip Rakity <prakity@marvell.com> Acked-by: Girish K S <girish.shivananjappa@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sdhci: check interrupt flags in ISR againAlexander Stein2012-03-271-7/+12
| | | | | | | | | | | | | | When using MSI it is possible that a new MSI is sent while an earlier MSI is currently handled. In this case SDHCI_INT_STATUS only contains SDHCI_INT_RESPONSE and the ISR would not be called again. But at the end of the ISR SDHCI_INT_DATA_END is now also pending which would be ignored. Fix this by rereading the interrupt flags in the ISR until no interrupt we care is pending. Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sdhci: add quirk for keeping card power during suspendAdrian Hunter2012-03-271-2/+11
| | | | | | | | | | Add quirk SDHCI_QUIRK2_HOST_OFF_CARD_ON to cater for the case when the card keeps power during suspend but the host controller does not i.e. the card power is not controlled by the host controller. In that case, the controller must be fully reset on resume. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sdhci: Add platform suspend/resume hooks.Chris Ball2012-03-251-0/+6
| | | | | | | Some platforms require saving/restoring registers across suspend/resume; this hook allows them to do that inside their driver. Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sdhci: restore the enabled dma when do reset allShaohui Xie2012-01-121-0/+5
| | | | | | | | | | | If dma is enabled, it'll be cleared when reset all is performed, this can be observed on some platforms, such as P2041 which has a version 2.3 controller, but platform like P4080 which has a version 2.2 controller, does not suffer this, so we will check if the dma is enabled, we should restore it after reset all. Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: host: Adds support for eMMC 4.5 HS200 modeGirish K S2012-01-121-15/+42
| | | | | | | | | This patch adds support for the HS200 mode on the host side. Also enables the tuning feature required when the HS200 mode is selected. Signed-off-by: Girish K S <girish.shivananjappa@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sdhci: Deal with failure case in sdhci_suspend_hostAaron Lu2012-01-121-3/+14
| | | | | | | | | | | | If there are errors happened in sdhci_suspend_host, handle it so that when the function returns with an error, the host's behaviour is the same before this function call, e.g. card detection is enabled and tuning timer is active, etc. Signed-off-by: Philip Rakity <prakity@marvell.com> Signed-off-by: Aaron Lu <aaron.lu@amd.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sd: Fix SDR12 timing regressionAlexander Elbs2012-01-121-2/+1
| | | | | | | | | | | | | This patch fixes a failure to recognize SD cards reported on a Dell Vostro with O2 Micro SD card reader. Patch 49c468f ("mmc: sd: add support for uhs bus speed mode selection") caused the problem, by setting the SDHCI_CTRL_HISPD flag even for legacy timings. Signed-off-by: Alexander Elbs <alex@segv.de> Acked-by: Philip Rakity <prakity@marvell.com> Acked-by: Arindam Nath <arindam.nath@amd.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sdhci: Fix tuning timer incorrect setting when suspending hostAaron Lu2012-01-121-2/+1
| | | | | | | | | | | | When suspending host, the tuning timer shoule be deactivated. And the HOST_NEEDS_TUNING flag should be set after tuning timer is deactivated. Signed-off-by: Philip Rakity <prakity@marvell.com> Signed-off-by: Aaron Lu <aaron.lu@amd.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sdhci: Always pass clock request value zero to set_clock host opTodd Poynor2012-01-111-1/+1
| | | | | | | | | | | | To allow the set_clock host op to disable the SDCLK source when not needed, always call the host op when the requested clock speed is zero. Do this even if host->clock already equals zero, because the SDHCI driver may set that value (without calling the host op) to force an update at the next (non-zero-speed) call. Signed-off-by: Todd Poynor <toddpoynor@google.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sdhci-pci: remove SDHCI_QUIRK2_OWN_CARD_DETECTIONAdrian Hunter2012-01-111-1/+0
| | | | | | | | | Even if a driver provides separate card detection, an interrupt is still needed to abort mmc requests that are in progress. SDHCI_QUIRK2_OWN_CARD_DETECTION prevents that, so remove it. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sdhci: prevent card detection activity for non-removable cardsAdrian Hunter2012-01-111-4/+3
| | | | | | | Do not enable card detection interrupts for non-removable cards. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sdhci: fix vmmc handlingAdrian Hunter2012-01-111-22/+21
| | | | | | | | | | Presently the vmmc regulator is enabled when the host controller is added and disabled when it is removed. However, the vmmc regulator should be under the control of the upper layers via ->set_ios(). Make it so. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: remove the second argument of k[un]map_atomic()Cong Wang2012-01-111-2/+2
| | | | | | Signed-off-by: Cong Wang <amwang@redhat.com> Acked-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: debugfs: expose the SDCLK frq in sys iosGiuseppe CAVALLARO2012-01-111-0/+10
| | | | | | | | | | | | | | This patch is to expose the actual SDCLK frequency in /sys/kernel/debug/mmcX/ios entry. For example, if the max clk for a normal speed card is 20MHz this is reported in /sys/kernel/debug/mmcX/ios. Unfortunately the actual SDCLK frequency (i.e. Baseclock / divisor) is not reported at all: for example, in that case, on Arasan HC, it should be 48/4=12 (MHz). Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sdhci: remove "state" argument from sdhci_suspend_hostManuel Lauss2011-12-191-1/+1
| | | | | | | | | Drop the "state" argument from sdhci_suspend_host. Its only user is the PCI glue; this allows to move all SDHCI glues to use dev_pm_ops instead. Signed-off-by: Manuel Lauss <manuel.lauss@googlemail.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: core: Add Power Off Notify Feature eMMC 4.5Girish K S2011-10-261-0/+9
| | | | | | | | | | | | | | This patch adds support for the power off notify feature, available in eMMC 4.5 devices. If the host has support for this feature, then the mmc core will notify the device by setting the POWER_OFF_NOTIFICATION byte in the extended csd register with a value of 1 (POWER_ON). For suspend mode short timeout is used, whereas for the normal poweroff long timeout is used. Signed-off-by: Girish K S <girish.shivananjappa@linaro.org> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: replace printk with appropriate display macroGirish K S2011-10-261-47/+45
| | | | | | | | All the files using printk function for displaying kernel messages in the mmc driver have been replaced with corresponding macro. Signed-off-by: Girish K S <girish.shivananjappa@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sdhci-pci: add runtime pm supportAdrian Hunter2011-10-261-44/+211
| | | | | | | | | | | | | Ths patch allows runtime PM for sdhci-pci, runtime suspending after inactivity of 50ms and ensuring runtime resume before SDHC registers are accessed. During runtime suspend, interrupts are masked. The host controller state is restored at runtime resume. For Medfield, the host controller's card detect mechanism is supplanted by an always-on GPIO which provides for card detect wake-up. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: Add module.h to drivers/mmc users assuming implicit presence.Paul Gortmaker2011-10-261-0/+1
| | | | | | | | | We are cleaning up the implicit presence of module.h; these guys are some of the people who just assume it will be there. Call it out explitly for those that really need it. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sdhci: add eMMC hardware reset supportAdrian Hunter2011-10-261-0/+9
| | | | | | | | Add an SDHCI operation for hardware reset and connect it to the host controller operation. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sdhci: use f_max instead of host->clock for timeoutsAndy Shevchenko2011-08-131-5/+2
| | | | | | | | | When timeout_clk is calculated the host->clock could be zero. So, instead of host->clock the calculation now uses mmc->f_max. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sdhci: move timeout_clk calculation farther downAndy Shevchenko2011-08-131-19/+19
| | | | | | | | This moves the calculation below the assignment of mmc->f_max, which we need for calculating timeout_clk in the next patch in this series. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sdhci: check host->clock before using it as a denominatorAndy Shevchenko2011-08-131-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Sometimes host->clock could be zero which is a legal situation. This patch checks host->clock before usage as a denominator when timeout is calculated. A similar patch is applied for mmc core (see commit e9b8684, "mmc: fix division by zero in MMC core"). Without this patch, the execution of the sdhci_calc_timeout could end up with a backtrace: <0>[ 4.014319] divide error: 0000 [#1] PREEMPT SMP <4>[ 4.014352] Modules linked in: g_ether <4>[ 4.014376] <4>[ 4.014393] Pid: 33, comm: kworker/u:2 Not tainted 3.0.0+ #646 <4>[ 4.014421] EIP: 0060:[<c12fa38e>] EFLAGS: 00010046 CPU: 1 <4>[ 4.014449] EIP is at sdhci_calc_timeout+0x2e/0x100 <4>[ 4.014468] EAX: 00000000 EBX: f5930fc8 ECX: 00000000 EDX: 00000000 <4>[ 4.014488] ESI: f5291de8 EDI: f5291db8 EBP: f5291c6c ESP: f5291c50 <4>[ 4.014508] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 <0>[ 4.014529] Process kworker/u:2 (pid: 33, ti=f5290000 task=f53065a0 task.ti=f5290000) <0>[ 4.014546] Stack: <4>[ 4.014557] 00000082 c1054fdd f5291c78 04000000 f5930fc8 f5291de8 f5291db8 f5291cac <4>[ 4.014611] c12fab7c c107a98b f5291c88 c13b6d3f f593109c f5882000 f5291cac c1054fdd <4>[ 4.014663] 00000000 00000000 f5882000 00000082 f5930fc8 f5291db8 0000000a f5291ccc <0>[ 4.014716] Call Trace: <4>[ 4.014743] [<c1054fdd>] ? mod_timer+0x11d/0x380 <4>[ 4.014770] [<c12fab7c>] sdhci_prepare_data+0x2c/0x3a0 <4>[ 4.014798] [<c107a98b>] ? trace_hardirqs_off+0xb/0x10 <4>[ 4.014827] [<c13b6d3f>] ? _raw_spin_unlock_irqrestore+0x2f/0x60 <4>[ 4.014854] [<c1054fdd>] ? mod_timer+0x11d/0x380 <4>[ 4.014880] [<c12fc7db>] sdhci_send_command+0xdb/0x210 <4>[ 4.014906] [<c12fd5f3>] sdhci_request+0xc3/0x150 <4>[ 4.014932] [<c12ec56a>] mmc_start_request+0xda/0x200 <4>[ 4.014960] [<c120d7c2>] ? __raw_spin_lock_init+0x32/0x60 <4>[ 4.014989] [<c1066a85>] ? __init_waitqueue_head+0x35/0x50 <4>[ 4.015015] [<c12ec70b>] mmc_wait_for_req+0x7b/0x90 <4>[ 4.015045] [<c12f0c67>] mmc_send_cxd_data+0xf7/0x130 <4>[ 4.015076] [<c12ecbc0>] ? mmc_erase+0x140/0x140 <4>[ 4.015102] [<c12f139d>] mmc_send_ext_csd+0x1d/0x20 <4>[ 4.015125] [<c12efef0>] mmc_get_ext_csd+0x70/0x140 <4>[ 4.015151] [<c12effe8>] mmc_compare_ext_csds+0x28/0x190 <4>[ 4.015176] [<c12f039f>] mmc_init_card+0x24f/0x650 <4>[ 4.015201] [<c13b6d5d>] ? _raw_spin_unlock_irqrestore+0x4d/0x60 <4>[ 4.015226] [<c107fd9c>] ? trace_hardirqs_on_caller+0x11c/0x160 <4>[ 4.015255] [<c12f09a4>] mmc_attach_mmc+0xa4/0x190 <4>[ 4.015282] [<c12ee3f0>] mmc_rescan+0x210/0x240 <4>[ 4.015311] [<c105f9b6>] process_one_work+0x176/0x550 <4>[ 4.015336] [<c105f93a>] ? process_one_work+0xfa/0x550 <4>[ 4.015360] [<c12ee1e0>] ? mmc_init_erase+0x140/0x140 <4>[ 4.015385] [<c1061c2a>] worker_thread+0x12a/0x2c0 <4>[ 4.015410] [<c1061b00>] ? manage_workers.clone.18+0x100/0x100 <4>[ 4.015437] [<c1066244>] kthread+0x74/0x80 <4>[ 4.015463] [<c10661d0>] ? __init_kthread_worker+0x60/0x60 <4>[ 4.015490] [<c13b7dfa>] kernel_thread_helper+0x6/0xd <0>[ 4.015507] Code: 57 89 d7 56 53 89 c3 83 ec 10 8b 40 04 8b 72 28 f6 c4 10 89 45 f0 0f 85 91 00 00 00 85 f6 0f 84 c1 00 00 00 8b 4e 04 31 d2 89 c8 <f7> 73 58 ba d3 4d 62 10 89 c1 8b 06 f7 e2 c1 ea 06 01 d1 f7 45 <0>[ 4.015829] EIP: [<c12fa38e>] sdhci_calc_timeout+0x2e/0x100 SS:ESP 0068:f5291c50 Reported-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: Revert "mmc: sdhci: Fix SDHCI_QUIRK_TIMEOUT_USES_SDCLK"Andy Shevchenko2011-08-131-4/+3
| | | | | | | | This reverts commit 4b01681c7764, which introduced a new potential divide by zero in the process of fixing one. The subsequent commits attempt to fix the issue properly. Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sdhci: fix retuning timer wrongly deleted in sdhci_tasklet_finishAaron Lu2011-08-131-3/+0
| | | | | | | | | | Currently, the retuning timer for retuning mode 1 will be deleted in function sdhci_tasklet_finish after a mmc request done, which will make retuning timing never trigger again. This patch fixed this problem. Signed-off-by: Aaron Lu <Aaron.Lu@amd.com> Reviewed-by: Philip Rakity <prakity@marvell.com> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sdhci: specify maximum discard timeoutAdrian Hunter2011-07-201-0/+5
| | | | | | | | | In general, SDHC hardware timeout cannot be avoided. Accordingly, the maximum timeout is specified to limit the maximum discard size. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sdhci: fix interrupt storm from card detectionShawn Guo2011-07-201-4/+25
| | | | | | | | | | | | | | | | | | | | The issue was initially found by Eric Benard as below. http://permalink.gmane.org/gmane.linux.ports.arm.kernel/108031 Not sure about other SDHCI based controller, but on Freescale eSDHC, the SDHCI_INT_CARD_INSERT bits will be immediately set again when it gets cleared, if a card is inserted. The driver need to mask the irq to prevent interrupt storm which will freeze the system. And the SDHCI_INT_CARD_REMOVE gets the same situation. The patch fixes the problem based on the initial idea from Eric Benard. Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Cc: Eric Benard <eric@eukrea.com> Tested-by: Arnaud Patard <arnaud.patard@rtp-net.org> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sdhci: Auto-CMD23 fixes.Andrei Warkentin2011-05-251-2/+2
| | | | | | | | | | | | | | | | | | Fixes bugs in Auto-CMD23 feature enable decision. Auto-CMD23 should be enabled if host is >= v3, and SDMA is not in use. USE_ADMA | USE_SDMA | Auto-CMD23 ---------+----------+----------- 0 | 0 | 1 ---------+----------+----------- 0 | 1 | 0 ---------+----------+----------- 1 | 0 | 1 ---------+----------+----------- 1 | 1 | 1 Signed-off-by: Andrei Warkentin <andreiw@motorola.com> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sdhci: Auto-CMD23 support.Andrei Warkentin2011-05-251-1/+16
| | | | | | | | Enables Auto-CMD23 support where available (SDHCI 3.0 controllers) Signed-off-by: Andrei Warkentin <andreiw@motorola.com> Tested-by: Arindam Nath <arindam.nath@amd.com> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sdhci: Implement MMC_CAP_CMD23 for SDHCI.Andrei Warkentin2011-05-251-16/+47
| | | | | | | | Implements support for multiblock transfers bounded by SET_BLOCK_COUNT (CMD23). Signed-off-by: Andrei Warkentin <andreiw@motorola.com> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sdhci: add hooks for setting UHS in platform specific codePhilip Rakity2011-05-241-15/+18
| | | | | | | | | Allow platform specific code to set UHS registers if implementation requires speciial platform specific handling Signed-off-by: Philip Rakity <prakity@marvell.com> Reviewed-by: Arindam Nath <arindam.nath@amd.com> Signed-off-by: Chris Ball <cjb@laptop.org>
OpenPOWER on IntegriCloud