[U-Boot] [PATCH 3/3] tegra2: Add support for Compal Paz00 (Toshiba AC100)

[Simon Glass]

HI Stephen,

On Mon, Jan 9, 2012 at 12:04 PM, Stephen Warren <swarren at nvidia.com> wrote:
> On 01/09/2012 12:55 PM, Simon Glass wrote:
> ...
>>> +       debug("board_mmc_init: init eMMC\n");
>>> +       /* init dev 0, eMMC chip, with 4-bit bus */
>>> +       /* The board has an 8-bit bus, but 8-bit doesn't work yet */
>>> +       tegra2_mmc_init(0, 4, -1, -1);
>>
>> Yes - I will see if I can do a patch to enable 8-bit.
>
> BTW, I briefly looked at this quite a while back when I first started
> looking at U-Boot. I filed an internal bug to investigate this further
> at some later time. The notes are below:

I committed a few patches to our tree a week or two ago - got a
reduction from about 120ms to 70ms in kernel load time. Will see what
I can do.

Thank you for the notes.

>
> MMC devices can have a 1-, 4-, or 8-bit data bus. Support for 8-bit data
> buses is currently not fully implemented in mainline(Denx) U-Boot. This
> is mostly an issue with the MMC core, and not Tegra-specific. The
> following potential issues exist:
>
> 1)
>
> drivers/mmc/tegra2_mmc.c:tegra2_mmc_init() contains:
>
> if (bus_width == 8)
>    mmc->host_caps = MMC_MODE_8BIT;
> else
>    mmc->host_caps = MMC_MODE_4BIT;
>
> I /think/ this should be rewritten as:
>
> if (bus_width == 8)
>    mmc->host_caps = MMC_MODE_8BIT;
> if (bus_width >= 4)
>    mmc->host_caps = MMC_MODE_4BIT;
>
> ... thus allowing both caps to be set at once.
>
> 2)
>
> drivers/mmc/mmc.c:mmc_change_freq() contains the following for v4 cards:
>
> mmc->card_caps |= MMC_MODE_4BIT;
>
> Nothing ever performs:
>
> mmc->card_caps |= MMC_MODE_8BIT;
>
> ... so 8-bit mode can never be active.
>
> I note that ChromeOS's U-Boot replaces the above code with:
>
> if(mmc->host_caps & MMC_MODE_8BIT)
>    mmc->card_caps |= MMC_MODE_8BIT;
> else
>    mmc->card_caps |= MMC_MODE_4BIT;
>
> which implies that the 8-bit and 4-bit mode flags are meant to be
> mutually exclusive, which seems a little odd; our controller could do
> either just fine...
>
> 3)
>
> drivers/mmc/mmc.c:mmc_startup() contains:
>
> if (mmc->card_caps & MMC_MODE_4BIT) {
>    // setup for 4-bit mode
> } else if (mmc->card_caps & MMC_MODE_8BIT) {
>    // setup for 8-bit mode
> }
>
> which oddly checks for 4-bit mode first, so if both 4- and 8-bit mode
> are allowed, 4-bit wins.
>
> 4)
>
> If you look at the Linux kernel MMC driver, there's a lot more to
> selecting between 1-, 4-, and 8-bit mode. Specifically:
>
> a) You're supposed to try 8-bit mode, test it and see if it works. If
> that fails, fall back to trying 4-bit mode, then fall back to 1-bit
> mode. U-Boot currently just picks one, doesn't fully test it, and if it
> fails, you're done.
>
> b) You're supposed to test the card works correctly after selecting a
> bus width using a special bus-width test command.
>
> c) The Linux kernel at least also executes commands to switch the card
> between various power modes that the card reports it needs for different
> bus speeds and widths. I don't think U-Boot does this anywhere.
>
> (a) and (b) are also supported by the following document from the MMC
> association:
>
> http://read.pudn.com/downloads153/doc/project/671834/MMC
> SD/AN_MMCA050419.pdf
>
> I hacked a fix for (1), (2), and (3) above and tested Seaboard's
> internal eMMC. While data transfer appeared to still operated correctly,
> I didn't observe any difference in transfer speed. I don't know if this
> is due to (4) above, or some other issue. However, I did observe a
> nearly 2x speedup going from 4- to 8-bit mode when running the Linux kernel.
>
> So, quite a lot of further investigation/work needed here.
>
> --
> nvpublic

Regards,
Simon