From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=95.215.58.136 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793818144; b=cLnxOPK3cZ3QMuyCdRikdi8RWdqBXDetO7NE1qDvaIVOiKotxH6+zZqp93t3okbq6XJA 5qw8u2qPMLnkWANPzvisfEg4C7ATtziBO7/B4OBbddhaLofCLH7GpDRK7aufgjAIzLS53 AcunwfpK9OVRFWRG1TJQ3ITMs1AcxDQO2JSc6F99wQRRq8WhW0iCGHQlU9TGGCCU0p6gS URlecGxs0KNzPDAN5KaTZ8p0Gi82BvCB9NPv84oJiQscsVXqoEooxtnuj28I2JMkKZS/9 wiDvPUitRkn4ekO/gMB97ZtVMkwS2cUUuxLgP46Yf7Sx0J7d5Kqk1kZLV/8qqWr52CA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793818144; h=DMARC-Filter:X-Envelope-To:DKIM-Signature:X-Envelope-To:Received: X-Mizu-Trace-ID:X-Migadu-Flow:Message-ID:Date:MIME-Version:User-Agent: Subject:To:Cc:References:Content-Language:From:In-Reply-To: Content-Type:Content-Transfer-Encoding; bh=jxDJfQuqQySbeyhsMbdeZNmsBQGEc57n+fRANcEbFqc=; b=y0b7x9J14X+0xPgCgDxsYCwkKr1SEdcnSpn0yh5s0plOeZK11L9jmCmdYMKVksgMMxeA 6d2IuuXp8UUlRINZyoeALyM0y+bQvHjGbY3LF3T3F51k/PRyQDKRFldjPvpuFLPHMSx4A SA3USYVzdxMhuQd2lk9Sn+KXFx8ti08ZS+dSZJyn2rsy53Wj47o4CaQsErjV458qEkRKL aMg/CpIbKOrzd11/j8JqurIEz+cUpFxhbnf6fM0L5Yzd1HIamapBo3Wj18PCJCyKRKUd8 N7XG1/PKYRAdLrJyrBshwPdvt85YPKJrskx1axFzPBnZkZxmCHW3HUU+5EkNO4uX7hA== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=YLKlqYBe; arc=none smtp.remote-ip=95.215.58.136 Received: from mta1.migadu.com (out-136.mta1.migadu.com [95.215.58.136]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 10EF4606A31B for ; Wed, 4 Nov 2026 18:49:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 10EF4606A31B Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=YLKlqYBe X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=HhYkGcuQrbLxya5Xd6Xhc7SivvwextAyDRpHv8somGw=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1793818141; v=1; x=1794422941; b=YLKlqYBel6PfpITm5cSBNxwyzxER01KRFjFuL39PTtTfCRD8ERoCSUuIA2qh1JOiIjcemOF2 2SNQZTDqfVz9rCXAbKZxe3v4yAKVMcPHqCRU5lfHLg16MC9BO3dl+/Lj8OELsntWy14hFkfO//Y csAC25jQRzYgZ428pEbwI4js= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id ca283ee4143799e8; Wed, 04 Nov 2026 18:49:00 +0000 X-Mizu-Trace-ID: ca283ee4143799e8 X-Migadu-Flow: FLOW_OUT Message-ID: <5c29414f-69ec-4e43-ace6-4a335c04fbf3@linux.dev> Date: Wed, 4 Nov 2026 10:48:58 -0800 X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mmc: sdhci-pci-gli: GL9767: Wait for UHS-II PHY before LPM To: =?UTF-8?B?QmVuQ2h1YW5nW+iOiuaZuumHj10=?= , Adrian Hunter , Ulf Hansson Cc: "linux-mmc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Victor Shih , Lucas Lai References: <20261021233313.247155-1-matthew.schwartz@linux.dev> Content-Language: en-US From: Matthew Schwartz In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 10/30/26 3:53 AM, BenChuang[莊智量] wrote: > > >> -----Original Message----- >> From: Matthew Schwartz >> Sent: Thursday, October 22, 2026 7:33 AM >> To: Adrian Hunter ; Ulf Hansson >> Cc: linux-mmc@vger.kernel.org; linux-kernel@vger.kernel.org; Victor Shih ; Lucas Lai >> ; BenChuang[莊智量] ; Matthew Schwartz >> >> Subject: [PATCH] mmc: sdhci-pci-gli: GL9767: Wait for UHS-II PHY before LPM >> >> sdhci_gl9767_set_clock() re-enables low power negotiation right after >> releasing the UHS-II PHY reset. If the bus then goes idle before the >> PHY has settled, every SDHCI MMIO read returns all-ones for about 250 >> us. sdhci_uhs2_interface_detect() takes that as IF_DETECT and LANE_SYNC >> set, so a UHS-I only microSD card is treated as UHS-II. The attach then >> either fails with "SDHCI_UHS2_CAPS_PTR(65535) is wrong" or, if the >> registers come back before the CAPS_PTR read, runs DEVICE_INIT 30 times >> with a 10 second timeout each and delays card detection by 5 minutes. >> >> Config register 0x8CC reads 0x2000 from clock enable until about 250-300 >> us after the PHY reset release and 0x1000 otherwise. Poll its bit 13 >> before re-enabling low power negotiation. The register meaning is >> inferred from that behaviour, and with the wait in place 12 of 12 >> UHS-II probes of a UHS-I card correctly found no UHS-II interface. >> >> Fixes: 27dd3b82557a ("mmc: sdhci-pci-gli: enable UHS-II mode for GL9767") >> Signed-off-by: Matthew Schwartz > > Hi Matthew, > > Thanks for the patch. > > I checked the GL9767 register definition. Register 0x8CC is the UHS-II > Status Register, and bit 13 is documented as > UHS2_WAKEUP_ACTIVATE. > > I was able to reproduce the "SDHCI_UHS2_CAPS_PTR(65535) is wrong" issue > on my GL9767 test system, and I can no longer reproduce it with this > patch applied. Thanks for looking up the definition and for testing. > > Tested-by: Ben Chuang > >> --- >> drivers/mmc/host/sdhci-pci-gli.c | 29 ++++++++++++++++++++++++++++- >> 1 file changed, 28 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/mmc/host/sdhci-pci-gli.c b/drivers/mmc/host/sdhci-pci-gli.c >> index b55618566d651..bd383918d27c7 100644 >> --- a/drivers/mmc/host/sdhci-pci-gli.c >> +++ b/drivers/mmc/host/sdhci-pci-gli.c >> @@ -205,6 +205,9 @@ >> #define PCIE_GLI_9767_COMBO_MUX_CTL_RST_EN BIT(6) >> #define PCIE_GLI_9767_COMBO_MUX_CTL_WAIT_PERST_EN BIT(10) >> >> +#define PCIE_GLI_9767_PHY_STS 0x8CC >> +#define PCIE_GLI_9767_PHY_STS_UHS2_BUSY BIT(13) > > maybe PCIE_GLI_9767_UHS2_STS and PCIE_GLI_9767_UHS2_STS_WAKEUP_ACTIVATE Sounds good, will do in v2. > >> + >> #define PCIE_GLI_9767_PWR_MACRO_CTL 0x8D0 >> #define PCIE_GLI_9767_PWR_MACRO_CTL_LOW_VOLTAGE GENMASK(3, 0) >> #define PCIE_GLI_9767_PWR_MACRO_CTL_LD0_LOW_OUTPUT_VOLTAGE GENMASK(15, 12) >> @@ -1190,6 +1193,27 @@ static void gl9767_set_low_power_negotiation(struct pci_dev *pdev, bool enable) >> gl9767_vhs_read(pdev); >> } >> >> +static u32 gl9767_read_phy_sts(struct pci_dev *pdev) >> +{ >> + u32 value; >> + >> + pci_read_config_dword(pdev, PCIE_GLI_9767_PHY_STS, &value); >> + >> + return value; >> +} >> + >> +static void sdhci_gl9767_uhs2_wait_phy_ready(struct sdhci_host *host) >> +{ >> + struct sdhci_pci_slot *slot = sdhci_priv(host); >> + struct pci_dev *pdev = slot->chip->pdev; >> + u32 value; >> + >> + if (read_poll_timeout_atomic(gl9767_read_phy_sts, value, >> + !(value & PCIE_GLI_9767_PHY_STS_UHS2_BUSY), >> + 10, 10000, false, pdev)) >> + pr_warn("%s: UHS-II PHY not ready after reset.\n", mmc_hostname(host->mmc)); >> +} >> + > > One thing I was curious about. > > The commit message mentions an observed settling time of approximately > 250-300 us, while the polling loop allows up to 10 ms before reporting > a timeout. > > I assume the timeout is intentionally conservative, but I was wondering > whether there was any particular reason for choosing 10 ms. No particular reason beyond headroom. I only had the measured 250-300 us to go on, so I picked a ceiling well above that which is only reached if the bit never clears. If the GL9767 spec gives a maximum wakeup time, I'm happy to use that instead. > > Best regards, > Ben Chuang > >> static void sdhci_gl9767_uhs2_phy_reset(struct sdhci_host *host, bool assert) >> { >> struct sdhci_pci_slot *slot = sdhci_priv(host); >> @@ -1276,9 +1300,12 @@ static void sdhci_gl9767_set_clock(struct sdhci_host *host, unsigned int clock) >> >> sdhci_enable_clk(host, clk); >> >> - if (mmc_card_uhs2(host->mmc)) >> + if (mmc_card_uhs2(host->mmc)) { >> /* De-assert reset */ >> sdhci_gl9767_uhs2_phy_reset(host, false); >> + /* Low power negotiation before the PHY settles makes MMIO read all-ones */ >> + sdhci_gl9767_uhs2_wait_phy_ready(host); >> + } >> >> gl9767_set_low_power_negotiation(pdev, true); >> } >> -- >> 2.56.0 > > ________________________________ > > Genesys Logic Email Confidentiality Notice: > This mail and any attachments may contain information that is confidential, proprietary, privileged or otherwise protected by law. The mail is intended solely for the named addressee (or a person responsible for delivering it to the addressee). If you are not the intended recipient of this mail, you are not authorized to read, print, copy or disseminate this mail. > > If you have received this email in error, please notify us immediately by reply email and immediately delete this message and any attachments from your system. Please be noted that any unauthorized use, dissemination, distribution or copying of this email is strictly prohibited. > ________________________________