Make a new function out of common code used for drive
strength selection.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

In preparation for supporting also eMMC drive strength,
add the 'card' as a parameter so that the callback can
distinguish different types of cards if necessary.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Card drive strength selection uses a callback to
which a mask of supported drive strengths is passed.
Currently, the bits are checked against the values
in the SD specifications. That is not necessary
because the callback will anyway match the mask
against a valid value. Simplify by taking the mask
as is but still ensuring that the default mandatory
value (type B) is always supported.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Initialization of UHS-I modes for SD and SDIO cards
employs a callback to allow the host driver to
choose a drive strength value. Currently that
assumes the card drive strength and host driver
type must be the same value. Change to let the
callback make that decision and return both the
card drive strength and host driver type.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

IO state variable drv_type could be set during card
initialization. Consequently, it must be reset to the
default value when setting the initial state.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Since the regulator used for the SDMMC IO voltage is not expected to
draw a lot of current, most systems will probably use an inexpensive
LDO for it.  LDO regulators apparently have the feature that they
don't actively drive the voltage down--they wait for other components
in the system to drag the voltage down.  Thus they will transition
faster under heavy loads and slower under light loads.

During an SDMMC voltage change from 3.3V to 1.8V, we are almost
certainly under a light load.  To be specific:
* The regulator is hooked through pulls to CMD0-3 and DAT.  Probably
  the CMD pulls are something like 47K and the DAT is something like
  10K.
* The card is supposed to be driving DAT0-3 low during voltage change
  which will draw _some_ current, but not a lot.
* The regulator is also provided to the SDMMC host controller, but the
  SDMMC host controller is in open drain mode during the voltage
  change and so shouldn't be drawing much current.

In order to keep the SDMMC host working properly (or for noise
reasons), there might also be a capacitor attached to the SDMMC IO
regulator.  This also will have the effect of slowing down transitions
of the regulator, especially under light loads.

From experimental evidence, we've seen the voltage change fail if the
card doesn't detect that the voltage fell to less than about 2.3V when
we turn on the clock.  On one device (that admittedly had a 47K CMD
pullup instead of a 10K CMD pullup) we saw that the voltage was just
about 2.3V after 5ms and thus the voltage change would sometimes fail.
Doubling the delay gave margin and made the voltage change work 100%
of the time, despite the slightly weaker CMD pull.

At the moment submitting this as an RFC patch since my problem _could_
be fixed by increasing the pull strength (or using a smaller
capacitor).  However being a little bit more lenient to strange
hardware could also be a good thing.
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Acked-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

card->ext_csd.enhanced_area_offset is defined as "unsigned long long",
and, ext_csd[] is defined as u8.
unsigned long long data might have strange data if first bit of ext_csd[]
was 1. this patch cast it to (unsigned long long)
Special thanks to coverity <http://www.coverity.com>

ex)
        u8  data8;
        u64 data64;

        data8 = 0x80;
        data64 = (data8 << 24); // 0xffffffff80000000
        data64 = (((unsigned long long)data8) << 24); // 0x80000000;
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Allow to specify in the device-tree that no physical write-protect signal
is connected to a particular instance of a MMC controller. Setting the
property will cause the core will assume that the SD card is always
read-write.

The name for the new property is 'disable-wp' and was chosen based on the
property with the same function from the Synopsys designware mobile storage
host controller DT bindings specification.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Kumar Gala <galak@codeaurora.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

It is not uncommon to see systems where there is no physical write-protect
signal (e.g. when using eMMC or microSD card slots). For some controllers,
which have a dedicated write-protection detection logic (like SDHCI
controllers), the get_ro() callback can return bogus data in such a case.

Instead of handling this on a per controller basis this patch adds a new
capability flag to the MMC core that can be set to specify that the result
of get_ro() is invalid. When the flag is set the core will not call
get_ro() and assume that the card is always read-write.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Check the error code for EOPNOTSUPP and do not print
reset warning in that case.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

CRC errors could possibly be alleviated by
re-tuning so flag re-tuning needed in those cases.
Note this has no effect if re-tuning has not been
enabled.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

