This one is a bit odd.
We tsleep(9) if !cold *and* usecs is a duration longer than a tick.
Otherwise we delay(9).
I am reluctant to leave the "usecs > tick" comparison here, but I am
even more reluctant to remove it and introduce latency where there
wasn't any before.
I'm going to leave the comparison and circle back to try to remove it
later.
... unless someone familiar with the driver thinks otherwise.
ok?
Index: sdmmc/sdmmc.c
===================================================================
RCS file: /cvs/src/sys/dev/sdmmc/sdmmc.c,v
retrieving revision 1.54
diff -u -p -r1.54 sdmmc.c
--- sdmmc/sdmmc.c 31 Dec 2019 10:05:33 -0000 1.54
+++ sdmmc/sdmmc.c 7 Feb 2020 13:43:09 -0000
@@ -577,10 +577,8 @@ sdmmc_init(struct sdmmc_softc *sc)
void
sdmmc_delay(u_int usecs)
{
- int nticks = usecs / (1000000 / hz);
-
- if (!cold && nticks > 0)
- tsleep(&sdmmc_delay, PWAIT, "mmcdly", nticks);
+ if (!cold && usecs > tick)
+ tsleep_nsec(&sdmmc_delay, PWAIT, "mmcdly", USEC_TO_NSEC(usecs));
else
delay(usecs);
}
