summaryrefslogtreecommitdiffstats
path: root/mm/zbud.c
diff options
context:
space:
mode:
authorUlf Hansson <ulf.hansson@linaro.org>2013-10-10 17:22:23 +0200
committerChris Ball <cjb@laptop.org>2013-10-30 20:28:43 -0400
commit4d22378221bd0ed69c2e99408d31c108d72aeb80 (patch)
tree298044ec52b46b7de410e924d85508f0abadee16 /mm/zbud.c
parent0cb403a227774f60f6f52137ca3618805498c4e6 (diff)
downloadtalos-op-linux-4d22378221bd0ed69c2e99408d31c108d72aeb80.tar.gz
talos-op-linux-4d22378221bd0ed69c2e99408d31c108d72aeb80.zip
mmc: core: Add MMC_CAP_RUNTIME_RESUME to resume at runtime_resume
In some environments it is to prefer to postpone the resume of the card device until runtime_resume is being carried out, since it will mean a signficant decrease of the total system resume time. The reason of the decreased resume time is simply because of the actual re-initalization of the card, which typically takes hundreds of milliseconds, is performed outside the resume sequence and wont thus affect it. For removable card, the detect work tries to re-detect the card to make sure it is still present, as a part of that sequence the card will also be runtime_resumed and thus also fully resumed. For a non-removable card, typically a mmc blk request will trigger a runtime_resume and thus fully resume the card. This also means the first request will likely suffer from an inital latency since the re-initialization of the card needs to be performed. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org>
Diffstat (limited to 'mm/zbud.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud