Re: [BUG] - Short freezes in gameplay due to MMC_CAP_AGGRESSIVE_PM on RTS525A card reader

[Ulf Hansson]

On Wed, 28 Jan 2026 at 18:14, Bart Van Assche <bvanassche@xxxxxxx> wrote:
>
> On 1/28/26 5:23 AM, Ulf Hansson wrote:
> > How does other block device drivers do this?
>
> The role of the Linux kernel is to provide mechanisms while remaining as
> policy-neutral as possible. In other words, it is up to user space to
> decide whether to enable or to disable runtime PM.

I agree.

>
> For UFS devices some form of runtime PM is enabled by default for
> battery-powered devices because otherwise the impact on battery life
> would be unacceptable. If the latency impact of runtime resume is not
> acceptable for some applications then it is up to user space software to
> tune runtime power management as necessary.

Seems reasonable to me, but how do we distinguish that it's a
battery-powered device?

Are we considering UFS a technology that is used solely for
battery-powered devices or is there something else we consider?

>
> Additionally, cpu_latency_qos_update_request() is called by the UFS
> driver during runtime suspend and resume to prevent that CPU frequency
> scaling negatively affects UFS processing latency. I'd like to move
> these cpu_latency_qos_update_request() calls from the UFS driver into
> the block layer core because I think that every block driver that
> supports runtime power management needs this.

While this is more about performance tuning rather than I/O request
latency in regards to runtime PM, I certainly agree that this belongs
in the common block code.

Although, a tricky part when moving it upwards into the more common
layers, is that those latency constraint values may have a very
different impact, as the numbers are platform specific, right?

Thanks a lot for your comments!

Kind regards
Uffe