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>

Define the ADMA descriptor structure instead of
using manual offsets and casts.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Define all the ADMA constants instead of having numbers
scattered throughout the code.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Define the maximum number of segments instead of
having the constant 128 appearing in the code in
various places.
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, separate out code
that touches the ADMA descriptor by adding
sdhci_adma_mark_end().
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>

Rename sdhci_set_adma_desc to sdhci_adma_write_desc and
sdhci_show_adma_error to sdhci_adma_show_error so that
all ADMA functions start with sdhci_adma_.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The intent of the warning is to warn if the ADMA table
overflows.  However there can be one more 'end' entry
so the condition should be adjusted accordingly.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Bytes are being copied from/to a single page.  The intent
of the warning is to warn if the page boundary is crossed.
There are two problems.  First, PAGE_MASK is mistaken for
(PAGE_SIZE - 1).  Secondly, instead of using the number
of bytes to copy, the warning is using the maximum that
that value could be.  Fix both.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The ADMA2 descriptor table size was being calculated incorrectly
Fix it.

Note that it has been wrong for a long time and likely has not
caused any problems because of a combination of 1) not needing
alignment descriptors for block operations 2) more memory being
allocated than was requested 3) the use of
SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC which does not use an extra
descriptor for the end marker.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Add the case of SET_BLOCK_COUNT command error to the error conditions
check for making a controller reset at request handling finish.
Otherwise, if the SET_BLOCK_COUNT command failed, e.g. with a timeout,
the controller state was not reset, and the next command failed too.

In the case of data error the controller reset is already done in
finish_data() function before sending stop command (if present),
so the finish tasklet should make a reset after data error only
if no stop command existed in the request.

Also, fix the indentation of this condition check to make it more logical.
Signed-off-by: NAndrew Gabbasov <andrew_gabbasov@mentor.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

As a follow-up of commit
"mmc: sdhci: Balance vmmc regulator_enable(), and always enable vqmmc"
vmmc regulator disable is also not needed in sdhci_remove_host.
The regulator is completely controlled by mmc_power_up and mmc_power_off
functions and is already disabled by the time of removing the host.
Extra regulator_disable call in sdhci_remove_host is unbalanced and
causes a warning reported by regulator core, so should be removed.
Signed-off-by: NAndrew Gabbasov <andrew_gabbasov@mentor.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Let a driver override the timeout clock frequency by
populating it before calling sdhci_add_host().  Note
the value will otherwise be zero because sdhci_host is
zeroed when allocated.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Add a quirk for a host controller that always sets
a Transfer Complete interrupt status for the stop
command even when a busy response is not indicated.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

We find tuning timeout because of the secure erase operation lasts too
long, so don't do tuning when device is busy.
Signed-off-by: NYi Sun <yi.y.sun@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Use the much more common pr_warn instead of pr_warning.

Other miscellanea:

o Coalesce formats
o Realign arguments
o Remove extra spaces when coalescing formats
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Right now enable 1.2v IO voltage for SDHC is by using vqmmc.
Thus for the host which doesn't have vqmmc, or its vqmmc does
not support 1.2v, directly use MMC_CAP2_HS200 may cause HS200
failure.

So needs to check if vqmmc is able to support 1.2v. If it does
not support, disable 1.2v IO for HS200.
Signed-off-by: NChuanxiao Dong <chuanxiao.dong@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

It is fully legal for a controller to start handling busy-end interrupt
before it has signaled that the command has completed. So make sure
we do things in the proper order, Or it results that command interrupt
is ignored so it can cause unexpected operations. This is founded at some
toshiba emmc with the bellow warning.

"mmc0: Got command interrupt 0x00000001 even though
no command operation was in progress."

This issue has been also reported by Youssef TRIKI:
It is not specific to Toshiba devices, and happens with eMMC devices
as well as SD card which support Auto-CMD12 rather than CMD23.

Also, similar patch is submitted by:
Gwendal Grignou <gwendal@chromium.org>

Changes since v1:
 Fixed conflict with the next of git.linaro.org/people/ulf.hansson/mmc.git
 and Tested if issue is fixed again.
Signed-off-by: NHankyung Yu <hankyung.yu@lge.com>
Signed-off-by: NChanho Min <chanho.min@lge.com>
Tested-by: NYoussef TRIKI <youssef.triki@st.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

sdhci_disable_irq_wakeups() is exported, but it is not called outside sdhci.c.

Make it static and do not export it, so that the following sparse warning is
fixed:

drivers/mmc/host/sdhci.c:2548:6: warning: symbol 'sdhci_disable_irq_wakeups' was not declared. Should it be static?
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The timeout_clk calculation code for SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK case
is common and could be moved into common sdhci_do_set_ios, then platform code
which is not using sdhci_set_clock does not need to write the same code again.
Signed-off-by: NDong Aisheng <b29396@freescale.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The timeout_clk calculation code in sdhci_add_host is meaningless for
SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK.
So only execute them with no SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK set.
Signed-off-by: NDong Aisheng <b29396@freescale.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Currently the common code assume 0xE is the maximum timeout counter
value and use it to write into the timeout counter register.
However, it's fairly possible that some other SoCs may have different
max timeout register value. That means 0xE may be incorrect and
becomes meaningless.

It's also possible that other platforms has different timeout
calculation algorithm. To be flexible, this patch provides a .set_timeout
hook for those platforms to set the timeout on their way if they need.
Reviewed-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NDong Aisheng <b29396@freescale.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Currently the max timeout count is hardcode to 1 << 27 for calcuate
the max_busy_timeout, however, for some platforms the max timeout
count may not be 1 << 27, e.g. i.MX uSDHC is 1 << 28.
Thus 1 << 27 is not correct for such platform.

