- 16 11月, 2010 1 次提交
-
-
由 Lionel Debroux 提交于
While at it, fix two checkpatch errors. Several non-const struct instances constified by this patch were added after the introduction of platform_suspend_ops in checkpatch.pl's list of "should be const" structs (79404849). Patch against mainline. Inspired by hunks of the grsecurity patch, updated for newer kernels. Signed-off-by: NLionel Debroux <lionel_debroux@yahoo.fr> Acked-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 30 3月, 2010 1 次提交
-
-
由 Tejun Heo 提交于
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: NTejun Heo <tj@kernel.org> Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
-
- 11 6月, 2009 1 次提交
-
-
由 Pavel Machek 提交于
For suspend/resume to work, spitz needs pxa_pm_suspend/resume to be called. Otherwise PSPR is not set properly, and system will die during resume. Signed-off-by: NPavel Machek <pavel@ucw.cz> Signed-off-by: NEric Miao <eric.y.miao@gmail.com>
-
- 09 3月, 2009 1 次提交
-
-
由 Eric Miao 提交于
This isn't perfect but at least solves the problem of pm.c's dependency on register definitions in <mach/lubbock.h>, which doesn't make much sense. Signed-off-by: NEric Miao <eric.miao@marvell.com>
-
- 09 9月, 2008 1 次提交
-
-
由 Russell King 提交于
Currently, we set PSPR just before entering sleep mode. However, some platforms have different requirements for setting PSPR in order to properly wake up. Set PSPR earlier in the suspend cycle so that platforms can change the setting by using a sysdev driver instead. Acked-by: NEric Miao <eric.miao@marvell.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 07 8月, 2008 2 次提交
-
-
由 Russell King 提交于
This just leaves include/asm-arm/plat-* to deal with. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
Remove includes of asm/hardware.h in addition to asm/arch/hardware.h. Then, since asm/hardware.h only exists to include asm/arch/hardware.h, update everything to directly include asm/arch/hardware.h and remove asm/hardware.h. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 09 5月, 2008 1 次提交
-
-
由 Russell King 提交于
Related to d3930614. RCSR is only present on PXA2xx CPUs, not on PXA3xx CPUs. Therefore, we should not be unconditionally writing to RCSR from generic code. Since we now clear the RCSR status from the SoC specific PXA PM code and before reset in the arch_reset() function, the duplication in the corgi, poodle, spitz and tosa code can be removed. Acked-by: NRichard Purdie <rpurdie@rpsys.net> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 04 5月, 2008 1 次提交
-
-
由 Robert Jarzmik 提交于
Each time a pxa type cpu went in suspend, a portion of kmalloc memory was corrupted. The issue was an incorrect length allocation introduced by the commit 711be5cc for the save registers array (=> overflow). Signed-off-by: NRobert Jarzmik <rjarzmik@free.fr> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 24 4月, 2008 1 次提交
-
-
由 Dmitry Baryshkov 提交于
The kernel should clean stale bits from reset status, so that they won't confuse the bootloader. Signed-off-by: NDmitry Baryshkov <dbaryshkov@gmail.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 26 1月, 2008 1 次提交
-
-
由 eric miao 提交于
registers are retained during standby mode, thus it's not necessary to save/restore and checksum Signed-off-by: Neric miao <eric.miao@marvell.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 19 10月, 2007 1 次提交
-
-
由 Rafael J. Wysocki 提交于
The name of 'struct pm_ops' suggests that it is related to the power management in general, but in fact it is only related to suspend. Moreover, its name should indicate what this structure is used for, so it seems reasonable to change it to 'struct platform_suspend_ops'. In that case, the name of the global variable of this type used by the PM core and the names of related functions should be changed accordingly. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Acked-by: NPavel Machek <pavel@ucw.cz> Cc: Len Brown <lenb@kernel.org> Cc: Greg KH <greg@kroah.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 21 7月, 2007 1 次提交
-
-
由 Eric Miao 提交于
1. introduce a structure pxa_cpu_pm_fns for pxa25x/pxa27x specific operations as follows: struct pxa_cpu_pm_fns { int save_size; void (*save)(unsigned long *); void (*restore)(unsigned long *); int (*valid)(suspend_state_t state); void (*enter)(suspend_state_t state); } 2. processor specific registers saving and restoring are performed by calling the corresponding (*save) and (*restore) 3. pxa_cpu_pm_fns->save_size should be initialized to the required size for processor specific registers saving, the allocated memory address will be passed to (*save) and (*restore) memory allocation happens early in pxa_pm_init(), and save_size should be assigned prior to this (which is usually true, since pxa_pm_init() happens in device_initcall() 4. there're some redundancies for those SLEEP_SAVE_XXX and related macros, will be fixed later, one way possible is for the system devices to handle the specific registers saving and restoring Signed-off-by: Neric miao <eric.y.miao@gmail.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 12 7月, 2007 3 次提交
-
-
由 Russell King 提交于
Remove the RTC management over a suspend/resume cycle. Firstly, we may not be using the internal RTC for time keeping; some platforms have an external RTC for this inspite of the PXA having an internal RTC. Secondly, the RTC library code handles updating system time on resume. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
Move the pm_ops structure into the PXA25x and PXA27x support files. Remove the old pxa_pm_prepare() function, and rename the both pxa_cpu_pm_prepare() functions as pxa_pm_prepare(). We'll fix that later. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
pxa_pm_finish() does nothing but return zero. The core code does nothing with this return value, and will not try to call the finish method in the pm_ops structure if it is NULL. Therefore, we can remove this useless function. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 01 5月, 2007 2 次提交
-
-
由 Johannes Berg 提交于
Almost all users of pm_ops only support mem sleep, don't check in .valid and don't reject any others in .prepare so users can be confused if they check /sys/power/state, especially when new states are added (these would then result in s-t-r although they're supposed to be something different). This patch implements a generic pm_valid_only_mem function that is then exported for users and puts it to use in almost all existing pm_ops. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Cc: David Brownell <david-b@pacbell.net> Acked-by: NPavel Machek <pavel@ucw.cz> Cc: linux-pm@lists.linux-foundation.org Cc: Len Brown <lenb@kernel.org> Acked-by: NRussell King <rmk@arm.linux.org.uk> Cc: Greg KH <greg@kroah.com> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Paul Mundt <lethal@linux-sh.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Johannes Berg 提交于
This patch series cleans up some misconceptions about pm_ops. Some users of the pm_ops structure attempt to use it to stop the user from entering suspend to disk, this, however, is not possible since the user can always use "shutdown" in /sys/power/disk and then the pm_ops are never invoked. Also, platforms that don't support suspend to disk simply should not allow configuring SOFTWARE_SUSPEND (read the help text on it, it only selects suspend to disk and nothing else, all the other stuff depends on PM). The pm_ops structure is actually intended to provide a way to enter platform-defined sleep states (currently supported states are "standby" and "mem" (suspend to ram)) and additionally (if SOFTWARE_SUSPEND is configured) allows a platform to support a platform specific way to enter low-power mode once everything has been saved to disk. This is currently only used by ACPI (S4). This patch: The pm_ops.pm_disk_mode is used in totally bogus ways since nobody really seems to understand what it actually does. This patch clarifies the pm_disk_mode description. It also removes all the arm and sh users that think they can veto suspend to disk via pm_ops; not so since the user can always do echo shutdown > /sys/power/disk, they need to find a better way involving Kconfig or such. ACPI is the only user left with a non-zero pm_disk_mode. The patch also sets the default mode to shutdown again, but when a new pm_ops is registered its pm_disk_mode is selected as default, that way the default stays for ACPI where it is apparently required. Signed-off-by: NJohannes Berg <johannes@sipsolutions.net> Cc: David Brownell <david-b@pacbell.net> Acked-by: NPavel Machek <pavel@ucw.cz> Cc: <linux-pm@lists.linux-foundation.org> Cc: Len Brown <lenb@kernel.org> Acked-by: NRussell King <rmk@arm.linux.org.uk> Cc: Greg KH <greg@kroah.com> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Acked-by: NPaul Mundt <lethal@linux-sh.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 04 12月, 2006 1 次提交
-
-
由 Lennert Buytenhek 提交于
XScale cores either have a DSP coprocessor (which contains a single 40 bit accumulator register), or an iWMMXt coprocessor (which contains eight 64 bit registers.) Because of the small amount of state in the DSP coprocessor, access to the DSP coprocessor (CP0) is always enabled, and DSP context switching is done unconditionally on every task switch. Access to the iWMMXt coprocessor (CP0/CP1) is enabled only when an iWMMXt instruction is first issued, and iWMMXt context switching is done lazily. CONFIG_IWMMXT is supposed to mean 'the cpu we will be running on will have iWMMXt support', but boards are supposed to select this config symbol by hand, and at least one pxa27x board doesn't get this right, so on that board, proc-xscale.S will incorrectly assume that we have a DSP coprocessor, enable CP0 on boot, and we will then only save the first iWMMXt register (wR0) on context switches, which is Bad. This patch redefines CONFIG_IWMMXT as 'the cpu we will be running on might have iWMMXt support, and we will enable iWMMXt context switching if it does.' This means that with this patch, running a CONFIG_IWMMXT=n kernel on an iWMMXt-capable CPU will no longer potentially corrupt iWMMXt state over context switches, and running a CONFIG_IWMMXT=y kernel on a non-iWMMXt capable CPU will still do DSP context save/restore. These changes should make iWMMXt work on PXA3xx, and as a side effect, enable proper acc0 save/restore on non-iWMMXt capable xsc3 cores such as IOP13xx and IXP23xx (which will not have CONFIG_CPU_XSCALE defined), as well as setting and using HWCAP_IWMMXT properly. Signed-off-by: NLennert Buytenhek <buytenh@wantstofly.org> Acked-by: NDan Williams <dan.j.williams@intel.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 01 7月, 2006 1 次提交
-
-
由 Jörn Engel 提交于
Signed-off-by: NJörn Engel <joern@wohnheim.fh-wedel.de> Signed-off-by: NAdrian Bunk <bunk@stusta.de>
-
- 13 12月, 2005 1 次提交
-
-
由 Lothar Wassmann 提交于
[ARM] 3201/1: PXA27x: Prevent hangup during resume due to inadvertedly enabling MBREQ (replaces: 3198/1) Patch from Lothar Wassmann The patch makes sure, that the ouptut functions of pins are restored before restoring the Alternat Function settings, preventing pins from being intermediately configured for undefined or unwanted alternate functions. Here is the original comment: I've got a PXA270 system that uses GPIO80 as nCS4. This system did hang on resume. Digging into the problem I found that the processor stalled immediately when restoring the GAFR2_U register which restored the alternate function for GPIO80. Since the GPDR registers were restored after the GAFR registers, the offending GPIO was configured as input at this point. Thus the alternate function that was in effect after restoring the GAFR was in fact the input function "MBREQ" instead of the output function "nCS4". The "PXA27x Processor Family Developer's Manual" (Footnote in Table 6-1 on page 6-3) states that: "The MBREQ alternate function must not be enabled until the PSSR[RDH] bit field is cleared. For more details, see Table 3-15, "PSSR Bit Definitions" on page 3-71." There is another note in the Developer's Manual (chapter 24.4.2 "GPIO operation as Alternate Function" on page 24-4) stating that: "Configuring a GPIO for an alternate function that is not defined for it causes unpredictable results." Since some GPIOs have no input function defined, and to prevent inadvertedly programming the MBREQ function on some pin, the GAFR registers should be restored after the GPDR registers have been restored. Additional provisions have to be made when the MBREQ function is actually required. The corresponding GAFR bits should not be restored with the regular GAFR restore, but must be set only after the PSSR bits have been cleared. Signed-off-by: NLothar Wassmann <LW@KARO-electronics.de> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 06 11月, 2005 1 次提交
-
-
由 Richard Purdie 提交于
Patch from Richard Purdie Update the PXA pm.c file to allow machines (such as the Sharp Zaurus) to override the standard pm functions but reuse/wrap them where needed. The init call is made slightly earlier to give machine code an init level to override them in removing any race. Signed-off-by: Richard Purdie Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 20 6月, 2005 1 次提交
-
-
由 Russell King 提交于
We need to re-initialise the stack pointers for undefined, IRQ and abort mode handlers whenever we resume. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 04 6月, 2005 1 次提交
-
-
由 Todd Poynor 提交于
Patch from Todd Poynor PXA27x sleep fixes: * set additional sleep/wakeup registers for Mainstone boards. * move CKEN=0 to pxa25x-specific code; that value is harmful on pxa27x. * save/restore additional registers, including some found necessary for C5 processors and/or newer blob versions. * enable future support of additional sleep modes for PXA27x (eg, standby, deep sleep). * split off cpu-specific sleep processing between pxa27x and pxa25x into separate files (partly in preparation for additional sleep modes). Includes fixes from David Burrage. Signed-off-by: Todd Poynor Signed-off-by: Nicolas Pitre Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-