On 10/05/16 17:34, Stephen Warren wrote: > On 05/10/2016 10:13 AM, Jon Hunter wrote: [snip] >> Stephen, for your u-boot testing, do you are set the bit in the vendor >> misc register to enable version 3.0 support for sdhci on tegra30? This >> is what the above quirk is doing (and has done so for a very long time). > > I don't see anything in the U-Boot driver that is equivalent to the > kernel's NVQUIRK_ENABLE_SDHCI_SPEC_300. I assume that means the > controller advertises an early spec version when in U-Boot, which simply > means U-Boot doesn't know to take advantage of any faster transfer modes > enabled by later specification versions, but I'm not entirely sure what > effect the following kernel code has on the HW: > >> /* Erratum: Enable SDHCI spec v3.00 support */ >> if (soc_data->nvquirks & NVQUIRK_ENABLE_SDHCI_SPEC_300) >> misc_ctrl |= SDHCI_MISC_CTRL_ENABLE_SDHCI_SPEC_300; Do you see it touch the SDHCI_TEGRA_VENDOR_MISC_CTRL register? The TRM states ... "SDMMC_SPARE0[4] : When set, SD3.0 support is advertised in SDMMC_SLOT_INTERRUPT_STATUS_0_SPECIFICATION_VERSION_NUMBER Otherwise, only SD2.0 support is advertised" So I *believe* this means that the sdhci version will now appear as 3.0 and so the host->version == SDHCI_SPEC_300. There are many places in the sdhci driver where it is checking ... if (host->version >= SDHCI_SPEC_300) ... > Perhaps the kernel driver should pulse the controller's CAR reset signal > in probe() to ensure that the HW is in a known state? I will take a look. Jon -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
