On Thu, Dec 14, 2017 at 1:05 PM, Andrey Smirnov <andrew.smir...@gmail.com> wrote: > On Thu, Dec 14, 2017 at 7:32 AM, Philippe Mathieu-Daudé <f4...@amsat.org> > wrote: >> [...] >>>>> + case ESDHC_DLL_CTRL: >>>>> + case ESDHC_TUNE_CTRL_STATUS: >>>>> + case 0x6c: >>>> >>>> Isn't there a name we can give 0x6c ? >>>> >>> >>> Unfortunately, not that I know of. It's a mystery register not listed >>> in RM and the only place I can found it being mentioned is in Linux >>> driver as a part of errata ESDHC_FLAG_ERR004536 fix, where it is used >>> nameless as well. >> >> This sets the SD CLK/RCLK frequency (10-bit) for the 104MB/sec bus speed >> (UHS-I mode). >> >> The "Sampling Clock Tuning Procedure" figure in the Spec v3 is helpful. >> > > I am a bit hesitant to agree that this is indeed the case. ERR004536 > errata's title is "uSDHC: ADMA Length Mismatch Error may occur for > longer read latencies" and recommented workaround is "Use SDMA (or > ADMA1) in case the AHB latency is larger than the “minimal time for > one block”. On top of that corresponding code in Linux > (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/mmc/host/sdhci-esdhc-imx.c?h=v4.15-rc3#n1061) > doesn't seem to use it as a 10-bit frequency field, treating it more > like a single-bit flag.
Ok, I'll have a better look when applying these SD patches on top of my current SD tree. Regards, Phil.
