Message-ID: <CAPDyKFoC-dwzcsABNy9pA=GGirBWwcxQhNMeTSSStXHtXmWbcg@mail.gmail.com>
Date: Wed, 28 Jan 2026 14:23:57 +0100
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Christoph Hellwig <hch@....de>, Bart Van Assche <bvanassche@....org>, Jens Axboe <axboe@...nel.dk>, 
	Ricky WU <ricky_wu@...ltek.com>, Matthew Schwartz <matthew.schwartz@...ux.dev>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, 
	"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>, linux-block <linux-block@...r.kernel.org>
Subject: Re: [BUG] - Short freezes in gameplay due to MMC_CAP_AGGRESSIVE_PM on
 RTS525A card reader

+ linux-block, Jens, Bart (ufs), Christoph (nvme)

[...]

> > >>>>>>>
> > >>>>>>> diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c
> > >>>> b/drivers/mmc/host/rtsx_pci_sdmmc.c
> > >>>>>>> index 1e5170435cf8..a7c7daf66d5c 100644
> > >>>>>>> --- a/drivers/mmc/host/rtsx_pci_sdmmc.c
> > >>>>>>> +++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
> > >>>>>>> @@ -1499,7 +1499,7 @@ static void realtek_init_host(struct
> > >>>> realtek_pci_sdmmc *host)
> > >>>>>>>         mmc->caps = MMC_CAP_4_BIT_DATA |
> > >>>> MMC_CAP_SD_HIGHSPEED |
> > >>>>>>>                 MMC_CAP_MMC_HIGHSPEED |
> > >>>> MMC_CAP_BUS_WIDTH_TEST |
> > >>>>>>>                 MMC_CAP_UHS_SDR12 |
> > MMC_CAP_UHS_SDR25;
> > >>>>>>> -       if (pcr->rtd3_en)
> > >>>>>>> +       if (pcr->rtd3_en && PCI_PID(pcr) != PID_525A)
> > >>>>>>>                 mmc->caps = mmc->caps |
> > >>>> MMC_CAP_AGGRESSIVE_PM;
> > >>>>>>>         mmc->caps2 = MMC_CAP2_NO_PRESCAN_POWERUP |
> > >>>> MMC_CAP2_FULL_PWR_CYCLE |
> > >>>>>>>                 MMC_CAP2_NO_SDIO;
> > >>>>>>> --
> > >>>>>>> 2.52.0
> > >>>>>>>
> > >>>>>>> I think what's happening here is that RTS525A shuts off power to the
> > >> card
> > >>>> reader when games are idle for 10 seconds or more, and then when the
> > >> game
> > >>>> goes to load new assets it has to go through the whole re-tuning process
> > >> which
> > >>>> takes 1-2 seconds. The other brands of card readers I have keep the
> > device
> > >>>> powered the whole time so they do not have this issue, and that's what
> > >>>> untagging MMC_CAP_AGGRESSIVE_PM seems to mimic.
> > >>>>>>
> > >>>>>> Right, MMC_CAP_AGGRESSIVE_PM does exactly what you think. If
> > there
> > >>>> are
> > >>>>>> an idle period of no requests for the SD card, the mmc core may
> > decide
> > >>>>>> to power-off the card for those mmc host drivers that has set
> > >>>>>> MMC_CAP_AGGRESSIVE_PM. The idea is that we want to avoid
> > wasting
> > >>>> power
> > >>>>>> when the card is unused, which is typically important on some battery
> > >>>>>> driven devices.
> > >>>>>>
> > >>>>>> The main problem however, is that we are lacking a common policy for
> > >>>>>> how to handle this generically for all eMMC/SD cards. Ideally it
> > >>>>>> should be independent of what mmc host drivers that is managing it,
> > >>>>>> but that's not the case.
> > >>>>>>
> > >>>>>> That said, without changing the code you can use sysfs to either tweak
> > >>>>>> the idle-period or to simply prevent "runtime_suspend" (meaning
> > >>>>>> power-off) for the SD card.
> > >>>>>>
> > >>>
> > >>> Hi Ulf, Matthew
> > >>>
> > >>> In our Windows card reader driver, the idle period time is set to
> > >> approximately 10 seconds.
> > >>> Is there any recommended way to control or configure this idle period
> > time?
> > >>
> > >> I tried adjusting pm_schedule_suspend(device, 10000); in rtsx_pcr, but this
> > just
> > >> increases the time until you inevitably run into the issue. There are some
> > >> games that can go a very long time in runtime_suspend without loading
> > new
> > >> assets, but when they inevitably go into runtime_resume after say 3 or 5
> > >> minutes, this hang in gameplay seems unavoidable with
> > >> MMC_CAP_AGGRESSIVE_PM in particular. I found an old laptop of mine
> > with
> > >> an RTS5261 reader and that has the same issue unless I disable
> > >> MMC_CAP_AGGRESSIVE_PM.
> > >>
> > >>> Or is it possible to introduce a capability tag that is less aggressive than
> > >> MMC_CAP_AGGRESSIVE_PM?
> > >>
> > >> Full disclosure: This is my first time looking at mmc/rtsx code, so I'll defer to
> > >> Ulf on this.
> > >>
> > >>> Since most notebooks have very strict power-saving requirements during
> > idle
> > >> states,
> > >>> we are not able to avoid using the MMC_CAP_AGGRESSIVE_PM capability.
> > >>
> > >> The only other comparison I have is from card readers in other devices of
> > mine,
> > >> a Genesys Logic GL9767 in a ROG Ally X and an O2 Micro in my Steam
> > Deck.
> > >> For both of these, the card reader drivers do not seem to implement any
> > form
> > >> of runtime power management on Linux, so the experience when playing
> > >> games off of them has been flawless.
> > >>
> > >> Matt
> > >>
> > >
> > > Since our driver is designed to be a general-purpose driver for all readers,
> > > the scenarios you mentioned — ROG Ally X and Steam Deck — are gaming
> > handheld devices.
> >
> > The drivers they use were not designed to be gaming-focused either, they are
> > general purpose.
> > O2 Micro has been around since before handheld gaming PCs were even a
> > thing. Personally,
> > I disagree with classifying gaming as falling outside of "general purpose"
> > parameters.
> >
>
> What I’m referring to here is the product positioning — whether the device is categorized as a gaming handheld or a notebook PC.
>
> > > For Realtek reader usage on handheld platforms,
> > > we would recommend disabling this power-saving function(pcr->rtd3_en)
> > through BIOS settings/guidelines.
> >
> > Just to clarify, is the recommendation to disable this feature for every device
> > with a Realtek card
> > reader that might be used to play games from an SD card? My MSI Raider
> > GE67HX laptop with RTS5261 has
> > this same freeze in gameplay if I use an SD card. Using an SD card as a
> > portable library is very
> > common.
> >
> > Thanks,
> > Matt
> >
>
> Over the past few years, the vast majority of notebook manufacturers have placed strong emphasis on power consumption,
> requiring support for S0ix with very strict power efficiency targets.
> As a result, we updated the driver to further reduce power consumption.
>
> To address this issue, it seems necessary to provide a mechanism that allows games or user-mode applications to dynamically enable or disable the power-management (PM) functionality.
>
> Ricky

