Re: [PATCH V7 25/25] mmc: sdhci-acpi: Enable Software Command Queuing for some Intel controllers

[Adrian Hunter <adrian.hunter@intel.com>]

On 25/11/16 17:15, Linus Walleij wrote:
> On Fri, Nov 25, 2016 at 11:07 AM, Adrian Hunter <adrian.hunter@intel.com> wrote:
> 
>> Set MMC_CAP_SWCMDQ for Intel BYT and related eMMC host controllers.
>>
>> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
>> ---
>>  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.