On 25/11/16 17:15, Linus Walleij wrote:
> On Fri, Nov 25, 2016 at 11:07 AM, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote:
>
>> Set MMC_CAP_SWCMDQ for Intel BYT and related eMMC host controllers.
>>
>> Signed-off-by: Adrian Hunter <adrian.hunter@xxxxxxxxx>
>> ---
>> drivers/mmc/host/sdhci-acpi.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/mmc/host/sdhci-acpi.c b/drivers/mmc/host/sdhci-acpi.c
>> index 81d4dc034793..95fc4de05c54 100644
>> --- a/drivers/mmc/host/sdhci-acpi.c
>> +++ b/drivers/mmc/host/sdhci-acpi.c
>> @@ -274,7 +274,7 @@ static int sdhci_acpi_sd_probe_slot(struct platform_device *pdev,
>> static const struct sdhci_acpi_slot sdhci_acpi_slot_int_emmc = {
>> .chip = &sdhci_acpi_chip_int,
>> .caps = MMC_CAP_8_BIT_DATA | MMC_CAP_NONREMOVABLE |
>> - MMC_CAP_HW_RESET | MMC_CAP_1_8V_DDR |
>> + MMC_CAP_HW_RESET | MMC_CAP_1_8V_DDR | MMC_CAP_SWCMDQ |
>
> Actually I don't see why SOFTWARE command queueing would need a cap flag
> in the host at all?
>
> Isn't the whole point with it that if it is available, we don't need any special
> hardware support to use it with any host?
>
> So why not just enable it if the card supports it in that case, why flag
> it in the host at all?
It is a good question. I was trying to remember why I did that way, but
nothing came to mind.
Now it is dependent on MMC_CAP_CMD_DURING_TFR which host controllers may not
support. An example is SDHCI host controllers that have
SDHCI_QUIRK_RESET_AFTER_REQUEST since the reset will interfere with ongoing
transfers.
So I will drop MMC_CAP_SWCMDQ and just check MMC_CAP_CMD_DURING_TFR.
--
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
