On Sep 11, 2012, at 9:44 AM, Chris Ball wrote:
> Hi,
>
> On Tue, Sep 11 2012, Kumar Gala wrote:
>> In sdhci_add_host()
>>
>> We have the following
>>
>> ...
>> mmc->caps |= MMC_CAP_SDIO_IRQ | MMC_CAP_ERASE | MMC_CAP_CMD23;
>>
>> if (host->quirks & SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12)
>> host->flags |= SDHCI_AUTO_CMD12;
>>
>> /* Auto-CMD23 stuff only works in ADMA or PIO. */
>> if ((host->version >= SDHCI_SPEC_300) &&
>> ((host->flags & SDHCI_USE_ADMA) ||
>> !(host->flags & SDHCI_USE_SDMA))) {
>> host->flags |= SDHCI_AUTO_CMD23;
>> DBG("%s: Auto-CMD23 available\n", mmc_hostname(mmc));
>> } else {
>> DBG("%s: Auto-CMD23 unavailable\n", mmc_hostname(mmc));
>> }
>>
>> ...
>>
>> I'm not clear what the difference is between mmc->caps & host->flags, but shouldn't we move setting MMC_CAP_CMD23 inside the 'Auto-CMD23' if check?
>
> The main answer is: No, because CMD23 is distinct from Auto-CMD23.
>
> Multiblock transfers (CMD23) date back from MMC cards (which is why
> they're an MMC host capability) and can also be used in SDHCI.
>
> Auto-CMD23 is a new feature in SDHCI 3.0 that reduces the overhead
> of sending CMD23. It doesn't work if we're using SDMA, though.
>
> As for capability vs. flags, the capability is more of an inherent
> property of the controller, and flags are runtime decisions on whether
> to use that capability, based on e.g. the presence of a quirk.
>
> So, I think the code's correct as written. Feel free to ask more
> questions if you're investigating a specific problem that you haven't
> mentioned yet.
Chris,
thanks for the info. Do you know what's required on controller side to handle cards that support CMD23?
I'm trying to figure out if older controller's on FSL SoCs are missing some feature to allow CMD23 to work (vs Auto-CMD23).
- k--
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
