Skip to content

Commit

Permalink
---
Browse files Browse the repository at this point in the history
yaml
---
r: 274128
b: refs/heads/master
c: d5240df
h: refs/heads/master
v: v3
  • Loading branch information
Russell King committed Nov 5, 2011
1 parent 8e52c0c commit 0ffc614
Show file tree
Hide file tree
Showing 378 changed files with 9,096 additions and 11,265 deletions.
2 changes: 1 addition & 1 deletion [refs]
Original file line number Diff line number Diff line change
@@ -1,2 +1,2 @@
---
refs/heads/master: 534baf55dd16d5de9c8d045190469eef9d31ffff
refs/heads/master: d5240dfd3c80ad2fd17b25ca38d199ab1262ab6e
8 changes: 4 additions & 4 deletions trunk/Documentation/power/freezing-of-tasks.txt
Original file line number Diff line number Diff line change
Expand Up @@ -22,12 +22,12 @@ try_to_freeze_tasks() that sets TIF_FREEZE for all of the freezable tasks and
either wakes them up, if they are kernel threads, or sends fake signals to them,
if they are user space processes. A task that has TIF_FREEZE set, should react
to it by calling the function called refrigerator() (defined in
kernel/freezer.c), which sets the task's PF_FROZEN flag, changes its state
kernel/power/process.c), which sets the task's PF_FROZEN flag, changes its state
to TASK_UNINTERRUPTIBLE and makes it loop until PF_FROZEN is cleared for it.
Then, we say that the task is 'frozen' and therefore the set of functions
handling this mechanism is referred to as 'the freezer' (these functions are
defined in kernel/power/process.c, kernel/freezer.c & include/linux/freezer.h).
User space processes are generally frozen before kernel threads.
defined in kernel/power/process.c and include/linux/freezer.h). User space
processes are generally frozen before kernel threads.

It is not recommended to call refrigerator() directly. Instead, it is
recommended to use the try_to_freeze() function (defined in
Expand Down Expand Up @@ -95,7 +95,7 @@ after the memory for the image has been freed, we don't want tasks to allocate
additional memory and we prevent them from doing that by freezing them earlier.
[Of course, this also means that device drivers should not allocate substantial
amounts of memory from their .suspend() callbacks before hibernation, but this
is a separate issue.]
is e separate issue.]

3. The third reason is to prevent user space processes and some kernel threads
from interfering with the suspending and resuming of devices. A user space
Expand Down
10 changes: 0 additions & 10 deletions trunk/Documentation/power/runtime_pm.txt
Original file line number Diff line number Diff line change
Expand Up @@ -789,16 +789,6 @@ will behave normally, not taking the autosuspend delay into account.
Similarly, if the power.use_autosuspend field isn't set then the autosuspend
helper functions will behave just like the non-autosuspend counterparts.

Under some circumstances a driver or subsystem may want to prevent a device
from autosuspending immediately, even though the usage counter is zero and the
autosuspend delay time has expired. If the ->runtime_suspend() callback
returns -EAGAIN or -EBUSY, and if the next autosuspend delay expiration time is
in the future (as it normally would be if the callback invoked
pm_runtime_mark_last_busy()), the PM core will automatically reschedule the
autosuspend. The ->runtime_suspend() callback can't do this rescheduling
itself because no suspend requests of any kind are accepted while the device is
suspending (i.e., while the callback is running).

The implementation is well suited for asynchronous use in interrupt contexts.
However such use inevitably involves races, because the PM core can't
synchronize ->runtime_suspend() callbacks with the arrival of I/O requests.
Expand Down
195 changes: 0 additions & 195 deletions trunk/Documentation/watchdog/convert_drivers_to_kernel_api.txt

This file was deleted.

2 changes: 1 addition & 1 deletion trunk/MAINTAINERS
Original file line number Diff line number Diff line change
Expand Up @@ -2387,7 +2387,7 @@ F: include/linux/netfilter_bridge/ebt_*.h
F: net/bridge/netfilter/ebt*.c

ECRYPT FILE SYSTEM
M: Tyler Hicks <tyhicks@canonical.com>
M: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
M: Dustin Kirkland <kirkland@canonical.com>
L: ecryptfs@vger.kernel.org
W: https://launchpad.net/ecryptfs
Expand Down
15 changes: 8 additions & 7 deletions trunk/arch/arm/Kconfig
Original file line number Diff line number Diff line change
Expand Up @@ -595,7 +595,6 @@ config ARCH_MMP
select TICK_ONESHOT
select PLAT_PXA
select SPARSE_IRQ
select GENERIC_ALLOCATOR
help
Support for Marvell's PXA168/PXA910(MMP) and MMP2 processor line.

