linux-stable.git/drivers/mmc/core, branch v4.4.2

mmc: mmc: Improve reliability of mmc_select_hs400()

2015-11-09T12:16:32+00:00

mmc_select_hs400() calls __mmc_switch() which checks the switch is
successful using CMD13 (SEND_STATUS).  The problem is that it does that
using the timing settings of the previous mode.  That is prone to error,
especially when switching from HS to HS400 because the timing parameters
for HS mode are tighter than the timing parameters for HS400 mode.

In the case when CMD13 polling is used (i.e. not MMC_CAP_WAIT_WHILE_BUSY)
with the switch command, it must be assumed that using different modes on
the card and host must work.

However in the case when CMD13 polling is not used
(i.e. MMC_CAP_WAIT_WHILE_BUSY) mmc_select_hs400() can be made more
reliable by setting the host to the correct timing before sending CMD13.

This patch does that.

Signed-off-by: Adrian Hunter 
Cc:  # 4.2+
Tested-by: Alim Akhtar 
Signed-off-by: Ulf Hansson

mmc: mmc: Move mmc_switch_status()

2015-11-09T12:16:26+00:00

Move the mmc_switch_status() function in preparation for calling it
in mmc_select_hs400().

Signed-off-by: Adrian Hunter 
Cc:  # 4.2+
Tested-by: Alim Akhtar 
Signed-off-by: Ulf Hansson

mmc: mmc: Fix HS setting in mmc_select_hs400()

2015-11-09T12:16:20+00:00

mmc_select_hs400() begins with the card and host in HS200 mode.
Therefore, any commands sent to the card should use HS200 timing.
It is incorrect to set the host to High Speed (HS) timing before
sending the switch command.  Doing so is unreliable because
the timing parameters for HS mode are tighter than the timing
parameters for HS200 mode.  Thus the HS timings should be set
only after the card has switched mode.

However, it is not unreasonable first to reduce the frequency to
the HS mode frequency, which should make the switch command and
subsequent CMD13 commands more reliable.

This patch does that.

Signed-off-by: Adrian Hunter 
Cc:  # 4.2+
Tested-by: Alim Akhtar 
Signed-off-by: Ulf Hansson

mmc: mmc: Improve reliability of mmc_select_hs200()

2015-11-09T12:12:08+00:00

Currently mmc_select_hs200() uses __mmc_switch() which checks the
success of the switch to HS200 mode using CMD13 (SEND_STATUS).
The problem is that it does that using the timing settings of legacy
mode.  That is prone to error, not least because the timing parameters
for legacy mode are tighter than the timing parameters for HS200 mode.

In the case when CMD13 polling is used (i.e. not MMC_CAP_WAIT_WHILE_BUSY)
with the switch command, it must be assumed that using different modes on
the card and host must work.

However in the case when CMD13 polling is not used
(i.e. MMC_CAP_WAIT_WHILE_BUSY) mmc_select_hs200() can be made more
reliable by setting the host to the correct timing before sending CMD13.

This patch does that.

A complication is that the caller, mmc_select_timing(), will ignore a
switch error (indicated by -EBADMSG), assume the old mode is valid
and continue, so the old timing must be restored in that case.

Signed-off-by: Adrian Hunter 
Cc:  # 4.2+
Tested-by: Alim Akhtar 
Signed-off-by: Ulf Hansson

mmc: pwrseq: Use highest priority for eMMC restart handler

2015-10-27T10:11:06+00:00

The pwrseq_emmc driver does a eMMC card reset before a system reboot to
allow broken or limited ROM boot-loaders (that don't have an eMMC reset
logic) to be able to read the second stage from the eMMC.

But this has to be called before a system reboot handler and while most
of them use the priority 128, there are other restart handlers (such as
the syscon-reboot one) that use a higher priority. So, use the highest
priority to make sure that the eMMC hw is reset before a system reboot.

Signed-off-by: Javier Martinez Canillas 
Tested-by: Markus Reichl 
Tested-by: Anand Moon 
Reviewed-by: Alim Akhtar 
Tested-by: Douglas Anderson 
Signed-off-by: Ulf Hansson

mmc: mmc: extend the mmc_send_tuning()

2015-10-27T09:38:41+00:00

The mmc_execute_tuning() has already prepared the opcode,
there is no need to prepare it again at mmc_send_tuning(),
and, there is a BUG of mmc_send_tuning() to determine the opcode
by bus width, assume eMMC was running at HS200, 4bit mode,
then the mmc_send_tuning() will overwrite the opcode from CMD21
to CMD19, then got error.

in addition, extend an argument of "cmd_error" to allow getting
if there was cmd error when tune response.

Signed-off-by: Chaotian Jing 
[Ulf: Rebased patch]
Signed-off-by: Ulf Hansson

mmc: core: Add DT bindings for eMMC hardware reset support

2015-10-27T09:21:15+00:00

Sometime only need set MMC_CAP_HW_RESET for one of MMC hosts,
So set it in device tree is better.

Signed-off-by: Chaotian Jing 
Signed-off-by: Ulf Hansson

mmc: skip reclaiming host on mmc_add_card() error

2015-10-26T15:00:14+00:00

There's little sense in releasing the host on mmc_add_card() error
immediately after reclaiming  it, so reclaim the host  only in case
of success.

Signed-off-by: Sergei Shtylyov 
Signed-off-by: Ulf Hansson

mmc: core: Add mmc_regulator_set_vqmmc()

2015-10-26T15:00:10+00:00

This adds logic to the MMC core to set VQMMC.  This is expected to be
called by MMC drivers like dw_mmc as part of (or instead of) their
start_signal_voltage_switch() callback.

A few notes:

* When setting the signal voltage to 3.3V we do our best to make VQMMC
  and VMMC match.  It's been reported that this makes some old cards
  happy since they were tested back in the day before UHS when VQMMC
  and VMMC were provided by the same regulator.  A nice side effect of
  this is that we don't end up on the hairy edge of VQMMC (2.7V),
  which some EEs claim is a little too close to the minimum for
  comfort.
  This is done in two steps. At first we try to find a VQMMC within
  a 0.3V tolerance of VMMC and if this is not supported by the
  supplying regulator we try to find a suitable voltage within the
  whole 2.7V-3.6V area of the spec.

* The two step approach is currently necessary, as the used
  regulator_set_voltage_triplet(min, target, max) uses a simple
  implementation that just tries two basic steps:
	regulator_set_voltage(target, max);
	regulator_set_voltage(min, target);
  So with only one step with 2.7-3.6V borders, if a suitable voltage
  is a bit below VMMC, we would directly get the lowest 2.7V
  which some boards (like Rockchips) don't like at all.

* When setting the signal voltage to 1.8V or 1.2V we aim for that
  specific voltage instead of picking the lowest one in the range.

* We very purposely don't print errors in mmc_regulator_set_vqmmc().
  There are cases where the MMC core will try several different
  voltages and we don't want to pollute the logs.

Signed-off-by: Douglas Anderson 
Signed-off-by: Heiko Stuebner 
Signed-off-by: Ulf Hansson

mmc: core: move ocr-bit to voltage translation into separate function

2015-10-26T15:00:10+00:00

We will shortly need the calculation of an ocr-bit to the actual
voltage in a second place too, so move it from mmc_regulator_set_ocr
to a common function mmc_ocrbitnum_to_vdd to make that possible.

Signed-off-by: Heiko Stuebner 
Signed-off-by: Ulf Hansson