u-boot.git/drivers/mmc, branch v2020.07

mmc: sdhci: Fix HISPD bit handling

2020-06-24T06:05:30+00:00

SDHCI HISPD bits need to be configured based on desired mmc
timings mode and some HISPD quirks.

So, handle the HISPD bit based on the mmc computed selected
mode(timing parameter) rather than fixed mmc card clock
frequency.

Linux handle the HISPD similar like this in below commit but no
SDHCI_QUIRK_BROKEN_HISPD_MODE,

commit <501639bf2173> ("mmc: sdhci: fix SDHCI_QUIRK_NO_HISPD_BIT handling")

This eventually fixed the mmc write issue observed in
rk3399 sdhci controller.

Bug log for refernece,
=> gpt write mmc 0 $partitions
Writing GPT: mmc write failed
** Can't write to device 0 **
** Can't write to device 0 **
error!

Cc: Kever Yang 
Cc: Peng Fan 
Peng Fan: added back "ctrl &= ~SDHCI_CTRL_HISPD;" per Jaehoon's suggestion
Tested-by: Suniel Mahesh  # roc-rk3399-pc
Signed-off-by: Jagan Teki

mmc: retry CMD1 in mmc_send_op_cond() until the eMMC is ready

2020-06-24T06:05:30+00:00

According to eMMC specification v5.1 section 6.4.3, we should issue
CMD1 repeatedly in the idle state until the eMMC is ready even if
mmc_send_op_cond() send CMD1 with argument = 0. Otherwise some eMMC
devices seems to enter the inactive mode after mmc_complete_op_cond()
issued CMD0 when the eMMC device is busy.

Signed-off-by: Haibo Chen 
Reviewed-by: Peng Fan

mmc: fsl_esdhc_imx: disable the CMD CRC check for standard tuning

2020-06-24T06:05:30+00:00

In current code, we add 1ms dealy after each tuning command for standard
tuning method. Adding this 1ms dealy is because USDHC default check the
CMD CRC and DATA line. If detect the CMD CRC, USDHC standard tuning
IC logic do not wait for the tuning data sending out by the card, trigger
the buffer read ready interrupt immediately, and step to next cycle. So
when next time the new tuning command send out by USDHC, card may still
not send out the tuning data of the upper command，then some eMMC cards
may stuck, can't response to any command, block the whole tuning procedure.

If do not check the CMD CRC for tuning, then do not has this issue. USDHC
will wait for the tuning data of each tuning command and check them. If the
tuning data pass the check, it also means the CMD line also okay for tuning.

So this patch disable the CMD CRC check for tuning, save some time for the
whole tuning procedure.

Signed-off-by: Haibo Chen

mmc: fsl_esdhc: Gracefully fail on unsupported voltage switch

2020-06-15T01:45:22+00:00

Unsupported voltage on voltage switch is not an error, do not
print error message in such a case. This happens e.g. if the
eMMC is already in 1V8 mode or when testing 1V2 mode operation
on systems which only do 3V3/1V8 switching.

Signed-off-by: Marek Vasut 
Cc: Fabio Estevam 
Cc: Jaehoon Chung 
Cc: Peng Fan 
Cc: Stefano Babic 
Reviewed-by: Jaehoon Chung

mmc: fsl_esdhc: Fix SDR104 and HS200 support

2020-06-15T01:45:22+00:00

The 3V3/1V8 switching could never have worked on any of the iMXes
ever since 51313b49f2 ("mmc: fsl_esdhc: support SDR104 and HS200"),
because that commit uses priv->vqmmc_dev when switching voltages on
mode switch, while local vqmmc_dev in probe to store the regulator
pointer. Those are two different variables with the same name. So
the priv->vqmmc_dev was always NULL and thus voltage switch between
modes never really suceeded.

Fix this by assigning priv->vqmmc_dev with value of the vqmmc_dev
in probe.

Fixes: 51313b49f2 ("mmc: fsl_esdhc: support SDR104 and HS200")
Signed-off-by: Marek Vasut 
Cc: Fabio Estevam 
Cc: Jaehoon Chung 
Cc: Peng Fan 
Cc: Stefano Babic 
Reviewed-by: Jaehoon Chung

mmc: ca_dw_mmc: Misc cleanup of driver

2020-06-15T01:45:22+00:00

- Rename DT compatible name
- Remove uneccessary if-statement to support 8-bit buswidth
- Remove redundant error msg
- Use symbolic constants in switch statement

Signed-off-by: Arthur Li 
Signed-off-by: Alex Nemirovsky 
CC: Peng Fan 
CC: Jaehoon Chung 
CC: Tom Rini

mmc: fsl_esdhc: workaround for hardware 3.3v IO reliability issue

2020-06-15T01:45:22+00:00

When eSDHC operates at 3.3v, damage can accumulate in an internal
level shifter at a higher than expected rate. The faster the interface
runs, the more damage accumulates. This issue now is found on LX2160A
eSDHC1 for only SD card.

The hardware workaround is recommended to use an on-board level shifter
that is 1.8v on SoC side and 3.3v on SD card side.

For boards without hardware workaround, this option could be enabled,
ensuring 1.8v IO voltage and disabling eSDHC if no card.
This option assumes no hotplug, and u-boot has to make all the way to
to linux to use 1.8v UHS-I speed mode if has card.
If you do not want the workaround for better user experience, of course
you can choose to not select it running eSDHC in unsafe mode.

Signed-off-by: Yangbo Lu 
Acked-by: Peng Fan

mmc: fsl_esdhc: read register once for card inserted status

2020-06-15T01:45:22+00:00

No need to poll register for card inserted status.

Signed-off-by: Yangbo Lu 
Acked-by: Peng Fan

common: Drop linux/bitops.h from common header

2020-05-19T01:19:23+00:00

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass

common: Drop linux/delay.h from common header

2020-05-19T01:19:23+00:00

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass