sdhci-pxav3 host controller used SDCLK for data timeout.
Signed-off-by: NKevin Liu <kliu5@marvell.com>
Acked-by: NHaojian Zhuang <haojian.zhuang@gmail.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

1. seperate device tree parsing from platform data handling which
   can make further work easy when platform data can be removed.

2. add calling mmc_of_parse which can parse more of property and
   pxav3_get_mmc_pdata can be shrinked a lot.
Signed-off-by: NKevin Liu <kliu5@marvell.com>
Acked-by: NHaojian Zhuang <haojian.zhuang@gmail.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Flag PXA_FLAG_CARD_PERMANENT is set in sdhci_pxa_platdata flags to
indicate that the card is always wired to host, like on-chip emmc,
which is permanently present and don't need detection.

So only MMC_CAP_NONREMOVABLE should be set for this case. But current
code also sets SDHCI_QUIRK_BROKEN_CARD_DETECTION, which doesn't make
sense.
Signed-off-by: NKevin Liu <kliu5@marvell.com>
Acked-by: NHaojian Zhuang <haojian.zhuang@gmail.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

sdhci_pltfm_init can set host->ops and host->quirks if sdhci_pltfm_data
is transfered as arguments. Then no need to set them manually in
sdhci_pxav3_probe.
Signed-off-by: NKevin Liu <kliu5@marvell.com>
Acked-by: NHaojian Zhuang <haojian.zhuang@gmail.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

mci_writew causes a failure of fifo access for 64-bit.
mci_writeq is correct.
Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

The mvsdio driver was already using some dev_*() functions to print
some messages, but still using pr_*() functions for some others. This
patch converts all messages to use dev_*() functions.

Many of the pr_*() function calls were printing the output of
mmc_hostname() to preprend the message with an identifier for the
device. Since the dev_*() functions do that automatically, this patch
also gets rid of those string prefixes.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Ralph Droms <rdroms@gmail.com> reported that 3.9-rc was breaking the
SDIO interface on his Sheevaplug platform, and that the recent changes
to the mvsdio driver are responsible for this breakage. Precisely, the
regression has been introduced by 07728b77 (mmc: mvsdio: use
slot-gpio for card detect gpio).

After investigation, is turns out that the Sheevaplug does not have
any "card detect" GPIO, and the Sheevaplug has not been converted to
the Device Tree. Therefore, the Sheevaplug board code does not define
a value for the .gpio_card_detect field of the mvsdio_platform_data
structure, which means that its value is 0. Unfortunately,
gpio_is_valid() considers 0 as a valid GPIO, and therefore calls
mmc_gpio_request_cd(), which fails and makes the entire probing of the
driver fail.

In fact, in the previous mvsdio code, before the Device Tree binding
was introduced, 0 was not considered as a valid GPIO. Therefore, this
fix revert back to this behavior in the non-DT case, by setting the
gpio_card_detect and gpio_write_protect local variables to -EINVAL
when the corresponding fields of the mvsdio_platform_data structure
are set to zero (i.e, left undefined). Of course, it prevents to use
GPIO 0 as a card detect or write protect GPIO, but it was a defiency
of the previous non-DT code, and the fix moving forward is to convert
platforms to the Device Tree.

The problem has been reproduced successfully on the Kirkwood-based
Marvell DB-88F6281-BP Development Board (that doesn't use the Device
Tree) and the fix has proven to work properly, after of course
removing the gpio_card_detect field of the mvsdio_platform_data
instance for this board.
Reported-by: NRalph Droms <rdroms@gmail.com>
Tested-by: NRalph Droms <rdroms@gmail.com>
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

This patch adds the new driver for CSR SiRF SoCs:

SiRFprimaII: unicore ARM Cortex-A9
SiRFatlas6: unicore ARM Cortex-A9
SiRFmarco: dual core ARM Cortex-A9 SMP
Signed-off-by: NBarry Song <Baohua.Song@csr.com>
Signed-off-by: NBin Shi <Bin.Shi@csr.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NChris Ball <cjb@laptop.org>

For normal request mmc_blk_issue_rq is called twice with asynchronous
transfer(cur and prev). Host's claim and release can be done in each
mmc_blk_issue_rq. However, Special request is currently excluded in
asynchronous transfer. After special request is finished, if there is
no new request, mmc_release_host won't be called in mmc_blk_issue_rq.
The problem is founded during mmc_suspend.