Expand Down Expand Up @@ -770,7 +769,6 @@ config ARCH_S3C64XX
select CPU_V6
select ARM_VIC
select HAVE_CLK
select HAVE_TCM
select CLKDEV_LOOKUP
select NO_IOPORT
select ARCH_USES_GETTIMEOFFSET
Expand All @@ -779,6 +777,9 @@ config ARCH_S3C64XX
select SAMSUNG_CLKSRC
select SAMSUNG_IRQ_VIC_TIMER
select S3C_GPIO_TRACK
select S3C_GPIO_PULL_UPDOWN
select S3C_GPIO_CFG_S3C24XX
select S3C_GPIO_CFG_S3C64XX
select S3C_DEV_NAND
select USB_ARCH_HAS_OHCI
select SAMSUNG_GPIOLIB_4BIT
Expand Down Expand Up @@ -837,8 +838,8 @@ config ARCH_S5PV210
help
Samsung S5PV210/S5PC110 series based systems

config ARCH_EXYNOS
bool "SAMSUNG EXYNOS"
config ARCH_EXYNOS4
bool "Samsung EXYNOS4"
select CPU_V7
select ARCH_SPARSEMEM_ENABLE
select ARCH_HAS_HOLES_MEMORYMODEL
Expand All @@ -852,7 +853,7 @@ config ARCH_EXYNOS
select HAVE_S3C2410_WATCHDOG if WATCHDOG
select NEED_MACH_MEMORY_H
help
Support for SAMSUNG's EXYNOS SoCs (EXYNOS4/5)
Samsung EXYNOS4 series based systems

config ARCH_SHARK
bool "Shark"
Expand Down Expand Up @@ -1079,7 +1080,7 @@ source "arch/arm/mach-s5pc100/Kconfig"

source "arch/arm/mach-s5pv210/Kconfig"

source "arch/arm/mach-exynos/Kconfig"
source "arch/arm/mach-exynos4/Kconfig"

source "arch/arm/mach-shmobile/Kconfig"

Expand Down Expand Up @@ -2211,7 +2212,7 @@ menu "Power management options"
source "kernel/power/Kconfig"

config ARCH_SUSPEND_POSSIBLE
depends on !ARCH_S5PC100
depends on !ARCH_S5P64X0 && !ARCH_S5PC100
depends on CPU_ARM920T || CPU_ARM926T || CPU_SA1100 || \
CPU_V6 || CPU_V6K || CPU_V7 || CPU_XSC3 || CPU_XSCALE
def_bool y
Expand Down
2 changes: 1 addition & 1 deletion trunk/arch/arm/Makefile
Original file line number Diff line number Diff line change
Expand Up @@ -180,7 +180,7 @@ machine-$(CONFIG_ARCH_S3C64XX) := s3c64xx
machine-$(CONFIG_ARCH_S5P64X0) := s5p64x0
machine-$(CONFIG_ARCH_S5PC100) := s5pc100
machine-$(CONFIG_ARCH_S5PV210) := s5pv210
machine-$(CONFIG_ARCH_EXYNOS4) := exynos
machine-$(CONFIG_ARCH_EXYNOS4) := exynos4
machine-$(CONFIG_ARCH_SA1100) := sa1100
machine-$(CONFIG_ARCH_SHARK) := shark
machine-$(CONFIG_ARCH_SHMOBILE) := shmobile
Expand Down
9 changes: 7 additions & 2 deletions trunk/arch/arm/configs/exynos4_defconfig
Original file line number Diff line number Diff line change
Expand Up @@ -4,18 +4,19 @@ CONFIG_KALLSYMS_ALL=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_BLK_DEV_BSG is not set
CONFIG_ARCH_EXYNOS=y
CONFIG_ARCH_EXYNOS4=y
CONFIG_S3C_LOWLEVEL_UART_PORT=1
CONFIG_MACH_SMDKC210=y
CONFIG_MACH_SMDKV310=y
CONFIG_MACH_ARMLEX4210=y
CONFIG_MACH_UNIVERSAL_C210=y
CONFIG_MACH_NURI=y
CONFIG_MACH_ORIGEN=y
CONFIG_MACH_SMDK4412=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_SMP=y
CONFIG_NR_CPUS=2
CONFIG_HOTPLUG_CPU=y
CONFIG_PREEMPT=y
CONFIG_AEABI=y
CONFIG_CMDLINE="root=/dev/ram0 rw ramdisk=8192 initrd=0x41000000,8M console=ttySAC1,115200 init=/linuxrc mem=256M"
Expand Down Expand Up @@ -60,9 +61,13 @@ CONFIG_DETECT_HUNG_TASK=y
CONFIG_DEBUG_RT_MUTEXES=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
CONFIG_DEBUG_INFO=y
# CONFIG_RCU_CPU_STALL_DETECTOR is not set
CONFIG_SYSCTL_SYSCALL_CHECK=y
CONFIG_DEBUG_USER=y
CONFIG_DEBUG_ERRORS=y
CONFIG_DEBUG_LL=y
CONFIG_EARLY_PRINTK=y
CONFIG_DEBUG_S3C_UART=1
CONFIG_CRC_CCITT=y
Loading

0 comments on commit 0ffc614

Please sign in to comment.