The eMMC signalling voltage is determined by VCCQ which is provided to
the card by the host.  Signalling is not required to begin at 3.3v and,
if the host and card both support a particular VCC/VCCQ combination, it
can be used immediately.

In contrast, SD Cards must begin with 3.3v signalling and may switch to
a lower voltage signalling if instructed to do so in CMD11.  A message
is required to coordinate this operation because the card only receives
a 3.3v VDD and must know when to use the 1.8v produced by its internal
regulator.

It makes sense for the core to begin with 3.3v signalling but when that
can't be set, 1.8v and 1.2v signalling also should be attempted.  This
is especially important when an external regulator with a limited range
is used to supply VCCQ to an eMMC part.
Signed-off-by: NTim Kryger <tim.kryger@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <chris@printf.net>

The sdio func device is added to the driver model after the card
device.

This means the sdio func device will be suspend before the card device
and thus resumed after. The consequence are the mmc core don't
explicity need to protect itself from receiving sdio requests in
suspended state. Instead that can be handled from the sdio bus, which
is thus invokes the PM callbacks instead of old dummy function.

In the case were the sdio func driver don't implement the PM callbacks
the mmc core will in the early phase of system suspend, remove the
card from the driver model and thus power off it.

Cc: Aaron Lu <aaron.lu@intel.com>
Cc: NeilBrown <neilb@suse.de>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NAaron Lu <aaron.lu@intel.com>
Tested-by: Nxiaoming wang <xiaoming.wang@intel.com>
Tested-by: NChuanxiao Dong <chuanxiao.dong@intel.com>
Signed-off-by: NChris Ball <chris@printf.net>

When plugging a specific micro SD card at MMC socket of a custom i.MX28 board,
we get the following kernel warning:

WARNING: CPU: 0 PID: 30 at drivers/mmc/host/mxs-mmc.c:342 mxs_mmc_start_cmd+0x34c/0x378()
Modules linked in:
CPU: 0 PID: 30 Comm: kworker/u2:1 Not tainted 3.14.0-rc5 #8
Workqueue: kmmcd mmc_rescan
[<c0015420>] (unwind_backtrace) from [<c0012cb0>] (show_stack+0x10/0x14)
[<c0012cb0>] (show_stack) from [<c001daf8>] (warn_slowpath_common+0x6c/0x8c)
[<c001daf8>] (warn_slowpath_common) from [<c001db34>] (warn_slowpath_null+0x1c/0x24)
[<c001db34>] (warn_slowpath_null) from [<c0349478>] (mxs_mmc_start_cmd+0x34c/0x378)
[<c0349478>] (mxs_mmc_start_cmd) from [<c0338fa0>] (mmc_start_request+0xc4/0xf4)
[<c0338fa0>] (mmc_start_request) from [<c03390b4>] (mmc_wait_for_req+0x50/0x164)
[<c03390b4>] (mmc_wait_for_req) from [<c03405b8>] (mmc_app_send_scr+0x158/0x1c8)
[<c03405b8>] (mmc_app_send_scr) from [<c033ee1c>] (mmc_sd_setup_card+0x80/0x3c8)
[<c033ee1c>] (mmc_sd_setup_card) from [<c033f788>] (mmc_sd_init_card+0x124/0x66c)
[<c033f788>] (mmc_sd_init_card) from [<c033fd7c>] (mmc_attach_sd+0xac/0x174)
[<c033fd7c>] (mmc_attach_sd) from [<c033a658>] (mmc_rescan+0x25c/0x2d8)
[<c033a658>] (mmc_rescan) from [<c003597c>] (process_one_work+0x1b4/0x4ec)
[<c003597c>] (process_one_work) from [<c0035de4>] (worker_thread+0x130/0x464)
[<c0035de4>] (worker_thread) from [<c003c824>] (kthread+0xb4/0xd0)
[<c003c824>] (kthread) from [<c000f420>] (ret_from_fork+0x14/0x34)

The error is due to an invalid value in CSD register of a specific 2GB
micro SD card. The CSD version of this card is 1.0 but the TACC field
has the invalid value 0.

cid:0000005553442020000000000000583f
csd:00000032535a83bfedb7ffbf1680003f
date:08/2005
erase_size:512
fwrev:0x0
hwrev:0x0
manfid:0x000000
name:USD
oemid:0x0000
preferred_erase_size:4194304
scr:0225000000000000
serial:0x00000000
type:SD

Since the kernel is making use of this TACC field to calculate the SD
card timeout, an invalid value 0 leads to a warning at
mxs_ns_to_ssp_ticks() and later the following misleading error message
appears in a loop:

mxs-mmc 80010000.ssp: card claims to support voltages below defined range
mxs-mmc 80010000.ssp: no support for card's volts
mmc0: error -22 whilst initialising MMC card

