1. 21 Apr, 2007 2 commits
  2. 06 Feb, 2007 1 commit
    • Russell King's avatar
      [ARM] Move processor_modes[] to .../process.c · ae0a846e
      Russell King authored
      bad_mode() currently prints the mode which caused the exception, and
      then causes an oops dump to be printed which again displays this
      information (since the CPSR in the struct pt_regs is correct.)  This
      leads to processor_modes[] being shared between traps.c and process.c
      with a local declaration of it.
      We can clean this up by moving processor_modes[] to process.c and
      removing the duplication, resulting in processor_modes[] becoming
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
  3. 30 Nov, 2006 1 commit
    • Paul Gortmaker's avatar
      [ARM] 3911/2: Simplify alloc_thread_info on ARM · 12221442
      Paul Gortmaker authored
      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: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
  4. 27 Sep, 2006 1 commit
    • Hyok S. Choi's avatar
      [ARM] nommu: manage the CP15 things · f12d0d7c
      Hyok S. Choi authored
      All the current CP15 access codes in ARM arch can be categorized and
      conditioned by the defines as follows:
           Related operation	Safe condition
        a. any CP15 access	!CPU_CP15
        b. alignment trap	CPU_CP15_MMU
        c. D-cache(C-bit)	CPU_CP15
        d. I-cache		CPU_CP15 && !( CPU_ARM610 || CPU_ARM710 ||
      				CPU_ARM720 || CPU_ARM740 ||
      				CPU_XSCALE || CPU_XSC3 )
        e. alternate vector	CPU_CP15 && !CPU_ARM740
        f. TTB		CPU_CP15_MMU
        g. Domain		CPU_CP15_MMU
        h. FSR/FAR		CPU_CP15_MMU
      For example, alternate vector is supported if and only if
      "CPU_CP15 && !CPU_ARM740" is satisfied.
      Signed-off-by: default avatarHyok S. Choi <hyok.choi@samsung.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
  5. 01 Jul, 2006 1 commit
  6. 30 Jun, 2006 1 commit
  7. 22 Jun, 2006 1 commit
    • Russell King's avatar
      [ARM] Add thread_notify infrastructure · d6551e88
      Russell King authored
      Some machine classes need to allow VFP support to be built into the
      kernel, but still allow the kernel to run even though VFP isn't
      present.  Unfortunately, the kernel hard-codes VFP instructions
      into the thread switch, which prevents this being run-time selectable.
      Solve this by introducing a notifier which things such as VFP can
      hook into to be informed of events which affect the VFP subsystem
      (eg, creation and destruction of threads, switches between threads.)
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
  8. 19 Jun, 2006 1 commit
  9. 16 May, 2006 1 commit
  10. 09 May, 2006 1 commit
  11. 31 Mar, 2006 1 commit
  12. 15 Mar, 2006 1 commit
  13. 12 Jan, 2006 4 commits
  14. 03 Jan, 2006 1 commit
    • Russell King's avatar
      [ARM] Cleanup ARM includes · 78ff18a4
      Russell King authored
      arch/arm/kernel/entry-armv.S has contained a comment suggesting
      that asm/hardware.h and asm/arch/irqs.h should be moved into the
      asm/arch/entry-macro.S include.  So move the includes to these
      two files as required.
      Add missing includes (asm/hardware.h, asm/io.h) to asm/arch/system.h
      includes which use those facilities, and remove asm/io.h from
      Remove other unnecessary includes from arch/arm/kernel, arch/arm/mm
      and arch/arm/mach-footbridge.
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
  15. 09 Nov, 2005 3 commits
    • Nick Piggin's avatar
      [PATCH] sched: resched and cpu_idle rework · 64c7c8f8
      Nick Piggin authored
      Make some changes to the NEED_RESCHED and POLLING_NRFLAG to reduce
      confusion, and make their semantics rigid.  Improves efficiency of
      resched_task and some cpu_idle routines.
      * In resched_task:
      - TIF_NEED_RESCHED is only cleared with the task's runqueue lock held,
        and as we hold it during resched_task, then there is no need for an
        atomic test and set there. The only other time this should be set is
        when the task's quantum expires, in the timer interrupt - this is
        protected against because the rq lock is irq-safe.
      - If TIF_NEED_RESCHED is set, then we don't need to do anything. It
        won't get unset until the task get's schedule()d off.
      - If we are running on the same CPU as the task we resched, then set
        TIF_NEED_RESCHED and no further action is required.
      - If we are running on another CPU, and TIF_POLLING_NRFLAG is *not* set
        after TIF_NEED_RESCHED has been set, then we need to send an IPI.
      Using these rules, we are able to remove the test and set operation in
      resched_task, and make clear the previously vague semantics of
      * In idle routines:
      - Enter cpu_idle with preempt disabled. When the need_resched() condition
        becomes true, explicitly call schedule(). This makes things a bit clearer
        (IMO), but haven't updated all architectures yet.
      - Many do a test and clear of TIF_NEED_RESCHED for some reason. According
        to the resched_task rules, this isn't needed (and actually breaks the
        assumption that TIF_NEED_RESCHED is only cleared with the runqueue lock
        held). So remove that. Generally one less locked memory op when switching
        to the idle thread.
      - Many idle routines clear TIF_POLLING_NRFLAG, and only set it in the inner
        most polling idle loops. The above resched_task semantics allow it to be
        set until before the last time need_resched() is checked before going into
        a halt requiring interrupt wakeup.
        Many idle routines simply never enter such a halt, and so POLLING_NRFLAG
        can be always left set, completely eliminating resched IPIs when rescheduling
        the idle task.
        POLLING_NRFLAG width can be increased, to reduce the chance of resched IPIs.
      Signed-off-by: default avatarNick Piggin <npiggin@suse.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Con Kolivas <kernel@kolivas.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Nick Piggin's avatar
      [PATCH] sched: disable preempt in idle tasks · 5bfb5d69
      Nick Piggin authored
      Run idle threads with preempt disabled.
      Also corrected a bugs in arm26's cpu_idle (make it actually call schedule()).
      How did it ever work before?
      Might fix the CPU hotplugging hang which Nigel Cunningham noted.
      We think the bug hits if the idle thread is preempted after checking
      need_resched() and before going to sleep, then the CPU offlined.
      After calling stop_machine_run, the CPU eventually returns from preemption and
      into the idle thread and goes to sleep.  The CPU will continue executing
      previous idle and have no chance to call play_dead.
      By disabling preemption until we are ready to explicitly schedule, this bug is
      fixed and the idle threads generally become more robust.
      From: alexs <ashepard@u.washington.edu>
        PPC build fix
      From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
        MIPS build fix
      Signed-off-by: default avatarNick Piggin <npiggin@suse.de>
      Signed-off-by: default avatarYoichi Yuasa <yuasa@hh.iij4u.or.jp>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Nicolas Pitre's avatar
      [ARM] 3100/1: simplify a pointer computation · c906107b
      Nicolas Pitre authored
      Patch from Nicolas Pitre
      Looks clearer this way.
      Signed-off-by: default avatarNicolas Pitre <nico@cam.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
  16. 02 Nov, 2005 1 commit
  17. 26 Jul, 2005 1 commit
  18. 27 Jun, 2005 1 commit
  19. 05 May, 2005 1 commit
    • Russell King's avatar
      [PATCH] ARM: Fix kernel stack offset calculations · 4f7a1812
      Russell King authored
      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: default avatarRussell King <rmk@arm.linux.org.uk>
  20. 17 Apr, 2005 1 commit
  21. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      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!