Cortex-A9 SoCs from Rockchip use a slightly modified variant of dw_mmc
controllers that seems to require the SDMMC_CMD_USE_HOLD_REG bit to
always be set.

There also seem to be no other modifications (additional register etc)
present, so to keep the footprint low, add this small variant to the
pltfm driver.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Acked-by: NSeungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

In a subsquent patch probe will need to do some handling of data from
the dt match table. So to prevent the need for forward declarations,
move probe and remove below the match table.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Acked-by: NSeungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

dw_mci_pltfm_remove gets exported and used by dw_mmc-exynos, so should
not be static.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
Acked-by: NSeungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Add support for eMMC hardware reset for HID 80860F14.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Add support for eMMC hardware reset for BYT eMMC.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Add platform specific functionality for the DW SD/MMC driver for
SoCFPGA. Move SDMMC_CMD_USE_HOLD_REG to dw_mmc.h so other platforms
can use this define.
Signed-off-by: NDinh Nguyen <dinguyen@altera.com>
Reviewed-by: NPavel Machek <pavel@denx.de>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
Acked-by: NOlof Johansson <olof@lixom.net>
Acked-by: Seungwon Jeon <tgih.jun@samsung.com
Signed-off-by: NChris Ball <cjb@laptop.org>

Although the HC supports HS200 (eMMC) the caps2 are always zero; this
means there's no way to use the super speed mode (when init the card).

If the HC support SDR104, for SD3.0, so it also supports HS200 for eMMC
and this patch just sets the MMC_CAP2_HS200 in the host caps2 field.
Reported-by: NYoussef Triki <youssef.triki@st.com>
Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
Reviewed-by: NPhilip Rakity <prakity@nvidia.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Commit bb691ae4 breaks boot on OLPC
XO-4, it hangs somewhere inside sdhci_add_host.

When pm_runtime_set_autosuspend_delay() was being called, the device's
usage counter was 0, causing the PM layer to runtime-suspend the
device.  We then went on to call sdhci_add_host() on a suspended
device, which hung.

Fix this by making the driver consistent with the omap_hsmmc driver,
both in terms of runtime PM initialization and error handling. Now
the device is not runtime-suspended until we exit the probe routine.
Signed-off-by: NDaniel Drake <dsd@laptop.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

The DT-binding for MMC_CAP2_FULL_PWR_CYCLE, is used to indicate whether
it is possible to perform a full power cycle of the card.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

MMC_CAP2_FULL_PWR_CYCLE shall be set by host drivers which are able to
do a complete power cycle of the card. In the eMMC case that includes
both vcc and vccq.

This CAP is providing the protocol layer with important information,
needed to take optimized decisions during card initialization and in
the suspend/resume sequence.

MMC_CAP2_POWEROFF_NOTIFY is replaced by MMC_CAP2_FULL_PWR_CYCLE, since
it makes sense to use a wider scope for it.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

In suspend mode it is important to save power. If the host is able to
cut buth vcc and vccq, the MMC_CAP2_POWEROFF_NOTIFY shall be set. It
will mean the card will be completely powered down at suspend and the
power off notification cmd will be sent prior power down.

It seems common not being able to cut both vcc and vccq for a host. In
this situation we issue the sleep cmd in favor of the power off
notification cmd, to save more power.

While maintainng the above policy, we also want to make use of the
power off notification in the shutdown sequence, even in the case were
the host has not set MMC_CAP2_POWEROFF_NOTIFY, since we know vcc and
vccq will regardless be cut.

We accomplish this by always enabling the power off notification byte
in the EXT_CSD and issue the power off notification when either
MMC_CAP2_POWEROFF_NOTIFY is set or we are executing a shutdown.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

The shutdown sequence of an (e)MMC is very similar to a suspend. We
re-use the suspend function and tell it we are not in suspend context.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Depending on the context of the operation while powering down the card,
either POWER_OFF_NOTIFY_SHORT or POWER_OFF_NOTIFY_LONG will be used. In
suspend context a short timeout is preferred while a long timeout would
be acceptable in a shutdown/hibernation context.