This error is only found on this 2GB SD card on mxs platform.
On x86 this card works without any problems.

The following patch based on the work of Peter Chan and Otavio Salvador.
It catches the case that the determined timeout is still 0 and sets it
to a valid value.

Successful tested on a i.MX28 board.
Signed-off-by: NStefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <chris@printf.net>

Use new ATTRIBUTE_GROUPS macro to declare attribute groups.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <chris@printf.net>

This change removes the callback from atomic context which it doesn't
need to be in, and puts it in line with the debounced rescan.

This code is based on these e-mail threads with Christian Daudt:

  https://lkml.org/lkml/2013/8/19/539
  https://lkml.org/lkml/2014/3/19/79Signed-off-by: NMarkus Mayer <markus.mayer@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <chris@printf.net>

This change distinguishes DDR timing mode of current
mixed usage to clarify device type.
Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <chris@printf.net>

Add functions to request a CD GPIO using the GPIO descriptor API.
Note that the new request function is paired with mmc_gpiod_free_cd()
not mmc_gpio_free_cd().  Note also that it must be called prior to
mmc_add_host() otherwise the caller must also call
mmc_gpiod_request_cd_irq().
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NChris Ball <chris@printf.net>

In preparation for adding a descriptor-based CD GPIO API, split out
CD IRQ request into a separate function.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NChris Ball <chris@printf.net>

In preparation for adding a descriptor-based CD GPIO API, switch from
recording GPIO numbers to recording GPIO descriptors.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Tested-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NChris Ball <chris@printf.net>

Signed-off-by: NAlexander Shiyan <shc_work@mail.ru>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

When sending the sleep command for host drivers supporting
MMC_CAP_WAIT_WHILE_BUSY, we need to confirm that max_busy_timeout is
big enough comparing to the sleep timeout specified from card's
EXT_CSD. If this isn't case, we use a R1 response instead of R1B and
fallback to use a delay instead.

Do note that a max_busy_timeout set to zero by the host, is interpreted
as it can cope with whatever timeout the mmc core provides it with.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <chris@printf.net>

Conform to the eMMC spec and use the CMD6 generic timeout from the
EXT_CSD register, when switching to HS200 mode.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <chris@printf.net>

If the host controller supports busy detection in HW, we expect the
MMC_CAP_WAIT_WHILE_BUSY to be set. Likewise the corresponding
host->max_busy_timeout should reflect the maximum busy detection
timeout supported by the host.

Previously we expected a host that supported MMC_CAP_WAIT_WHILE_BUSY to
cope with any timeout, which just isn't feasible due to HW limitations.

For most switch operations, R1B responses are expected and thus we need
to check for busy detection completion. To cope with cases where the
requested busy detection timeout is greater than what the host are able
to support, we fallback to use a R1 response instead. This will prevent
the host from doing HW busy detection.

In those cases, busy detection completion is handled by polling the for
the card's status using CMD13. This is the same mechanism used when the
host doesn't support MMC_CAP_WAIT_WHILE_BUSY.

Do note, a host->max_busy_timeout set to zero, is interpreted by the
mmc core as it don't know what the host supports. It will then provide
the host with whatever timeout the mmc core finds suitable.

For some cases the mmc core has unfurtunate no clue of what timeout to
use. In these cases we provide the host with a timeout value of zero,
which the host may interpret as use whatever timeout it finds suitable.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <chris@printf.net>

Instead of using several references to card->host, let's use a local
variable. That means we can remove the BUG_ON verifications for the
same pointers.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <chris@printf.net>

Instead of handle specific adaptations, releated to certain switch
operations, inside __mmc_switch, push this to be handled by the caller
instead.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <chris@printf.net>

To better reflect that the cmd_timeout_ms is directly related to the
busy detection timeout, let's rename it.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <chris@printf.net>

Rename host->max_discard_to to host->max_busy_timeout, to reflect that
it tells the mmc core layer about the maximum supported busy detection
timeout by the host.

This timeout is at the moment only applicable to erase/trim/discard
commands. By the renaming we provide the option of make use of it for
other commands that cares about busy detection. In other words, those
commands that wants an R1B response, like for example the mmc switch
command.

Do note that the max_busy_timeout is supposed to be specified only by
hosts supporting MMC_CAP_WAIT_WHILE_BUSY.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <chris@printf.net>

Provide the option to configure these speed modes per host, for those
host driver's that can't distinguish this in runtime.
Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <chris@printf.net>

Provide the option to configure these speed modes per host, for those
host driver's that can't distinguish this in runtime.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NChris Ball <chris@printf.net>

Provide the option to configure these speed modes per host, for those
host driver's that can't distinguish this in runtime.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NChris Ball <chris@printf.net>

