Message-ID: <z3lucllumwco5xcvphnzwaqjvdhmbraofhww4i427exqfhxrot@rsrvalmulhup>
Date: Thu, 24 Jul 2025 14:58:20 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Sarthak Garg <quic_sartgarg@...cinc.com>
Cc: Ulf Hansson <ulf.hansson@...aro.org>,
        Adrian Hunter <adrian.hunter@...el.com>, linux-mmc@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
        quic_cang@...cinc.com, quic_nguyenb@...cinc.com,
        quic_rampraka@...cinc.com, quic_pragalla@...cinc.com,
        quic_sayalil@...cinc.com, quic_nitirawa@...cinc.com,
        quic_bhaskarv@...cinc.com, kernel@...cinc.com
Subject: Re: [PATCH V1] mmc: sdhci-msm: Enable MMC_CAP_AGGRESSIVE_PM for
 qualcomm controllers

On Thu, Jul 24, 2025 at 05:12:56PM +0530, Sarthak Garg wrote:
> 
> 
> On 5/27/2025 8:50 PM, Ulf Hansson wrote:
> > On Wed, 21 May 2025 at 17:41, Dmitry Baryshkov
> > <dmitry.baryshkov@....qualcomm.com> 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@...cinc.com> 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

Upstream kernels support targets starting from APQ8060, so they are much
older than 5-6 years. For example, I'd like to point out several SDHCI
v4 targets (MSM8974 - MSM8998).

> 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
> 
> 
> 
> 
> 

-- 
With best wishes
Dmitry

Powered by blists - more mailing lists