We add a new parameter to the mmc_suspend function so we can provide an
indication of what notification type to use.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

For the SD .shutdown callback we re-use the SD suspend function since
it performs the relevant actions.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

By adding an optional .shutdown callback to the bus_ops struct we
provide the possibility to let each bus type handle it's shutdown
requirements.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Considering shutdown of the card, the responsibility to initate this
sequence shall be driven from the mmc_bus.

This patch enables the mmc_bus to handle this sequence properly. A new
.shutdown callback is added in the mmc_driver struct which is used to
shutdown the blk device.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

The host should be responsible to suspend|resume the host and not the
card. This patch changes this behaviour, by moving the responsiblity
to the mmc bus instead which already holds the card device.

The exported functions mmc_suspend|resume_host are now to be considered
as depcrecated. Once all host drivers moves away from using them, we
can remove them. As of now, a successful error code is always returned.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

By moving code from the mmc_suspend|resume_host down into each
.suspend|resume bus_ops callback, we get a more flexible solution.

Some nice side effects are that we get a better understanding of each
bus_ops suspend|resume sequence and the common code don't have to take
care of specific corner cases, especially for the SDIO case.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

This patch moves the validation for all the suspend prerequisites to be
done at SUSPEND_PREPARE notification. Previously in the SDIO case parts
of the validation was done from mmc_suspend_host.

This patch invents a new pre_suspend bus_ops callback and implements it
for SDIO. Returning an error code from it, will mean at SUSPEND_PREPARE
notification, the card will be removed before proceeding with the
suspend sequence.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

For every bus_ops type the .remove callback always exist, thus there
are no need to check the existence of it, before we decide to call it.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Use managed resources for the mmio memory region and the clock.
Makes the code a bit shorter.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NChris Ball <cjb@laptop.org>

Use the slot-gpio helpers to handle the write protect and card detect
GPIO pins instead of re-implementing the same functionality in the driver.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NChris Ball <cjb@laptop.org>

It's a bit shorter than open-conding it. While we are at it also make
jz4740_mmc_pm_ops static.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NChris Ball <cjb@laptop.org>

For no reason, the code handling write errors was implemented while
the code handling read errors was missing.
Signed-off-by: NPaul Cercueil <paul@crapouillou.net>
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NChris Ball <cjb@laptop.org>

Signed-off-by: NPaul Cercueil <paul@crapouillou.net>
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NChris Ball <cjb@laptop.org>

The following error randomly appears on an imx6q board where gpio is
used to implement card-detection when mounting EXT4 rootfs during boot.

mmc1: Card removed during transfer!
mmc1: Resetting controller.
mmcblk0: unknown error -123 sending read/write command, card status 0x900
end_request: I/O error, dev mmcblk0, sector 106744
EXT4-fs error (device mmcblk0p2): ext4_find_entry:1312: inode #5011: comm swapper/0: reading directory lblock 0

It turns out that the error message comes from the card removal check
in function sdhci_card_event().  While we have a well implemented
function sdhci_do_get_cd() handling all the possible cases of
CD, the current code only checks controller internal CD case.  That
causes problem for other CD cases like gpio on above imx6q board.

Improve the check by using sdhci_do_get_cd() to cover all possible CD
cases, so that above error on the imx6q board gets fixed.
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

As of now we rely on code outside of the driver to set the ciu clock
frequency.  There's no reason to do that.  Add support for setting up
the clock in the driver during probe.
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

It is possible to specify a regulator that should be turned on when
dw_mmc is probed.  At the moment dw_mmc will fail to use the regulator
properly if the regulator probes after dw_mmc.  Fix this problem by
honoring EPROBE_DEFER.

