linux.git/drivers/mmc/core/core.c, branch v4.1 Linux kernel source tree mmc: core: add missing pm event in mmc_pm_notify to fix hib restore 2015-05-04T08:33:33+00:00 Grygorii Strashko Grygorii.Strashko@linaro.org 2015-04-23T10:43:43+00:00 184af16b09360d6273fd6160e6ff7f8e2482ef23 The PM_RESTORE_PREPARE is not handled now in mmc_pm_notify(), as result mmc_rescan() could be scheduled and executed at late hibernation restore stages when MMC device is suspended already - which, in turn, will lead to system crash on TI dra7-evm board: WARNING: CPU: 0 PID: 3188 at drivers/bus/omap_l3_noc.c:148 l3_interrupt_handler+0x258/0x374() 44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4_PER1_P3 (Idle): Data Access in User mode during Functional access Hence, add missed PM_RESTORE_PREPARE PM event in mmc_pm_notify(). Fixes: 4c2ef25fe0b8 (mmc: fix all hangs related to mmc/sd card...) Signed-off-by: Grygorii Strashko <Grygorii.Strashko@linaro.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> 
The PM_RESTORE_PREPARE is not handled now in mmc_pm_notify(),
as result mmc_rescan() could be scheduled and executed at
late hibernation restore stages when MMC device is suspended
already - which, in turn, will lead to system crash on TI dra7-evm board:

WARNING: CPU: 0 PID: 3188 at drivers/bus/omap_l3_noc.c:148 l3_interrupt_handler+0x258/0x374()
44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4_PER1_P3 (Idle): Data Access in User mode during Functional access

Hence, add missed PM_RESTORE_PREPARE PM event in mmc_pm_notify().

Fixes: 4c2ef25fe0b8 (mmc: fix all hangs related to mmc/sd card...)
Signed-off-by: Grygorii Strashko <Grygorii.Strashko@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
mmc: core: Enable runtime PM management of host devices 2015-03-31T14:50:14+00:00 Ulf Hansson ulf.hansson@linaro.org 2015-03-27T11:15:15+00:00 9250aea76bfcbf4c2a7868e5566281bf2bb7af27 Currently those host drivers which have deployed runtime PM, deals with the runtime PM reference counting entirely by themselves. Since host drivers don't know when the core will send the next request through some of the host_ops callbacks, they need to handle runtime PM get/put between each an every request. In quite many cases this has some negative effects, since it leads to a high frequency of scheduled runtime PM suspend operations. That due to the runtime PM reference count will normally reach zero in-between every request. We can decrease that frequency, by enabling the core to deal with runtime PM reference counting of the host device. Since the core often knows that it will send a seqeunce of requests, it makes sense for it to keep a runtime PM reference count during these periods. More exactly, let's increase the runtime PM reference count by invoking pm_runtime_get_sync() from __mmc_claim_host(). Restore that action by invoking pm_runtime_mark_last_busy() and pm_runtime_put_autosuspend() in mmc_release_host(). In this way a runtime PM reference count will be kept during the complete cycle of a claim -> release host. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Konstantin Dorfman <kdorfman@codeaurora.org> 
Currently those host drivers which have deployed runtime PM, deals with
the runtime PM reference counting entirely by themselves.

Since host drivers don't know when the core will send the next request
through some of the host_ops callbacks, they need to handle runtime PM
get/put between each an every request.

In quite many cases this has some negative effects, since it leads to a
high frequency of scheduled runtime PM suspend operations. That due to
the runtime PM reference count will normally reach zero in-between
every request.

We can decrease that frequency, by enabling the core to deal with
runtime PM reference counting of the host device. Since the core often
knows that it will send a seqeunce of requests, it makes sense for it
to keep a runtime PM reference count during these periods.

