ensure that all such commands have a non-zero retry count except for those that are expected to fail (for example, because they are used to probe for feature support). While it is possible to pass a retry count down to the hardware driver in the command request structure, no hardware driver currently implements any retry logic. The hardware doesn't know much about the context of a single request, so it makes more sense to handle retries at a layer that does. This adds retry loops to the mmc_wait_for_cmd() and mmc_wait_for_app_cmd() functions. These functions are the gateway from other code within mmc.c to the hardware. App commands are a sequence of two commands and a retry has to rerun both of them in order, so it needs its own retry loop. Retry looping is specifically NOT implemented in mmc_wait_for_request() because it is the gateway for children on the bus, and they have to implement their own retry logic depending on what makes sense for them. |
||
---|---|---|
.. | ||
bridge.h | ||
mmc.c | ||
mmcbr_if.m | ||
mmcbrvar.h | ||
mmcbus_if.m | ||
mmcreg.h | ||
mmcsd.c | ||
mmcvar.h |