The mmc_card_sleep|awake APIs are not being used since the support is
already properly encapsulated within the suspend sequence. Sleep|awake
command is also specific for eMMC.

We remove the sleep|awake bus_ops, the mmc_card_sleep|awake APIs and
move the code into the mmc specific core instead. This also includes
the mmc ops function, mmc_sleepawake. All releated functions have then
become static and we have got far less code to maintain.

Additionally this patch also simplifies the code from mmc_sleepawake,
since it is only used to put the card to sleep and not awake.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Aggressive power management is suitable when saving power is
essential. At request inactivity timeout, aka pm runtime
autosuspend timeout, the card will be suspended.

Once a new request arrives, the card will be re-initalized and
thus the first request will suffer from a latency. This latency
is card-specific, experiments has shown in general that SD-cards
has quite poor initialization time, around 300ms-1100ms. eMMC is
not surprisingly far better but still a couple of hundreds of ms
has been observed.

Except for the request latency, it is important to know that
suspending the card will also prevent the card from executing
internal house-keeping operations in idle mode. This could mean
degradation in performance.

To use this feature make sure the request inactivity timeout is
chosen carefully. This has not been done as a part of this patch.

Enable this feature by using host cap MMC_CAP_AGGRESSIVE_PM and
by setting CONFIG_MMC_UNSAFE_RESUME.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

The sanitize support is added as a user-app ioctl call, and
was removed from the block-device request, since its purpose is
to be invoked not via File-System but by a user.

This feature deletes the unmap memory region of the eMMC card,
by writing to a specific register in the EXT_CSD.

unmap region is the memory region that was previously deleted
(by erase, trim or discard operation).

In order to avoid timeout when sanitizing large-scale cards,
the timeout for sanitize operation is 240 seconds.
Signed-off-by: NYaniv Gardi <ygardi@codeaurora.org>
Signed-off-by: NMaya Erez <merez@codeaurora.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Previously the MMC_CAP2_DETECT_ON_ERR was invented for detecting
slow card removal. In was never a realy good solution and a proper
fix has been merged using gpio debouncing instead. We remove this
cap in this patch.

Although when using polling card detect mode, the code invented for
MMC_CAP2_DETECT_ON_ERR is re-used to complete card removal in an
earlier phase. There are no need waiting for the polling timeout to
elapse in this case.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NKevin Liu <kliu5@marvell.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Commit fa550189 introduced a performance
regression by adding mmc_power_up() to mmc_start_host().  mmc_power_up()
is not necessary to host controller initialization, it is part of card
initialization and is performed anyway asynchronously.

This patch allows a driver to leave the power up in asynchronous code
(as it was before).

On my current target platform this reduces driver initialization from:

[    1.313220] initcall sdhci_acpi_driver_init+0x0/0x12 returned 0 after 102008 usecs

to this:

[    1.217209] initcall sdhci_acpi_driver_init+0x0/0x12 returned 0 after 8331 usecs
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Macros are used in case that an inline function doesn't work.
Otherwise, use an empty inline function.

(a) Case of !CONFIG_LEDS_TRIGGERS
Following macros are replaced with inline functions.
  led_trigger_register_simple()
  led_trigger_unregister_simple()
  led_trigger_event()
To make inline types, the structure, 'led_trigger' should be defined.
This structure has no member at all.

(b) Case of !CONFIG_LEDS_TRIGGER_IDE_DISK
ledtrig_ide_activity() macro is replaced with an inline function as well.

(c) DEFINE_LED_TRIGGER() and DEFINE_LED_TRIGGER_GLOBAL()
Struct 'led_trigger' is defined both cases, with CONFIG_LEDS_TRIGGERS and
without CONFIG_LEDS_TRIGGERS.
Those macros are moved out of CONFIG_LED_TRIGGERS because of no-dependency
on CONFIG_LEDS_TRIGGERS.

(d) Fix build errors in mmc-core driver
After replacing macros with inline functions, following build errors occur.
(condition: CONFIG_LEDS_TRIGGERS is not set)

  drivers/mmc/core/core.c: In function 'mmc_request_done':
  drivers/mmc/core/core.c:164:25: error: 'struct mmc_host' has no member named 'led'
  drivers/mmc/core/core.c: In function 'mmc_start_request':
  drivers/mmc/core/core.c:254:24: error: 'struct mmc_host' has no member named 'led'
  make[3]: *** [drivers/mmc/core/core.o] Error 1

