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

[Bart Van Assche]

On 2/5/26 3:26 AM, Ulf Hansson wrote:
> The other concern I was trying to point out, is that using the runtime
> PM suspend/resume callbacks for managing the QoS constraint isn't
> really a good fit in my opinion, because of the potential idle period
> beyond the point when I/O was completed and when we may be waiting for
> the device to be runtime suspended (especially when runtime PM
> autosuspend is used).
>
> More precisely, during this idle period there is no point in keeping
> the QoS constraint as it would mean potentially wasting unnecessary
> energy by preventing low power states for CPUs. Ideally, I think it
> would be better if we could monitor the I/O request queue to manage
> the QoS constraint directly. Perhaps that is what you suggested too, I
> just didn't get it. :-)

Hmm ... the block layer RPM code monitors the request queue, isn't it?
I don't see how the request queue could be monitored more directly than
how the block layer RPM code does it today - by checking the counter of
the number of requests that is in flight?

Deciding that the I/O request queue is empty is not possible without
waiting until the idle period has expired, isn't it?

> That said, speaking about runtime suspend for UFS. Is runtime PM
> enabled for the UFS card too or is it just the UFS host controller
> that supports it?

It depends on the decisions made by the manufacturer of the device that
includes the UFS device.

In multiple recent UFS-powered devices RPM is enabled for both the UFS
device and the UFS host controller.

Bart.