It is also possible that other platforms may have different values.
To be flexible, we add a get_max_timeout_count hook to get the correct
maximum timeout value for these platforms.
Reviewed-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NDong Aisheng <b29396@freescale.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

when SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK is set, timeout_clk is sdclk.
We need to update it when we change sdclk in sdhci_set_clock.
This allow to have a more precisse timeout and max_busy_timeout. This
can help for command that need a big busy wait (erase, ...).
Signed-off-by: NMatthieu CASTET <matthieu.castet@parrot.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

When we wait for busy after sending a command, if there is
a timeout, we got SDHCI_INT_DATA_TIMEOUT flags.
Before this commit we got the message :
"Got data interrupt 0x00100000 even though no data  operation was in progress."
and we need to wait 10s that sdhci_timeout_timer expires.
Signed-off-by: NMatthieu CASTET <matthieu.castet@parrot.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

curr should use signed type since it will contain the returned
value which is possible to be a negative value. Using u32 will
make the returned value to be true even there is a negative result.
Change to use int instead of u32
Signed-off-by: NChuanxiao Dong <chuanxiao.dong@intel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

After the switch to the MMC core regulator infrastucture, we already
have a local "mmc" pointer in various functions. There is no longer a
need to access the data structure via host->mmc.
Signed-off-by: NMarkus Mayer <markus.mayer@linaro.org>
Reviewed-by: NMatt Porter <mporter@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The MMC core in mmc_set_signal_voltage() already provides for the delay
required to switch to 1.8V, so there is no need for drivers to perform
this wait themselves.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

While merging the sdhci patchset from Russell King, somehow a blank
line was left behind. Let's correct the formatting.

Cc: Chris Ball <chris@printf.net>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

A standard compliant SDHCI can itself supply VDD at 1.8, 3.0, or 3.3v.
Several vendors ignore this and instead rely upon external regulators
to supply VDD.  While the external regulators typically can supply one
of the standard SDHCI voltage levels, there is no real reason for this
to be a hard requirement.

This patch alters the SDHCI driver such that external VDD regulators
that provide voltages other than the three mentioned above may be used
so long as they can supply a voltage that meets the needs of the card.

In the case that an external VDD regulator is provided, it is reasonable
to ignore the voltage capabilities of the host controller and allow the
external regulator to set the OCR mask.  Additionally, there is no need
to convert a VDD voltage request into one of the standard SDHCI voltage
levels or program it in the host controller's power control register.
Signed-off-by: NTim Kryger <tim.kryger@gmail.com>
Tested-by: NSachin Kamat <spk.linux@gmail.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Remove those unused ret variables to make it obvious that these function
will not return any errors in the current implementation.
Signed-off-by: NMarkus Pargmann <mpa@pengutronix.de>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

Switch the common SDHCI code over to use mmc_host's regulator pointers
and remove the ones in the sdhci_host structure.  Additionally, use the
common mmc_regulator_get_supply function to get the regulators and set
the ocr_avail mask.

This change sets the ocr_avail directly based upon the voltage ranges
supported which ensures ocr_avail is set correctly while allowing the
use of regulators that can't provide exactly 1.8v, 3.0v, or 3.3v.
Signed-off-by: NTim Kryger <tim.kryger@gmail.com>
Signed-off-by: NMarkus Mayer <markus.mayer@linaro.org>
Reviewed-by: NMatt Porter <mporter@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>

The SD Host Controller spec states that the SD Host Controller can
request that the driver send up to 40 CMD19's while doing tuning
and that the total time the card spends responding must be < 150ms.
The sdhci_execute_tuning() function in sdhci.c that loops through
sending the CMD19's has multiple bugs. First it sets a "timeout"
variable to 150 and a loop counter variable to 40. It then decrements
both variables by 1 at the end of each loop. It tries to handle
violations of the count and time by doing a break when BOTH variables
are equal to zero, which can never happen because they we set to
different values and decremented by 1 at the same time. The timeout
variable is not based on time at all and is totally useless.
The routine also considers a loop counter of zero to be an error
which means that any controller that requests the max of 40 CMD19s
will cause tuning to fail and be disabled.

I've fixed these issues by allowing up to 40 CMD19's and I've removed
any attempt to handle the 150ms time limit. Removing timeout checking
seems safe here because each CMD19 is timeout protected and the max
loop counters insures we don't loop forever. Adding timeout checking
would not be as simple as snapping the time at the loop start and
checking for 150ms to pass because the loop queues the CMD19's and
uses events to wait for completion so the time would include
all the normal scheduler latencies.
Signed-off-by: NAl Cooper <alcooperx@gmail.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <chris@printf.net>

Track whether preset mode is currently enabled in hardware, and use that
when making decisions elsewhere in the code rather than reading the
register and checking the bit.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Tested-by: NMarkus Pargmann <mpa@pengutronix.de>
Tested-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <chris@printf.net>

Move the remaining parts of the power handling in sdhci_do_set_ios()
into sdhci_set_power().
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Tested-by: NMarkus Pargmann <mpa@pengutronix.de>
Tested-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <chris@printf.net>

Move the regulator handling into sdhci_set_power() rather than being in
sdhci_do_set_ios().  This wraps all power control up into this function.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Tested-by: NMarkus Pargmann <mpa@pengutronix.de>
Tested-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <chris@printf.net>

The only user (sdhci-of-esdhc) no longer uses these callbacks, so lets
remove them to discourage any further use.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Tested-by: NMarkus Pargmann <mpa@pengutronix.de>
Tested-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <chris@printf.net>

Clean up the code in sdhci_execute_tuning() so the decision whether
to execute tuning is clearer - and despite this reflecting what the
original code was doing, it shows that it may not be what the author
actually intended.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Tested-by: NMarkus Pargmann <mpa@pengutronix.de>
Tested-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <chris@printf.net>