The dw_mmc driver changes to make the IO accesors endian agnostic did not
take into account the fifo accesses do not need to be swapped. To fix this
add a mmci_fifo_read/write wrapper to allow these to be passed through the
IO without being swapped.

Since these are now specific functions, it would be easier just to store
the pointer to the fifo registers in the host block instead of the offset
to them. So change the host->data_offset to host->fifo_reg (which also
means we catch all the places this is read or written).
Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Everybody expects the error field in the struct mmc_command|data to be
and int but it's actually an unsigned int. Let's convert it into an int
to meet the expectations.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

In the Designware databook's description of the "Voltage Switch Normal
Scenario" it instructs us to set a timer and fail the voltage change
if we don't see the voltage change interrupt within 2ms.  Let's
implement that.  Without implementing this I have often been able to
reproduce a hang while trying to send CMD11 on an rk3288-based board
while constantly ejecting and inserting UHS cards.
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.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>

Move the member for card_int_gpio into the struct spear_sdhci.

In this way we eliminate the last user of the struct sdhci_plat_data,
which enables us to remove the exported header for sdhci-spear.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Since there no users of the struct sdhci_host, but the shdci host
drivers themselves, let's move the definition of it to the local sdhci
header.

The exported sdhci header then becomes empty, so let's remove it.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Add quirk to handle broken auto-CMD23.
Some controllers do not respond after the first auto-CMD23 is issued.

This allows CMD23 to still work (mandatory for the faster UHS-I mode)
rather than disabling CMD23 entirely via SDHCI_QUIRK2_HOST_NO_CMD23.

Signed-off by: Corneliu Doban <cdoban@broadcom.com>
Signed-off-by: NScott Branden <sbranden@broadcom.com>
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>

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>

No one is using .init/.cleanup callback function.
Let's remove these.
sdhi_ops and .cd_wakeup are also removed
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

This patch defines a quirk to disable the block count
for single block transactions.
It is a preparation and will be used by Fujitsu
SDHCI controller f_sdh30 driver.
Signed-off-by: NVincent Yang <Vincent.Yang@tw.fujitsu.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

This patch defines a quirk for tuning work
around for some sdhci host controller. It sets
both SDHCI_CTRL_EXEC_TUNING and SDHCI_CTRL_TUNED_CLK
for tuning.
It is a preparation and will be used by Fujitsu
SDHCI controller f_sdh30 driver.
Signed-off-by: NVincent Yang <Vincent.Yang@tw.fujitsu.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

One of the reasons omap_hsmmc doesn't use the slot-gpio library
is that it has some non-standard functionality in the card-detect
interrupt service routine.

To make it possible for omap_hsmmc (and maybe others) to be converted
to use slot-gpio, add 'mmc_gpio_request_cd_isr' which provide an
alternate isr to be register by the slot-gpio code.
Signed-off-by: NNeilBrown <neilb@suse.de>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Always check if the card is alive after a successful reset. This allows
us to remove mmc_hw_reset_check(), leaving mmc_hw_reset() as the only
card reset interface.
Signed-off-by: NJohan Rudholm <johanru@axis.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

This patch is based on the patches by Per Forlin, Tony Lin and Ryan QIAN.

This patch complete the API 'post_req' and 'pre_req' in sdhci host side,

Test Env:
1. i.MX6Q-SABREAUTO board, CPU @ 996MHz, use ADMA in uSDHC controller.
2. Test command:
		$ echo 1 > /proc/sys/vm/drop_caches
	write to sd card:
		$ dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=2000 conv=fsync
	read the sd card:
		$ dd if=/dev/mmcblk0 of=/dev/null bs=1M count=2000

3. TOSHIBA 16GB SD3.0 card, running at 4 bit, SDR104 @ 198MHZ
	Performance with and without this patch:
      -------------------------------------------------
	  |                    | read speed | write speed |
	  |------------------------------------------------
	  | with this patch    | ~76.7 MB/s |  ~23.3 MB/s |
	  |------------------------------------------------
	  |without this patch  | ~60.5 MB/s |  ~22.5 MB/s |
	  -------------------------------------------------

