Use regulator_get_optional() to tell the core that requests for regulators
can fail in a real system.
Signed-off-by: NMark Brown <broonie@linaro.org>
Acked-by: NChris Ball <cjb@laptop.org>

Add a card_event callback to sdhci so that clients can provide their
own card_event to be called when card_detect is triggered.
Signed-off-by: NChristian Daudt <csd@broadcom.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

This patch fixes the HC ctrl_2 programming where, in case of
SDR104 and HS200, we have to write 100b in the the UHS Mode
bits. We wrote 101b that is reserved from Arasan Specs.
Reported-by: NYoussef Triki <youssef.triki@st.com>
Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.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>

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>

If card power is dependent on SD bus power then the host controller
must not be runtime suspended while the card is powered up.  Add
the ability to stay runtime-resumed in that case and enable it with a new
quirk SDHCI_QUIRK2_CARD_ON_NEEDS_BUS_ON.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.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>

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>

3714f4315354 ("mmc: sdhci: update signal voltage switch code") changed the
type of the second parameter of sdhci_do_start_signal_voltage_switch(),
from "struct mmc_ios *ios" to "int signal_voltage" which causes the
following build warning:

drivers/mmc/host/sdhci.c:2044:2: warning: initialization from incompatible pointer type [enabled by default]
drivers/mmc/host/sdhci.c:2044:2: warning: (near initialization for 'sdhci_ops.start_signal_voltage_switch') [enabled by default]

Use the previous type so that it matches the start_signal_voltage_switch()
definition from host.h.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Reviewed-by: NJohan Rudholm <johan.rudholm@stericsson.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Some regulators don't report any voltage values, so checking supported
voltage range results in disabling all SDHCI_CAN_VDD_* flags and
registration failure. This patch finally provides a correct fix for the
registration of SDHCI driver with all possible voltage regulators:
dummy, fixed and regulated without using regulator_count_voltages()
hacks.
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

4d55c5a1 ("mmc: sdhci: enable preset value after uhs initialization")
added preset value support and enabled it by default during sd card init.

Below are the enhancements introduced by this patch:

1. In current code, preset value is enabled after setting clock finished,
which means the clock is manually set by driver firstly and then suddenly
switched to preset value at this point. So the first setting is useless
and unnecessary. What's more, the first clock setting may differ from the
preset one.  The better way is enable preset value just after switch to
UHS mode so the preset value can take effect immediately. So move preset
value enable from mmc_sd_init_card to sdhci_set_ios which will be called
during set timing.

2. In current code, preset value is disabled at the beginning of
mmc_attach_sd.  It's too late since low freq (400khz) should be set in
mmc_power_up.  So move preset value disable to sdhci_set_ios which will
be called during power up.

3. host->clock and ios->drv_type should also be updated according to the
preset value if it's enabled. Current code missed this.

4. This patch also introduce a quirk to disable preset value in case
preset value doesn't work.

This patch has been verified on sdhci-pxav3 platform with both preset
enabled and disabled.
Signed-off-by: NKevin Liu <kliu5@marvell.com>
Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

The protocol related code is moved to core stack. So update the host
driver accordingly.
Signed-off-by: NKevin Liu <kliu5@marvell.com>
Tested-by: NTim Wang <wangtt@marvell.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

The 8bit in the function name is misleading. When set, it will be
used to set the bus width, regardless of whether 8bit or another
bus width is requested, so change the function name to
platform_bus_width.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
Tested-by: NDirk Behme <dirk.behme@de.bosch.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

There are three places where same piece of code is used. Let's split it
to a separate function.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Don't disable SD Host IRQ during suspend if it is wake up source.
Enable wakeup event during suspend.
Signed-off-by: NJialing Fu <jlfu@marvell.com>
Signed-off-by: NKevin Liu <kliu5@marvell.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Current code missed disabling interrupts before free irq which is shared.