At the same time move the regulator code out of the slot init code.
We only specify one regulator for the whole device and other parts of
the code (like suspend/resume) assume that the regulator has only been
enabled once.
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

In order to make it possible to reduce the SD bus frequency,
parse the optional "max-frequency" attribute as documented in
devicetree/bindings/mmc/mmc.txt
Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
Acked-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

The SDCLK is divided down from the host controller clock. Host
controller clock may be different from the maximum SDCLK, so
get it from the platform, instead of just using the max SDCLK.
Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
Acked-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Inside the routine mmc_blk_ioctl_cmd() the sanitize command is
identified according to the value of bits 16-23 of the argument.

but what happens if a different command is sent, and only by
chance, bits 16-23 contain the value of SANITIZE command ?
In that case a SANITIZE command will be falsely identified.
In order to prevent such a case, the condition is expanded and
now it also checks the opcode itself, and verifies that it is an
MMC_SWITCH opcode.
Signed-off-by: NYaniv Gardi <ygardi@codeaurora.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Header file not needed anymore as we have removed the calls to
cpu_is_xxx() macro.
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: NLudovic Desroches <ludovic.desroches@atmel.com>
Acked-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

The PCI driver is getting simplier and tidier with pcim_* and devm_*
functions in use.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NSeungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

In few places usage of ret variable is not needed.
This patch simplifies those pieces of code.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NSeungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

devm_ioremap_resource does sanity checks on the given resource.
No need to duplicate this in the driver.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NSeungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

We had a multi-partition SD-Card with two ext2 file systems. The partition
table was getting overwritten by a race between the card removal and
the unmount of the 2nd ext2 partition.

What was observed:
1. Suspend/resume would call to remove the device. The clearing
   of the device information is done asynchronously.
2. A request is made to unmount the file system (this is called
   after the removal has started).
3. The remapping table was cleared by the asynchronous part of
   the device removal.
4. A write request to the super block (block 0 of the partition)
   was sent down and instead of being remapped to the partition
   offset, it was remapped to block 0 of the device which is where
   the partition table is located.
5. Write was queued and written resulting in the overwriting
   of the partition table with the ext2 super block.
6. The mmc_queue is cleaned up.

The mmc card device driver used to access SD cards, was calling del_gendisk
before calling mmc_cleanup-queue. The comment in the mmc_blk_remove_req
code indicated that it expected del_gendisk to block all further requests
from being queued but it doesn't. The mmc driver uses the presences of the
mmc_queue to determine if the request should be queued.

The fix was to clean up the mmc_queue before the rest of the
the delete partition code is called.

This prevents the overwriting of the partition table.

However, the umount gets an error trying to write the super block.
The umount should be issued before the device is removed but that
is not always possible. The umount is still needed to cleanup other
data structures.

Addresses the problem described in http://crbug.com/240815Signed-off-by: NPaul Taysom <taysom@chromium.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Patch "mmc: sdhci: Add size for caller in init+register" changed the
interface for sdhci_pltfm_init, while patch "mmc: sdhci-sirf: add mmc
host sdhci-pltfm based driver for SiRF SoCs" added a new driver
with the old interface.

This changes the sirf driver to use the new interface, avoiding
one warning, and simplifying the init sequence. Since we're here
already, this also adds an error path for failed clk_prepare_enable.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NChristian Daudt <csd@broadcom.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_{get,set}_drvdata() with &pdev->dev,
so we can directly pass a struct platform_device.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Acked-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Signed-off-by: NChris Ball <cjb@laptop.org>

Fix to return a negative error code instead of 0 when we cannot get
IRQ source by platform_get_irq(), as done elsewhere in this function.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Acked-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NChris Ball <cjb@laptop.org>

Fix to return a negative error code in the gpio_to_irq() error
handling case instead of 0, as done elsewhere in this function.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Reviewed-by: NJingoo Han <jg1.han@samsung.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NChris Ball <cjb@laptop.org>