lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 20 Feb 2017 12:39:21 +0100
From:   Ulf Hansson <>
To:     Ritesh Harjani <>
Cc:     "" <>,
        Adrian Hunter <>,
        Shawn Lin <>,
        "" <>,
        Andy Gross <>,
        "" <>,
        Georgi Djakov <>,
        Alex Lemberg <>,
        Mateusz Nowak <>,
        Yuliy Izrailov <>,
        Asutosh Das <>,
        David Griego <>,
        Sahitya Tummala <>,
        Venkat Gopalakrishnan <>,
        Pramod Gurav <>,,
        "" <>
Subject: Re: [RFC PATCH 0/4] mmc: core: Provide CMD5 awake and partial_init support

On 20 February 2017 at 09:03, Ritesh Harjani <> wrote:
> As per JEDEC spec - CMD5 can be used to awake from sleep mode for emmc.
> This patch series provide CMD5(awake) + mmc_partial_init support to resume
> mmc card device. This is mainly to reduce the resume time.

I assume with "resume time" you don't mean "system PM resume time"?

The current approach we have for MMC is to postpone system PM resume
of the card until it's actually needed, thus via runtime PM instead.
Then the time it takes to re-initialize the eMMC don't affect the
system PM resume time at all.

Therefore I am wondering about how big of a problem this really is. Is
there a specific use case you are optimizing for?

> This was tested on db410c (emmc with HS200 mode) and MS8996 (emmc with HS400ES)
> based internal board. This patch reduced the resume time by ~50% on msm8996
> and ~11% on db410c.

The improved behaviour in percentage is very interesting, but I would
also like to see real numbers.

Moreover, I would like to know what kind of mechanism the
corresponding host drivers/controllers are using for card busy

> As of now this patch series provides a caps (MMC_CAP2_SLEEP_AWAKE) to enable this feature.
> Since there is no dependency on host platform for this, we can enable this feature by
> default as well. Thoughts?

I will look into the series in more detail, however we must not add a
corresponding DT binding for this as this isn't a HW configuration. I
guess what you need to know is that VCCQ stays powered on when the
card is a sleep, else waking up with CMD5 won't work

The current main concern I can think of, is whether the added
complexity to the wakeup path can be justified for the improved

> Ritesh Harjani (4):
>   Documentation: mmc: add mmc-sleep-awake
>   mmc: core: add mmc-sleep-awake caps
>   mmc: mmc: add support for CMD5 awake
>   mmc: core: Implement mmc_partial_init during resume
>  Documentation/devicetree/bindings/mmc/mmc.txt |   2 +
>  drivers/mmc/core/core.c                       |  13 +++
>  drivers/mmc/core/core.h                       |   1 +
>  drivers/mmc/core/host.c                       |   2 +
>  drivers/mmc/core/mmc.c                        | 160 ++++++++++++++++++++++++--
>  include/linux/mmc/card.h                      |   3 +
>  include/linux/mmc/host.h                      |   2 +
>  7 files changed, 176 insertions(+), 7 deletions(-)
> --
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project.

Kind regards

Powered by blists - more mailing lists