[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-arm] [PATCH 12/13] sdhci: Add i.MX specific subtype of SDHCI

From: Philippe Mathieu-Daudé
Subject: Re: [Qemu-arm] [PATCH 12/13] sdhci: Add i.MX specific subtype of SDHCI
Date: Thu, 14 Dec 2017 13:17:21 -0300

On Thu, Dec 14, 2017 at 1:05 PM, Andrey Smirnov
<address@hidden> wrote:
> On Thu, Dec 14, 2017 at 7:32 AM, Philippe Mathieu-Daudé <address@hidden> 
> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]