MMC_CAP_RUNTIME_RESUME was invented to decrease system PM resume time for
systems that particularly needs this. As the feature has matured let's
make it the default behavior for MMC/SD.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

As mmc_claim_host() invokes pm_runtime_get_sync() for the mmc host device,
it's important that the host is kept claimed for *all* accesses to it via
the host_ops callbacks.

In mmc_rescan(), the ->card_event() and the ->get_cd() callback are being
invoked without claiming the host, let's fix this.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The ->card_event() callback may be called when re-scan is disabled and for
non-removable cards, which both cases are unnecessary.

Instead let's move the call later in mmc_rescan() where these constraints
have been validated.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The driver will not probe without valid DMA channels so no need to check
if they are valid when the module is removed.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
CC: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Though the mmc core driver should/will continue to support the legacy
"enable-sdio-wakeup" property to enable SDIO as the wakeup source, we
need to add support for the new standard property "wakeup-source".

This patch adds support for "wakeup-source" property in addition to the
existing "enable-sdio-wakeup" property.

Cc: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Anytime a write operation is performed with Reliable Write flag enabled,
the eMMC device is enforced to bypass the cache and do a write to the
underling NVM device by Jedec specification; this causes a performance
penalty since write operations can't be optimized by the device cache.

In our tests, we replayed a typical mobile daily trace pattern and found
~9% overall time reduction in trace replay by using this patch. Also the
write ops within 4KB~64KB chunk size range get a 40~60% performance
improvement by using the patch (as this range of write chunks are the ones
affected by REQ_META).

This patch has been discussed in the Mobile & Embedded Linux Storage Forum
and it's the results of feedbacks from many people. We also checked with
fsdevl and f2fs mailing list developers that this change in the usage of
REQ_META is not affecting FS behavior and we got positive feedbacks.
Reporting here the feedbacks:
http://comments.gmane.org/gmane.linux.file-systems/97219
http://thread.gmane.org/gmane.linux.file-systems.f2fs/3178/focus=3183Signed-off-by: NBruce Ford <bford@micron.com>
Signed-off-by: NLuca Porzio <lporzio@micron.com>
Fixes: ce39f9d1 ("mmc: support packed write command for eMMC4.5 devices")
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

If NO_DMA=y:

    ERROR: dma_unmap_sg [drivers/mmc/host/android-goldfish.ko] undefined!
    ERROR: dma_alloc_coherent [drivers/mmc/host/android-goldfish.ko] undefined!
    ERROR: dma_map_sg [drivers/mmc/host/android-goldfish.ko] undefined!
    ERROR: dma_free_coherent [drivers/mmc/host/android-goldfish.ko] undefined!

Add a dependency on HAS_DMA to fix this.
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

drivers/mmc/host/mtk-sd.c: In function ‘get_best_delay’:
drivers/mmc/host/mtk-sd.c:1284: warning: ‘delay_phase.start’ is used uninitialized in this function
drivers/mmc/host/mtk-sd.c:1284: warning: ‘delay_phase.maxlen’ is used uninitialized in this function

If delay is zero, these fields are indeed not initialized.
Let the compiler preinitialize the whole struct to fix this.
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

mmc_select_hs400() calls __mmc_switch() which checks the switch is
successful using CMD13 (SEND_STATUS).  The problem is that it does that
using the timing settings of the previous mode.  That is prone to error,
especially when switching from HS to HS400 because the timing parameters
for HS mode are tighter than the timing parameters for HS400 mode.

In the case when CMD13 polling is used (i.e. not MMC_CAP_WAIT_WHILE_BUSY)
with the switch command, it must be assumed that using different modes on
the card and host must work.

However in the case when CMD13 polling is not used
(i.e. MMC_CAP_WAIT_WHILE_BUSY) mmc_select_hs400() can be made more
reliable by setting the host to the correct timing before sending CMD13.

This patch does that.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Cc: <stable@vger.kernel.org> # 4.2+
Tested-by: NAlim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Move the mmc_switch_status() function in preparation for calling it
in mmc_select_hs400().
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Cc: <stable@vger.kernel.org> # 4.2+
Tested-by: NAlim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

mmc_select_hs400() begins with the card and host in HS200 mode.
Therefore, any commands sent to the card should use HS200 timing.
It is incorrect to set the host to High Speed (HS) timing before
sending the switch command.  Doing so is unreliable because
the timing parameters for HS mode are tighter than the timing
parameters for HS200 mode.  Thus the HS timings should be set
only after the card has switched mode.

However, it is not unreasonable first to reduce the frequency to
the HS mode frequency, which should make the switch command and
subsequent CMD13 commands more reliable.