The reason of these errors is non-existent member variable, 'led'.
It is only valid when CONFIG_LEDS_TRIGGERS is set.
But now, it can be used without this dependency.
To fix build errors, member 'led' is always used without its config option in
'include/linux/mmc/host.h'.
Signed-off-by: NMilo(Woogyom) Kim <milo.kim@ti.com>
Signed-off-by: NBryan Wu <cooloney@gmail.com>

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>

The "extern" keyword isn't required in function declarations, remove it.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NChris Ball <cjb@laptop.org>

MMC defines a number of standard DT bindings. Having each driver parse
them individually adds code redundancy and is error prone. Provide a
standard function to unify the parsing. After all drivers are converted
to using it instead of their own parsers, this function can be integrated
into mmc_alloc_host().
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NChris Ball <cjb@laptop.org>

This patch supports packed write command of eMMC4.5 devices.  Several
writes can be grouped in packed command and all data of the individual
commands can be sent in a single transfer on the bus. Large amounts of
data in one transfer rather than several data of small size are
effective for eMMC write internally.  As a result, packed command help
write throughput be improved.  The following tables show the results
of packed write.

Type A:
test     none |  packed
iozone   25.8 |  31
tiotest  27.6 |  31.2
lmdd     31.2 |  35.4

Type B:
test     none |  packed
iozone   44.1 |  51.1
tiotest  47.9 |  52.5
lmdd     51.6 |  59.2

Type C:
test     none |  packed
iozone   19.5 |  32
tiotest  19.9 |  34.5
lmdd     22.8 |  40.7
Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
Reviewed-by: NMaya Erez <merez@codeaurora.org>
Reviewed-by: NNamjae Jeon <linkinjeon@gmail.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

This patch adds packed command feature of eMMC4.5.  The maximum number
for packing read (or write) is offered and exception event relevant to
packed command which is used for error handling is enabled. If host
wants to use this feature, MMC_CAP2_PACKED_CMD should be set.
Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
Reviewed-by: NMaya Erez <merez@codeaurora.org>
Reviewed-by: NSubhash Jadavani <subhashj@codeaurora.org>
Reviewed-by: NNamjae Jeon <linkinjeon@gmail.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>

This host_ops member is used to test if the card is signaling busy by
pulling dat[0:3] low.
Signed-off-by: NJohan Rudholm <johan.rudholm@stericsson.com>
Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
Tested-by: NWei WANG <wei_wang@realsil.com.cn>
Signed-off-by: NChris Ball <cjb@laptop.org>

When current request is running on the bus and if next request fetched
by mmcqd is NULL, mmc context (mmcqd thread) gets blocked until the
current request completes. This means that if new request comes in while
the mmcqd thread is blocked, this new request can not be prepared in
parallel to current ongoing request. This may result in delaying the new
request execution and increase it's latency.

This change allows to wake up the MMC thread on new request arrival.
Now once the MMC thread is woken up, a new request can be fetched and
prepared in parallel to the current running request which means this new
request can be started immediately after the current running request
completes.

With this change read throughput is improved by 16%.
Signed-off-by: NKonstantin Dorfman <kdorfman@codeaurora.org>
Reviewed-by: NSeungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

According to UHS-I initialization sequence for SDIO 3.0 cards,
the host must set bit[24] (S18R) of OCR register during OCR
handshake to know whether the SDIO card is capable of doing
1.8V I/O.
Signed-off-by: NSujit Reddy Thumma <sthumma@codeaurora.org>
Signed-off-by: NSubhash Jadavani <subhashj@codeaurora.org>
Reviewed-by: NJohan Rudholm <johan.rudholm@stericsson.com>
Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

When current request is running on the bus and if next request fetched
by mmcqd is NULL, mmc context (mmcqd thread) gets blocked until the
current request completes. This means that if new request comes in while
the mmcqd thread is blocked, this new request can not be prepared in
parallel to current ongoing request. This may result in delaying the new
request execution and increase it's latency.

