From: Matthew Schwartz <matthew.schwartz@linux.dev>
To: Ricky WU <ricky_wu@realtek.com>,
"ulf.hansson@linaro.org" <ulf.hansson@linaro.org>
Cc: "linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mmc: rtsx_pci_sdmmc: implement sdmmc_card_busy function
Date: Fri, 16 Jan 2026 09:24:53 -0800 [thread overview]
Message-ID: <d21955d1-afb3-4a72-bf69-b8e4b6ca2a70@linux.dev> (raw)
In-Reply-To: <220bd61b3ab743b492632764a38f95f0@realtek.com>
On 1/15/26 2:23 AM, Ricky WU wrote:
> Hi Matthew,
>
> Thanks for working on this patch.
>
> We’ve tested this change on our platforms and can confirm that adding the
> card_busy() callback does resolve the
> “cannot verify signal voltage switch” issue for us 👍.
>
> That said, while reviewing the change we noticed a potential redundancy in
> the existing driver logic. In sdmmc_switch_voltage() we already perform
> explicit DAT line stabilization checks via
> sd_wait_voltage_stable_1() and sd_wait_voltage_stable_2().
>
> Once card_busy() is implemented and used by the MMC core during the
> voltage-switch verification phase, these two stabilization steps appear to
> be partially overlapping with what the core now validates via
> card_busy(). In our testing, with card_busy() present, the stable_1 /
> stable_2 logic no longer seems strictly necessary and could likely be
> simplified or removed with some adjustment.
>
> From a process point of view, we’re not sure which approach you’d prefer:
>
> Land your patch as-is first, and then we can follow up with a separate
> cleanup/modification patch to adjust sdmmc_switch_voltage(), or
>
> We can prepare an additional patch that builds on top of yours and share
> it with you for review, so the changes can be aligned together.
Hi Ricky,
Let's go with this method.
Thanks!
Matt
>
> Please let us know which option you think makes more sense for upstream, or
> if you’d prefer a different approach.
>
> Thanks again for the fix and for looking into this driver.
>
> Best regards,
> Ricky
>
>> rtsx_pci_sdmmc does not have an sdmmc_card_busy function, so any voltage
>> switches cause a kernel warning, "mmc0: cannot verify signal voltage switch."
>>
>> Copy the sdmmc_card_busy function from rtsx_pci_usb to rtsx_pci_sdmmc to
>> fix this.
>>
>> Fixes: ff984e57d36e ("mmc: Add realtek pcie sdmmc host driver")
>> Signed-off-by: Matthew Schwartz <matthew.schwartz@linux.dev>
>> ---
>> drivers/mmc/host/rtsx_pci_sdmmc.c | 41
>> +++++++++++++++++++++++++++++++
>> 1 file changed, 41 insertions(+)
>>
>> diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c
>> b/drivers/mmc/host/rtsx_pci_sdmmc.c
>> index dc2587ff8519..4db3328f46df 100644
>> --- a/drivers/mmc/host/rtsx_pci_sdmmc.c
>> +++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
>> @@ -1306,6 +1306,46 @@ static int sdmmc_switch_voltage(struct mmc_host
>> *mmc, struct mmc_ios *ios)
>> return err;
>> }
>>
>> +static int sdmmc_card_busy(struct mmc_host *mmc) {
>> + struct realtek_pci_sdmmc *host = mmc_priv(mmc);
>> + struct rtsx_pcr *pcr = host->pcr;
>> + int err;
>> + u8 stat;
>> + u8 mask = SD_DAT3_STATUS | SD_DAT2_STATUS | SD_DAT1_STATUS
>> + | SD_DAT0_STATUS;
>> +
>> + mutex_lock(&pcr->pcr_mutex);
>> +
>> + rtsx_pci_start_run(pcr);
>> +
>> + err = rtsx_pci_write_register(pcr, SD_BUS_STAT,
>> + SD_CLK_TOGGLE_EN |
>> SD_CLK_FORCE_STOP,
>> + SD_CLK_TOGGLE_EN);
>> + if (err)
>> + goto out;
>> +
>> + mdelay(1);
>> +
>> + err = rtsx_pci_read_register(pcr, SD_BUS_STAT, &stat);
>> + if (err)
>> + goto out;
>> +
>> + err = rtsx_pci_write_register(pcr, SD_BUS_STAT,
>> + SD_CLK_TOGGLE_EN |
>> +SD_CLK_FORCE_STOP, 0);
>> +out:
>> + mutex_unlock(&pcr->pcr_mutex);
>> +
>> + if (err)
>> + return err;
>> +
>> + /* check if any pin between dat[0:3] is low */
>> + if ((stat & mask) != mask)
>> + return 1;
>> + else
>> + return 0;
>> +}
>> +
>> static int sdmmc_execute_tuning(struct mmc_host *mmc, u32 opcode) {
>> struct realtek_pci_sdmmc *host = mmc_priv(mmc); @@ -1418,6
>> +1458,7 @@ static const struct mmc_host_ops realtek_pci_sdmmc_ops = {
>> .get_ro = sdmmc_get_ro,
>> .get_cd = sdmmc_get_cd,
>> .start_signal_voltage_switch = sdmmc_switch_voltage,
>> + .card_busy = sdmmc_card_busy,
>> .execute_tuning = sdmmc_execute_tuning,
>> .init_sd_express = sdmmc_init_sd_express, };
>> --
>> 2.52.0
>
next prev parent reply other threads:[~2026-01-16 17:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-29 20:45 [PATCH] mmc: rtsx_pci_sdmmc: implement sdmmc_card_busy function Matthew Schwartz
2026-01-15 10:23 ` Ricky WU
2026-01-16 17:24 ` Matthew Schwartz [this message]
2026-01-21 14:54 ` Ulf Hansson
2026-01-22 8:47 ` Ricky WU
2026-01-28 3:06 ` Ricky WU
2026-01-28 12:42 ` Ulf Hansson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d21955d1-afb3-4a72-bf69-b8e4b6ca2a70@linux.dev \
--to=matthew.schwartz@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=ricky_wu@realtek.com \
--cc=ulf.hansson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.