Notice below comments for function free_irq (kernel/irq/manage.c):
On a shared IRQ the caller must ensure the interrupt is disabled
on the card it drives before calling this function.

Original code has below issue during suspend/resume when multiple SD
hosts share the same IRQ:
1. Assume there are two hosts (host1 for emmc while host2 for sd) share
the same mmc irq.
2. When system suspend, host2 will be suspended before host1.
So the sequence is below:
	step1: irq handler for host2 removed ->
	step2: irq handler for host1 removed and irq disabled ->
	... system suspended ...
	... system resumed ...
	step3: irq enabled and the irq handler for host1 restored ->
	step4: irq handler for host2 restored
3. So there is the buggy time slot that the irq is enabled but the irq
handler for host2 is removed. Then host2 interrupt can be triggered
but can't be handled at that moment.
Signed-off-by: NJialing Fu <jlfu@marvell.com>
Signed-off-by: NKevin Liu <kliu5@marvell.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Call mmc_gpio_get_cd() to query card presence from cd-gpio before
asking SDHCI.  The rationale behind this change is that flag
SDHCI_QUIRK_BROKEN_CARD_DETECTION is designed for SDHCI controller to
tell that SDHCI_PRESENT_STATE is broken, and it should be used for this
case only.  So when cd-gpio is being used, the controller should set
the flag to tell that SDHCI_PRESENT_STATE is not available.

However, the existing code will skip checking cd-gpio as long as flag
SDHCI_QUIRK_BROKEN_CARD_DETECTION is set.  Change the querying order
between cd-gpio and SDHCI to support the rationale above.
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

There are three places where same piece of code is used. Let's split it
to a separate function.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Don't disable SD Host IRQ during suspend if it is wake up source.
Enable wakeup event during suspend.
Signed-off-by: NJialing Fu <jlfu@marvell.com>
Signed-off-by: NKevin Liu <kliu5@marvell.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Current code missed disabling interrupts before free irq which is shared.

Notice below comments for function free_irq (kernel/irq/manage.c):
On a shared IRQ the caller must ensure the interrupt is disabled
on the card it drives before calling this function.

Original code has below issue during suspend/resume when multiple SD
hosts share the same IRQ:
1. Assume there are two hosts (host1 for emmc while host2 for sd) share
the same mmc irq.
2. When system suspend, host2 will be suspended before host1.
So the sequence is below:
	step1: irq handler for host2 removed ->
	step2: irq handler for host1 removed and irq disabled ->
	... system suspended ...
	... system resumed ...
	step3: irq enabled and the irq handler for host1 restored ->
	step4: irq handler for host2 restored
3. So there is the buggy time slot that the irq is enabled but the irq
handler for host2 is removed. Then host2 interrupt can be triggered
but can't be handled at that moment.
Signed-off-by: NJialing Fu <jlfu@marvell.com>
Signed-off-by: NKevin Liu <kliu5@marvell.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Call mmc_gpio_get_cd() to query card presence from cd-gpio before
asking SDHCI.  The rationale behind this change is that flag
SDHCI_QUIRK_BROKEN_CARD_DETECTION is designed for SDHCI controller to
tell that SDHCI_PRESENT_STATE is broken, and it should be used for this
case only.  So when cd-gpio is being used, the controller should set
the flag to tell that SDHCI_PRESENT_STATE is not available.

However, the existing code will skip checking cd-gpio as long as flag
SDHCI_QUIRK_BROKEN_CARD_DETECTION is set.  Change the querying order
between cd-gpio and SDHCI to support the rationale above.
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Extracting a part of the SDHCI card tasklet into a .card_event()
implementation allows SDHCI hosts to use generic card-detection
services, e.g. the GPIO slot function.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Reviewed-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

