During its probing the SDHI driver prints out the clock frequency, but
does it wrongly, always reporting 0Hz. Use the MMC host frequency value
to fix this issue.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Reviewed-by: NSimon Horman <horms+renesas@verge.net.au>
Signed-off-by: NChris Ball <cjb@laptop.org>

kfree on a null pointer is a no-op.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

kfree on a null pointer is a no-op.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Use devm_kzalloc, devm_gpio_request_one and devm_request_irq to make
cleanup path simpler.
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

The OLPC XO-1.75 laptop includes a SDHCI controller which is 1.8v
capable, and it truthfully reports so in its capabilities. This
alternate voltage is used for driving new "UHS-I" SD cards at their
full speed.

However, what the controller doesn't know is that the motherboard
physically doesn't have a 1.8v supply available, so attempting to
switch to the 1.8v level will result in a situation that cannot be
recovered from without physically replugging the SD card.

Add a device tree flag that can be used on systems like these,
and hook it up to the equivalent SDHCI quirk.
Signed-off-by: NDaniel Drake <dsd@laptop.org>
Reviewed-by: NPhilip Rakity <prakity@nvidia.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

The OLPC XO-1.75 laptop includes a SDHCI controller which is 1.8v
capable, and it truthfully reports so in its capabilities. This
alternate voltage is used for driving new "UHS-I" SD cards at their
full speed.

However, what the controller doesn't know is that the motherboard
physically doesn't have a 1.8v supply available.

Add a quirk so that systems such as this one can override disable
1.8v support, adding support for UHS-I cards (by running them at
3.3v).

This avoids a problem where the system would first try to run the
card at 1.8v, fail, and then not be able to fully reset the card
to retry at the normal 3.3v voltage.

This is more appropriate than using the MISSING_CAPS quirk, which
is intended for cases where the SDHCI controller is actually lying
about its capabilities, and would force us to somehow override both
caps words from another source.
Signed-off-by: NDaniel Drake <dsd@laptop.org>
Reviewed-by: NPhilip Rakity <prakity@nvidia.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Suspend methods provided by SDIO drivers are not supposed to be called by
the PM core.  Instead, when the SDIO core gets to suspend a device's
ancestor, it calls the device driver's suspend routine.  However, the PM
core executes suspend callback routines directly for device drivers whose
bus types don't provide suspend callbacks.  In consequece, because the
SDIO bus type doesn't provide a suspend callback, the SDIO drivers'
suspend routines will be executed by the PM core (which shouldn't
happen).

To prevent this from happening, add empty system suspend/resume callbacks
for the SDIO bus type.

An analogous change had been made already by commit (e841a7c6 mmc: sdio:
Use empty system suspend/resume callbacks at the bus level), but then it
was reverted inadvertently by commit (d8e2ac33 mmc: sdio: Fix PM_SLEEP
related build warnings) that attempted to fix build warnings introduced
by commit e841a7c6.
Reported-by: NNeilBrown <neilb@suse.de>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Add missing usb_put_dev on failure path in vub300_probe().

Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: NMarina Makienko <makienko@ispras.ru>
Signed-off-by: NChris Ball <cjb@laptop.org>

clk_{un}prepare is mandatory for platforms using common clock
framework. Because for SPEAr we don't do anything in clk_{un}prepare()
calls, just call them once in probe/remove.
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

SPEAr sdhci driver expects the clock to be set to 50 MHz for proper
functioning.  This patch sets clk to 50 MHz in probe.
Signed-off-by: NVipul Kumar Samar <vipulkumar.samar@st.com>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

This patch adds support for pin configuration using pinctrl subsystem
to the sdhci-s3c driver.
Signed-off-by: NTomasz Figa <t.figa@samsung.com>
Acked-by: NThomas Abraham <thomas.abraham@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

The set of GPIO pins used by sdhci-s3c driver varies between
configurations, such as card detect method, pinctrl availability, etc.
This overly complicates the code requesting and freeing GPIO pins, which
must check which pins are used, when freeing them.

This patch modifies the sdhci-s3c driver to use devm_gpio_request to
free requested pins automatically after unbinding the driver.
Signed-off-by: NTomasz Figa <t.figa@samsung.com>
Acked-by: NThomas Abraham <thomas.abraham@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

The IP versions older than 2.3 didn't support commands with busy
response which expect the TC bit set. But after the VVN2.3, eSDHC
IP has supported it.
Signed-off-by: NJerry Huang <Chang-Ming.Huang@freescale.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

The third argument for of_get_property() is a pointer, hence pass
NULL instead of 0.

Fixes the following sparse warning:
sdhci-s3c.c:452:48: warning: Using plain integer as NULL pointer
sdhci-s3c.c:457:52: warning: Using plain integer as NULL pointer
Signed-off-by: NTushar Behera <tushar.behera@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Define the most frequently used bitmasks of the Interrupt Enable /
Interrupt Status register with consistent naming ( with _EN suffix).

