u-boot.git/include/mmc.h, branch v2020.04 Unnamed repository; edit this file 'description' to name the repository. mmc: Merge SD_LEGACY and MMC_LEGACY bus modes 2020-03-09T00:33:16+00:00 Faiz Abbas faiz_abbas@ti.com 2020-02-26T08:14:32+00:00 e8d5dde4473514327b5ea67fb69d8fdd8410240c MMC_LEGACY & SD_LEGACY are not differentiated timings in the spec and don't have any meaningful differences. Therefore, get rid of all references to SD_LEGACY and use MMC_LEGACY to mean both of them. Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> 
MMC_LEGACY & SD_LEGACY are not differentiated timings in the spec and
don't have any meaningful differences. Therefore, get rid of all
references to SD_LEGACY and use MMC_LEGACY to mean both of them.

Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
mmc: Add a deferred_probe() API 2020-03-09T00:33:15+00:00 Faiz Abbas faiz_abbas@ti.com 2020-02-26T08:14:30+00:00 32860bdbc1f2d4133c1ef38685c6b02368136fbb Add a deferred_probe() API for platforms that want to do some configurations just before starting to enumerate the device. Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> 
Add a deferred_probe() API for platforms that want to do some
configurations just before starting to enumerate the device.

Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
mmc: Add a saved_clock member 2020-03-09T00:33:15+00:00 Faiz Abbas faiz_abbas@ti.com 2020-02-26T08:14:29+00:00 0d3c8584885a7c76929bfa59fa34e44a2134ae1f Add a saved_clock member to struct mmc to store the previous clock speed in the clock needs to be stopped for some time. Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> 
Add a saved_clock member to struct mmc to store the previous clock speed
in the clock needs to be stopped for some time.

Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
mmc: make <mmc.h> self-contained 2020-03-09T00:33:15+00:00 Masahiro Yamada masahiroy@kernel.org 2020-02-24T17:25:30+00:00 bd602c536771c53d0d56273d8f7d6596425b8f5c This header uses bd_t without including its definition. Change it to (struct bd_info), and add the forward declaration to specify it as a structure. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com> 
This header uses bd_t without including its definition.

Change it to (struct bd_info), and add the forward declaration
to specify it as a structure.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
mmc: add mmc_get_dma_dir() helper 2020-02-20T07:09:56+00:00 Masahiro Yamada yamada.masahiro@socionext.com 2020-02-14T07:40:25+00:00 a7b2b6cc0aa9294b570a3161a05c6ccf4c0b6e40 Copied from Linux kernel. include/linux/mmc/host.h Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com> 
Copied from Linux kernel.
include/linux/mmc/host.h

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
mmc: add additional quirk for APP_CMD retry 2020-01-16T05:21:01+00:00 Joel Johnson mrjoel@lixil.net 2020-01-11T16:08:14+00:00 d4a5fa314db9e18535a8672919ac235daf5e20b9 It was observed (on ClearFog Base) that sending MMC APP_CMD returned an error on the first attempt. The issue appears to be timing related since even inserting a puts() short debug entry before the execution added sufficient delay to receive success on first attempt. Follow the existing quirks pattern to retry if initial issuance failed so as to not introduce any delay unless needed. Signed-off-by: Joel Johnson <mrjoel@lixil.net> 
It was observed (on ClearFog Base) that sending MMC APP_CMD returned
an error on the first attempt. The issue appears to be timing related
since even inserting a puts() short debug entry before the execution
added sufficient delay to receive success on first attempt.

Follow the existing quirks pattern to retry if initial issuance
failed so as to not introduce any delay unless needed.

Signed-off-by: Joel Johnson <mrjoel@lixil.net>
mmc: add a driver callback for power-cycle 2019-10-10T02:59:48+00:00 Yann Gautier yann.gautier@st.com 2019-09-19T15:56:12+00:00 3602a56ac637952ea8d1b49ad525a0d70982fd92 Some MMC peripherals require specific power cycle sequence, where some registers need to be written between the regulator is turned off and then back on. This is the case for the MMC IP embedded in STM32MP1 SoC. In STM32MP157 reference manual [1], the power cycle sequence is: 1. Reset the SDMMC with the RCC.SDMMCxRST register bit. This will reset the SDMMC to the reset state and the CPSM and DPSM to the Idle state. 2. Disable the Vcc power to the card. 3. Set the SDMMC in power-cycle state. This will make that the SDMMC_D[7:0], SDMMC_CMD and SDMMC_CK are driven low, to prevent the card from being supplied through the signal lines. 4. After minimum 1ms enable the Vcc power to the card. 5. After the power ramp period set the SDMMC to the power-off state for minimum 1ms. The SDMMC_D[7:0], SDMMC_CMD and SDMMC_CK are set to drive “1”. 6. After the 1ms delay set the SDMMC to power-on state in which the SDMMC_CK clock will be enabled. 7. After 74 SDMMC_CK cycles the first command can be sent to the card. The step 3. cannot be handled by the current framework implementation. A new callback (host_power_cycle) is created, and called in mmc_power_cycle(), after mmc_power_off(). The incorrect power cycle sequence has shown some boot failures on STM32MP1 with some SD-cards, especially on cold boots when the input frequency is low (<= 25MHz). Those failures are no more seen with this correct power cycle sequence. [1] https://www.st.com/resource/en/reference_manual/DM00327659.pdf Signed-off-by: Yann Gautier <yann.gautier@st.com> 
Some MMC peripherals require specific power cycle sequence, where some
registers need to be written between the regulator is turned off and then
back on. This is the case for the MMC IP embedded in STM32MP1 SoC.