HS400 re-tuning must be done in HS200 mode. Add
the ability to switch from HS400 mode to HS200
mode before re-tuning and switch back to HS400
after re-tuning.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Make a separate function to do the mmc_switch status check
so it can be re-used. This is preparation for adding support
for HS400 re-tuning.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The sleep command is issued after deselecting the
card, but re-tuning won't work on a deselected card
so re-tuning must be held.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Hold re-tuning during bkops to prevent
it from conflicting with the busy state.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Hold re-tuning during erase commands to prevent
it from conflicting with the sequence of commands.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Hold re-tuning during switch commands to prevent
it from conflicting with the busy state or the CMD13
verification.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

At the start of each request, re-tune if needed and
then hold off re-tuning again until the request is done.

Note that though there is one function that starts
requests (mmc_start_request) there are two that wait for
the request to be done (mmc_wait_for_req_done and
mmc_wait_for_data_req_done).  Also note that
mmc_wait_for_data_req_done can return even when the
request is not done (which allows the block driver
to prepare a newly arrived request while still
waiting for the previous request).

This patch ensures re-tuning is held for the duration
of a request.  Subsequent patches will also hold
re-tuning at other times when it might cause a
conflict.

In addition, possibly a command is failing because
re-tuning is needed. Use mmc_retune_recheck() to check
re-tuning. At that point re-tuning is held, at least by
the request, so mmc_retune_recheck() flags host->retune_now
if the hold count is 1.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Enable re-tuning when tuning is executed and
disable re-tuning when card is no longer initialized.

In the case of SDIO suspend, the card can keep power.
In that case, re-tuning need not be disabled, but, if
a re-tuning timer is being used, ensure it is disabled
and assume that re-tuning will be needed upon resume
since it is not known how long the suspend will last.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Currently, there is core support for tuning during
initialization. There can also be a need to re-tune
periodically (e.g. sdhci) or to re-tune after the
host controller is powered off (e.g. after PM
runtime suspend / resume) or to re-tune in response
to CRC errors.

The main requirements for re-tuning are:
  - ability to enable / disable re-tuning
  - ability to flag that re-tuning is needed
  - ability to re-tune before any request
  - ability to hold off re-tuning if the card is busy
  - ability to hold off re-tuning if re-tuning is in
  progress
  - ability to run a re-tuning timer

To support those requirements 7 members are added to struct
mmc_host:

  unsigned int		can_retune:1;	/* re-tuning can be used */
  unsigned int		doing_retune:1;	/* re-tuning in progress */
  unsigned int		retune_now:1;   /* do re-tuning at next req */
  int			need_retune;	/* re-tuning is needed */
  int			hold_retune;	/* hold off re-tuning */
  unsigned int		retune_period;  /* re-tuning period in secs */
  struct timer_list	retune_timer;	/* for periodic re-tuning */

need_retune is an integer so it can be set without needing
synchronization. hold_retune is a integer to allow nesting.

Various simple functions are provided to set / clear those
variables.

Subsequent patches take those functions into use.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Some drivers schedule automatic hw resets. An example is mwifiex,
which schedules a card reset if the command handler between driver
and card firmware becomes out of sync
Signed-off-by: NAndreas Fenkart <afenkart@gmail.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The PM_RESTORE_PREPARE is not handled now in mmc_pm_notify(),
as result mmc_rescan() could be scheduled and executed at
late hibernation restore stages when MMC device is suspended
already - which, in turn, will lead to system crash on TI dra7-evm board:

WARNING: CPU: 0 PID: 3188 at drivers/bus/omap_l3_noc.c:148 l3_interrupt_handler+0x258/0x374()
44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4_PER1_P3 (Idle): Data Access in User mode during Functional access

Hence, add missed PM_RESTORE_PREPARE PM event in mmc_pm_notify().

Fixes: 4c2ef25f (mmc: fix all hangs related to mmc/sd card...)
Signed-off-by: NGrygorii Strashko <Grygorii.Strashko@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

This reverts commit 6685ac62 ("mmc: core: Convert mmc_driver to
device_driver")

The reverted commit went too far in simplifing the device driver parts
for mmc.

Let's restore the old mmc_driver to enable driver core to sooner
or later to remove the ->probe(), ->remove() and ->shutdown() callbacks
from the struct device_driver.

Note that, the old ->suspend|resume() callbacks in the struct
mmc_driver don't need to be restored, since the mmc block layer has
converted to the modern system PM ops.

Fixes: 6685ac62 ("mmc: core: Convert mmc_driver to device_driver")
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>

If the struct mmc_pwrseq_match .alloc function used to allocate a
struct mmc_pwrseq fails, the error is propagated to mmc_of_parse().

But instead of returning the error code in pwrseq, host->pwrseq is
returned which will always be 0. So mmc_of_parse() succeeds even if
the pwrseq .alloc function failed and host->pwrseq is NULL.

This makes the SDIO device to not be powered if the power sequencing
.alloc functions wants to be deferred due a missing resource because
the mmc controller driver probe did wrongly succeed.

Fixes: 0f12a0ce ("mmc: pwrseq: simplify alloc/free hooks")
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Reviewed-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The eMMC on a tablet I've will stop working / communicating as soon as
the kernel executes:

		mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
 				EXT_CSD_HPI_MGMT, 1,
 				card->ext_csd.generic_cmd6_time);

There seems to be no way to reliable identify eMMC-s which have a broken
hpi implementation, but at least for eMMC's which are soldered onto a board
we can work around this by specifying that hpi is broken in devicetree.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Currently those host drivers which have deployed runtime PM, deals with
the runtime PM reference counting entirely by themselves.

Since host drivers don't know when the core will send the next request
through some of the host_ops callbacks, they need to handle runtime PM
get/put between each an every request.

In quite many cases this has some negative effects, since it leads to a
high frequency of scheduled runtime PM suspend operations. That due to
the runtime PM reference count will normally reach zero in-between
every request.

We can decrease that frequency, by enabling the core to deal with
runtime PM reference counting of the host device. Since the core often
knows that it will send a seqeunce of requests, it makes sense for it
to keep a runtime PM reference count during these periods.

More exactly, let's increase the runtime PM reference count by invoking
pm_runtime_get_sync() from __mmc_claim_host(). Restore that action by
invoking pm_runtime_mark_last_busy() and pm_runtime_put_autosuspend()
in mmc_release_host(). In this way a runtime PM reference count will be
kept during the complete cycle of a claim -> release host.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Acked-by: NKonstantin Dorfman <kdorfman@codeaurora.org>

These callbacks have been set to deprecated for some time. The last
user (omap_hsmmc) has moved away from using them, which thus enables
us to completely remove them.
Signed-off-by: NNeilBrown <neil@brown.name>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Every call to sdio_enable_4bit_bus is followed (on success) by a call
to mmc_set_bus_width().

To simplify the code, include those calls directly in
sdio_enable_4bit_bus().
Signed-off-by: NNeilBrown <neil@brown.name>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The alloc() and free() hooks required each pwrseq implementation to set
host->pwrseq themselves. This is error-prone and could be done at a
higher level if alloc() was changed to return a pointer to a struct
mmc_pwrseq instead of an error code.

This patch performs this change and moves the burden of maintaining
host->pwrseq from the power sequence hooks to the pwrseq code.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The current error-path code (when gpiod_get_index() reports
an error) can never free pwrseq->reset_gpios[0], but might
try to tree pwrseq->reset_gpios[-1], which has unfortunate
consequences.
Signed-off-by: NNeilBrown <neil@brown.name>
Fixes: 934f1f48Acked-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Reported-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>

This patch fix spelling typo in printk messages.
Signed-off-by: NMasanari Iida <standby24x7@gmail.com>
Acked-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This patch provides a simple mmc-pwrseq-emmc driver, which controls
single gpio line. It perform standard eMMC hw reset procedure, as
descibed by Jedec 4.4 specification. This procedure is performed just
after MMC core enabled power to the given mmc host (to fix possible
issues if bootloader has left eMMC card in initialized or unknown
state), and before performing complete system reboot (also in case of
emergency reboot call). The latter is needed on boards, which doesn't
have hardware reset logic connected to emmc card and (limited or broken)
ROM bootloaders are unable to read second stage from the emmc card if
the card is left in unknown or already initialized state.
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Host drivers have different ways to sends their "init stream" to the
card. Some need to do it as part of a request, some do it from the
->set_ios() callback in the MMC_POWER_ON state and some don't send an
"init stream" at all.

