On 19/10/18 12:26 PM, Anisse Astier wrote:
> Hi Adrian,
>
> On Fri, Oct 19, 2018 at 10:07:38AM +0300, Adrian Hunter wrote:
>> On 18/10/18 1:21 PM, Anisse Astier wrote:
>>> If we don't have the voltage switch DSM methods available, there's no
>>> point in advertising to the rest of the kernel that we support 1.8V, or
>>> support voltage switch at all.
>>>
>>> This fixes an issue on a Gemini Lake (GLK) laptop : eMMC driver will
>>> timeout on boot (from 60seconds to 10minutes ) as the cqhci attempts CQE
>>> recovery after a failed voltage switch. In earlier kernels, the problem
>>> existed, but only delayed boot for about 10 seconds after an I/O error,
>>> allowing booting on the eMMC (almost) unnoticed.
>>
>> Can you send the kernel messages? Which kernel is it? Which laptop? An
>> acpidump might help too.
>
> You're right, I should have started with this. I have attached various
> dmesg traces:
> - dmesg-4.18.3-CQE-traces.txt : the original issue that was
> encountered, it shows the multiple CQE recovery timeouts, each taking
> about 60s
> - dmesg-4.19-rc8.noquirk.txt : a boot where the CQE recovery works, and
> only an I/O error is shown. I've reduced it to the mmc/sdhci traces.
> - dmesg-4.19-rc8.noquirk-with-error.txt : a boot where it fails, this
> is similar to the first one, but with a more recent kernel
> - dmesg-4.19-rc8.withquirk.txt : a boot with sdhci.debug_quirks2=0x90c
> on the command line. I've added the SDHCI_QUIRK2_NO_1_8_V quirk to
> the other ones present in the driver. You can see there's no CQE
> recovery or mmc I/O errors.
>
>
> I've reproduced the issue with linux 4.17, 4.18 and 4.19-rc8. The laptop
> is a noname laptop with an Insyde EFI firmware (Manufacturer: Notebook,
> Product Name: N75_77GU).
>
> You'll find the acpidump in the attachment. I've looked into another GLK
> laptop's tables, and the implemented acpi methods seem to only do a
> sleep(), which isn't really helpful. I've tried to add a similmar msleep
> in the voltage_switch function, but it didn't seem to help.
Please try disabling CQE i.e.
diff --git a/drivers/mmc/host/sdhci-pci-core.c b/drivers/mmc/host/sdhci-pci-core.c
index e53333c695b3..c0f8348f75f7 100644
--- a/drivers/mmc/host/sdhci-pci-core.c
+++ b/drivers/mmc/host/sdhci-pci-core.c
@@ -732,7 +732,7 @@ static int glk_emmc_probe_slot(struct sdhci_pci_slot *slot)
{
int ret = byt_emmc_probe_slot(slot);
- slot->host->mmc->caps2 |= MMC_CAP2_CQE;
+ //slot->host->mmc->caps2 |= MMC_CAP2_CQE;
if (slot->chip->pdev->device != PCI_DEVICE_ID_INTEL_GLK_EMMC) {
slot->host->mmc->caps2 |= MMC_CAP2_HS400_ES,
>
>>
>>>
>>> Signed-off-by: Anisse Astier <anisse@xxxxxxxxx>
>>> ---
>>> Hi,
>>>
>>> I'm looking forward to your feedback on this patch. Is it safe to
>>> have no voltage switch method ? Should the quirk be used or skipped
>>> entirely ?
>>
>> The eMMC is typically 1.8V only and the voltage switch does nothing. I have
>> been meaning to tidy it up, but it seemed like it was working so it didn't
>> get much priority, until now.
>
> Answering my own question, only the quirk is important; having a voltage
> switch callback or not has no impact.
>
> The kernel seems to assume that it's started at 3.3V, but maybe this is
> the issue then ?
>
> Regards,
>
> Anisse
>
