[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAPDyKFqhqNn1ZDQxshRidN=Odv6sTEcRz54=radQhknfx60Ovw@mail.gmail.com>
Date: Fri, 22 Apr 2022 11:10:32 +0200
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Brian Norris <briannorris@...omium.org>
Cc: Shawn Lin <shawn.lin@...k-chips.com>, linux-mmc@...r.kernel.org,
Douglas Anderson <dianders@...omium.org>,
Luca Weiss <luca@...tu.xyz>, linux-kernel@...r.kernel.org,
Heiner Kallweit <hkallweit1@...il.com>,
Adrian Hunter <adrian.hunter@...el.com>
Subject: Re: [PATCH v2] mmc: core: Don't set HS200 clock rate prematurely
On Fri, 22 Apr 2022 at 02:23, Brian Norris <briannorris@...omium.org> wrote:
>
> Commit 1c7ec586fe55 ("mmc: core: Set HS clock speed before sending HS
> CMD13") fixes problems with certain eMMC, but introduced new ones with
> others:
>
> qcom-msm8974-fairphone-fp2:
>
> [ 1.868608] mmc0: SDHCI controller on f9824900.sdhci [f9824900.sdhci] using ADMA 64-bit
> [ 1.925220] mmc0: mmc_select_hs200 failed, error -110
> [ 1.925285] mmc0: error -110 whilst initialising MMC card
>
> It appears we've overshot the acceptable clock rate here; while JESD84
> suggests that we can bump to 52 MHz before switching (CMD6) to HS400, it
> does *not* say we can switch to 200 MHz before switching to HS200 (see
> page 45 / table 28). Use the HS bounds (typically 52 MHz) instead of the
> HS200 bounds (which are only applicable after we successfully switch).
>
> Link: https://lore.kernel.org/lkml/11962455.O9o76ZdvQC@g550jk/
> Fixes: 1c7ec586fe55 ("mmc: core: Set HS clock speed before sending HS CMD13")
> Reported-by: Luca Weiss <luca@...tu.xyz>
> Signed-off-by: Brian Norris <briannorris@...omium.org>
Rather than applying this incremental patch, I decided to drop the
offending commit from my branch. Please submit a new version of that
patch and make sure to incorporate credits and information provided by
Luca, as a part of the new commit message.
The main reason for this step is that I think we want a clean patch
that we can use for stable kernels too.
Moreover, this also means you can drop the changes in mmc_set_clock()
that was introduced in 1c7ec586fe55().
Kind regards
Uffe
> ---
> Apologies for the quick resend; I fumbled the commit/send, even though I
> had already updated the comments...
>
> Changes in v2:
> * Updated comments
>
> drivers/mmc/core/mmc.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index 9ab915b5737a..82ca62c8669c 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -1485,13 +1485,15 @@ static int mmc_select_hs200(struct mmc_card *card)
> goto err;
>
> /*
> - * Bump to HS200 timing and frequency. Some cards don't
> - * handle SEND_STATUS reliably at the initial frequency.
> + * Bump to HS timing and frequency. Some cards don't handle
> + * SEND_STATUS reliably at the initial frequency.
> + * NB: We can't move to full (HS200) speeds until after we've
> + * successfully switched over.
> */
> old_timing = host->ios.timing;
> old_clock = host->ios.clock;
> mmc_set_timing(host, MMC_TIMING_MMC_HS200);
> - mmc_set_bus_speed(card);
> + mmc_set_clock(card->host, card->ext_csd.hs_max_dtr);
>
> /*
> * For HS200, CRC errors are not a reliable way to know the
> --
> 2.36.0.rc2.479.g8af0fa9b8e-goog
>
Powered by blists - more mailing lists