Commit Graph

189 Commits

Author SHA1 Message Date
Chris Ball
14efd95720 mmc: sdhci: fix NULL dereference in sdhci_request() tuning
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+]
2012-11-07 15:02:05 -05:00
Kevin Liu
657d59823c mmc: sdhci: fix IS_ERR() checking of regulator_get()
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>
2012-11-07 15:02:04 -05:00
Jerry Huang
63ef5d8c28 mmc: sdhci-of-esdhc: disable CMD23 for some Freescale SoCs
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>
2012-11-07 14:55:29 -05:00
Ulf Hansson
e6c085863f mmc: core: Fixup broken suspend and eMMC4.5 power off notify
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>
2012-10-07 17:41:45 -04:00
Guennadi Liakhovetski
bec9d4e593 mmc: sdhci: Test cd-gpio instead of SDHCI presence when probing
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>
2012-09-19 16:29:45 +08:00
Philip Rakity
77dcb3f4c3 mmc: sdhci: vmmc regulator should be explicitly enabled/disabled
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>
2012-09-04 13:58:13 -04:00
Philip Rakity
6231f3de13 mmc: sdhci: Add regulator support for vccq (voltage regualor)
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>
2012-09-04 13:58:13 -04:00
Aaron Lu
55c4665ea0 mmc: sd: Fix sd current limit setting
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>
2012-07-22 15:25:52 -04:00
Philip Rakity
38cfc2f71c mmc: sdhci: When a UHS switch fails, cycle power if regulator is used
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>
2012-07-22 15:25:51 -04:00
Daniel Drake
eb6d5ae1c9 mmc: sdhci: poll for card even when card is logically unremovable
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>
2012-07-22 15:25:49 -04:00
Aaron Lu
973905feab mmc: sdhci: Introduce new flag SDHCI_USING_RETUNING_TIMER
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>
2012-07-22 15:25:49 -04:00
Aaron Lu
b67c6b411d mmc: sdhci: restore host settings when card is removed
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>
2012-07-22 15:25:47 -04:00
Aaron Lu
473b095a72 mmc: sdhci: fix incorrect command used in tuning
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>
2012-07-22 15:25:46 -04:00
Mark Brown
0fc81ee310 mmc: sdhci: Report failure reasons for all cases in sdhci_add_host()
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>
2012-07-22 15:25:45 -04:00
Philip Rakity
bd6a8c30fa mmc: sdhci: Allow caps[1] to be set via SDHCI_QUIRK_MISSING_CAPS
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>
2012-07-22 15:25:44 -04:00
Philip Rakity
68737043bb mmc: only support voltage (vdd) that regulator agrees with
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>
2012-07-21 00:02:24 -04:00
Philip Rakity
0aa6770000 mmc: sdhci: only set 200mA support for 1.8v if 200mA is available
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>
2012-07-21 00:02:23 -04:00
Philip Rakity
bad37e1ac6 mmc: sdhci: if MAX_CURRENT is 0, try getting current from regulator
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>
2012-07-21 00:02:22 -04:00
Chris Ball
09eeff52bf mmc: sdhci: Use DBG() instead of pr_warning() on large timeout
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>
2012-06-06 05:52:36 -04:00
Mark Brown
021459773d mmc: sdhci: Log what timeout was set if the timeout is too large
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>
2012-04-22 11:17:16 -04:00
Daniel Drake
87b87a3fc0 mmc: sdhci: refine non-removable card checking for card detection
Commit c79396c191 ("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>
2012-04-20 20:44:25 -04:00
Al Cooper
4188bba0e9 mmc: Prevent 1.8V switch for SD hosts that don't support UHS modes.
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>
2012-04-05 20:32:32 -04:00
Alexander Stein
6379b2375a mmc: sdhci: check interrupt flags in ISR again
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>
2012-03-27 12:20:13 -04:00
Adrian Hunter
6308d2905b mmc: sdhci: add quirk for keeping card power during suspend
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>
2012-03-27 12:20:08 -04:00
Chris Ball
a1b13b4e18 mmc: sdhci: Add platform suspend/resume hooks.
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>
2012-03-25 19:33:44 -04:00
Shaohui Xie
3abc1e8042 mmc: sdhci: restore the enabled dma when do reset all
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>
2012-01-12 15:17:17 -05:00
Girish K S
069c9f1428 mmc: host: Adds support for eMMC 4.5 HS200 mode
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>
2012-01-12 15:17:16 -05:00
Aaron Lu
38a60ea2e7 mmc: sdhci: Deal with failure case in sdhci_suspend_host
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>
2012-01-12 15:17:08 -05:00
Alexander Elbs
dd8df17fe8 mmc: sd: Fix SDR12 timing regression
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>
2012-01-12 15:17:03 -05:00
Aaron Lu
c6ced0db08 mmc: sdhci: Fix tuning timer incorrect setting when suspending host
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>
2012-01-12 15:16:55 -05:00
Todd Poynor
30832ab56c mmc: sdhci: Always pass clock request value zero to set_clock host op
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>
2012-01-11 23:58:47 -05:00
Adrian Hunter
e2a0a5829c mmc: sdhci-pci: remove SDHCI_QUIRK2_OWN_CARD_DETECTION
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>
2012-01-11 23:58:47 -05:00
Adrian Hunter
c79396c191 mmc: sdhci: prevent card detection activity for non-removable cards
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>
2012-01-11 23:58:47 -05:00
Adrian Hunter
ceb6143b2d mmc: sdhci: fix vmmc handling
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>
2012-01-11 23:58:47 -05:00
Cong Wang
482fce997e mmc: remove the second argument of k[un]map_atomic()
Signed-off-by: Cong Wang <amwang@redhat.com>
Acked-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Chris Ball <cjb@laptop.org>
2012-01-11 23:58:42 -05:00
Giuseppe CAVALLARO
df16219f36 mmc: debugfs: expose the SDCLK frq in sys ios
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>
2012-01-11 23:58:40 -05:00
Manuel Lauss
29495aa04a mmc: sdhci: remove "state" argument from sdhci_suspend_host
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>
2011-12-19 15:50:11 -08:00
Girish K S
bec8726abc mmc: core: Add Power Off Notify Feature eMMC 4.5
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>
2011-10-26 16:32:23 -04:00
Girish K S
a3c76eb9d4 mmc: replace printk with appropriate display macro
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>
2011-10-26 16:32:22 -04:00
Adrian Hunter
66fd8ad510 mmc: sdhci-pci: add runtime pm support
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>
2011-10-26 16:32:20 -04:00
Paul Gortmaker
88b4767974 mmc: Add module.h to drivers/mmc users assuming implicit presence.
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>
2011-10-26 16:32:19 -04:00
Adrian Hunter
20758b66dc mmc: sdhci: add eMMC hardware reset support
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>
2011-10-26 16:32:06 -04:00
Andy Shevchenko
65be3fef93 mmc: sdhci: use f_max instead of host->clock for timeouts
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>
2011-08-13 14:50:30 -04:00
Andy Shevchenko
272308caaa mmc: sdhci: move timeout_clk calculation farther down
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>
2011-08-13 14:50:29 -04:00
Andy Shevchenko
78a2ca2727 mmc: sdhci: check host->clock before using it as a denominator
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>
2011-08-13 14:50:28 -04:00
Andy Shevchenko
83cbcd93a1 mmc: Revert "mmc: sdhci: Fix SDHCI_QUIRK_TIMEOUT_USES_SDCLK"
This reverts commit 4b01681c77, 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>
2011-08-13 14:50:27 -04:00
Aaron Lu
78869618a8 mmc: sdhci: fix retuning timer wrongly deleted in sdhci_tasklet_finish
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>
2011-08-13 14:50:19 -04:00
Adrian Hunter
58d1246db3 mmc: sdhci: specify maximum discard timeout
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>
2011-07-20 17:21:04 -04:00
Shawn Guo
d25928d1ee mmc: sdhci: fix interrupt storm from card detection
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>
2011-07-20 17:21:01 -04:00
Andrei Warkentin
4f3d3e9b50 mmc: sdhci: Auto-CMD23 fixes.
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>
2011-05-25 16:52:26 -04:00