This patch does that.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Cc: <stable@vger.kernel.org> # 4.2+
Tested-by: NAlim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Currently mmc_select_hs200() uses __mmc_switch() which checks the
success of the switch to HS200 mode using CMD13 (SEND_STATUS).
The problem is that it does that using the timing settings of legacy
mode.  That is prone to error, not least because the timing parameters
for legacy mode are tighter than the timing parameters for HS200 mode.

In the case when CMD13 polling is used (i.e. not MMC_CAP_WAIT_WHILE_BUSY)
with the switch command, it must be assumed that using different modes on
the card and host must work.

However in the case when CMD13 polling is not used
(i.e. MMC_CAP_WAIT_WHILE_BUSY) mmc_select_hs200() can be made more
reliable by setting the host to the correct timing before sending CMD13.

This patch does that.

A complication is that the caller, mmc_select_timing(), will ignore a
switch error (indicated by -EBADMSG), assume the old mode is valid
and continue, so the old timing must be restored in that case.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Cc: <stable@vger.kernel.org> # 4.2+
Tested-by: NAlim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The commit converting pxamci to slot-gpio API inverted the logic of the
read-only gpio. Fix it by inverting the logic again.

Fixes: fd546ee6 ("mmc: pxamci: fix card detect with slot-gpio API")
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Cc: stable@vger.kernel.org
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

When card is running with DDR mode, dwmmc needs to set DDR_REG bit at
UHS_REG register.
Before this patch, dwmmc controller doesn't consider this.
If this patch is not applied, CRC or other error shoulds be occurred.
Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: NAlim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

According to DesignWare DoC file, CardThreshold bit should be
bit[27:16].
So it's correct to use (0xFFF << 16), not (0x1FFF << 16).
Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: NAlim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The "host->dms->ch" pointer is NULL here so we can't use it to print the
error message.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

An spi_driver does not need to set an owner, it will be populated by the
driver core.
Signed-off-by: NAndrew F. Davis <afd@ti.com>
Acked-by: NJonathan Cameron <jic23@kernel.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

The pwrseq_emmc driver does a eMMC card reset before a system reboot to
allow broken or limited ROM boot-loaders (that don't have an eMMC reset
logic) to be able to read the second stage from the eMMC.

But this has to be called before a system reboot handler and while most
of them use the priority 128, there are other restart handlers (such as
the syscon-reboot one) that use a higher priority. So, use the highest
priority to make sure that the eMMC hw is reset before a system reboot.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Tested-by: NMarkus Reichl <m.reichl@fivetechno.de>
Tested-by: NAnand Moon <linux.amoon@gmail.com>
Reviewed-by: NAlim Akhtar <alim.akhtar@samsung.com>
Tested-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

add HS400 mode and tune support
Signed-off-by: NChaotian Jing <chaotian.jing@mediatek.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The mmc_execute_tuning() has already prepared the opcode,
there is no need to prepare it again at mmc_send_tuning(),
and, there is a BUG of mmc_send_tuning() to determine the opcode
by bus width, assume eMMC was running at HS200, 4bit mode,
then the mmc_send_tuning() will overwrite the opcode from CMD21
to CMD19, then got error.

in addition, extend an argument of "cmd_error" to allow getting
if there was cmd error when tune response.
Signed-off-by: NChaotian Jing <chaotian.jing@mediatek.com>
[Ulf: Rebased patch]
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

add implement of ops->hw_reset() for eMMC
Signed-off-by: NChaotian Jing <chaotian.jing@mediatek.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Even if we only use one gpd, we need alloc 2 gpd and make
the gpd->next pointer to the second gpd, or may get gpd checksum
error, this was checked by hardware
Signed-off-by: NChaotian Jing <chaotian.jing@mediatek.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

use the ios->timing directly is better
It can reflect current timing and do settings by timing
Signed-off-by: NChaotian Jing <chaotian.jing@mediatek.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

cmd_ints_mask and data_ints_mask are constant value,
so make it to const
Signed-off-by: NChaotian Jing <chaotian.jing@mediatek.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Sometime only need set MMC_CAP_HW_RESET for one of MMC hosts,
So set it in device tree is better.
Signed-off-by: NChaotian Jing <chaotian.jing@mediatek.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Enable omap_hsmmc for Keystone 2 architecture which reuses the HSMMC
IP found on OMAP platforms.
Signed-off-by: NFranklin S Cooper Jr <fcooper@ti.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Add ACPI HIDs for Intel host controllers including one
supporting HS400.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Add PCI IDs for Intel host controllers
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

This patch add some macros for HCON register operations
to make code more readable.
Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

DesignWare MMC Controller can supports two types of DMA
mode: external dma and internal dma. We get a RK312x platform
integrated dw_mmc and ARM pl330 dma controller. This patch add
edmac ops to support these platforms. I've tested it on RK31xx
platform with edmac mode and RK3288 platform with idmac mode.
Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The eSDHC doesn't have a standard power control register, so when
writing this register in stack we should do nothing to avoid
incorrect operation.
Signed-off-by: NYangbo Lu <yangbo.lu@freescale.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

