[U-Boot] [PATCH 1/5] Tegra30: fdt: Add SDMMC (sdhci) nodes for T30 boards (Cardhu for now)

[Stephen Warren <swarren@wwwdotorg.org>]

On 02/27/2013 09:20 AM, Tom Warren wrote:
> Stephen/Rhyland,
> 
> On Tue, Feb 26, 2013 at 4:10 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 02/26/2013 01:46 PM, Tom Warren wrote:
>>> Took these values directly from the kernel dts files.
>>
>>> diff --git a/arch/arm/dts/tegra30.dtsi b/arch/arm/dts/tegra30.dtsi
>>
>>> +     sdhci at 78000000 {
>>> +             compatible = "nvidia,tegra30-sdhci", "nvidia,tegra20-sdhci";
>>
>> Looking at this more, I /think/ this should only include the Tegra30
>> compatible value, since there are new quirks that are required to be
>> enabled on Tegra30 relative to Tegra20 or the HW won't work. The kernel
>> DT file is no doubt buggy here.
>
> Looking at the SDMMC reg space in the T20 and T30 TRMs, I don't see
> anything major that would make the MMC driver not work on T30 as is
> (in fact, I know it works just fine w/o modification). Looking at the
> sdhci-tegra.c driver source, the only quirk difference is
> DATA_TIMEOUT_USES_SDCLK. The U-Boot Tegra MMC driver doesn't reference
> the caps Timeout Clock Frequency bits, so this quirk/difference
> doesn't matter.

The compatible value does not document whether the U-Boot driver will
operate on the HW without changes, but rather whether there are
incompatible HW changes.

Now, those changes might only affect some theoretical driver that
doesn't actually exist. However, that is not relevant; compatible is
purely about describing HW compatibility or not.

I'll note that both the current upstream U-Boot MMC driver and likely
the current upstream Linux kernel MMC driver probably don't take
advantage of many of the performance or power-saving features present in
the HW, so it's likely pretty easy for their to be a HW difference that
could affect a driver, but not actually yet affect either of these two
particular drivers.

In particular, the difference in DATA_TIMEOUT_USES_SDCLK would probably
be enough on its own to merit not marking Tegra30 as
backwards-compatible with Tegra20, since it's a bug WAR or issue that a
Tegra30 driver apparently would need to be aware of but not a Tegra20
driver (if that feature is used by the driver).