This change allows to wake up the MMC thread on new request arrival.
Now once the MMC thread is woken up, a new request can be fetched and
prepared in parallel to the current running request which means this new
request can be started immediately after the current running request
completes.

With this change read throughput is improved by 16%.
Signed-off-by: NKonstantin Dorfman <kdorfman@codeaurora.org>
Reviewed-by: NSeungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

According to UHS-I initialization sequence for SDIO 3.0 cards,
the host must set bit[24] (S18R) of OCR register during OCR
handshake to know whether the SDIO card is capable of doing
1.8V I/O.
Signed-off-by: NSujit Reddy Thumma <sthumma@codeaurora.org>
Signed-off-by: NSubhash Jadavani <subhashj@codeaurora.org>
Reviewed-by: NJohan Rudholm <johan.rudholm@stericsson.com>
Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Some hosts need to perform additional actions upon card insertion or
ejection. Add a host operation to be called from card detection handlers.
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>

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>

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>

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>

If MMC_CAP_NONREMOVABLE is set, only issue a detect job on init.
Signed-off-by: NJohan Rudholm <johan.rudholm@stericsson.com>
Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
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>

This prepares for the addition of further slot functions.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NChris Ball <cjb@laptop.org>

To handle CD and WP SD/MMC slot pins we need generic flags to specify their
polarity.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NChris Ball <cjb@laptop.org>

struct mmc_host::hotplug is becoming a generic hook for slot functions.
Rename it accordingly.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NChris Ball <cjb@laptop.org>

Add a function to get regulators, supplying card's Vdd and Vccq on a
specific host. If a Vdd supplying regulator is found, the function checks,
whether a valid OCR mask can be obtained from it. The Vccq regulator is
optional. A failure to get it is not fatal.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Reviwed-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Commit 06e8935f ("optimized SDIO IRQ handling for single irq")
introduced some spurious calls to SDIO function interrupt handlers,
such as when the SDIO IRQ thread is started, or the safety check
performed upon a system resume.  Let's add a flag to perform the
optimization only when a real interrupt is signaled by the host
driver and we know there is no point confirming it.
Reported-by: NSujit Reddy Thumma <sthumma@codeaurora.org>
Signed-off-by: NNicolas Pitre <nico@linaro.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Let drivers specify the use of high-capacity erase size.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Most parts of the enable / disable API are no longer used and
can be removed.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Tested-by: NVenkatraman S <svenkatr@ti.com>
Tested-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

To prevent I/O as soon as possible at card removal, a new detect work is
re-scheduled without a delay to let a rescan remove the card device as
soon as possible.

Additionally, MMC_CAP2_DETECT_ON_ERR can now be used to handle "slowly"
removed cards that a scheduled detect work did not detect as removed.
To prevent further I/O requests for these lingering removed cards,
check if card has been removed and then schedule a detect work to
properly remove it.
Signed-off-by: NUlf Hansson <ulf.hansson@stericsson.com>
Reviewed-by: NNamjae Jeon <linkinjeon@gmail.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

The <linux/device.h> header includes a lot of stuff, and
it in turn gets a lot of use just for the basic "struct device"
which appears so often.

Clean up the users as follows:

1) For those headers only needing "struct device" as a pointer
in fcn args, replace the include with exactly that.

2) For headers not really using anything from device.h, simply
delete the include altogether.

3) For headers relying on getting device.h implicitly before
being included themselves, now explicitly include device.h

4) For files in which doing #1 or #2 uncovers an implicit
dependency on some other header, fix by explicitly adding
the required header(s).

Any C files that were implicitly relying on device.h to be
present have already been dealt with in advance.

Total removals from #1 and #2: 51.  Total additions coming
from #3: 9.  Total other implicit dependencies from #4: 7.

As of 3.3-rc1, there were 110, so a net removal of 42 gives
about a 38% reduction in device.h presence in include/*
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

There is an understood mismatch between the voltage the host controller is
set to and the voltage supplied to the card by a fixed voltage regulator.
Teaching the driver to accept the mismatch is overly complicated.  Instead
just accept the regulator's voltage.

This patch adds MMC_CAP2_BROKEN_VOLTAGE.

If the voltage didn't satisfy between min_uV and max_uV, try to change
the voltage in core.c.  When changing the voltage, maybe use
regulator_set_voltage().

In regulator_set_voltage(), check the below condition.

	/* sanity check */
	if (!rdev->desc->ops->set_voltage &&
	    !rdev->desc->ops->set_voltage_sel) {
		ret = -EINVAL;
		goto out;
	}