4. SanDisk 8GB SD3.0 card, running at 4 bit, DDR50 @ 50MHZ
	Performance with and without this patch:
      -------------------------------------------------
	  |                    | read speed | write speed |
	  |------------------------------------------------
	  | with this patch    | ~40.5 MB/s |  ~15.6 MB/s |
	  |------------------------------------------------
	  |without this patch  | ~36.1 MB/s |  ~14.1 MB/s |
	  -------------------------------------------------

5. Kingston 8GB SD2.0 card, running at 4 bit, High-speed @ 50MHZ
	Performance with and without this patch:
      -------------------------------------------------
	  |                    | read speed | write speed |
	  |------------------------------------------------
	  | with this patch    | ~22.7 MB/s |  ~8.2 MB/s  |
	  |------------------------------------------------
	  |without this patch  | ~21.3 MB/s |  ~8.0 MB/s  |
	  -------------------------------------------------

6. About eMMC, Sandisk 8GB eMMC on i.MX6DL-sabresd board, CPU @ 792MHZ,
   eMMC running at 8 bit, DDR52 @ 52MHZ.
	Performance with and without this patch:
      -------------------------------------------------
	  |                    | read speed | write speed |
	  |------------------------------------------------
	  | with this patch    | ~37.3 MB/s |  ~10.5 MB/s |
	  |------------------------------------------------
	  |without this patch  | ~33.4 MB/s |  ~10.5 MB/s |
	  -------------------------------------------------
Signed-off-by: NHaibo Chen <haibo.chen@freescale.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Since previous patches removed the need for the tuning block patterns
to be exported, let's move them close to the mmc_send_tuning() API.

Those are now intended to be used only by the mmc core.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NStephen Boyd <sboyd@codeaurora.org>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>

By moving the allocation of the slot-gpio data into mmc_alloc_host(),
we can remove the slot-gpio internal calls to mmc_gpio_alloc().

This means mmc_gpio_alloc() has now only one caller left, which
consequence allow us to simplify and remove some of the slot-gpio code.

Additionally, this makes the slot-gpio mutex redundant, so let's remove
it.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The slot-gpio uses the devm*_ managed functions. Still it provide APIs
to explicitly free requested CD/WP GPIOs, but these API isn't being
used.

Therefore let's simplify slot-gpio by removing these unused APIs. If it
later turns out we need some of them, we can always consider to restore
the code.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

