| Message ID | 20200414161413.3036-7-ulf.hansson@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | mmc: Improve host driver's support for R1B responses | expand |
On Tue, 14 Apr 2020 at 20:40, Michał Mirosław <mirq-linux@rere.qmqm.pl> wrote: > > On Tue, Apr 14, 2020 at 06:14:00PM +0200, Ulf Hansson wrote: > > Some commands uses R1B responses, which means the card may assert the DAT0 > > line to signal busy for a period of time, after it has received the > > command. The mmc core normally specifies the busy period for the command in > > the cmd->busy_timeout. Ideally the driver should respect it, but that > > requires quite some update of the code, so let's defer that to someone with > > the HW at hand. > > > > Instead, let's inform the mmc core about the maximum supported busy timeout > > in ->max_busy_timeout during ->probe(). This value corresponds to the fixed > > ~2s timeout of the polling loop, implemented in cb710_wait_for_event(). In > > this way, we let the mmc core validate the needed timeout, which may lead > > to that it converts from a R1B into a R1 response and then use CMD13 to > > poll for busy completion. > > > > In other words, this change enables support for commands with longer busy > > periods than 2s, like erase (CMD38) for example. > [...] > > + /* > > + * In cb710_wait_for_event() we use a fixed timeout of ~2s, hence let's > > + * inform the core about it. A future improvement should instead make > > + * use of the cmd->busy_timeout. > > + */ > [...] > > I'm not sure whether the controller limits busy signalling time. > Since this is rare HW now, I would just pass the timeout to > cb710_wait_for_event() and see if someone reports a bug. Alright, let me try something like that. Thanks for your suggestion. Kind regards Uffe
diff --git a/drivers/mmc/host/cb710-mmc.c b/drivers/mmc/host/cb710-mmc.c index e33270e40539..e84ed84ea4cc 100644 --- a/drivers/mmc/host/cb710-mmc.c +++ b/drivers/mmc/host/cb710-mmc.c @@ -10,6 +10,8 @@ #include <linux/delay.h> #include "cb710-mmc.h" +#define CB710_MMC_REQ_TIMEOUT_MS 2000 + static const u8 cb710_clock_divider_log2[8] = { /* 1, 2, 4, 8, 16, 32, 128, 512 */ 0, 1, 2, 3, 4, 5, 7, 9 @@ -707,6 +709,12 @@ static int cb710_mmc_init(struct platform_device *pdev) mmc->f_min = val >> cb710_clock_divider_log2[CB710_MAX_DIVIDER_IDX]; mmc->ocr_avail = MMC_VDD_32_33|MMC_VDD_33_34; mmc->caps = MMC_CAP_4_BIT_DATA; + /* + * In cb710_wait_for_event() we use a fixed timeout of ~2s, hence let's + * inform the core about it. A future improvement should instead make + * use of the cmd->busy_timeout. + */ + mmc->max_busy_timeout = CB710_MMC_REQ_TIMEOUT_MS; reader = mmc_priv(mmc);
Some commands uses R1B responses, which means the card may assert the DAT0 line to signal busy for a period of time, after it has received the command. The mmc core normally specifies the busy period for the command in the cmd->busy_timeout. Ideally the driver should respect it, but that requires quite some update of the code, so let's defer that to someone with the HW at hand. Instead, let's inform the mmc core about the maximum supported busy timeout in ->max_busy_timeout during ->probe(). This value corresponds to the fixed ~2s timeout of the polling loop, implemented in cb710_wait_for_event(). In this way, we let the mmc core validate the needed timeout, which may lead to that it converts from a R1B into a R1 response and then use CMD13 to poll for busy completion. In other words, this change enables support for commands with longer busy periods than 2s, like erase (CMD38) for example. Cc: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> --- drivers/mmc/host/cb710-mmc.c | 8 ++++++++ 1 file changed, 8 insertions(+) -- 2.20.1