Use meaningful concatenation of bitfields for INT_EN_MASK, which shows
which interrupts are enabled by default.  No functional changes.
Signed-off-by: NVenkatraman S <svenkatr@ti.com>
Acked-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Fatal errors for the driver are not reported when just error debug
is enabled. Convert selected dev_dbg to dev_err for accurate error
reporting.
Reported-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NVenkatraman S <svenkatr@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

prepare() is supposed to prevent new children from being registered.
On the MMC subsystem, children (new cards) registration starts with
the card detect IRQ.

Move card detect IRQ disabling to prepare() so that no new cards
will be registered while we're trying to suspend.

Likewise, move card detect IRQ enabling to complete() so we only
try to register new children after our MMC IP is back up.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NVenkatraman S <svenkatr@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

HSMMC IP on AM33xx need a special setting to handle High-speed cards.
Other platforms like TI81xx, OMAP4 may need this as-well. This depends
on the HSMMC IP timing closure done for the high speed cards.

From AM335x TRM (SPRUH73F - 18.3.12 Output Signals Generation):

The MMC/SD/SDIO output signals can be driven on either falling edge or
rising edge depending on the SD_HCTL[2] HSPE bit. This feature allows
to reach better timing performance, and thus to increase data transfer
frequency.

There are few pre-requisites for enabling the HSPE bit
- Controller should support High-Speed-Enable Bit and
- Controller should not be using DDR Mode and
- Controller should advertise that it supports High Speed in
  capabilities register and
- MMC/SD clock coming out of controller > 25MHz
Signed-off-by: NHebbar, Gururaja <gururaja.hebbar@ti.com>
Signed-off-by: NVenkatraman S <svenkatr@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Update error code to cmd->error for commands with response_busy and no data.
Signed-off-by: NBalaji T K <balajitk@ti.com>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NVenkatraman S <svenkatr@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Avoid soft reset of command internal state machine on data errors.
Signed-off-by: NBalaji T K <balajitk@ti.com>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NVenkatraman S <svenkatr@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