[<c0541124>] (__schedule+0x0/0x78c) from [<c05419e8>] (schedule+0x38/0x78)
[<c05419b0>] (schedule+0x0/0x78) from [<c03a843c>] (__mmc_claim_host+0xac/0x1b4)
[<c03a8390>] (__mmc_claim_host+0x0/0x1b4) from [<c03ac98c>] (mmc_suspend+0x28/0x9c)
[<c03ac964>] (mmc_suspend+0x0/0x9c) from [<c03aad24>] (mmc_suspend_host+0xb4/0x194)
...
Reported-by: NJohan Rudholm <jrudholm@gmail.com>
Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
Tested-by: NJohan Rudholm <johan.rudholm@stericsson.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

MMC hosts are added asynchronously. We need to wait until detect returns to
avoid failed root filesystem mounts.

VFS: Cannot open root device "mmcblk0p1" or unknown-block(0,0): error -6
Please append a correct "root=" boot option; here are the available partitions:
mmc0: host does not support reading read-only switch. assuming write-enable.
1f00             256 mtdblock0  (driver?)
1f01             256 mtdblock1  (driver?)
1f02            2560 mtdblock2 mmc0: new SDHC card at address b368
 (driver?)
1f03           29696 mtdblock3  (driver?)
1f04           16384 mtdblock4 mmcblk0: mmc0:b368 USD   3.72 GiB
 (driver?)
 mmcblk0: p1
b300         3910656 mmcblk0  driver: mmcblk
  b301         3906560 mmcblk0p1 00000000-01
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Signed-off-by: NSergey Yanovich <ynvich@gmail.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Basically all drivers can have sdhci_ops struct const, but almost none do.
This patch constifies all sdhci_ops struct declarations where possible.

The patch was auto-generated with the following coccinelle semantic patch:

// <smpl>
@r1@
identifier ops;
identifier fld;
@@
ops.fld = ...;

@disable optional_qualifier@
identifier ops != r1.ops;
@@
static
+const
struct sdhci_ops ops = { ... };
// </smpl>
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

All users of the sdhci_ops struct in the sdhci core already treat it as
const.  The sdhci-pltfm code itself never actually looks at the ops field
of the sdhci_pltfm_data struct and merely passes it on to the sdhci core,
so make we can make it const in the sdhci_pltfm_data struct as well.
This allows us to declare sdhci_ops structs as const in drivers using
the sdhci-pltfm helper code.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

The sdhci_pltfm_data struct is never modified within the sdhci_pltfm
module. So make the pdata parameter to sdhci_pltfm_init and
sdhci_pltfm_register const.  This allows drivers to declare their
sdhci_pltfm_data struct as const.