There are no reason to why the use of a non-volatile internal eMMC
cache should be controlled by a host cap. Instead let's just enable it
if the eMMC card supports it.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NSeungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: NChris Ball <chris@printf.net>

Earlier we disabled the cache during suspend, which meant a flush was
internally at the eMMC performed as well.

To simplify code we can make use of the mmc_flush_cache(), during mmc
suspend, which makes the mmc_cache_ctrl() redundant so then we can
remove it.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NSeungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: NChris Ball <chris@printf.net>

There are no active users of this host capability. The primary reason
for adding this cap was due to a bug in ux500 boot loader code, which
is not a relevant issue any more. So, let's remove it.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <chris@printf.net>

Due to the removal of the Kconfig option MMC_UNSAFE_RESUME, several
validations of a present bus_ops callback became redundant. Let's
remove these.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <chris@printf.net>

Invoking system suspend or shutdown without using the Kconfig option
MMC_UNSAFE_RESUME, did trigger an ungraceful power cut of the card.

To improve the situation, change the behavior to always make use of the
available bus_ops callbacks that handles system suspend and shutdown
properly.

By changing the behavior MMC_UNSAFE_RESUME becomes redundant, so lets's
remove it.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <chris@printf.net>

Polling SDIO_CCCR_INTx could create a fake interrupt with Marvell
SD8797 card. Add a quirk to handle this case. The fixup here is
to issue a dummy CMD52 read to function 0 register 0xff, and this
dummy read must be right after SDIO_CCCR_INTx is read.

Patch has been verified on a dw_mmc controller (Samsung Chromebook)
with MMC_CAP_SDIO_IRQ disabled.
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Reviewed-by: NPaul Stewart <pstew@chromium.org>
Reviewed-by: NDoug Anderson <dianders@chromium.org>
Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <chris@printf.net>

