linux-stable.git/drivers/mmc/core/host.c, branch linux-4.2.y

mmc: core: Don't return an error for CD/WP GPIOs when GPIOLIB is unset

2015-10-22T21:49:32+00:00

commit 43934ece2ea72c1dd279c0b0478c1a036d5d77ee upstream.

When CONFIG_GPIOLIB is unset, its stubs will return -ENOSYS. That means
when the mmc core parses DT for CD/WP GPIOs via mmc_of_parse(), -ENOSYS
becomes propagated to the caller. Typically this means that the mmc host
driver fails to probe.

As the CD/WP GPIOs are already treated as optional, let's extend that to
cover the case when CONFIG_GPIOLIB is unset.

Reported-by: Michal Simek 
Fixes: 16b23787fc70 ("mmc: sdhci-of-arasan: Call OF parsing for MMC")
Signed-off-by: Ulf Hansson 
Tested-by: Michal Simek 
Acked-by: Venu Byravarasu 
Signed-off-by: Greg Kroah-Hartman

mmc: dt: Allow to specify that no write protect signal is present

2015-06-01T07:07:00+00:00

Allow to specify in the device-tree that no physical write-protect signal
is connected to a particular instance of a MMC controller. Setting the
property will cause the core will assume that the SD card is always
read-write.

The name for the new property is 'disable-wp' and was chosen based on the
property with the same function from the Synopsys designware mobile storage
host controller DT bindings specification.

Signed-off-by: Lars-Peter Clausen 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
Signed-off-by: Ulf Hansson

mmc: core: Add support for HS400 re-tuning

2015-06-01T07:06:57+00:00

HS400 re-tuning must be done in HS200 mode. Add
the ability to switch from HS400 mode to HS200
mode before re-tuning and switch back to HS400
after re-tuning.

Signed-off-by: Adrian Hunter 
Signed-off-by: Ulf Hansson

mmc: host: Add facility to support re-tuning

2015-06-01T07:06:53+00:00

Currently, there is core support for tuning during
initialization. There can also be a need to re-tune
periodically (e.g. sdhci) or to re-tune after the
host controller is powered off (e.g. after PM
runtime suspend / resume) or to re-tune in response
to CRC errors.

The main requirements for re-tuning are:
  - ability to enable / disable re-tuning
  - ability to flag that re-tuning is needed
  - ability to re-tune before any request
  - ability to hold off re-tuning if the card is busy
  - ability to hold off re-tuning if re-tuning is in
  progress
  - ability to run a re-tuning timer

To support those requirements 7 members are added to struct
mmc_host:

  unsigned int		can_retune:1;	/* re-tuning can be used */
  unsigned int		doing_retune:1;	/* re-tuning in progress */
  unsigned int		retune_now:1;   /* do re-tuning at next req */
  int			need_retune;	/* re-tuning is needed */
  int			hold_retune;	/* hold off re-tuning */
  unsigned int		retune_period;  /* re-tuning period in secs */
  struct timer_list	retune_timer;	/* for periodic re-tuning */

need_retune is an integer so it can be set without needing
synchronization. hold_retune is a integer to allow nesting.

Various simple functions are provided to set / clear those
variables.

Subsequent patches take those functions into use.

Signed-off-by: Adrian Hunter 
Signed-off-by: Ulf Hansson

mmc: core: Initial support for MMC power sequences

2015-01-28T11:31:12+00:00

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 
Tested-by: Javier Martinez Canillas 
Reviewed-by: Javier Martinez Canillas

mmc: slot-gpio: Rework how to handle allocation of slot-gpio data

2015-01-19T08:56:18+00:00

By moving the allocation of the slot-gpio data into mmc_alloc_host(),
we can remove the slot-gpio internal calls to mmc_gpio_alloc().

This means mmc_gpio_alloc() has now only one caller left, which
consequence allow us to simplify and remove some of the slot-gpio code.

Additionally, this makes the slot-gpio mutex redundant, so let's remove
it.

Signed-off-by: Ulf Hansson

mmc: core: Free all resources for the class device at ->dev_release()

2015-01-19T08:56:17+00:00

To be consistent when freeing data, let's move the idr_remove() call
from mmc_free_host() into the ->dev_release() callback for the class
device.

Signed-off-by: Ulf Hansson

mmc: core: Return error at failure of request CD/WP in mmc_of_parse()

2015-01-19T08:56:14+00:00

Instead of just printing an error when mmc_of_parse() fails to request
CD/WP GPIO pins, let's propagate all errors, except for -ENOENT.
Earlier only -EPROBE_DEFER was handled correctly.

As a side effect of this change and by relying on host drivers to
handle the errors during ->probe(), we don't need to free any data in
the error path.

This also means we are actually fixing a bug, since we remove the call
to mmc_gpio_free_cd() which wasn't the correct function to invoke to
handle cleanup. Instead that should have been mmc_gpiod_free_cd().

Signed-off-by: Ulf Hansson

mmc: core: fix card detection regression

2014-11-05T08:28:48+00:00

Since commit 89168b489915 ("mmc: core: restore detect line inversion
semantics"), the SD card on i.MX28 (and possibly other) devices isn't
detected and booting stops at:

[    4.120617] Waiting for root device /dev/mmcblk0p3...

This is caused by the MMC_CAP2_CD_ACTIVE_HIGH flag being set incorrectly
when the host controller doesn't use a GPIO for card detection (but
instead uses a dedicated pin). In this case mmc_gpiod_request_cd() will
return before assigning to the gpio_invert variable, leaving the
variable uninitialized. The variable then gets used to set the flag.
This patch fixes the issue by making sure gpio_invert is set to false
when a GPIO isn't used. After this patch, i.MX28 boots fine.

The MMC_CAP2_RO_ACTIVE_HIGH (write protect) flag is also set incorrectly
for the exact same reason (it uses the same uninitialized variable), so
this patch fixes that too.

Fixes: 89168b489915 ("mmc: core: restore detect line inversion semantics")
Reported-by: Stefan Wahren 
Signed-off-by: Kristina Martšenko 
Tested-by: Fabio Estevam 
Signed-off-by: Ulf Hansson

mmc: core: restore detect line inversion semantics

2014-10-02T09:51:26+00:00

commit 98e90de99a0c43bd434da814c882c4332441871e
"mmc: host: switch OF parser to use gpio descriptors"
switched the semantic behaviour of card detect and read
only flags such that the inversion capability flag would
only be set if inversion was explicitly specified in the
device tree, in the hopes that no-one was using double
inversion.

It turns out that the XOR:ing between the explicit
inversion was indeed in use, so we need to restore the
old semantics where both ways of inversion are checked
and the end result XOR:ed.

Reported-by: Javier Martinez Canillas 
Tested-by: Javier Martinez Canillas 
Signed-off-by: Linus Walleij 
Signed-off-by: Ulf Hansson