More exactly, let's increase the runtime PM reference count by invoking
pm_runtime_get_sync() from __mmc_claim_host(). Restore that action by
invoking pm_runtime_mark_last_busy() and pm_runtime_put_autosuspend()
in mmc_release_host(). In this way a runtime PM reference count will be
kept during the complete cycle of a claim -> release host.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Acked-by: Konstantin Dorfman <kdorfman@codeaurora.org>
mmc: core: Remove the ->enable|disable() callbacks 2015-03-27T09:57:55+00:00 NeilBrown neil@brown.name 2015-03-25T21:43:37+00:00 40433267331bc6b9d70d5cdd14bfa2c8e3e5f0ec 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: NeilBrown <neil@brown.name> Signed-off-by: Ulf 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: NeilBrown <neil@brown.name>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
mmc: core: Invoke mmc_pwrseq_post_power_on() prior MMC_POWER_ON state 2015-02-03T19:56:58+00:00 Ulf Hansson ulf.hansson@linaro.org 2015-02-02T15:01:14+00:00 4febb7e20aa619e2b2845519dad247e4038dc383 Host drivers have different ways to sends their "init stream" to the card. Some need to do it as part of a request, some do it from the ->set_ios() callback in the MMC_POWER_ON state and some don't send an "init stream" at all. To be able to use the reset GPIOs from the simple MMC power sequence provider, the card need to be powered and the "init stream" must not have been sent. To cope with these requirements, invoke mmc_pwrseq_post_power_on() prior we change the state to MMC_POWER_ON in mmc_power_up(). Host drivers shall perform power up operations in the MMC_POWER_UP state. Unfortunate three hosts (au1xmmc, cb710-mmc and toshsd) don't conform to this expectation. Instead those ignore the MMC_POWER_UP state and delays their power up operations to the MMC_POWER_ON state. Those hosts needs to change their behavior to enable proper support for the simple MMC power sequence provider. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> 
Host drivers have different ways to sends their "init stream" to the
card. Some need to do it as part of a request, some do it from the
->set_ios() callback in the MMC_POWER_ON state and some don't send an
"init stream" at all.

To be able to use the reset GPIOs from the simple MMC power sequence
provider, the card need to be powered and the "init stream" must not
have been sent.

To cope with these requirements, invoke mmc_pwrseq_post_power_on()
prior we change the state to MMC_POWER_ON in mmc_power_up().

Host drivers shall perform power up operations in the MMC_POWER_UP
state. Unfortunate three hosts (au1xmmc, cb710-mmc and toshsd) don't
conform to this expectation. Instead those ignore the MMC_POWER_UP
state and delays their power up operations to the MMC_POWER_ON state.

Those hosts needs to change their behavior to enable proper support for
the simple MMC power sequence provider.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
mmc: Resolve BKOPS compatability issue 2015-01-29T10:15:12+00:00 Alexey Skidanov alexey.skidanov@sandisk.com 2015-01-29T08:49:43+00:00 0501be6429e4eb02f417ad83eacd84b8c57b0283 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: Alexey Skidanov <alexey.skidanov@sandisk.com> Signed-off-by: Ulf 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: Alexey Skidanov <alexey.skidanov@sandisk.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
mmc: core: Initial support for MMC power sequences 2015-01-28T11:31:12+00:00 Ulf Hansson ulf.hansson@linaro.org 2014-11-28T13:38:36+00:00 3aa8793f751d4cfcaca886e75ab30dfb00cf1d88 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: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Reviewed-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> 
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: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Reviewed-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
mmc: core: Move mmc_card_removed() into mmc_start_request() 2015-01-19T08:56:30+00:00 Adrian Hunter adrian.hunter@intel.com 2014-12-05T17:41:02+00:00 f100c1c2b55b08d419b7cd3985cc144b41ce9a1f Both callers of mmc_start_request() call mmc_card_removed() so move that call into mmc_start_request(). This patch is preparation for adding re-tuning support. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> 
Both callers of mmc_start_request() call mmc_card_removed()
so move that call into mmc_start_request().

This patch is preparation for adding re-tuning support.

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
mmc: core: Simplify by adding mmc_execute_tuning() 2015-01-19T08:56:30+00:00 Adrian Hunter adrian.hunter@intel.com 2014-12-05T17:40:59+00:00 63e415c64003fd62a302a1dc19f082e2c6f1b7cc For each MMC, SD and SDIO there is code that holds the clock, calls ops->execute_tuning, and releases the clock. Simplify the code a bit by providing a separate function to do that. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> 
For each MMC, SD and SDIO there is code that
holds the clock, calls ops->execute_tuning, and
releases the clock. Simplify the code a bit by
providing a separate function to do that.

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
mmc: core: refactor the hw_reset routines 2015-01-19T08:56:27+00:00 Johan Rudholm johan.rudholm@axis.com 2015-01-12T14:38:05+00:00 f855a3717eaff1179837060c4796f1cd706331e7 Move the (e)MMC specific hw_reset code from core.c into mmc.c. Call the code from the new bus_ops member "reset". This also allows for adding a SD card specific reset procedure. Signed-off-by: Johan Rudholm <johanru@axis.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> 
Move the (e)MMC specific hw_reset code from core.c into mmc.c. Call the
code from the new bus_ops member "reset". This also allows for adding
a SD card specific reset procedure.

Signed-off-by: Johan Rudholm <johanru@axis.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
mmc: core: always check status after reset 2015-01-19T08:56:27+00:00 Johan Rudholm johan.rudholm@axis.com 2015-01-12T14:38:04+00:00 83533ab28380f6957af39a7b322e639e42dbdaf1 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: Johan Rudholm <johanru@axis.com> Signed-off-by: Ulf 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: Johan Rudholm <johanru@axis.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>