| Message ID | 20230915160130.352099-3-jbrunet@baylibre.com |
|---|---|
| State | Deferred |
| Delegated to: | Tom Rini |
| Headers | show |
| Series | mmc: meson-gx: improve MMC reliabilty | expand |
After running some tests, I've noticed inconsistent behavior with the eMMC:
On a cold boot (following a shutdown), the eMMC operates as expected within U-Boot.
On a hot reboot (via the kernel's reboot command), the eMMC sometimes (not always, but if
fit in error, next need to do poweroff) does not work:
U-Boot is able to read the dtb file but won't boot kernel completely, or
U-Boot might fail to read from the eMMC altogether.
This behavior had not occurred before (when the phase was set to 270 on axg).
On Fri, 2023-09-15 at 18:01 +0200, Jerome Brunet wrote:
> It has been reported that some devices have problems with a 180 degree
> core phase. Setting 270 helped some of these devices. Other continue to
> struggle (while it works fine with 180 in Linux ... :sigh:)
>
> Poking around the HW, it seems that setting a 270 core phase during the
> identification, then using 180 for the rest of the operations, helps the
> device operate correctly.
>
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> ---
> drivers/mmc/meson_gx_mmc.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/meson_gx_mmc.c b/drivers/mmc/meson_gx_mmc.c
> index c6168792cbae..284be2b9dca4 100644
> --- a/drivers/mmc/meson_gx_mmc.c
> +++ b/drivers/mmc/meson_gx_mmc.c
> @@ -54,9 +54,14 @@ static void meson_mmc_config_clock(struct mmc *mmc)
>
> /* Clk always on */
> meson_mmc_clk |= pdata->version->clk_always_on;
> - meson_mmc_clk |= CLK_CO_PHASE_180;
> meson_mmc_clk |= CLK_TX_PHASE_000;
>
> + /* Core phase according to mode */
> + if (mmc->selected_mode == MMC_LEGACY)
> + meson_mmc_clk |= CLK_CO_PHASE_270;
> + else
> + meson_mmc_clk |= CLK_CO_PHASE_180;
> +
> /* 1GHz / CLK_MAX_DIV = 15,9 MHz */
> if (mmc->clock > 16000000) {
> clk = SD_EMMC_CLKSRC_DIV2;
On Thu 09 Nov 2023 at 16:49, Viacheslav <adeep@lexina.in> wrote: > After running some tests, I've noticed inconsistent behavior with the eMMC: > On a cold boot (following a shutdown), the eMMC operates as expected within U-Boot. > On a hot reboot (via the kernel's reboot command), the eMMC sometimes (not always, but if > fit in error, next need to do poweroff) does not work: No sure I understand. MMC appears to work (passes the ID phases - which was the problem before) but fitImage (or dtb) you get is not correct out of eMMC read, is not correct ? Have you checked the content ? some checksum maybe ? What does 'mmc info' reports on boot and reboot (when it fails or not) ? > U-Boot is able to read the dtb file but won't boot kernel completely, or > U-Boot might fail to read from the eMMC altogether. > > This behavior had not occurred before (when the phase was set to 270 on axg). > > On Fri, 2023-09-15 at 18:01 +0200, Jerome Brunet wrote: >> It has been reported that some devices have problems with a 180 degree >> core phase. Setting 270 helped some of these devices. Other continue to >> struggle (while it works fine with 180 in Linux ... :sigh:) >> >> Poking around the HW, it seems that setting a 270 core phase during the >> identification, then using 180 for the rest of the operations, helps the >> device operate correctly. >> >> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> >> --- >> drivers/mmc/meson_gx_mmc.c | 7 ++++++- >> 1 file changed, 6 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/mmc/meson_gx_mmc.c b/drivers/mmc/meson_gx_mmc.c >> index c6168792cbae..284be2b9dca4 100644 >> --- a/drivers/mmc/meson_gx_mmc.c >> +++ b/drivers/mmc/meson_gx_mmc.c >> @@ -54,9 +54,14 @@ static void meson_mmc_config_clock(struct mmc *mmc) >> >> /* Clk always on */ >> meson_mmc_clk |= pdata->version->clk_always_on; >> - meson_mmc_clk |= CLK_CO_PHASE_180; >> meson_mmc_clk |= CLK_TX_PHASE_000; >> >> + /* Core phase according to mode */ >> + if (mmc->selected_mode == MMC_LEGACY) >> + meson_mmc_clk |= CLK_CO_PHASE_270; >> + else >> + meson_mmc_clk |= CLK_CO_PHASE_180; >> + >> /* 1GHz / CLK_MAX_DIV = 15,9 MHz */ >> if (mmc->clock > 16000000) { >> clk = SD_EMMC_CLKSRC_DIV2;
diff --git a/drivers/mmc/meson_gx_mmc.c b/drivers/mmc/meson_gx_mmc.c index c6168792cbae..284be2b9dca4 100644 --- a/drivers/mmc/meson_gx_mmc.c +++ b/drivers/mmc/meson_gx_mmc.c @@ -54,9 +54,14 @@ static void meson_mmc_config_clock(struct mmc *mmc) /* Clk always on */ meson_mmc_clk |= pdata->version->clk_always_on; - meson_mmc_clk |= CLK_CO_PHASE_180; meson_mmc_clk |= CLK_TX_PHASE_000; + /* Core phase according to mode */ + if (mmc->selected_mode == MMC_LEGACY) + meson_mmc_clk |= CLK_CO_PHASE_270; + else + meson_mmc_clk |= CLK_CO_PHASE_180; + /* 1GHz / CLK_MAX_DIV = 15,9 MHz */ if (mmc->clock > 16000000) { clk = SD_EMMC_CLKSRC_DIV2;
It has been reported that some devices have problems with a 180 degree core phase. Setting 270 helped some of these devices. Other continue to struggle (while it works fine with 180 in Linux ... :sigh:) Poking around the HW, it seems that setting a 270 core phase during the identification, then using 180 for the rest of the operations, helps the device operate correctly. Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> --- drivers/mmc/meson_gx_mmc.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)