- 06 9月, 2008 1 次提交
-
-
由 Russell King 提交于
pc_pointer() was a function to mask the PC for 26-bit ARMs, which we no longer support. Remove it. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 03 8月, 2008 1 次提交
-
-
由 Russell King 提交于
Move platform independent header files to arch/arm/include/asm, leaving those in asm/arch* and asm/plat* alone. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 26 7月, 2008 1 次提交
-
-
由 FUJITA Tomonori 提交于
We duplicate alloc/free_thread_info defines on many platforms (the majority uses __get_free_pages/free_pages). This patch defines common defines and removes these duplicated defines. __HAVE_ARCH_THREAD_INFO_ALLOCATOR is introduced for platforms that do something different. Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk> Cc: Pekka Enberg <penberg@cs.helsinki.fi> Cc: <linux-arch@vger.kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 19 4月, 2008 1 次提交
-
-
由 Catalin Marinas 提交于
This patch adds the detection and handling of the ThumbEE extension on ARMv7 CPUs. Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
-
- 01 8月, 2007 1 次提交
-
-
由 Stephane Eranian 提交于
Remove unused TIF_NOTIFY_RESUME flag for all processor architectures. The flag was not used excecpt on IA-64 where the patch replaces it with TIF_PERFMON_WORK. Signed-off-by: Nstephane eranian <eranian@hpl.hp.com> Cc: <linux-arch@vger.kernel.org> Cc: "Luck, Tony" <tony.luck@intel.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 20 7月, 2007 1 次提交
-
-
由 Russell King 提交于
asm/thread_info.h doesn't need asm/ptrace.h, remove it. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 06 5月, 2007 1 次提交
-
-
由 Russell King 提交于
utrace removes the ptrace_message field in task_struct. Move our use of this field into a new member in thread_info called "syscall" Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 14 12月, 2006 1 次提交
-
-
由 Rafael J. Wysocki 提交于
Currently, to tell a task that it should go to the refrigerator, we set the PF_FREEZE flag for it and send a fake signal to it. Unfortunately there are two SMP-related problems with this approach. First, a task running on another CPU may be updating its flags while the freezer attempts to set PF_FREEZE for it and this may leave the task's flags in an inconsistent state. Second, there is a potential race between freeze_process() and refrigerator() in which freeze_process() running on one CPU is reading a task's PF_FREEZE flag while refrigerator() running on another CPU has just set PF_FROZEN for the same task and attempts to reset PF_FREEZE for it. If the refrigerator wins the race, freeze_process() will state that PF_FREEZE hasn't been set for the task and will set it unnecessarily, so the task will go to the refrigerator once again after it's been thawed. To solve first of these problems we need to stop using PF_FREEZE to tell tasks that they should go to the refrigerator. Instead, we can introduce a special TIF_*** flag and use it for this purpose, since it is allowed to change the other tasks' TIF_*** flags and there are special calls for it. To avoid the freeze_process()-refrigerator() race we can make freeze_process() to always check the task's PF_FROZEN flag after it's read its "freeze" flag. We should also make sure that refrigerator() will always reset the task's "freeze" flag after it's set PF_FROZEN for it. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Acked-by: NPavel Machek <pavel@ucw.cz> Cc: Russell King <rmk@arm.linux.org.uk> Cc: David Howells <dhowells@redhat.com> Cc: Andi Kleen <ak@muc.de> Cc: "Luck, Tony" <tony.luck@intel.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Paul Mundt <lethal@linux-sh.org> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 30 11月, 2006 1 次提交
-
-
由 Paul Gortmaker 提交于
Remove ARM local cache of 4 struct thread_info. Can cause oops under certain circumstances. Russell indicated the original optimization was required on older kernels to avoid thread starvation on memory fragmentation, but may no longer be required. I've updated the patch to 19rc4 and ensured no <config.h> dain-bramage slipped in this time (sorry about that). Original description follows: I was given some test results which pointed to an Oops in alloc_thread_info (happened 2x), and after looking at the code, I see that ARM has its own local cache of 4 struct thread_info. There wasn't any clear (to me) synchronization between the alloc_thread_info and the free_thread_info. I looked over the other arch, and they all simply allocate them on an as needed basis, so I simplified the ARM to do the same, based on the other arch (e.g. PPC) and the folks doing the testing have indicated that this fixed the oops. Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 02 7月, 2006 1 次提交
-
-
由 Lennert Buytenhek 提交于
Patch from Lennert Buytenhek This patch makes the iWMMXt context switch hook use the generic thread notifier infrastructure that was recently merged in commit d6551e88. Signed-off-by: NLennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 01 7月, 2006 1 次提交
-
-
由 Adrian Bunk 提交于
Signed-off-by: NAdrian Bunk <bunk@stusta.de>
-
- 29 6月, 2006 1 次提交
-
-
由 Lennert Buytenhek 提交于
Patch from Lennert Buytenhek Add the necessary kernel bits for crunch task switching. Signed-off-by: NLennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 13 3月, 2006 1 次提交
-
-
由 Russell King 提交于
This patch removes the reliance of iwmmxt on hand coded alignments. Since thread_info is always 8K aligned, specifying that fpstate is 8-byte aligned achieves the same effect without needing to resort to hand coded alignments. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 13 1月, 2006 2 次提交
-
-
由 Al Viro 提交于
{get,put}_thread_info() were introduced in 2.5.4 and never had been called by anything in the tree. Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Al Viro 提交于
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 17 11月, 2005 1 次提交
-
-
由 Russell King 提交于
atomic.h, bitops.h and mmu_context.h are using likely/unlikely. thread_info.h uses __attribute_const__. Hence these files require linux/compiler.h to be included. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 24 6月, 2005 1 次提交
-
-
由 Jesper Juhl 提交于
The preempt_count member of struct thread_info is currently either defined as int, unsigned int or __s32 depending on arch. This patch makes the type of preempt_count an int on all archs. Having preempt_count be an unsigned type prevents the catching of preempt_count < 0 bugs, and using int on some archs and __s32 on others is not exactely "neat" - much nicer when it's just int all over. A previous version of this patch was already ACK'ed by Robert Love, and the only change in this version of the patch compared to the one he ACK'ed is that this one also makes sure the preempt_count member is consistently commented. Signed-off-by: NJesper Juhl <juhl-lkml@dif.dk> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 05 5月, 2005 1 次提交
-
-
由 Russell King 提交于
Various places in the ARM kernel implicitly assumed that kernel stacks are always 8K due to hard coded constants. Replace these constants with definitions. Correct the allowable range of kernel stack pointer values within the allocation. Arrange for the entire kernel stack to be zeroed, not just the upper 4K if CONFIG_DEBUG_STACK_USAGE is set. Signed-off-by: NRussell King <rmk@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!
-