To be able to use the reset GPIOs from the simple MMC power sequence
provider, the card need to be powered and the "init stream" must not
have been sent.

To cope with these requirements, invoke mmc_pwrseq_post_power_on()
prior we change the state to MMC_POWER_ON in mmc_power_up().

Host drivers shall perform power up operations in the MMC_POWER_UP
state. Unfortunate three hosts (au1xmmc, cb710-mmc and toshsd) don't
conform to this expectation. Instead those ignore the MMC_POWER_UP
state and delays their power up operations to the MMC_POWER_ON state.

Those hosts needs to change their behavior to enable proper support for
the simple MMC power sequence provider.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>

Some WLAN chips attached to a SDIO interface, need a reference clock.

Since this is very common, extend the prseq_simple driver to support
an optional clock that is enabled prior the card power up procedure.

Note: the external clock is optional. Thus an error is not returned
if the clock is not found.
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Many WLAN attached to a SDIO/MMC interface, needs more than one pin for
their reset sequence. For example, is very common for chips to have two
pins: one for reset and one for power enable.

This patch adds support for more reset pins to the pwrseq_simple driver
and instead hardcoding a fixed number, it uses the of_gpio_named_count()
since the MMC power sequence is only built when CONFIG_OF is enabled.
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

This patch is coming to fix compatibility issue of BKOPS_EN  field of EXT_CSD.
In eMMC-5.1, BKOPS_EN was changed, and now it has two operational bits:
Bit 0 - MANUAL_EN
Bit 1 - AUTO_EN
In previous eMMC revisions, only Bit 0 was supported.
Signed-off-by: NAlexey Skidanov <alexey.skidanov@sandisk.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The need for reset GPIOs has several times been pointed out from
erlier posted patchsets. Especially some WLAN chips which are
attached to an SDIO interface may use a GPIO reset.

The reset GPIO is asserted at initialization and prior we start the
power up procedure. The GPIO will be de-asserted right after the power
has been provided to the card, from the ->post_power_on() callback.

Note, the reset GPIO is optional. Thus we don't return an error even if
we can't find a GPIO for the consumer.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Reviewed-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>

To add the core part for the MMC power sequence, let's start by adding
initial support for the simple MMC power sequence provider.

In this initial step, the MMC power sequence node are fetched and the
compatible string for the simple MMC power sequence provider are
verified.

At this point we don't parse the node for any properties, but instead
that will be handled from following patches. Since there are no
properties supported yet, let's just implement the ->alloc() and the
->free() callbacks.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Reviewed-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>

System on chip designs may specify a specific MMC power sequence. To
successfully detect an (e)MMC/SD/SDIO card, that power sequence must
be followed while initializing the card.

To be able to handle these SOC specific power sequences, let's add a
MMC power sequence interface. It provides the following functions to
help the mmc core to deal with these power sequences.

mmc_pwrseq_alloc() - Invoked from mmc_of_parse(), to initialize data.
mmc_pwrseq_pre_power_on()- Invoked in the beginning of mmc_power_up().
mmc_pwrseq_post_power_on()- Invoked at the end in mmc_power_up().
mmc_pwrseq_power_off()- Invoked from mmc_power_off().
mmc_pwrseq_free() - Invoked from mmc_free_host(), to free data.

Each MMC power sequence provider will be responsible to implement a set
of callbacks. These callbacks mirrors the functions above.

This patch adds the skeleton, following patches will extend the core of
the MMC power sequence and add support for a specific simple MMC power
sequence.

Do note, since the mmc_pwrseq_alloc() is invoked from mmc_of_parse(),
host drivers needs to make use of this API to enable the support for
MMC power sequences. Moreover the MMC power sequence support depends on
CONFIG_OF.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Reviewed-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>

Both callers of mmc_start_request() call mmc_card_removed()
so move that call into mmc_start_request().

This patch is preparation for adding re-tuning support.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>