There's little sense in releasing the host on mmc_add_card() error
immediately after reclaiming  it, so reclaim the host  only in case
of success.
Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The driver depends on GOLDFISH but there isn't a build dependency
so it's a good idea to allow the driver to always be built when the
COMPILE_TEST option is enabled.

That way, the driver can be built with a config generated by make
allyesconfig and check if a patch would break the build.
Signed-off-by: NLuis de Bethencourt <luisbg@osg.samsung.com>
Reviewed-by: NJean Delvare <jdelvare@suse.de>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

This algorithm will try 1 degree increments, since there's no way to tell
what resolution the underlying phase code uses. As an added bonus, doing
many tunings yields better results since some tests are run more than once
(ex: if the underlying driver uses 45 degree increments, the tuning code
will try the same angle more than once).

It will then construct a list of good phase ranges (even ranges that cross
360/0), will pick the biggest range then it will set the sample_clk to the
middle of that range.

We do not touch ciu_drive (and by extension define default-drive-phase).
Drive phase is mostly used to define minimum hold times, while one could
write some code to determine what phase meets the minimum hold time (ex 10
degrees) this will not work with the current clock phase framework (which
floors angles, so we'll get 0 deg, and there's no way to know what
resolution the floors happen at). We assume that the default drive angles
set by the hardware are good enough.

If a device has device specific code (like exynos) then that will still
take precedence, otherwise this new code will execute. If the device wants
to tune, but has no sample_clk defined we'll return EIO with an error
message.
Signed-off-by: NAlexandru M Stan <amstan@chromium.org>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

We've introduced a new helper in the MMC core:
mmc_regulator_set_vqmmc().  Let's use this in dw_mmc.  Using this new
helper has some advantages:

1. We get the mmc_regulator_set_vqmmc() behavior of trying to match
   VQMMC and VMMC when the signal voltage is 3.3V.  This ensures max
   compatibility.

2. We get rid of a few more warnings when probing unsupported
   voltages.

3. We get rid of some non-dw_mmc specific code in dw_mmc.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

This adds logic to the MMC core to set VQMMC.  This is expected to be
called by MMC drivers like dw_mmc as part of (or instead of) their
start_signal_voltage_switch() callback.

A few notes:

* When setting the signal voltage to 3.3V we do our best to make VQMMC
  and VMMC match.  It's been reported that this makes some old cards
  happy since they were tested back in the day before UHS when VQMMC
  and VMMC were provided by the same regulator.  A nice side effect of
  this is that we don't end up on the hairy edge of VQMMC (2.7V),
  which some EEs claim is a little too close to the minimum for
  comfort.
  This is done in two steps. At first we try to find a VQMMC within
  a 0.3V tolerance of VMMC and if this is not supported by the
  supplying regulator we try to find a suitable voltage within the
  whole 2.7V-3.6V area of the spec.

* The two step approach is currently necessary, as the used
  regulator_set_voltage_triplet(min, target, max) uses a simple
  implementation that just tries two basic steps:
	regulator_set_voltage(target, max);
	regulator_set_voltage(min, target);
  So with only one step with 2.7-3.6V borders, if a suitable voltage
  is a bit below VMMC, we would directly get the lowest 2.7V
  which some boards (like Rockchips) don't like at all.

* When setting the signal voltage to 1.8V or 1.2V we aim for that
  specific voltage instead of picking the lowest one in the range.

* We very purposely don't print errors in mmc_regulator_set_vqmmc().
  There are cases where the MMC core will try several different
  voltages and we don't want to pollute the logs.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

We will shortly need the calculation of an ocr-bit to the actual
voltage in a second place too, so move it from mmc_regulator_set_ocr
to a common function mmc_ocrbitnum_to_vdd to make that possible.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

MMC_CLKGATE was once invented to save power by gating the bus clock at
request inactivity. At that time it served its purpose. The modern way to
deal with power saving for these scenarios, is by using runtime PM.

Nowadays, several host drivers have deployed runtime PM, but for those
that haven't and which still cares power saving at request inactivity,
it's certainly time to deploy runtime PM as it has been around for several
years now.

To simplify code to mmc core and thus decrease maintenance efforts, this
patch removes all code related to MMC_CLKGATE.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>

Signed-off-by: NYangbo Lu <yangbo.lu@freescale.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Freescale eSDHC driver now supports both little-endian and
big-endian mode eSDHC IPs for ARM and PPC. So, MMC_SDHCI_OF_ESDHC
option needs to be reconfigured.
Signed-off-by: NYangbo Lu <yangbo.lu@freescale.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>