| Message ID | 20180717145216.16840-4-niklas.soderlund+renesas@ragnatech.se (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Jul 17, 2018 at 04:52:15PM +0200, Niklas Söderlund wrote: > When tuning each tap is issued CMD19 twice and the result of both runs > recorded in host->taps. If the result is different between the two runs > the wrong sampling clock position was selected. Fix this by merging the > two runs and only keep the result for each tap if it was good in both > sets. > > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> > > --- > > * Changes since v2 > - Rewrote the change to use a less clumsy loop. The patch is now > completely changed from Hayakawa-sans version and therefor I have also > claimed authorship. > - Fixed spelling in comment as suggested by Geert. > > * Changes since v1 > - Updated commit message after discussion with Wolfram. > - Expanded comment in code to better explain why the results are merged. > --- > drivers/mmc/host/renesas_sdhi_core.c | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/drivers/mmc/host/renesas_sdhi_core.c b/drivers/mmc/host/renesas_sdhi_core.c > index 384ae6cfa289e22c..777e32b0e410e850 100644 > --- a/drivers/mmc/host/renesas_sdhi_core.c > +++ b/drivers/mmc/host/renesas_sdhi_core.c > @@ -384,6 +384,18 @@ static int renesas_sdhi_select_tuning(struct tmio_mmc_host *host) > /* Clear SCC_RVSREQ */ > sd_scc_write32(host, priv, SH_MOBILE_SDHI_SCC_RVSREQ, 0); > > + /* > + * When tuning CMD19 is issued twice for each tap, merge the > + * result requiring the tap to be good in both runs before > + * considering it for tuning selection. > + */ > + for (i = 0; i < host->tap_num * 2; i++) { > + int offset = host->tap_num * (i < host->tap_num ? 1 : -1); > + > + if (!test_bit(i, host->taps)) > + clear_bit(i + offset, host->taps); > + } > + > /* > * Find the longest consecutive run of successful probes. If that > * is more than SH_MOBILE_SDHI_MAX_TAP probes long then use the > -- > 2.18.0 > -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jul 17, 2018 at 04:52:15PM +0200, Niklas Söderlund wrote: > When tuning each tap is issued CMD19 twice and the result of both runs > recorded in host->taps. If the result is different between the two runs > the wrong sampling clock position was selected. Fix this by merging the > two runs and only keep the result for each tap if it was good in both > sets. > > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> So, I tested this patch without having patch 2 applied and it worked: Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Ulf, I think patches 1 & 3 are good and should be applied to 4.18 with stable attached. And I wonder if it was easier if I'd send you pull requests now that we are working with even more developers on SDHI? Simon, Niklas, what do you think?
On Tue, Jul 24, 2018 at 01:26:34PM +0200, Wolfram Sang wrote: > On Tue, Jul 17, 2018 at 04:52:15PM +0200, Niklas Söderlund wrote: > > When tuning each tap is issued CMD19 twice and the result of both runs > > recorded in host->taps. If the result is different between the two runs > > the wrong sampling clock position was selected. Fix this by merging the > > two runs and only keep the result for each tap if it was good in both > > sets. > > > > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> > > So, I tested this patch without having patch 2 applied and it worked: > > Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> > Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> > > Ulf, I think patches 1 & 3 are good and should be applied to 4.18 with > stable attached. > > And I wonder if it was easier if I'd send you pull requests now that we > are working with even more developers on SDHI? Simon, Niklas, what do > you think? Of course its up to Ulf but from my point of view it would make sense for you to coordinate things at least for now. -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Wolfram, On 2018-07-24 13:26:34 +0200, Wolfram Sang wrote: > On Tue, Jul 17, 2018 at 04:52:15PM +0200, Niklas Söderlund wrote: > > When tuning each tap is issued CMD19 twice and the result of both runs > > recorded in host->taps. If the result is different between the two runs > > the wrong sampling clock position was selected. Fix this by merging the > > two runs and only keep the result for each tap if it was good in both > > sets. > > > > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> > > So, I tested this patch without having patch 2 applied and it worked: > > Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> > Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> > > Ulf, I think patches 1 & 3 are good and should be applied to 4.18 with > stable attached. I have collected all tags and broken out 1 and 3 to a v4 of this series for easy consumption for either you or Ulf. And I'm working on updating 2 and 4. > > And I wonder if it was easier if I'd send you pull requests now that we > are working with even more developers on SDHI? Simon, Niklas, what do > you think? > For me this approach would be great but as Simon points out maybe Ulf have a different idea. If you end up collecting and sending pull requests can you provide a public branch of the patches you have sent PR for so I can base my work upon that to avoid potential merge conflicts?
diff --git a/drivers/mmc/host/renesas_sdhi_core.c b/drivers/mmc/host/renesas_sdhi_core.c index 384ae6cfa289e22c..777e32b0e410e850 100644 --- a/drivers/mmc/host/renesas_sdhi_core.c +++ b/drivers/mmc/host/renesas_sdhi_core.c @@ -384,6 +384,18 @@ static int renesas_sdhi_select_tuning(struct tmio_mmc_host *host) /* Clear SCC_RVSREQ */ sd_scc_write32(host, priv, SH_MOBILE_SDHI_SCC_RVSREQ, 0); + /* + * When tuning CMD19 is issued twice for each tap, merge the + * result requiring the tap to be good in both runs before + * considering it for tuning selection. + */ + for (i = 0; i < host->tap_num * 2; i++) { + int offset = host->tap_num * (i < host->tap_num ? 1 : -1); + + if (!test_bit(i, host->taps)) + clear_bit(i + offset, host->taps); + } + /* * Find the longest consecutive run of successful probes. If that * is more than SH_MOBILE_SDHI_MAX_TAP probes long then use the
When tuning each tap is issued CMD19 twice and the result of both runs recorded in host->taps. If the result is different between the two runs the wrong sampling clock position was selected. Fix this by merging the two runs and only keep the result for each tap if it was good in both sets. Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> --- * Changes since v2 - Rewrote the change to use a less clumsy loop. The patch is now completely changed from Hayakawa-sans version and therefor I have also claimed authorship. - Fixed spelling in comment as suggested by Geert. * Changes since v1 - Updated commit message after discussion with Wolfram. - Expanded comment in code to better explain why the results are merged. --- drivers/mmc/host/renesas_sdhi_core.c | 12 ++++++++++++ 1 file changed, 12 insertions(+)