A-003500: False ADMA Error might be reported when ADMA is used for
multiple block read command with Stop at Block Gap. If PROCTL[SABGREQ]
is set when the particular block's data is received by the System side
logic before entire block (with CRC) data is received by the SD side
logic, and also if ADMA descriptor line is fetched at the same time,
then DMA engine might report false ADMA error. eSDHC might not be able
to Continue (PROCTL[CREQ]=1) after Stop at Block Gap.
This issue will impact the eSDHC IP VVN2.3.
Signed-off-by: NHaijun Zhang <Haijun.Zhang@freescale.com>
Signed-off-by: NJerry Huang <Chang-Ming.Huang@freescale.com>
Acked-by: NAnton Vorontsov <cbouatmailru@gmail.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>

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>

The vmmc regulator enable in sdhci_add_host is NOT necessary since
it can be enabled during mmc_power_up by function mmc_regulator_set_ocr.
And this extra enable will make regulator_enable/regulator_disable
unbalanced. Consequently, vmmc can't be disabled during mmc_power_off.

Also, if the vqmmc regulator exists, it should be enabled regardless it
support 1.8v or not.
Signed-off-by: NKevin Liu <kliu5@marvell.com>
Signed-off-by: NPhilip Rakity <prakity@marvell.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Commit 473b095a ("mmc: sdhci: fix incorrect command used in tuning")
introduced a NULL dereference at resume-time if an SD 3.0 host controller
raises the SDHCI_NEEDS_TUNING flag while no card is inserted.  Seen on an
OLPC XO-4 with sdhci-pxav3, but presumably affects other controllers too.
Signed-off-by: NChris Ball <cjb@laptop.org>
Cc: stable <stable@vger.kernel.org> [3.3+]

There are two problems here:

The check for vmmc was printing an unnecessary pr_info() when
host->vmmc is NULL.

The intent of the check for vqmmc was to only remove UHS if we have a
regulator that doesn't support the required voltage, but since IS_ERR()
doesn't catch NULL, we were actually removing UHS modes if vqmmc isn't
present at all -- since it isn't present for most users, this breaks
UHS for them.  This patch fixes that UHS regression in 3.7-rc1.
Signed-off-by: NKevin Liu <kliu5@marvell.com>
Signed-off-by: NBin Wang <binw@marvell.com>
Reviewed-by: NPhilip Rakity <prakity@marvell.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

CMD23 causes lots of errors in kernel on some freescale SoCs
(P1020, P1021, P1022, P1024, P1025 and P4080) when MMC card used,
which is because these controllers does not support CMD23,
even on the SoCs which declares CMD23 is supported.
Therefore, we'll not use CMD23.
Signed-off-by: NJerry Huang <Chang-Ming.Huang@freescale.com>
Signed-off-by: NShaohui Xie <Shaohui.Xie@freescale.com>
Acked-by: NAnton Vorontsov <cbouatmailru@gmail.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

This patch fixes up the broken suspend sequence for eMMC with sleep
support. Additionally it reworks the eMMC4.5 Power Off Notification
feature so it fits together with the existing sleep feature.

The CMD0 based re-initialization of the eMMC at resume is re-introduced
to maintain compatiblity for devices using sleep.

A host shall use MMC_CAP2_POWEROFF_NOTIFY to enable the Power Off
Notification feature. We might be able to remove this cap later on,
if we think that Power Off Notification always is preferred over
sleep, even if the host is not able to cut the eMMC VCCQ power.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NSaugata Das <saugata.das@linaro.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Previously to this patch, an SDHCI platform that uses a GPIO for
card detection instead of the internal SDHCI_CARD_PRESENT bit on
the presence register would fail to detect a new card.

Some drivers worked around this in various ways: esdhc-imx defines
an IO accessor to fake the presence bit being true, s3c turns on
polling (which stops the SDHCI driver from checking the bit) after
a card's inserted.  But none of this should be necessary; the real
fix is to check whether we're using a GPIO and avoid relying on
the presence bit if so, as this patch implements.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NChris Ball <cjb@laptop.org>

The vmmc regulator should not rely on the platform code to enable it.
Expliciitly enable and disable the regulator inside the driver.
Signed-off-by: NPhilip Rakity <prakity@marvell.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