ae4bf788 ("mmc: omap_hsmmc: consolidate error report handling of HSMMC
IRQ") sets both end_cmd and end_trans to 1.

Setting end_cmd to 1 for Data Timeout/CRC leads to NULL pointer dereference of
host->cmd as the command complete has previously been handled.
Set end_cmd only in case of command Timeout/CRC.

Moreover host->cmd->error should not be updated on data error case, only
host->data->error needs to be updated.
Signed-off-by: NBalaji T K <balajitk@ti.com>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NVenkatraman S <svenkatr@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Add dt-based retrieval of host sdio pm capabilities. Based on
the dt based discovery do a bus init in the resume function.
Signed-off-by: NOlof Johansson <olofj@chromium.org>
Signed-off-by: NAbhilash Kesavan <a.kesavan@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Add support for optional pm capabilities such as MMC_PM_KEEP_POWER
and MMC_PM_WAKE_SDIO_IRQ.
Signed-off-by: NAbhilash Kesavan <a.kesavan@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Add documentation for pm capabilties such as MMC_PM_KEEP_POWER
and MMC_PM_WAKE_SDIO_IRQ.
Signed-off-by: NAbhilash Kesavan <a.kesavan@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Fix typo in the synopsis dwmmc controller dt binding filename.
Signed-off-by: NAbhilash Kesavan <a.kesavan@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Acked-by: NZhangfei Gao <zhangfei.gao@marvell.com>
Signed-off-by: NKevin Liu <kliu5@marvell.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

For regulator vmmc/vmmcq, use voltage range as below
3.3v/3.0v: (2.7v, 3.6v)
1.8v: (1.7v, 1.95v)
Original code uses the precise value which may fail in regulator
driver if it does NOT support the precise voltage.
Signed-off-by: NJialing Fu <jlfu@marvell.com>
Signed-off-by: NKevin Liu <kliu5@marvell.com>
Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

This patch adds support for the SD/MMC host controller found
on Wondermedia 8xxx series SoCs, currently supported under
arm/arch-vt8500.

A binding document is also included, based on mmc.txt with
additional properties.
Signed-off-by: NTony Prisk <linux@prisktech.co.nz>
Signed-off-by: NChris Ball <cjb@laptop.org>

RPMB partition is accessing though /dev/block/mmcXrpmb device
User callers can read and write entire data frame(s) as defined
by JEDEC Standard JESD84-A441, using standard IOCTL interface.
Signed-off-by: NAlex Macro <alex.macro@stericsson.com>
Signed-off-by: NLoic Pallardy <loic.pallardy@stericsson.com>
Reviewed-by: NNamjae Jeon <linkinjeon@gmail.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NKrishna Konda <kkonda@codeaurora.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Provide support for automatically sending Set Block Count
(CMD23) messages. Used at least for RPMB support.
Signed-off-by: NAlex Macro <alex.macro@stericsson.com>
Signed-off-by: NLoic Pallardy <loic.pallardy@stericsson.com>
Reviewed-by: NNamjae Jeon <linkinjeon@gmail.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NJohan Rudholm <johan.rudholm@stericsson.com>
Acked-by: NKrishna Konda <kkonda@codeaurora.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Extend current sysfs access to ext_csd rpmb parameters (RPMB partition
size) and rel_sector information.
Signed-off-by: NLoic Pallardy <loic.pallardy@stericsson.com>
Reviewed-by: NNamjae Jeon <linkinjeon@gmail.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NJohan Rudholm <johan.rudholm@stericsson.com>
Acked-by: NKrishna Konda <kkonda@codeaurora.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Do not scan rpmb partitions for "soft" partitions, since the rpmb
partition contains protected data. Silences the following message
during boot:

 mmcblkXRPMB: unknown partition table
Signed-off-by: NJohan Rudholm <johan.rudholm@stericsson.com>
Reviewed-by: NNamjae Jeon <linkinjeon@gmail.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NKrishna Konda <kkonda@codeaurora.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Following JEDEC standard, if the mmc supports RPMB partition,
a new interface is created and exposed via /dev/block.
Users will be able to access RPMB partition using standard
mmc IOCTL commands.
Signed-off-by: NAlex Macro <alex.macro@stericsson.com>
Signed-off-by: NLoic Pallardy <loic.pallardy@stericsson.com>
Reviewed-by: NNamjae Jeon <linkinjeon@gmail.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NJohan Rudholm <johan.rudholm@stericsson.com>
Acked-by: NKrishna Konda <kkonda@codeaurora.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Both of MMC_TIMING_LEGACY and MMC_TIMING_UHS_SDR12 are defined
to 0. And ios->timing is set to MMC_TIMING_LEGACY during power up.
But set_ios can't distinguish these two timing if host support
spec 3.0. Just adjust timing values to be different can resolve
this issue without any other impact.
Reviewed-by: NGirish K S <girish.shivananjappa@linaro.org>
Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NKevin Liu <kliu5@marvell.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Enable the quirk SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN since
SD_CAPABILITIES_1[15:8](BASE_FREQ) can't get correct base clock value.
It returns a fixed pre-set value like 200 on some sdhci-pxav3 based
platforms like MMP3 while return 0 on the other sdhci-pxav3 based
platforms.  So we enable the quirk and get the base clock via function
get_max_clock. Also add get_max_clock.
Reported-by: NPhilip Rakity <prakity@marvell.com>
Reviewed-by: NPhilip Rakity <prakity@Marvell.com>
Acked-by: NZhangfei Gao <zhangfei.gao@marvell.com>
Signed-off-by: NKevin Liu <kliu5@marvell.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

There are discrepancies with regards to how MMC capabilities
are carried throughout the subsystem. Let's standardise them
to eliminate any confusion.
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

All MXS users have been converted to device tree and the board files have
been removed.

No need to keep platform data in the driver.

Also move bus_width declaration in the beggining of mxs_mmc_probe() to
avoid: 'warning: ISO C90 forbids mixed declarations and code'.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Acked-by: NShawn Guo <shawn.guo@linaro.org>
Acked-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NChris Ball <cjb@laptop.org>

Before this patch, we always used only single sg entry for SDIO transfer.
This patch switches to using multiple sg entries. In the case of dwmci,
it supports only up to 4KB size per single sg entry. So if we want to
transfer more than 4KB, we should send more than 1 command.

When we tested before applying this patch, it took around 335 us for
5K(5120) bytes transfer with dwmci controller. After applying this patch,
it takes 242 us for 5K bytes. So this patch makes around 38% performance
improvement for 5K bytes transfer. If the transfer size is bigger, then
the performance improvement ratio will be increased.
Signed-off-by: NKyoungil Kim <ki0351.kim@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

There are infinite loops in the mmc code that can be caused by bad
hardware.  The code will loop forever if the device never comes back
from program mode, R1_STATE_PRG, and it is not ready for data,
R1_READY_FOR_DATA.

A long timeout is added to prevent the code from looping forever.
The timeout will occur if the device never comes back from program
state or the device never becomes ready for data.

It's not clear whether the timeout will do more than log a pr_err()
and then start a fresh hang all over again.  We may need to extend
this patch later to perform some kind of reset of the device (is
that possible?) or rejection of new I/O to the device.
Signed-off-by: NTrey Ramsay <tramsay@linux.vnet.ibm.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

The patch "dw_mmc: fix multiple drv_data NULL dereferences" has
unfortunately clashed with my "mmc: dw_mmc: constify dw_mci_idmac_ops
in exynos back-end" patch, causing new warnings to appear.

This should hopefully fix the issue for good.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NChris Ball <cjb@laptop.org>