UbiquitousOS
/
OpenCloudOS-Kernel
mirror of https://gitee.com/OpenCloudOS/OpenCloudOS-Kernel.git
11
0
Fork 0
Code Issues Projects Releases Wiki Activity
OpenCloudOS-Kernel/drivers/mmc/core/Kconfig

29 lines
975 B
Plaintext
Raw Normal View History

mmc: support unsafe resume of cards Since many have the system root on MMC/SD we must allow some foot shooting when it comes to resume. We cannot detect if a card is removed and reinserted during suspend, so the safe approach would be to assume it was, avoiding potential filesystem corruption. This will of course not work if you cannot release the card before suspend. This commit adds a compile time option that makes the MMC layer assume the card wasn't touched if it is redetected upon resume. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
2007-05-01 22:00:02 +08:00
#
# MMC core configuration
#
config MMC_UNSAFE_RESUME
mmc: add module parameter to set whether cards are assumed removable Some people run general-purpose distribution kernels on netbooks with a card that is physically non-removable or logically non-removable (e.g. used for /home) and cannot be cleanly unmounted during suspend. Add a module parameter to set whether cards are assumed removable or non-removable, with the default set by CONFIG_MMC_UNSAFE_RESUME. In general, it is not possible to tell whether a card present in an MMC slot after resume is the same that was there before suspend. So there are two possible behaviours, each of which will cause data loss in some cases: CONFIG_MMC_UNSAFE_RESUME=n (default): Cards are assumed to be removed during suspend. Any filesystem on them must be unmounted before suspend; otherwise, buffered writes will be lost. CONFIG_MMC_UNSAFE_RESUME=y: Cards are assumed to remain present during suspend. They must not be swapped during suspend; otherwise, buffered writes will be flushed to the wrong card. Currently the choice is made at compile time and this allows that to be overridden at module load time. Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Cc: Wouter van Heyst <larstiq@larstiq.dyndns.org> Cc: <linux-mmc@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-12-15 10:01:29 +08:00
bool "Assume MMC/SD cards are non-removable (DANGEROUS)"
mmc: support unsafe resume of cards Since many have the system root on MMC/SD we must allow some foot shooting when it comes to resume. We cannot detect if a card is removed and reinserted during suspend, so the safe approach would be to assume it was, avoiding potential filesystem corruption. This will of course not work if you cannot release the card before suspend. This commit adds a compile time option that makes the MMC layer assume the card wasn't touched if it is redetected upon resume. Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
2007-05-01 22:00:02 +08:00
help
If you say Y here, the MMC layer will assume that all cards
stayed in their respective slots during the suspend. The
normal behaviour is to remove them at suspend and
redetecting them at resume. Breaking this assumption will
in most cases result in data corruption.
This option is usually just for embedded systems which use
a MMC/SD card for rootfs. Most people should say N here.
mmc: add module parameter to set whether cards are assumed removable Some people run general-purpose distribution kernels on netbooks with a card that is physically non-removable or logically non-removable (e.g. used for /home) and cannot be cleanly unmounted during suspend. Add a module parameter to set whether cards are assumed removable or non-removable, with the default set by CONFIG_MMC_UNSAFE_RESUME. In general, it is not possible to tell whether a card present in an MMC slot after resume is the same that was there before suspend. So there are two possible behaviours, each of which will cause data loss in some cases: CONFIG_MMC_UNSAFE_RESUME=n (default): Cards are assumed to be removed during suspend. Any filesystem on them must be unmounted before suspend; otherwise, buffered writes will be lost. CONFIG_MMC_UNSAFE_RESUME=y: Cards are assumed to remain present during suspend. They must not be swapped during suspend; otherwise, buffered writes will be flushed to the wrong card. Currently the choice is made at compile time and this allows that to be overridden at module load time. Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Cc: Wouter van Heyst <larstiq@larstiq.dyndns.org> Cc: <linux-mmc@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-12-15 10:01:29 +08:00
This option sets a default which can be overridden by the
module parameter "removable=0" or "removable=1".
mmc: Aggressive clock gating framework This patch modifies the MMC core code to optionally call the set_ios() operation on the driver with the clock frequency set to 0 (gate) after a grace period of at least 8 MCLK cycles, then restore it (ungate) before any new request. This gives the driver the option to shut down the MCI clock to the MMC/SD card when the clock frequency is 0, i.e. the core has stated that the MCI clock does not need to be generated. It is inspired by existing clock gating code found in the OMAP and Atmel drivers and brings this up to the host abstraction. Gating is performed before and after any MMC request. This patchset implements this for the MMCI/PL180 MMC/SD host controller, but it should be simple to switch OMAP/Atmel over to using this instead. mmc_set_{gated,ungated}() add variable protection to the state holders for the clock gating code. This is particularly important when ordinary .set_ios() calls would race with the .set_ios() call resulting from a delayed gate operation. Signed-off-by: Linus Walleij <linus.walleij@stericsson.com> Reviewed-by: Chris Ball <cjb@laptop.org> Tested-by: Chris Ball <cjb@laptop.org> Signed-off-by: Chris Ball <cjb@laptop.org>
2010-11-09 10:36:50 +08:00
config MMC_CLKGATE
drivers/mmc/core: remove depends on CONFIG_EXPERIMENTAL The CONFIG_EXPERIMENTAL config item has not carried much meaning for a while now and is almost always enabled by default. As agreed during the Linux kernel summit, remove it from any "depends on" lines in Kconfigs. CC: Chris Ball <cjb@laptop.org> Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: Chris Ball <cjb@laptop.org>
2012-10-03 02:17:45 +08:00
bool "MMC host clock gating"
mmc: Aggressive clock gating framework This patch modifies the MMC core code to optionally call the set_ios() operation on the driver with the clock frequency set to 0 (gate) after a grace period of at least 8 MCLK cycles, then restore it (ungate) before any new request. This gives the driver the option to shut down the MCI clock to the MMC/SD card when the clock frequency is 0, i.e. the core has stated that the MCI clock does not need to be generated. It is inspired by existing clock gating code found in the OMAP and Atmel drivers and brings this up to the host abstraction. Gating is performed before and after any MMC request. This patchset implements this for the MMCI/PL180 MMC/SD host controller, but it should be simple to switch OMAP/Atmel over to using this instead. mmc_set_{gated,ungated}() add variable protection to the state holders for the clock gating code. This is particularly important when ordinary .set_ios() calls would race with the .set_ios() call resulting from a delayed gate operation. Signed-off-by: Linus Walleij <linus.walleij@stericsson.com> Reviewed-by: Chris Ball <cjb@laptop.org> Tested-by: Chris Ball <cjb@laptop.org> Signed-off-by: Chris Ball <cjb@laptop.org>
2010-11-09 10:36:50 +08:00
help
This will attempt to aggressively gate the clock to the MMC card.
This is done to save power due to gating off the logic and bus
noise when the MMC card is not in use. Your host driver has to
support handling this in order for it to be of any use.
If unsure, say N.