This patch also makes the sdhci_pltfm_data declarations const where
possible.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Fix regression introduced by commit 796211b7 ("mmc: atmel-mci: add
pdc support and runtime capabilities detection") which removed the need
for CONFIG_MMC_ATMELMCI_DMA but kept the Kconfig-entry as well as the
compile guards around dma_release_channel() in remove(). Consequently,
DMA is always enabled (if supported), but the DMA-channel is not
released on module unload unless the DMA-config option is selected.

Remove the no longer used CONFIG_MMC_ATMELMCI_DMA option completely.
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Acked-by: NLudovic Desroches <ludovic.desroches@atmel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

This patch adds the compatible string for MSHC controller of Exynos4412.
And exynos5250_dwmmc_caps is renamed to exynos_dwmmc_caps, since it has the
capabilities of common features supported by Exynos4 and Exynos5.
Signed-off-by: NDongjin Kim <tobetter@gmail.com>
Acked-by: NSeungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

'dw_mci_exynos_match' is always compiled in. Hence of_match_ptr
is not required.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
Acked-by: NSeungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Use resource_size() instead of explicit calculation. This was found via
make coccicheck.
Signed-off-by: NSilviu-Mihai Popescu <silviupopescu1990@gmail.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Commit f9c2a0dc
"mmc: dw_mmc: Fix PIO mode with support of highmem" introduced
a regression since v3.2 making the mmc_test hang on test #13
with a "Data starvation by host timeout" interrupt.

This is because, sg_mapping_iter is used to iterate through the
data which spans on multiple pages. The problem is detected on
unaligned data submission where the code previously checked for
!(sg_next(host->sg)) which is true because we only have a single
scatter/gather list which then expands to multiple pages.
Therefore, the driver incorrectly assumed that this was the last
list item and submitted unaligned data to the mmc device. This
overflowed the FIFO on the device before all the data were written
to it. The code was fixed to only submit unaligned data when we are
handling the last sg_miter item by checking whether we reached
the desired data length or not.

The patch was tested against mmc_test and all the tests passed.
Signed-off-by: NMarkos Chandras <markos.chandras@imgtec.com>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
Acked-by: NSeungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Previously, it was possible to add either 0 bytes or add nbytes
twice if we broke out of the outer loop and then carry on to the
"done" label. This is now fixed by adding the transferred bytes
right after the pull/pop operation
Signed-off-by: NMarkos Chandras <markos.chandras@imgtec.com>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
Acked-by: NSeungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

There is no reason to loop when handling an interrupt. The "if" clauses
will handle all of them sequentially. This also eliminates the extra loop
we used to take with no pending interrupts and we ended up breaking out
of the while loop.
Signed-off-by: NMarkos Chandras <markos.chandras@imgtec.com>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
Acked-by: NSeungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

host->data_offset is initialised at the end of the probe function
depending on the VERID register, and is used for PIO operations. Move
this initialisation earlier, before IRQs or slots are initialised, to be
sure that PIO won't occur prior to host->data_offset being initialised.
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
Acked-by: NSeungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Call the setpower platform callback in response to set_ios with
ios->power_mode == MMC_POWER_UP or MMC_POWER_OFF, instead of from the
card detect work function.

This appears to fix a problem I have where a card stuck in a funny state
doesn't get properly cleared by the power being turned off, presumably
due to lack of power sequencing. This resulted in the following log
messages after boot:

mmc0: error -110 whilst initialising SD card
mmc_host mmc0: Bus speed (slot 0) = 99840000Hz (slot req 300000Hz, actual 298922HZ div = 167)
mmc0: error -110 whilst initialising SD card
mmc_host mmc0: Bus speed (slot 0) = 99840000Hz (slot req 200000Hz, actual 199680HZ div = 250)
mmc0: error -110 whilst initialising SD card
mmc_host mmc0: Bus speed (slot 0) = 99840000Hz (slot req 195765Hz, actual 195764HZ div = 255)
mmc0: error -110 whilst initialising SD card
mmc_host mmc0: Bus speed (slot 0) = 99840000Hz (slot req 400000Hz, actual 399360HZ div = 125)
mmc0: error -110 whilst initialising SD card
mmc_host mmc0: Bus speed (slot 0) = 99840000Hz (slot req 300000Hz, actual 298922HZ div = 167)
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Acked-by: NSeungwon Jeon <tgih.jun@samsung.com>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Fixes:
/git/arm-soc/drivers/mmc/host/sdhci.c: In function 'sdhci_add_host':
/git/arm-soc/drivers/mmc/host/sdhci.c:2910:19: warning: ignoring
return value of 'regulator_enable', declared with attribute
warn_unused_result [-Wunused-result]
Reported-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NChris Ball <cjb@laptop.org>

Used resource_size function instead of explicit computation.
Patch found using coccinelle.
Signed-off-by: NAlexandru Gheorghiu <gheorghiuandru@gmail.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

The variable 'mmc' is initialized but never used, so remove it.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Acked-by: NTony Prisk <linux@prisktech.co.nz>
Signed-off-by: NChris Ball <cjb@laptop.org>

This patch fixes timeout problems on t4240's sdhci controller:

	mmc0: Too large timeout requested for CMD25!
	mmc0: Too large timeout requested for CMD25!
	mmc0: Too large timeout requested for CMD25!
Signed-off-by: NChunhe Lan <Chunhe.Lan@freescale.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

For some Realtek card readers, the power up sequence can only be executed
when power has been turned off fully.

So the rtsx host should not start power up sequence again when set_ios
been called if the power has been turned on.
Signed-off-by: NWei WANG <wei_wang@realsil.com.cn>
Signed-off-by: NChris Ball <cjb@laptop.org>

With device core now able to setup the default pin configuration,
the call to devm_pinctrl_get_select_default can be removed. And
the pin configuration code based on the deprecated Samsung specific
gpio bindings is also removed.
Signed-off-by: NThomas Abraham <thomas.abraham@linaro.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

This patch uses module_platform_driver_probe() macro which makes
the code smaller and simpler.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

This patch uses module_platform_driver_probe() macro which makes
the code smaller and simpler.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

ACPI spec 5 defined the _ADR encoding for sdio bus as:
High word - slot number (0 based)
Low word  - function number

This patch adds support for binding sdio function device with acpi node,
and if successful, involve acpi into its power management.
Signed-off-by: NAaron Lu <aaron.lu@intel.com>
Reviewed-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

1. mmc_rescan will call get_cd to know whether the card is present
before mmc_rescan_try_freq to avoid useless trials during
card removal or start host is called when card is not present.

2. get_cd needs to be checked to resolve slow card removal issue.
Signed-off-by: NKevin Liu <kliu5@marvell.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Function _mmc_detect_card_removed will be called to know whether
the card is still present when host->bus_ops->detect is called.
In current code, the return value of this function generally only
depend on the result of sending cmd13 to card, which may not safe
for card with detection support like slot gpio detection.
Because the communication status between host and card may out of
sync with the detect status if remove the card slowly or hands shake
during the process. The direct reason is the async between card
detect switch and card/slot pad contaction in hardware, which is
defined by spec.

The spec define card insert/remove sequence as below (both standard size
SD card and MicroSD card have the same sequence):
"Part 1 Standard Size SD Card Mechanical Addendum Ver4.00 Final,
Appendix C: Card Detection Switch" (Take normally open type as example)
a)SD card insertion sequence:
  The card detection switch should be turned on after all SD card
  contact pads are connected to the host connector contact pads.