On some systems the host controller does not support vccq
signaling.  This is supplied by a dedicated regulator (vqmmc).
Add support for this regulator.
Signed-off-by: NPhilip Rakity <prakity@marvell.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Host has different current capabilities at different voltages, we need
to record these settings seperately. The defined voltages are 1.8/3.0/3.3.
For other voltages, we do not touch current limit setting.

Before we set the current limit for the sd card, find out the host's
operating voltage first and then find out the current capabilities of
the host at that voltage to set the current limit.
Signed-off-by: NAaron Lu <aaron.lu@amd.com>
Reviewed-by: NPhilip Rakity <prakity@marvell.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Power needs to be removed from the card when switching to 1.8v fails.

If a regulator is used to control vmmc we need to turn the
regulator off and then back on otherwise power will not be
removed from the card.
Signed-off-by: NPhilip Rakity <prakity@marvell.com>
Reviewed-by: NAaron Lu <aaron.lu@amd.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

The Marvell CaFe is now marked as having bad card detection to fix
a problem during system resume.

Now on the OLPC XO-1 we are facing the issue that the card is marked
as logically unremovable (via MMC_UNSAFE_RESUME), which means that
mmc_card_is_removable considers the card non-removable. The existing
code logic decides not to poll for card presence in this case, and
card detection is also disabled because of the quirk being set.
This means that no SD cards are detected when inserted after boot.

Refine the logic to enable card presence polling in the case when
a card is logically unremovable, only avoiding the poll in the case
when the card is physically non-removable (denoted with
MMC_CAP_NONREMOVABLE).
Signed-off-by: NDaniel Drake <dsd@laptop.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Add a new flag of SDHCI_USING_RETUNING_TIMER to represent if the host
is using a retuning timer for the card inserted.

This flag is set when the host does tuning the first time for the card
and the host's retuning mode is 1. This flag is used afterwards whenever
needs to decide if the host is currently using a retuning timer.

This flag is cleared when the card is removed in sdhci_reinit.

The set/clear of the flag and the start/stop of the retuning timer is
associated with the card's init/remove time, so there is no need to
touch it when the host is to be removed as at that time the card should
have already been removed.
Signed-off-by: NAaron Lu <aaron.lu@amd.com>
Reviewed-by: NGirish K S <girish.shivananjappa@linaro.org>
Reviewed-by: NPhilip Rakity <prakity@marvell.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Some of the host settings are affected by different cards inserted, e.g.
when an UHS-I card is inserted, the SDHCI_NEEDS_RETUING flag might be
set when the tuning timer expired and host's max_blk_count will be
reduced to make sure the data transfer for a command does not exceed 4MiB
to meet the retuning mode 1's requirement.

When the card is removed, we should restore the original setting of the
host since we can't be sure the next card being inserted will still be
an UHS-I card that needs tuning. The original setting include its
max_blk_count and no set of the flag of SDHCI_NEEDS_RETUNING.
Signed-off-by: NAaron Lu <aaron.lu@amd.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

For SD hosts using retuning mode 1, when retuning timer expired, it will
need to do retuning in sdhci_request before processing the actual
request. But the retuning command is fixed: cmd19 for SD card and cmd21
for eMMC card, so we can't use the original request's command to do the
tuning.

And since the tuning command depends on the card type attached to the
host, we will need to know the card type to use the correct tuning
command.
Signed-off-by: NAaron Lu <aaron.lu@amd.com>
Reviewed-by: NPhilip Rakity <prakity@marvell.com>
Cc: stable <stable@vger.kernel.org> [3.3+]
Signed-off-by: NChris Ball <cjb@laptop.org>

For most error conditions sdhci_add_host() will print a diagnostic
message indicating why it failed but there are a few cases where this
does not happen. Add error messages in these cases to aid diagnosis.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NChris Ball <cjb@laptop.org>