This reverts and updates commit 77776fd0 ("mmc: sd: fix the
maximum au_size for SD3.0"). The au_size for SD3.0 cannot be achieved
by a simple bit shift, so this needs to be implemented differently.
Also, don't print the warning in case of 0 since 'not defined' is
different from 'invalid'.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Cc: stable <stable@vger.kernel.org> # [3.12, 3.13]
Signed-off-by: NChris Ball <chris@printf.net>

Non removable cards are always present, so do not call get_cd for them.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

The MMC_CAP_UHS_DDR50 must work on 1.8v.
However, the eMMC DDR mode can work on either 1.8v or 3.3v and
should not depend on UHS_DDR50.
So get rid of this limitation to let controller without 1.8v
signal voltage support can also work for eMMC DDR mode if it claims.
Signed-off-by: NDong Aisheng <b29396@freescale.com>
Acked-by: NShawn Guo <shawn.guo@linaro.org>
Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Modify acpi_preset_companion() to take a struct acpi_device pointer
instead of an ACPI handle as its second argument and redefine it as
a static inline wrapper around ACPI_COMPANION_SET() passing the
return value of acpi_find_child_device() directly as the second
argument to it.  Update its users to pass struct acpi_device
pointers instead of ACPI handles to it.

This allows some unnecessary acpi_bus_get_device() calls to be
avoided.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NAaron Lu <aaron.lu@intel.com>
Tested-by: Aaron Lu <aaron.lu@intel.com> # for ATA binding

Modify struct acpi_dev_node to contain a pointer to struct acpi_device
associated with the given device object (that is, its ACPI companion
device) instead of an ACPI handle corresponding to it.  Introduce two
new macros for manipulating that pointer in a CONFIG_ACPI-safe way,
ACPI_COMPANION() and ACPI_COMPANION_SET(), and rework the
ACPI_HANDLE() macro to take the above changes into account.
Drop the ACPI_HANDLE_SET() macro entirely and rework its users to
use ACPI_COMPANION_SET() instead.  For some of them who used to
pass the result of acpi_get_child() directly to ACPI_HANDLE_SET()
introduce a helper routine acpi_preset_companion() doing an
equivalent thing.

The main motivation for doing this is that there are things
represented by struct acpi_device objects that don't have valid
ACPI handles (so called fixed ACPI hardware features, such as
power and sleep buttons) and we would like to create platform
device objects for them and "glue" them to their ACPI companions
in the usual way (which currently is impossible due to the
lack of valid ACPI handles).  However, there are more reasons
why it may be useful.

First, struct acpi_device pointers allow of much better type checking
than void pointers which are ACPI handles, so it should be more
difficult to write buggy code using modified struct acpi_dev_node
and the new macros.  Second, the change should help to reduce (over
time) the number of places in which the result of ACPI_HANDLE() is
passed to acpi_bus_get_device() in order to obtain a pointer to the
struct acpi_device associated with the given "physical" device,
because now that pointer is returned by ACPI_COMPANION() directly.
Finally, the change should make it easier to write generic code that
will build both for CONFIG_ACPI set and unset without adding explicit
compiler directives to it.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> # on Haswell
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Aaron Lu <aaron.lu@intel.com> # for ATA and SDIO part

Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

In some environments it is to prefer to postpone the resume of the card
device until runtime_resume is being carried out, since it will mean a
signficant decrease of the total system resume time.

The reason of the decreased resume time is simply because of the actual
re-initalization of the card, which typically takes hundreds of
milliseconds, is performed outside the resume sequence and wont thus
affect it.

For removable card, the detect work tries to re-detect the card to make
sure it is still present, as a part of that sequence the card will also
be runtime_resumed and thus also fully resumed.

For a non-removable card, typically a mmc blk request will trigger a
runtime_resume and thus fully resume the card. This also means the
first request will likely suffer from an inital latency since the
re-initialization of the card needs to be performed.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

The card device is considered as in-active after it has been suspended.
To prevent any further runtime PM requests in suspend state, we then
disable runtime PM.

After the card device has been resumed, we shall consider it as active,
like we also do after a probe sequence. When resumed, we can safely
enable runtime PM again.

This will make sure the PM core can request the card device to go to
in-active state after a resume has been completed. Previously we had to
wait for new pm_runtime_get->pm_runtime_put cycle to be executed.

Additionally, once a resume has been carried out, update the last busy
mark. At the moment this will have no effect but if the PM core will
respect autosuspend enabled devices, when it directly triggers a
runtime_suspend from a runtime_idle, it will mean the card device will
be scheduled for a delayed runtime_suspend instead of done immediately.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Commit "mmc: core: Push common suspend|resume code into each bus_ops"
moved the responsibility for doing mmc_power_up|off into each
suspend/resume bus_ops. When using MMC_CAP_AGGRESSIVE_PM, through the
runtime callbacks, calls to mmc_power_up|off became redundant.

When removing them, we are also able to remove the calls to
mmc_claim|release_host, thus simplifing code a bit more.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

By adding a card state that records if it is suspended or resumed, we
can accept asyncronus suspend/resume requests for the mmc and sd
bus_ops.

MMC_CAP_AGGRESSIVE_PM, will at request inactivity through the runtime
bus_ops callbacks, execute a suspend of the the card. In the state were
this has been done, we can receive a suspend request for the mmc bus,
which for sd and mmc forced the card to active state by a
pm_runtime_get_sync. In other words, the card was resumed and then
immediately suspended again, completely unnecessary.

Since the suspend/resume bus_ops callbacks for sd and mmc are now
capable of handling asynchronous requests, we no longer need to force
the card to active state before executing suspend. Evidently preventing
the above sequence for MMC_CAP_AGGRESSIVE_PM.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

The are no more users of the deprecated mmc_suspend|resume_host API,
so let's remove it.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

We want to give user space provision to fully consume a card
insert/remove event, when the event was caused by a wakeup irq.

By signaling the wakeup event for a time of 5 s for devices configured
as wakeup capable, we likely will be prevent a sleep long enough to let
user space consume the event.

To enable this feature, host drivers must thus configure their devices
as wakeup capable.

This is a reworked implementation of the old wakelocks for the mmc
subsystem, originally authored by Colin Cross and San Mehat for the
Android kernel. Zoran Markovic shall also be given cred for recently
re-trying to upstream this feature.

Cc: San Mehat <san@google.com>
Cc: Colin Cross <ccross@android.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Zoran Markovic <zoran.markovic@linaro.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NZoran Markovic <zoran.markovic@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Since mmc_select_voltage now only gets called from the attach sequence,
it makes sense to move the out of spec validations of the card ocr into
this function.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

According to eMMC/SD/SDIO specs, the VDD (VCC) voltage level must be
maintained during the initialization sequence. If we want/need to tune
the voltage level, a complete power cycle of the card must be executed.

Most host drivers conforms to the specifications by only allowing to
change VDD voltage level at the MMC_POWER_UP state, but some also cares
about MMC_POWER_ON state, which they should'nt. This patch will not
break those drivers, but they could clean up code to better reflect
what is expected from the protocol layer.

A big re-work of the mmc_select_voltage function is done to only change
VDD voltage level if the host supports MMC_CAP2_FULL_PWR_CYCLE.
Otherwise only validation of the host and card ocr mask will be done.

A very nice side-effect of this patch is that we now don't need to
reset the negotiated ocr mask at the mmc_power_off function, since now
it will actually reflect the present voltage level, which safely can be
used at the next power up and re-initialization. Moreover, we then only
need to execute mmc_select_voltage from the attach sequence.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>