Re: [PATCH V1] mmc: sdhci-msm: Enable MMC_CAP_AGGRESSIVE_PM for qualcomm controllers

[Sarthak Garg]

On 5/27/2025 8:50 PM, Ulf Hansson wrote:
> On Wed, 21 May 2025 at 17:41, Dmitry Baryshkov
> <dmitry.baryshkov@xxxxxxxxxxxxxxxx> wrote:
> > On 21/05/2025 18:36, Sarthak Garg wrote:
> > > On 5/21/2025 8:19 PM, Dmitry Baryshkov wrote:
> > > > On 21/05/2025 17:35, Sarthak Garg wrote:
> > > > > On 5/21/2025 6:25 PM, Dmitry Baryshkov wrote:
> > > > > > On Wed, May 21, 2025 at 12:46:49PM +0530, Sarthak Garg wrote:
> > > > > > > On 11/15/2024 6:53 PM, Dmitry Baryshkov wrote:
> > > > > > > > On Fri, 15 Nov 2024 at 12:23, Sarthak Garg
> > > > > > > > <quic_sartgarg@xxxxxxxxxxx> wrote:
> > > > > > > > > On 11/4/2024 4:19 PM, Dmitry Baryshkov wrote:
> > > > > > > > > > On Mon, Nov 04, 2024 at 11:37:22AM +0530, Sarthak Garg wrote:
> > > > > > > > > > > Enable MMC_CAP_AGGRESSIVE_PM for qualcomm controllers.
> > > > > > > > > > > This enables runtime PM for eMMC/SD card.
> > > > > > > > > >
> > > > > > > > > > Could you please mention, which platforms were tested with this
> > > > > > > > > > patch?
> > > > > > > > > > Note, upstream kernel supports a lot of platforms, including
> > > > > > > > > > MSM8974, I
> > > > > > > > > > think the oldest one, which uses SDHCI.
> > > > > > > > >
> > > > > > > > > This was tested with qdu1000 platform.
> > > > > > > >
> > > > > > > > Are you sure that it won't break other platforms?
> > > > > > >
> > > > > > > Thanks for your valuable comment.
> > > > > > > I am not sure about the older platforms so to avoid issues on older
> > > > > > > platforms we can enable this for all SDCC version 5.0 targets ?
> > > > > >
> > > > > > No, there are still a lot of platforms. Either explain why this is
> > > > > > required for all v5 platforms (and won't break those) or find some
> > > > > > other
> > > > > > way, e.g. limit the change to QDU1000, explaining why it is _not_
> > > > > > applicable to other platforms.
> > > > >
> > > > > Thanks for your comment.
> > > >
> > > > No need to.
> > > >   >> I agree with your concern but for me also its not possible to test on
> > > > > all the platforms.
> > > >
> > > > Sure.
> > > > > > Lets say if I want to enable this caps for QDU1000 for which it has
> > > > > been tested and on any other upcoming target after testing, then how
> > > > > can I proceed to enable?
> > > >
> > > > Let's start from the beginning: why do you want to enable it on QDU1000?
> > >
> > > QDU1000 is one latest available target where we have enabled this and
> > > tested. This has been enabled to save power.
> >
> > Isn't it a powered device? How much power is the save? Is it worth it?
>
> Just wanted to share my view around this, in a slightly more generic
> way. My answer to the above, would be, yes, for any battery driven
> platform, it should be worth it.
>
> Unfortunately, I don't have any fresh numbers to share for eMMC/SD,
> but just searching for some vendor specific information about their
> eMMC/SD cards, should tell us I think. In fact, this problem isn't
> even limited to eMMC/SD, but rather applies to most flash based
> storage (UFS/NVMe etc) that are used on these types of platforms.
>
> How much there is to gain, obviously depends on the internal behaviour
> of the storage device. Of course, the number of cards being attached
> is important too.
>
> That said, enabling this feature (MMC_CAP_AGGRESSIVE_PM) needs to be
> done by taking into account that being *too* aggressive (too
> frequently) with turning off the power to the card, may cause a
> potential wear-out/brake of the card if we end up preventing it from
> doing internal house-keeping for too long.
>
> The current default autosuspend timeout
> (pm_runtime_set_autosuspend_delay()) is set to 3s in mmc_blk_probe().
> That seems way too aggressive in my opinion, so perhaps increasing
> that value to ~180s could allow us to enable this, even if 180s is
> just a guesstimate from my side.
>
> Also note that, during system wide suspend we always turn off the
> power to the card - and we really don't know if that is too frequent
> too. It depends on how the platform is used, compare a laptop with a
> smartphone, the frequency greatly differs.
>
> Kind regards
> Uffe


Hi ulf,

We already have AGGRESSIVE_PM enabled for all our internal targets and 
they are in production for quite long time (5-6 years) and haven't seen 
and performance degradations due to garbage collection. Also wear tears 
are not observed as per my current observations so far.

Like you rightly mentioned we may have battery powered devices where 
this caps will be useful and on the other hand we have always powered 
devices where this caps may not be needed, so can we make device tree 
changes and enable this PM property per board selectively?

Also I see there are four below vendor files who have already enabled 
this caps in their vendor file.

sdhci-pci-core.c sdhci-omap.c sdhci-acpi.c rtsx_pci_sdmmc.c

Let me know how can we proceed.

Regards,
Sarthak