Message ID | 20190319103417.28407-1-wsa+renesas@sang-engineering.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | mmc: renesas_sdhi: set CBSY flag before probing TMIO host | expand |
On Tue, Mar 19, 2019 at 11:34 AM Wolfram Sang <wsa+renesas@sang-engineering.com> wrote: > The CBSY flag should be proper before calling tmio_mmc_host_probe() set? > because this function will already use write16 which checks this bit. Gr{oetje,eeting}s, Geert
On Tue, Mar 19, 2019 at 11:57:00AM +0100, Geert Uytterhoeven wrote: > On Tue, Mar 19, 2019 at 11:34 AM Wolfram Sang > <wsa+renesas@sang-engineering.com> wrote: > > The CBSY flag should be proper before calling tmio_mmc_host_probe() > > set? No. The state should be proper. As you see in the code, it gets cleared for a certain type of SDHI.
On Tue, Mar 19, 2019 at 11:34:17AM +0100, Wolfram Sang wrote: > The CBSY flag should be proper before calling tmio_mmc_host_probe() > because this function will already use write16 which checks this bit. > > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> > --- > > This patch depends on "[RFT] mmc: renesas_sdhi: limit block count to 16 bit for > old revisions" [1]. This one, however, is not backed by a bug report but just > found by code review. I wouldn't suggest stable here because the non-working > case is probably more on the academic side (unless I overlooked something). > Yet, the code becomes easier to read because it is the flow one would expect. > So, I post this already for discussion. We need to wait for the dependency > first, of course. > > Tested on the SDR50 only SDHI of a Renesas Lager board (R-Car H2). No > regressions encountered: still probes fine and works at the same speed. Do you have plans for further testing? Reviewed-by: Simon Horman <horms+renesas@verge.net.au> > [1] https://patchwork.kernel.org/patch/10859279/ > > drivers/mmc/host/renesas_sdhi_core.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/mmc/host/renesas_sdhi_core.c b/drivers/mmc/host/renesas_sdhi_core.c > index 8742e27e4e8b..5885f3fb0b2f 100644 > --- a/drivers/mmc/host/renesas_sdhi_core.c > +++ b/drivers/mmc/host/renesas_sdhi_core.c > @@ -779,14 +779,14 @@ int renesas_sdhi_probe(struct platform_device *pdev, > if (ver < SDHI_VER_GEN2_SDR104 && mmc_data->max_blk_count > U16_MAX) > mmc_data->max_blk_count = U16_MAX; > > - ret = tmio_mmc_host_probe(host); > - if (ret < 0) > - goto edisclk; > - > /* One Gen2 SDHI incarnation does NOT have a CBSY bit */ > if (ver == SDHI_VER_GEN2_SDR50) > mmc_data->flags &= ~TMIO_MMC_HAVE_CBSY; > > + ret = tmio_mmc_host_probe(host); > + if (ret < 0) > + goto edisclk; > + > /* Enable tuning iff we have an SCC and a supported mode */ > if (of_data && of_data->scc_offset && > (host->mmc->caps & MMC_CAP_UHS_SDR104 || > -- > 2.11.0 >
Hi Wolfram, Thanks for your work. On 2019-03-19 11:34:17 +0100, Wolfram Sang wrote: > The CBSY flag should be proper before calling tmio_mmc_host_probe() > because this function will already use write16 which checks this bit. > > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> This matches whit how I read the code, nice catch. Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> > --- > > This patch depends on "[RFT] mmc: renesas_sdhi: limit block count to 16 bit for > old revisions" [1]. This one, however, is not backed by a bug report but just > found by code review. I wouldn't suggest stable here because the non-working > case is probably more on the academic side (unless I overlooked something). > Yet, the code becomes easier to read because it is the flow one would expect. > So, I post this already for discussion. We need to wait for the dependency > first, of course. > > Tested on the SDR50 only SDHI of a Renesas Lager board (R-Car H2). No > regressions encountered: still probes fine and works at the same speed. > > [1] https://patchwork.kernel.org/patch/10859279/ > > drivers/mmc/host/renesas_sdhi_core.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/mmc/host/renesas_sdhi_core.c b/drivers/mmc/host/renesas_sdhi_core.c > index 8742e27e4e8b..5885f3fb0b2f 100644 > --- a/drivers/mmc/host/renesas_sdhi_core.c > +++ b/drivers/mmc/host/renesas_sdhi_core.c > @@ -779,14 +779,14 @@ int renesas_sdhi_probe(struct platform_device *pdev, > if (ver < SDHI_VER_GEN2_SDR104 && mmc_data->max_blk_count > U16_MAX) > mmc_data->max_blk_count = U16_MAX; > > - ret = tmio_mmc_host_probe(host); > - if (ret < 0) > - goto edisclk; > - > /* One Gen2 SDHI incarnation does NOT have a CBSY bit */ > if (ver == SDHI_VER_GEN2_SDR50) > mmc_data->flags &= ~TMIO_MMC_HAVE_CBSY; > > + ret = tmio_mmc_host_probe(host); > + if (ret < 0) > + goto edisclk; > + > /* Enable tuning iff we have an SCC and a supported mode */ > if (of_data && of_data->scc_offset && > (host->mmc->caps & MMC_CAP_UHS_SDR104 || > -- > 2.11.0 >
On Tue, 19 Mar 2019 at 11:34, Wolfram Sang <wsa+renesas@sang-engineering.com> wrote: > > The CBSY flag should be proper before calling tmio_mmc_host_probe() > because this function will already use write16 which checks this bit. > > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Applied for next, thanks! Kind regards Uffe > --- > > This patch depends on "[RFT] mmc: renesas_sdhi: limit block count to 16 bit for > old revisions" [1]. This one, however, is not backed by a bug report but just > found by code review. I wouldn't suggest stable here because the non-working > case is probably more on the academic side (unless I overlooked something). > Yet, the code becomes easier to read because it is the flow one would expect. > So, I post this already for discussion. We need to wait for the dependency > first, of course. > > Tested on the SDR50 only SDHI of a Renesas Lager board (R-Car H2). No > regressions encountered: still probes fine and works at the same speed. > > [1] https://patchwork.kernel.org/patch/10859279/ > > drivers/mmc/host/renesas_sdhi_core.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/mmc/host/renesas_sdhi_core.c b/drivers/mmc/host/renesas_sdhi_core.c > index 8742e27e4e8b..5885f3fb0b2f 100644 > --- a/drivers/mmc/host/renesas_sdhi_core.c > +++ b/drivers/mmc/host/renesas_sdhi_core.c > @@ -779,14 +779,14 @@ int renesas_sdhi_probe(struct platform_device *pdev, > if (ver < SDHI_VER_GEN2_SDR104 && mmc_data->max_blk_count > U16_MAX) > mmc_data->max_blk_count = U16_MAX; > > - ret = tmio_mmc_host_probe(host); > - if (ret < 0) > - goto edisclk; > - > /* One Gen2 SDHI incarnation does NOT have a CBSY bit */ > if (ver == SDHI_VER_GEN2_SDR50) > mmc_data->flags &= ~TMIO_MMC_HAVE_CBSY; > > + ret = tmio_mmc_host_probe(host); > + if (ret < 0) > + goto edisclk; > + > /* Enable tuning iff we have an SCC and a supported mode */ > if (of_data && of_data->scc_offset && > (host->mmc->caps & MMC_CAP_UHS_SDR104 || > -- > 2.11.0 >
diff --git a/drivers/mmc/host/renesas_sdhi_core.c b/drivers/mmc/host/renesas_sdhi_core.c index 8742e27e4e8b..5885f3fb0b2f 100644 --- a/drivers/mmc/host/renesas_sdhi_core.c +++ b/drivers/mmc/host/renesas_sdhi_core.c @@ -779,14 +779,14 @@ int renesas_sdhi_probe(struct platform_device *pdev, if (ver < SDHI_VER_GEN2_SDR104 && mmc_data->max_blk_count > U16_MAX) mmc_data->max_blk_count = U16_MAX; - ret = tmio_mmc_host_probe(host); - if (ret < 0) - goto edisclk; - /* One Gen2 SDHI incarnation does NOT have a CBSY bit */ if (ver == SDHI_VER_GEN2_SDR50) mmc_data->flags &= ~TMIO_MMC_HAVE_CBSY; + ret = tmio_mmc_host_probe(host); + if (ret < 0) + goto edisclk; + /* Enable tuning iff we have an SCC and a supported mode */ if (of_data && of_data->scc_offset && (host->mmc->caps & MMC_CAP_UHS_SDR104 ||
The CBSY flag should be proper before calling tmio_mmc_host_probe() because this function will already use write16 which checks this bit. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> --- This patch depends on "[RFT] mmc: renesas_sdhi: limit block count to 16 bit for old revisions" [1]. This one, however, is not backed by a bug report but just found by code review. I wouldn't suggest stable here because the non-working case is probably more on the academic side (unless I overlooked something). Yet, the code becomes easier to read because it is the flow one would expect. So, I post this already for discussion. We need to wait for the dependency first, of course. Tested on the SDR50 only SDHI of a Renesas Lager board (R-Car H2). No regressions encountered: still probes fine and works at the same speed. [1] https://patchwork.kernel.org/patch/10859279/ drivers/mmc/host/renesas_sdhi_core.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)