b)SD removal sequence:
  The card detection switch should be turned off when the SD card
  is just going to be removed and before any SD card contact pad is
  disconnected from the host connector contact pad.

Below is the sequence when this issue occur (Take slot gpio detection
as example and remove the card slowly during the process):
1. gpio level changed and card detect interrupt triggered.
2. mmc_rescan was launched.
3. the card pads were still contacted with the slot pads because of slow
   removal. So _mmc_detect_card_removed and mmc_rescan think card was
   still present (cmd13 succeed).
4. card pads were discontacted from the card slot pads.
So the card was actually removed finally but the card removal event
has been missed by system.
The interval length between step 1 and step 4 depends on the
card removal speed. If it's longer than the detect work schedule
delay which is 200ms, this issue will likely happen.

This patch add the card detect status check in function
_mmc_detect_card_removed if cmd13 check succeed and host->ops->get_cd
provided. If get_cd detect no card present then schedule another detect
work 200ms later.
Signed-off-by: NKevin Liu <kliu5@marvell.com>
Tested-by: NJohan Rudholm <johan.rudholm@stericsson.com>
Reviewed-by: NPhilip Rakity <prakity@nvidia.com>
Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

The JEDEC MMC v4 spec defines a new PRV value in place of the original
fwrev and hwrev specified in v1. We can expose this in the kernel to enable
user space to more easily determine the product revision of a given MMC.
Signed-off-by: NBernie Thompson <bhthompson@chromium.org>
Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Do not return probe failure with missing DMA resources, allow driver
to work in PIO mode.  Tested on da850-evm by mounting partition
followed by file creation and deletion.
Signed-off-by: NManjunathappa, Prakash <prakash.pm@ti.com>
Tested-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

In the legacy code, driver clear not only UHS_REG 16 bit also 0-15bit.
If we use UHS-1 mode spec card like SDR50, SDR104. UHS_REG 0-15 should
be set by 1 according to slot id. In this case, legacy code can cause
problems.

In particular, UHS_REG consists of DDR_REG[31:16] and VOLT_REG[15:0].
Before adjusting this patch, bit[15:0] is always cleared.
Signed-off-by: NHyeonsu Kim <hyeonsu.kim@samsung.com>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
Acked-by: NSeungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

In dwc manual, the below contents are described:

"During end of packet, interrupt is not generated if threshold
programming is larger than any remaining data. It is responsibility
of host to read remaining bytes on seeing Data Transfer Done
interrupt"

We also have seen the data cannot be read fully when
"sg_miter->length" is less than FIFO size.
Signed-off-by: NKyoungil Kim <ki0351.kim@samsung.com>
Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Check the result of mmc_add_host() and return the value.
Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
Acked-by: NSeungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Use devm_clk_get() rather than clk_get() to make cleanup paths
more simple.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

If the CD/WP-GPIOs are not provided by the SoC's GPIO controller,
we need to handle the case where omap_hsmmc is probed earlier than
the GPIO controller chosen in the device tree.

Fix this by checking the return value of of_get_named_gpio against
-EPROBE_DEFER and passing it through to the probe function.
Signed-off-by: NJan Luebbe <jlu@pengutronix.de>
Acked-by: NBalaji T K <balajitk@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>