In STM32MP157 reference manual [1], the power cycle sequence is:
1. Reset the SDMMC with the RCC.SDMMCxRST register bit. This will reset
the SDMMC to the reset state and the CPSM and DPSM to the Idle state.
2. Disable the Vcc power to the card.
3. Set the SDMMC in power-cycle state. This will make that the
SDMMC_D[7:0], SDMMC_CMD and SDMMC_CK are driven low, to prevent the card
from being supplied through the signal lines.
4. After minimum 1ms enable the Vcc power to the card.
5. After the power ramp period set the SDMMC to the power-off state for
minimum 1ms. The SDMMC_D[7:0], SDMMC_CMD and SDMMC_CK are set to
drive “1”.
6. After the 1ms delay set the SDMMC to power-on state in which the
SDMMC_CK clock will be enabled.
7. After 74 SDMMC_CK cycles the first command can be sent to the card.

The step 3. cannot be handled by the current framework implementation.
A new callback (host_power_cycle) is created, and called in
mmc_power_cycle(), after mmc_power_off().

The incorrect power cycle sequence has shown some boot failures on
STM32MP1 with some SD-cards, especially on cold boots when the input
frequency is low (<= 25MHz).
Those failures are no more seen with this correct power cycle sequence.

[1] https://www.st.com/resource/en/reference_manual/DM00327659.pdf

Signed-off-by: Yann Gautier <yann.gautier@st.com>
spl: dm_mmc: Initialize only the required mmc device 2019-10-10T02:59:48+00:00 Lokesh Vutla lokeshvutla@ti.com 2019-09-09T09:10:36+00:00 80f02019ee6901a7fb0979677030f33fb9b1fa69 In SPL, all the available mmc devices gets initialized during boot. This might not work in cases where clocks are not available for certain mmc devices(other than boot device) and the support for enabling device might not be ready. Texas Instruments' K3 J721E device having a central system controller (dmsc) is one such example falling in this category. Below is the sequence for the failing scenario: - ROM comes up in SD mode and loads SPL by just initialing SD card. - SPL loads dmsc firmware from SD Card. Since ROM has enabled SD, SPL need not enable the SD, just need to re initialize the card. But SPL is trying to initialize other MMC instances which are in disabled state. Since dmsc firmware is not yet available, devices cannot be enabled. So in SPL, initialize only the mmc device that is needed. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> 
In SPL, all the available mmc devices gets initialized during boot.
This might not work in cases where clocks are not available for
certain mmc devices(other than boot device) and the support for
enabling device might not be ready.

Texas Instruments' K3 J721E device having a central system controller
(dmsc) is one such example falling in this category. Below is the
sequence for the failing scenario:
- ROM comes up in SD mode and loads SPL by just initialing SD card.
- SPL loads dmsc firmware from SD Card.
Since ROM has enabled SD, SPL need not enable the SD, just need
to re initialize the card. But SPL is trying to initialize other MMC
instances which are in disabled state. Since dmsc firmware is not yet
available, devices cannot be enabled. So in SPL, initialize only the
mmc device that is needed.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
mmc: Rename timeout parameters for clarification 2019-09-05T07:27:31+00:00 Sam Protsenko semen.protsenko@linaro.org 2019-08-14T19:52:51+00:00 6cf8a903c5e6723104b07b0fddc4a703556e558a It's quite hard to figure out time units for various function that have timeout parameters. This leads to possible errors when one forgets to convert ms to us, for example. Let's rename those parameters correspondingly to 'timeout_us' and 'timeout_ms' to prevent such issues further. While at it, add time units info as comments to struct mmc fields. This commit doesn't change the behavior, only renames parameters names. Buildman should report no changes at all. Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Reviewed-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Igor Opaniuk <igor.opaniuk@gmail.com> 
It's quite hard to figure out time units for various function that have
timeout parameters. This leads to possible errors when one forgets to
convert ms to us, for example. Let's rename those parameters
correspondingly to 'timeout_us' and 'timeout_ms' to prevent such issues
further.

While at it, add time units info as comments to struct mmc fields.

This commit doesn't change the behavior, only renames parameters names.
Buildman should report no changes at all.

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Igor Opaniuk <igor.opaniuk@gmail.com>
mmc: support hs400 enhanced strobe mode 2019-07-15T02:30:08+00:00 Peng Fan peng.fan@nxp.com 2019-07-10T06:43:07+00:00 44acd492480f8c8047326f3cb02d3e4d3760ecd0 eMMC 5.1+ supports HS400 Enhances Strobe mode without the need for tuning procedure. The flow is as following: - set HS_TIMIMG (Highspeed) - Host change freq to <= 52Mhz - set the bus width to Enhanced strobe and DDR8Bit(CMD6), EXT_CSD[183] = 0x86 instead of 0x80 - set HS_TIMING to 0x3 (HS400) - Host change freq to <= 200Mhz - Host select HS400 enhanced strobe complete Signed-off-by: Peng Fan <peng.fan@nxp.com> 
eMMC 5.1+ supports HS400 Enhances Strobe mode without the need for
tuning procedure.
The flow is as following:
 - set HS_TIMIMG (Highspeed)
 - Host change freq to <= 52Mhz
 - set the bus width to Enhanced strobe and DDR8Bit(CMD6),
   EXT_CSD[183] = 0x86 instead of 0x80
 - set HS_TIMING to 0x3 (HS400)
 - Host change freq to <= 200Mhz
 - Host select HS400 enhanced strobe complete

Signed-off-by: Peng Fan <peng.fan@nxp.com>