| Message ID | 20190423090235.17244-5-jbrunet@baylibre.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | mmc: meson-gx: clean up and tuning update | expand |
Hi Jerome, On Tue, Apr 23, 2019 at 11:03 AM Jerome Brunet <jbrunet@baylibre.com> wrote: > > At the moment, all our attempts to enable HS400 on Amlogic chipsets have > been unsuccessful or unreliable. Until we can figure out how to enable this > mode safely and reliably, let's force it off. last year I have seen issues with HS400 on my Khadas VIM2: [0] have you tested all other patches from this series and HS400 is still not working for you? I'm curious because this patch is early in the series and all the tuning fixes and improvements are after this patch. Martin [0] http://lists.infradead.org/pipermail/linux-amlogic/2018-January/006251.html
On Sat, 2019-04-27 at 22:02 +0200, Martin Blumenstingl wrote: > Hi Jerome, > > On Tue, Apr 23, 2019 at 11:03 AM Jerome Brunet <jbrunet@baylibre.com> wrote: > > At the moment, all our attempts to enable HS400 on Amlogic chipsets have > > been unsuccessful or unreliable. Until we can figure out how to enable this > > mode safely and reliably, let's force it off. > last year I have seen issues with HS400 on my Khadas VIM2: [0] > have you tested all other patches from this series and HS400 is still > not working for you? Because HS400 was never really stable to begin with. It was a mistake to enable it on the VIM2 > > I'm curious because this patch is early in the series and all the > tuning fixes and improvements are after this patch. There are several reasons why this new tuning won't solve the HS400 problem: - Signal resampling tuning granularity gets worse when rate rises. The resampling is done using the input frequency. We can basically resample up to the value of internal divider. In HS200 - Fin is 1GHz, Fout is 200MHz (1/5) so the resample range is [0, 4] In HS400 - Fin should be fdiv5 (400MHZ) and in such case, no resampling is possible (internal div = 1) Even if we keep 1GHz, then out is 333MHz max giving a range of [0, 2] that's not enough to tune Going further, tuning the Rx path does not make much sense in HS400 since we should be using the data strobe signal to account for the round trip delay of the clock and correctly sample Rx. AFAICT, If there is a tuning to be done for HS400, it is most likely linked to the data strobe. > > > Martin > > > [0] http://lists.infradead.org/pipermail/linux-amlogic/2018-January/006251.html
Hi Jerome, On Mon, Apr 29, 2019 at 10:29 AM Jerome Brunet <jbrunet@baylibre.com> wrote: > > On Sat, 2019-04-27 at 22:02 +0200, Martin Blumenstingl wrote: > > Hi Jerome, > > > > On Tue, Apr 23, 2019 at 11:03 AM Jerome Brunet <jbrunet@baylibre.com> wrote: > > > At the moment, all our attempts to enable HS400 on Amlogic chipsets have > > > been unsuccessful or unreliable. Until we can figure out how to enable this > > > mode safely and reliably, let's force it off. > > last year I have seen issues with HS400 on my Khadas VIM2: [0] > > have you tested all other patches from this series and HS400 is still > > not working for you? > > Because HS400 was never really stable to begin with. > It was a mistake to enable it on the VIM2 > > > > > I'm curious because this patch is early in the series and all the > > tuning fixes and improvements are after this patch. > > There are several reasons why this new tuning won't solve the HS400 problem: > - Signal resampling tuning granularity gets worse when rate rises. The resampling > is done using the input frequency. We can basically resample up to the value of > internal divider. > > In HS200 - Fin is 1GHz, Fout is 200MHz (1/5) so the resample range is [0, 4] > In HS400 - Fin should be fdiv5 (400MHZ) and in such case, no resampling is > possible (internal div = 1) > Even if we keep 1GHz, then out is 333MHz max giving a range of [0, 2] > that's not enough to tune this limitation would be great to have in the description of patch 7 from this series > Going further, tuning the Rx path does not make much sense in HS400 since we > should be using the data strobe signal to account for the round trip delay of > the clock and correctly sample Rx. AFAICT, If there is a tuning to be done for > HS400, it is most likely linked to the data strobe. it would be great to have a better description as part of the commit message - with that you can add my: Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> my proposal for an update patch description (apologies I have incorrectly summarized your findings): " At the moment, all our attempts to enable HS400 on Amlogic chipsets have been unsuccessful or unreliable: - signal resampling without delay adjustments and phase tuning for the RX and TX clocks (this caused CRC errors and hangs even without HS400 mode, for example on the Khadas VIM, Khadas VIM2 and libretech-cc boards) - signal resampling without delay adjustments and RX clock phase tuning (some HS200 and HS400 eMMC chips were not recognized, for example on the Khadas VIM and Khadas VIM2 boards) - signal resampling tuning with delay adjustments only (works fine for HS200 and UHS modes but doesn't fix HS400 eMMC chips, for example on Khadas VIM2) Further improvements for the HS400 mode are likely to be linked to the data strobe signal. Until we can figure out how to enable this mode safely and reliably, let's force it off. " This whole series is a good step forward. also thank you for this additional explanation! Regards Martin
On Mon, 2019-04-29 at 20:31 +0200, Martin Blumenstingl wrote: > Hi Jerome, > > On Mon, Apr 29, 2019 at 10:29 AM Jerome Brunet <jbrunet@baylibre.com> wrote: > > On Sat, 2019-04-27 at 22:02 +0200, Martin Blumenstingl wrote: > > > Hi Jerome, > > > > > > On Tue, Apr 23, 2019 at 11:03 AM Jerome Brunet <jbrunet@baylibre.com> wrote: > > > > At the moment, all our attempts to enable HS400 on Amlogic chipsets have > > > > been unsuccessful or unreliable. Until we can figure out how to enable this > > > > mode safely and reliably, let's force it off. > > > last year I have seen issues with HS400 on my Khadas VIM2: [0] > > > have you tested all other patches from this series and HS400 is still > > > not working for you? > > > > Because HS400 was never really stable to begin with. > > It was a mistake to enable it on the VIM2 > > > > > I'm curious because this patch is early in the series and all the > > > tuning fixes and improvements are after this patch. > > > > There are several reasons why this new tuning won't solve the HS400 problem: > > - Signal resampling tuning granularity gets worse when rate rises. The resampling > > is done using the input frequency. We can basically resample up to the value of > > internal divider. > > > > In HS200 - Fin is 1GHz, Fout is 200MHz (1/5) so the resample range is [0, 4] > > In HS400 - Fin should be fdiv5 (400MHZ) and in such case, no resampling is > > possible (internal div = 1) > > Even if we keep 1GHz, then out is 333MHz max giving a range of [0, 2] > > that's not enough to tune > this limitation would be great to have in the description of patch 7 > from this series That's not really a limitation. I should probably not have mentioned as it it seems to have made things even more unclear. I disabled HS400 before introducing the new tuning on purpose. Any comment regarding hs400 does not belong in patch 7 IHMO. If you want to add comment regarding hs400, I think it belongs here > > > Going further, tuning the Rx path does not make much sense in HS400 since we > > should be using the data strobe signal to account for the round trip delay of > > the clock and correctly sample Rx. AFAICT, If there is a tuning to be done for > > HS400, it is most likely linked to the data strobe. > it would be great to have a better description as part of the commit > message - with that you can add my: > Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> > > my proposal for an update patch description (apologies I have > incorrectly summarized your findings): > " > At the moment, all our attempts to enable HS400 on Amlogic chipsets have > been unsuccessful or unreliable: > - signal resampling without delay adjustments and phase tuning for the > RX and TX clocks (this caused CRC errors and hangs even without HS400 > mode, for example on the Khadas VIM, Khadas VIM2 and libretech-cc > boards) > - signal resampling without delay adjustments and RX clock phase > tuning (some HS200 and HS400 eMMC chips were not recognized, for > example on the Khadas VIM and Khadas VIM2 boards) > - signal resampling tuning with delay adjustments only (works fine for > HS200 and UHS modes but doesn't fix HS400 eMMC chips, for example on > Khadas VIM2) > > Further improvements for the HS400 mode are likely to be linked to the > data strobe signal. > Until we can figure out how to enable this mode safely and reliably, > let's force it off. > " Thanks for effort but all this just maintain the blur around HS400 on amlogic. Let me rephrase it: Tuning (phase or resampling) is meant to compensate the clock round trip in UHS and HS200 modes. In HS400, this should be taken care of by the data strobe. But we have not been to enable this reliably enable this on amlogic chipset ... ... and I believe we are back to the original commit message. That's my understanding of the hs400 problem. > > This whole series is a good step forward. > also thank you for this additional explanation! > > > Regards > Martin
Hi Jerome, On Mon, Apr 29, 2019 at 8:50 PM Jerome Brunet <jbrunet@baylibre.com> wrote: > > On Mon, 2019-04-29 at 20:31 +0200, Martin Blumenstingl wrote: > > Hi Jerome, > > > > On Mon, Apr 29, 2019 at 10:29 AM Jerome Brunet <jbrunet@baylibre.com> wrote: > > > On Sat, 2019-04-27 at 22:02 +0200, Martin Blumenstingl wrote: > > > > Hi Jerome, > > > > > > > > On Tue, Apr 23, 2019 at 11:03 AM Jerome Brunet <jbrunet@baylibre.com> wrote: > > > > > At the moment, all our attempts to enable HS400 on Amlogic chipsets have > > > > > been unsuccessful or unreliable. Until we can figure out how to enable this > > > > > mode safely and reliably, let's force it off. > > > > last year I have seen issues with HS400 on my Khadas VIM2: [0] > > > > have you tested all other patches from this series and HS400 is still > > > > not working for you? > > > > > > Because HS400 was never really stable to begin with. > > > It was a mistake to enable it on the VIM2 > > > > > > > I'm curious because this patch is early in the series and all the > > > > tuning fixes and improvements are after this patch. > > > > > > There are several reasons why this new tuning won't solve the HS400 problem: > > > - Signal resampling tuning granularity gets worse when rate rises. The resampling > > > is done using the input frequency. We can basically resample up to the value of > > > internal divider. > > > > > > In HS200 - Fin is 1GHz, Fout is 200MHz (1/5) so the resample range is [0, 4] > > > In HS400 - Fin should be fdiv5 (400MHZ) and in such case, no resampling is > > > possible (internal div = 1) > > > Even if we keep 1GHz, then out is 333MHz max giving a range of [0, 2] > > > that's not enough to tune > > this limitation would be great to have in the description of patch 7 > > from this series > > That's not really a limitation. I should probably not have mentioned as it it seems to > have made things even more unclear. I disabled HS400 before introducing the new tuning on > purpose. Any comment regarding hs400 does not belong in patch 7 IHMO. If you want > to add comment regarding hs400, I think it belongs here > > > > > > Going further, tuning the Rx path does not make much sense in HS400 since we > > > should be using the data strobe signal to account for the round trip delay of > > > the clock and correctly sample Rx. AFAICT, If there is a tuning to be done for > > > HS400, it is most likely linked to the data strobe. > > it would be great to have a better description as part of the commit > > message - with that you can add my: > > Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> > > > > my proposal for an update patch description (apologies I have > > incorrectly summarized your findings): > > " > > At the moment, all our attempts to enable HS400 on Amlogic chipsets have > > been unsuccessful or unreliable: > > - signal resampling without delay adjustments and phase tuning for the > > RX and TX clocks (this caused CRC errors and hangs even without HS400 > > mode, for example on the Khadas VIM, Khadas VIM2 and libretech-cc > > boards) > > - signal resampling without delay adjustments and RX clock phase > > tuning (some HS200 and HS400 eMMC chips were not recognized, for > > example on the Khadas VIM and Khadas VIM2 boards) > > - signal resampling tuning with delay adjustments only (works fine for > > HS200 and UHS modes but doesn't fix HS400 eMMC chips, for example on > > Khadas VIM2) > > > > Further improvements for the HS400 mode are likely to be linked to the > > data strobe signal. > > Until we can figure out how to enable this mode safely and reliably, > > let's force it off. > > " > > Thanks for effort but all this just maintain the blur around HS400 on amlogic. > > Let me rephrase it: > Tuning (phase or resampling) is meant to compensate the clock round trip in UHS > and HS200 modes. In HS400, this should be taken care of by the data strobe. > But we have not been to enable this reliably enable this on amlogic chipset ... I wasn't aware of this: so far I assumed that we're not setting the phase correctly, end of the story. thank you again for taking your time to explain this! > ... and I believe we are back to the original commit message. no need to update the description just to explain how HS400 works in general, so feel free to use my: Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Martin
On Tue, 2019-04-30 at 22:02 +0200, Martin Blumenstingl wrote: > > Thanks for effort but all this just maintain the blur around HS400 on amlogic. > > > > Let me rephrase it: > > Tuning (phase or resampling) is meant to compensate the clock round trip in UHS > > and HS200 modes. In HS400, this should be taken care of by the data strobe. > > But we have not been to enable this reliably enable this on amlogic chipset ... > I wasn't aware of this: so far I assumed that we're not setting the > phase correctly, end of the story. > thank you again for taking your time to explain this! No worries. There is the MMC in general, I think I understand it a bit now but I might still be mistaken about some stuff. Then there is the HW we have and the related black magic. I doubt this is the last update in this driver ... > > > ... and I believe we are back to the original commit message. > no need to update the description just to explain how HS400 works in > general, so feel free to use my: > Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c index 3df50b53f834..118f09da8dfb 100644 --- a/drivers/mmc/host/meson-gx-mmc.c +++ b/drivers/mmc/host/meson-gx-mmc.c @@ -823,10 +823,6 @@ static void meson_mmc_set_ios(struct mmc_host *mmc, struct mmc_ios *ios) if (meson_mmc_timing_is_ddr(ios)) val |= CFG_DDR; - val &= ~CFG_CHK_DS; - if (ios->timing == MMC_TIMING_MMC_HS400) - val |= CFG_CHK_DS; - err = meson_mmc_clk_set(host, ios); if (err) dev_err(host->dev, "Failed to set clock: %d\n,", err); @@ -1339,6 +1335,13 @@ static int meson_mmc_probe(struct platform_device *pdev) mmc->max_segs = SD_EMMC_DESC_BUF_LEN / sizeof(struct sd_emmc_desc); mmc->max_seg_size = mmc->max_req_size; + /* + * At the moment, we don't know how to reliably enable HS400. + * From the different datasheets, it is not even clear if this mode + * is officially supported by any of the SoCs + */ + mmc->caps2 &= ~MMC_CAP2_HS400; + /* data bounce buffer */ host->bounce_buf_size = mmc->max_req_size; host->bounce_buf =
At the moment, all our attempts to enable HS400 on Amlogic chipsets have been unsuccessful or unreliable. Until we can figure out how to enable this mode safely and reliably, let's force it off. Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> --- drivers/mmc/host/meson-gx-mmc.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)