e.MMC HS400 mode and FreeBSD's retune_ticks for its MMC_SEND_TUNING_BLOCK_HS200 activity when Enhanced Strobe is disabled

From: Mark Millard via freebsd-hackers <freebsd-hackers_at_freebsd.org>
Date: Fri, 10 Dec 2021 22:05:01 UTC
In reading to learn some about why recent changes broke booting
the Rock64 via the e.MMC that I have involved, I ran into the
following (that is not the cause of the boot issue but my reading
overlapped with the area before figuring that out):

. . .
int
sdhci_generic_tune(device_t brdev __unused, device_t reqdev, bool hs400)
{
. . .
       case bus_timing_mmc_hs200:
               /*
                * In HS400 mode, controllers use the data strobe line to
                * latch data from the devices so periodic re-tuning isn't 
                * expected to be required.
                */
               if (hs400)
                       slot->retune_ticks = 0;
               opcode = MMC_SEND_TUNING_BLOCK_HS200;
               break;
. . .

I expect that the above comment is wrong about the reason for
needing MMC_SEND_TUNING_BLOCK_HS200 use for HS400 support.
So I also expect that the conclusion is wrong when Enhanced
Strobe is disabled.

Quoting something I wrote elsewhere:

QUOTE
HS400 needs CMD21 use for synchronizing the command responses on
the CMD line to the CLK (a temporary use of HS200 mode to do the
tuning).
END QUOTE

But there is more context that I should have referenced:

For HS400, when Enhanced Strobe is disabled, the CMD-out line
(from device to host) has no matching strobe to go with it in
any fixed signal-timing relationship from what I've read.

So I expect that the comment is also wrong about needing
the CMD-out line to be periodically retuned vs. not --when
Enhanced Strobe is disabled.

(Data Out and CRC Response always are synced to the Strobe.)


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)