We're running into cases where our enabling of the SDIO interrupt in
dw_mmc doesn't actually take effect.  Specifically, adding patch like
this:

 +++ b/drivers/mmc/host/dw_mmc.c
 @@ -1076,6 +1076,9 @@ static void dw_mci_enable_sdio_irq(struct mmc_host *mmc, int enb)

      mci_writel(host, INTMASK,
           (int_mask | SDMMC_INT_SDIO(slot->id)));
 +    int_mask = mci_readl(host, INTMASK);
 +    if (!(int_mask & SDMMC_INT_SDIO(slot->id)))
 +      dev_err(&mmc->class_dev, "failed to enable sdio irq\n");
    } else {

...actually triggers the error message.  That's because the
dw_mci_enable_sdio_irq() unsafely does a read-modify-write of the
INTMASK register.

We can't just use the standard host->lock since that lock is not irq
safe and mmc_signal_sdio_irq() (called from interrupt context) calls
dw_mci_enable_sdio_irq().  Add a new irq-safe lock to protect INTMASK.

An alternate solution to this is to punt mmc_signal_sdio_irq() to the
tasklet and then protect INTMASK modifications by the standard host
lock.  This seemed like a bit more of a high-latency change.
Reported-by: NBing Zhao <bzhao@marvell.com>
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Reviewed-by: NJames Hogan <james.hogan@imgtec.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Re-tuning for HS400 mode must be done in HS200
mode. Currently there is no support for that.
That needs to be reflected in the code.
Specifically, if tuning is executed in HS400 mode
then return an error, and do not start the
tuning timer if HS200 tuning is being done prior
to switching to HS400.

Note that periodic re-tuning is not expected
to be needed for HS400 but re-tuning is still
needed after the host controller has lost power.
In the case of suspend/resume that is not necessary
because the card is fully re-initialised. That
just leaves runtime suspend/resume with no support
for HS400 re-tuning.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

This patch adds support for the bcm43340 and bcm43341 wireless
chipsets. These two chipsets are identical from wireless parts
perspective. As such they use the same firmware image.

Cc: Samuel Ortiz <sameo@linux.intel.com>
Cc: Rob Herring <rob.herring@linaro.org>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
[arend@broadcom.com: squash to single commit, remove 43341 chipid]
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: NHante Meuleman <meuleman@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

To be able to use mmc_send_tuning() prior the struct mmc_card has been
allocated, let's convert it to take the struct mmc_host* as parameter
instead.
Suggested-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NDong Aisheng <b29396@freescale.com>
Reviewed-by: NStephen Boyd <sboyd@codeaurora.org>

According to the SD card spec, Add a manual tuning command function
for SDR104/HS200.
Sending command 19 or command 21 to read data and compare with the
tunning block pattern.

This patch will help to decrease some platform private codes in SDHCI
platform_execute_tuning() callbacks.
Signed-off-by: NMinda Chen <Minda.Chen@csr.com>
Signed-off-by: NBarry Song <Baohua.Song@csr.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The bit of sdio interrupt is 16 in designware implementation,
but it is 24 on Rockchip SoCs.This patch add sdio_id0 for the
number of slot0 in the SDIO interrupt registers.
Signed-off-by: NAddy Ke <addy.ke@rock-chips.com>
Reviewed-by: NDoug Anderson <dianders@chromium.org>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

MMC core already has support for HS400.  Add HS400
support to SDHCI driver.  The SDHC Standard specification
does not define HS400 so consequently HS400 support is
non-standard.  However HS400 is not selected without
the host controller setting the corresponding capability
flags so host controllers not yet supporting HS400
will not be affected.  To support that, a quirk
SDHCI_QUIRK2_CAPS_BIT63_FOR_HS400 is introduced to
enable the use of capabilities register reserved bit-63
to indicate HS400 support.

Because HS400 is non-standard for SDHCI, it is possible
that different vendors will do things in different ways.
However HS200 support faced the same issue but currently
there is only one solution.  As such, no attempt has
been made to provide for alternate HS400 solutions except
for SDHCI_QUIRK2_CAPS_BIT63_FOR_HS400.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

1.2V HS200 mode capability is cleared if there is not a voltage
regulator that supports 1.2V.  Do the same for 1.2V HS400 mode.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Synopsys DW_MMC IP core supports Internal DMA Controller with 64-bit address mode from IP version 2.70a onwards.
Updated the driver to support IDMAC 64-bit addressing mode.
Signed-off-by: NPrabu Thangamuthu <prabu.t@synopsys.com>
Reviewed-by: NAlim Akhtar <alim.akhtar@samsung.com>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

SDHC controller in AMD chipsets require SDHC transfer mode
register to be cleared for commands without data. The issue was
uncovered during testing eMMC cards on KB/ML based platforms
Signed-off-by: NVincent Wan <vincent.wan@amd.com>
Signed-off-by: NWan Zongshun <mcuos.com@gmail.com>
Signed-off-by: NArindam Nath <arindam.nath@amd.com>
Tested-by: NVikram B <vikram.b@amd.com>
Tested-by: NRaghavendra Swamy <raghavendra.swamy@amd.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Add 64-bit ADMA support including:
	- add 64-bit ADMA descriptor
	- add SDHCI_USE_64_BIT_DMA flag
	- set upper 32-bits of DMA addresses
	- ability to select 64-bit ADMA
	- ability to use 64-bit ADMA sizes and alignment
	- display "ADMA 64-bit" when host is added

It is assumed that a 64-bit capable device has set a 64-bit DMA mask
and *must* do 64-bit DMA.  A driver has the opportunity to change
that during the first call to ->enable_dma().  Similarly
SDHCI_QUIRK2_BROKEN_64_BIT_DMA must be left to the drivers to
implement.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

In preparation for 64-bit ADMA, parameterize ADMA sizes
and alignment.  64-bit ADMA has a larger descriptor
because it contains a 64-bit address instead of a 32-bit
address.  Also data must be 8-byte aligned instead
of 4-byte aligned.  Consequently, sdhci_host members
are added for descriptor, table, and buffer sizes
and alignment.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

It is kernel-style to use 'void *' for anonymous data.
This is being applied to the ADMA bounce buffer which
contains unaligned bytes, and to the ADMA descriptor
table which will contain 32-bit ADMA descriptors
or 64-bit ADMA descriptors when support is added.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

In preparation for 64-bit ADMA, rename adma_desc to
adma_table.  That is because members will be added
for descriptor size and table size, so using adma_desc
(which is the table) is confusing.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Previous patches has replaced the calls to mmc_send_ext_csd() into
mmc_get_ext_csd(), thus mmc_send_ext_csd() has become redundant. Let's
remove it.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Callers of mmc_send_ext_csd() will be able to decrease code duplication
by using mmc_get_ext_csd() instead. Let's make it available.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The dw_mmc driver had a bunch of code that ran whenever a card was
ejected and inserted.  However, this code was old and crufty and
should be removed.  Some evidence that it's really not needed:

1. Is is supposed to be legal to use 'cd-gpio' on dw_mmc instead of
   using the built-in card detect mechanism.  The 'cd-gpio' code
   doesn't run any of the crufty old code but yet still works.

2. While looking at this, I realized that my old change (369ac861 mmc:
   dw_mmc: don't queue up a card detect at slot startup) actually
   castrated the old code a little bit already and nobody noticed.
   Specifically "last_detect_state" was left as 0 at bootup.  That
   means that on the first card removal none of the crufty code ran.

3. I can run "while true; do dd if=/dev/mmcblk1 of=/dev/null; done"
   while ejecting and inserting an SD Card and the world doesn't
   explode.

If some of the crufty old code is actually needed, we should justify
it and also put it in some place where it will be run even with
"cd-gpio".

Note that in my case I'm using the "cd-gpio" mechanism but for various
reasons the hardware triggers a dw_mmc "card detect" at bootup.  That
was actually causing a real bug.  The card detect workqueue was
running while the system was trying to enumerate the card.  The
"present != slot->last_detect_state" triggered and we were doing all
kinds of crazy stuff and messing up enumeration.  The new mechanism of
just asking the core to check the card is much safer and then the
bogus interrupt doesn't hurt.
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Tested-by: NJaehoon Chung <jh80.chung@samsung.com>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
Tested-by: Nalim.akhtar <alim.akhtar@samsung.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

For eMMC 5.0 compliant device, firmware version is stored in ext_csd.
Report firmware as a 64bit hexa decimal. Vendor can use hexa or ascii
string to report firmware version.
Also add FFU related EXT_CSD register and note if the device is FFU capable.
Signed-off-by: NGwendal Grignou <gwendal@chromium.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

In most of the cases mmc_get|set_drvdata() didn't simplify code, which
should be the primary reason for such macros.

Let's remove them and convert to the common device_driver macros,
dev_set|get_drvdata() instead.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The struct mmc_driver adds an extra layer on top of the struct
device_driver. That would be fine, if there were a good reason, but
that's not the case.

Let's simplify code by converting to the common struct device_driver
instead and thus also removing superfluous overhead.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The macro is only used by the mmc core, so let's move it in there.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>