Messages in this thread | | | Subject | Re: [PATCH v1 2/2] mmc: sdhci: Use the SW timer when the HW timer cannot meet the timeout value required by the device | From | Adrian Hunter <> | Date | Fri, 24 Sep 2021 16:26:37 +0300 |
| |
On 24/09/21 4:08 pm, Bean Huo wrote: > On Fri, 2021-09-24 at 15:17 +0300, Adrian Hunter wrote: >>>>> sdhci_writeb(host, count, SDHCI_TIMEOUT_CONTROL); >>>>> } >>>>> The driver has detected that the hardware timer cannot meet the >>>>> timeout >>>>> requirements of the device, but we still use the hardware >>>>> timer, >>>>> which will >>>>> allow potential timeout issuea . Rather than allowing a >>>>> potential >>>>> problem to exist, why can’t software timing be used to avoid >>>>> this >>>>> problem? >>>> Timeouts aren't that accurate. The maximum is assumed still to >>>> work. >>>> mmc->max_busy_timeout is used to tell the core what the maximum >>>> is. >>> mmc->max_busy_timeout is still a representation of Host HW timer >>> maximum timeout count, isn't it? >> >> >> Not necessarily. For SDHCI_QUIRK2_DISABLE_HW_TIMEOUT it would be >> >> set to zero to indicate no maximum. > > yes, this is the purpose of the patch, for the host controller without > quirk SDHCI_QUIRK2_DISABLE_HW_TIMEOUT, if the timeout count required by > device is beyond the HW timer max count, we choose SW timer to avoid the HW timer timeout IRQ. > > I don't know if I get it correctly.
Why can't drivers that want the behaviour just set the quirk?
Drivers that do not work with the quirk, do not have to set it.
| |