lkml.org 
[lkml]   [2022]   [Jan]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: Relation between MMC_CAP_WAIT_WHILE_BUSY and card_busy()
On Wed, 26 Jan 2022 at 04:46, Saravana Kannan <saravanak@google.com> wrote:
>
> I'm trying to understand the MMC suspend path a bit.
>
> I looked at the commit message of 6fa79651cc808f68db6f6f297be5a950ccd5dffb.
>
> IIUC, if MMC_CAP_WAIT_WHILE_BUSY is set then the mmc framework is
> going to depend on the card_busy() op to ensure correctness instead of
> using the S_A_TIMEOUT value from the card.

MMC_CAP_WAIT_WHILE_BUSY indicates whether the mmc controller supports
IRQ based busy detection completion. In other words, the mmc host
driver can receive an IRQ when busy signaling is completed on DAT0 by
the eMMC card.

However, to avoid waiting for the IRQ forever, there is a maximum
timeout that is specified by the mmc core, for the particular command
in question. For eMMC sleep, the S_A_TIMEOUT.

>
> But I see a lot of mmc host drivers that implement card_busy() but
> don't set the MMC_CAP_WAIT_WHILE_BUSY flag. That doesn't seem right to
> me if my understanding is correct.

That's perfectly okay. MMC_CAP_WAIT_WHILE_BUSY is IRQ based, while the
->card_busy() ops is used to poll for busy completion.

>
> If it's supposed to be "we'll use card_busy() if
> MMC_CAP_WAIT_WHILE_BUSY isn't set", then why do we have some mmc host
> drivers that have both?
>
> What am I misunderstanding?

There are some additional complexity for the corresponding code. This
has mostly ended up there because we also need to deal with mmc
controller's HW limitations around this feature.

For example, some mmc controllers have a HW limit for the length of
the timeout that can be set. If the needed timeout is longer than what
can be supported, we can't use IRQ based busy completion.

Did this make it more clear?

>
> -Saravana

Kind regards
Uffe

\
 
 \ /
  Last update: 2022-01-31 16:47    [W:1.217 / U:0.744 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site