| Message ID | 20201125213001.15003-1-wsa+renesas@sang-engineering.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | tmio: set max_busy_timeout | expand |
Hi Wolfram-san, > From: Wolfram Sang, Sent: Thursday, November 26, 2020 6:30 AM > > This is a follow-up to the series "mmc: tmio: honor busy timeouts > properly" which I sent out a few days ago. One of the patches there > needs more discussion, so I regrouped the series with another one, and > this is the first outcome. It is solely about max_busy_timeout: > > Patch 1 is from the previous series (with the comment from Shimoda-san > addressed) and sets max_busy_timeout with what TMIO always did. Patch 2 > introduces a hook and a default fallback for extended timeout ranges. > Patch 3 uses the hook for the extended range of R-Car Gen3 SDHIs. > > It has been tested that the applied values make sense. I have not > measured if the MMC core really sends R1 instead of R1B when the desired > timeout value is exceeded. All on a Salvator-XS with R-Car M3N. Thank you for the patch! I tested on Salvator-XS with R-Car H3 and I checked the MMC core use R1 instead of R1B by using an additional printk on mmc_do_erase(). So, Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Best regards, Yoshihiro Shimoda
On Wed, 25 Nov 2020 at 22:30, Wolfram Sang <wsa+renesas@sang-engineering.com> wrote: > > This is a follow-up to the series "mmc: tmio: honor busy timeouts > properly" which I sent out a few days ago. One of the patches there > needs more discussion, so I regrouped the series with another one, and > this is the first outcome. It is solely about max_busy_timeout: > > Patch 1 is from the previous series (with the comment from Shimoda-san > addressed) and sets max_busy_timeout with what TMIO always did. Patch 2 > introduces a hook and a default fallback for extended timeout ranges. > Patch 3 uses the hook for the extended range of R-Car Gen3 SDHIs. > > It has been tested that the applied values make sense. I have not > measured if the MMC core really sends R1 instead of R1B when the desired > timeout value is exceeded. All on a Salvator-XS with R-Car M3N. > > The patches are based on mmc/next as of today. The branch is here: > > git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/sdhi/extop > > Looking forward to comments! > > Happy hacking, > > Wolfram > > > Wolfram Sang (3): > mmc: tmio: set max_busy_timeout > mmc: tmio: add hook for custom busy_wait calculation > mmc: renesas_sdhi: populate hook for longer busy_wait > > drivers/mmc/host/renesas_sdhi_core.c | 23 +++++++++++++++++++++++ > drivers/mmc/host/tmio_mmc.h | 5 +++++ > drivers/mmc/host/tmio_mmc_core.c | 22 ++++++++++++++++++++++ > drivers/mmc/host/uniphier-sd.c | 1 + > include/linux/mfd/tmio.h | 7 ++++++- > 5 files changed, 57 insertions(+), 1 deletion(-) > > -- > 2.28.0 > Applied for next, by amending "from" to "Wolfram Sang <wsa+renesas@sang-engineering.com>", thanks! Kind regards Uffe