diff --git a/[refs] b/[refs] index c28b727a3d61..49a408b2de05 100644 --- a/[refs] +++ b/[refs] @@ -1,2 +1,2 @@ --- -refs/heads/master: 534baf55dd16d5de9c8d045190469eef9d31ffff +refs/heads/master: d5240dfd3c80ad2fd17b25ca38d199ab1262ab6e diff --git a/trunk/Documentation/power/freezing-of-tasks.txt b/trunk/Documentation/power/freezing-of-tasks.txt index 316c2ba187f4..38b57248fd61 100644 --- a/trunk/Documentation/power/freezing-of-tasks.txt +++ b/trunk/Documentation/power/freezing-of-tasks.txt @@ -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 @@ -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 diff --git a/trunk/Documentation/power/runtime_pm.txt b/trunk/Documentation/power/runtime_pm.txt index 5336149f831b..0e856088db7c 100644 --- a/trunk/Documentation/power/runtime_pm.txt +++ b/trunk/Documentation/power/runtime_pm.txt @@ -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. diff --git a/trunk/Documentation/watchdog/convert_drivers_to_kernel_api.txt b/trunk/Documentation/watchdog/convert_drivers_to_kernel_api.txt deleted file mode 100644 index ae1e90036d06..000000000000 --- a/trunk/Documentation/watchdog/convert_drivers_to_kernel_api.txt +++ /dev/null @@ -1,195 +0,0 @@ -Converting old watchdog drivers to the watchdog framework -by Wolfram Sang -========================================================= - -Before the watchdog framework came into the kernel, every driver had to -implement the API on its own. Now, as the framework factored out the common -components, those drivers can be lightened making it a user of the framework. -This document shall guide you for this task. The necessary steps are described -as well as things to look out for. - - -Remove the file_operations struct ---------------------------------- - -Old drivers define their own file_operations for actions like open(), write(), -etc... These are now handled by the framework and just call the driver when -needed. So, in general, the 'file_operations' struct and assorted functions can -go. Only very few driver-specific details have to be moved to other functions. -Here is a overview of the functions and probably needed actions: - -- open: Everything dealing with resource management (file-open checks, magic - close preparations) can simply go. Device specific stuff needs to go to the - driver specific start-function. Note that for some drivers, the start-function - also serves as the ping-function. If that is the case and you need start/stop - to be balanced (clocks!), you are better off refactoring a separate start-function. - -- close: Same hints as for open apply. - -- write: Can simply go, all defined behaviour is taken care of by the framework, - i.e. ping on write and magic char ('V') handling. - -- ioctl: While the driver is allowed to have extensions to the IOCTL interface, - the most common ones are handled by the framework, supported by some assistance - from the driver: - - WDIOC_GETSUPPORT: - Returns the mandatory watchdog_info struct from the driver - - WDIOC_GETSTATUS: - Needs the status-callback defined, otherwise returns 0 - - WDIOC_GETBOOTSTATUS: - Needs the bootstatus member properly set. Make sure it is 0 if you - don't have further support! - - WDIOC_SETOPTIONS: - No preparations needed - - WDIOC_KEEPALIVE: - If wanted, options in watchdog_info need to have WDIOF_KEEPALIVEPING - set - - WDIOC_SETTIMEOUT: - Options in watchdog_info need to have WDIOF_SETTIMEOUT set - and a set_timeout-callback has to be defined. The core will also - do limit-checking, if min_timeout and max_timeout in the watchdog - device are set. All is optional. - - WDIOC_GETTIMEOUT: - No preparations needed - - Other IOCTLs can be served using the ioctl-callback. Note that this is mainly - intended for porting old drivers; new drivers should not invent private IOCTLs. - Private IOCTLs are processed first. When the callback returns with - -ENOIOCTLCMD, the IOCTLs of the framework will be tried, too. Any other error - is directly given to the user. - -Example conversion: - --static const struct file_operations s3c2410wdt_fops = { -- .owner = THIS_MODULE, -- .llseek = no_llseek, -- .write = s3c2410wdt_write, -- .unlocked_ioctl = s3c2410wdt_ioctl, -- .open = s3c2410wdt_open, -- .release = s3c2410wdt_release, --}; - -Check the functions for device-specific stuff and keep it for later -refactoring. The rest can go. - - -Remove the miscdevice ---------------------- - -Since the file_operations are gone now, you can also remove the 'struct -miscdevice'. The framework will create it on watchdog_dev_register() called by -watchdog_register_device(). - --static struct miscdevice s3c2410wdt_miscdev = { -- .minor = WATCHDOG_MINOR, -- .name = "watchdog", -- .fops = &s3c2410wdt_fops, --}; - - -Remove obsolete includes and defines ------------------------------------- - -Because of the simplifications, a few defines are probably unused now. Remove -them. Includes can be removed, too. For example: - -- #include -- #include (if MODULE_ALIAS_MISCDEV is not used) -- #include (if no custom IOCTLs are used) - - -Add the watchdog operations ---------------------------- - -All possible callbacks are defined in 'struct watchdog_ops'. You can find it -explained in 'watchdog-kernel-api.txt' in this directory. start(), stop() and -owner must be set, the rest are optional. You will easily find corresponding -functions in the old driver. Note that you will now get a pointer to the -watchdog_device as a parameter to these functions, so you probably have to -change the function header. Other changes are most likely not needed, because -here simply happens the direct hardware access. If you have device-specific -code left from the above steps, it should be refactored into these callbacks. - -Here is a simple example: - -+static struct watchdog_ops s3c2410wdt_ops = { -+ .owner = THIS_MODULE, -+ .start = s3c2410wdt_start, -+ .stop = s3c2410wdt_stop, -+ .ping = s3c2410wdt_keepalive, -+ .set_timeout = s3c2410wdt_set_heartbeat, -+}; - -A typical function-header change looks like: - --static void s3c2410wdt_keepalive(void) -+static int s3c2410wdt_keepalive(struct watchdog_device *wdd) - { -... -+ -+ return 0; - } - -... - -- s3c2410wdt_keepalive(); -+ s3c2410wdt_keepalive(&s3c2410_wdd); - - -Add the watchdog device ------------------------ - -Now we need to create a 'struct watchdog_device' and populate it with the -necessary information for the framework. The struct is also explained in detail -in 'watchdog-kernel-api.txt' in this directory. We pass it the mandatory -watchdog_info struct and the newly created watchdog_ops. Often, old drivers -have their own record-keeping for things like bootstatus and timeout using -static variables. Those have to be converted to use the members in -watchdog_device. Note that the timeout values are unsigned int. Some drivers -use signed int, so this has to be converted, too. - -Here is a simple example for a watchdog device: - -+static struct watchdog_device s3c2410_wdd = { -+ .info = &s3c2410_wdt_ident, -+ .ops = &s3c2410wdt_ops, -+}; - - -Register the watchdog device ----------------------------- - -Replace misc_register(&miscdev) with watchdog_register_device(&watchdog_dev). -Make sure the return value gets checked and the error message, if present, -still fits. Also convert the unregister case. - -- ret = misc_register(&s3c2410wdt_miscdev); -+ ret = watchdog_register_device(&s3c2410_wdd); - -... - -- misc_deregister(&s3c2410wdt_miscdev); -+ watchdog_unregister_device(&s3c2410_wdd); - - -Update the Kconfig-entry ------------------------- - -The entry for the driver now needs to select WATCHDOG_CORE: - -+ select WATCHDOG_CORE - - -Create a patch and send it to upstream --------------------------------------- - -Make sure you understood Documentation/SubmittingPatches and send your patch to -linux-watchdog@vger.kernel.org. We are looking forward to it :) - diff --git a/trunk/MAINTAINERS b/trunk/MAINTAINERS index 6388a96dc1c4..a6afe342f0fc 100644 --- a/trunk/MAINTAINERS +++ b/trunk/MAINTAINERS @@ -2387,7 +2387,7 @@ F: include/linux/netfilter_bridge/ebt_*.h F: net/bridge/netfilter/ebt*.c ECRYPT FILE SYSTEM -M: Tyler Hicks +M: Tyler Hicks M: Dustin Kirkland L: ecryptfs@vger.kernel.org W: https://launchpad.net/ecryptfs diff --git a/trunk/arch/arm/Kconfig b/trunk/arch/arm/Kconfig index 44789eff983f..fe6b0526b3a6 100644 --- a/trunk/arch/arm/Kconfig +++ b/trunk/arch/arm/Kconfig @@ -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. @@ -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 @@ -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 @@ -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 @@ -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" @@ -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" @@ -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 diff --git a/trunk/arch/arm/Makefile b/trunk/arch/arm/Makefile index dfcf3b033e10..b7c2d377a6c2 100644 --- a/trunk/arch/arm/Makefile +++ b/trunk/arch/arm/Makefile @@ -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 diff --git a/trunk/arch/arm/configs/exynos4_defconfig b/trunk/arch/arm/configs/exynos4_defconfig index bffe68e190a3..cd40bb56e568 100644 --- a/trunk/arch/arm/configs/exynos4_defconfig +++ b/trunk/arch/arm/configs/exynos4_defconfig @@ -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" @@ -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 diff --git a/trunk/arch/arm/mach-exynos/mach-origen.c b/trunk/arch/arm/mach-exynos/mach-origen.c deleted file mode 100644 index f80b563f2be7..000000000000 --- a/trunk/arch/arm/mach-exynos/mach-origen.c +++ /dev/null @@ -1,700 +0,0 @@ -/* linux/arch/arm/mach-exynos4/mach-origen.c - * - * Copyright (c) 2011 Insignal Co., Ltd. - * http://www.insignal.co.kr/ - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. -*/ - -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include - -#include -#include - -#include