I have looped in the linux-block list and a couple of maintainers for
other block devices, to see how if they may have some input around
this topic.

Jens, Bart, Christoph, let me summarize:

For eMMC/SD, we have implemented runtime PM support for the card to
allow us to save power by putting the card into a low power state when
card has been idle for some period (3s is the default idle-period).

When we introduced this code in the mmc core several years ago, it was
kind of experimental, so we decided to have it default disabled. To
enable it, the mmc host driver needs to set a specific capability flag
(MMC_CAP_AGGRESSIVE_PM), statically at build-time (probably a not the
best idea in hindsight, but the use is still quite limited).

Now, to the problem. For the rtsx_pci_sdmmc mmc driver
MMC_CAP_AGGRESSIVE_PM is set. This works fine for most use-cases and
helps to save power, although for some gaming use-cases this fails.
More precisely, restoring the power to card introduces latency (of
course) - and this latency isn't acceptable for gaming.

To address the problem, there are a couple of ways for user space via
sysfs to control the behaviour.
1) It can prevent runtime suspend of the card via sysfs, before the
gaming use-case starts.
2) It can put a PM QoS latency constraint to prevent the lower power
state of the card (we don't obey to these constraints in the mmc core
today, but we could extend it to do it).
3) Increase the runtime PM idle period of the card (may not be
sufficient for gaming, but still an option for user space).

Another, completely different option is to change the behavior in the
mmc core, to default keep the card runtime resumed until user-space
allows runtime suspend via sysfs.

How does other block device drivers do this? What are their default
behaviors in regards to runtime PM?

[...]

Kind regards
Uffe

Powered by blists - more mailing lists