If some board should use the fixed-regulator, always return -EINVAL.
Then, eMMC didn't initialize always.

So if use a fixed-regulator, we need to add the MMC_CAP2_BROKEN_VOLTAGE.
Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Ensure clocks are always enabled before any interaction with the
host controller driver. This makes sure that there is no race
between host execution and the core layer turning off clocks
in different context with clock gating framework.
Signed-off-by: NSujit Reddy Thumma <sthumma@codeaurora.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NPer Forlin <per.forlin@stericsson.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

module_param(bool) used to counter-intuitively take an int.  In
fddd5201 (mid-2009) we allowed bool or int/unsigned int using a messy
trick.

It's time to remove the int/unsigned int option.  For this version
it'll simply give a warning, but it'll break next kernel version.
Acked-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

This patch adds the support of the HS200 bus speed for eMMC 4.5 devices.
The eMMC 4.5 devices have support for 200MHz bus speed. The function
prototype of the tuning function is modified to handle the tuning
command number which is different in sd and mmc case.
Signed-off-by: NGirish K S <girish.shivananjappa@linaro.org>
Signed-off-by: NPhilip Rakity <prakity@marvell.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Host may now use MMC_CAP2_NO_SLEEP_CMD to disable the use
of eMMC sleep/awake command.

This option can be used when your platform has a buggy
kernel crash dump software, which is supposed to store
the dump on the eMMC, but is not able to wake up the eMMC
from sleep state.

In particular, failures have been seen with u-boot; even if
it is fixed there, platforms will be slow to update their
bootloader binaries.
Signed-off-by: NUlf Hansson <ulf.hansson@stericsson.com>
Reviewed-by: NHanumath Prasad <hanumath.prasad@stericsson.com>
Reviewed-by: NSrinidhi Kasagar <srinidhi.kasagar@stericsson.com>
Acked-by: NSubhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

SD/MMC controllers provide different card insertion and removal detection
methods. On some of them the controller itself issues an interrupt, on
others polling is used, on yet others auxiliary means are used for this
purpose, e.g., a GPIO IRQ. Further, on some systems one of those methods
can be chosen at driver probing time and configured in software. E.g., on
some systems the SD/MMC controller card hot-plug detection pin can be
configured either as a respective controller functions, or an IRQ-capable
GPIO. To support such flexible configurations a card hot-plug context
is added by this patch.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NChris Ball <cjb@laptop.org>

Add a function mmc_detect_card_removed() which upper layers can use to
determine immediately if a card has been removed. This function should
be called after an I/O request fails so that all queued I/O requests
can be errored out immediately instead of waiting for the card device
to be removed.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Acked-by: NSujit Reddy Thumma <sthumma@codeaurora.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Current clock gating framework disables the MCI clock as soon as the
request is completed and enables it when a request arrives. This aggressive
clock gating framework, when enabled, cause following issues:

When there are back-to-back requests from the Queue layer, we unnecessarily
end up disabling and enabling the clocks between these requests since 8MCLK
clock cycles is a very short duration compared to the time delay between
back to back requests reaching the MMC layer. This overhead can effect the
overall performance depending on how long the clock enable and disable
calls take which is platform dependent. For example on some platforms we
can have clock control not on the local processor, but on a different
subsystem and the time taken to perform the clock enable/disable can add
significant overhead.

Also if the host controller driver decides to disable the host clock too
when mmc_set_ios function is called with ios.clock=0, it adds additional
delay and it is highly possible that the next request had already arrived
and unnecessarily blocked in enabling the clocks. This is seen frequently
when the processor is executing at high speeds and in multi-core platforms
thus reduces the overall throughput compared to if clock gating is
disabled.

Fix this by delaying turning off the clocks by posting request on
delayed workqueue. Also cancel the unscheduled pending work, if any,
when there is access to card.

sysfs entry is provided to tune the delay as needed, default
value set to 200ms.
Signed-off-by: NSujit Reddy Thumma <sthumma@codeaurora.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>