OrgZephyr/zephyr
OrgZephyr
/
zephyr
mirror of https://github.com/zephyrproject-rtos/zephyr.git
1
0
Fork 0
Code Issues Releases Wiki Activity
zephyr/kernel/smp.c

118 lines
2.3 KiB
C
Raw Normal View History

kernel: Make irq_{un}lock() APIs into a global spinlock in SMP mode In SMP mode, the idea of a single "IRQ lock" goes away. Long term, all usage needs to migrate to spinlocks (which become simple IRQ locks in the uniprocessor case). For the near term, we can ease the migration (at the expense of performance) by providing a compatibility implementation around a single global lock. Note that one complication is that the older lock was recursive, while spinlocks will deadlock if you try to lock them twice. So we implement a simple "count" semantic to handle multiple locks. Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2018-01-30 01:23:49 +08:00
/*
* Copyright (c) 2018 Intel corporation
*
* SPDX-License-Identifier: Apache-2.0
*/
#include <kernel.h>
#include <kernel_structs.h>
#include <spinlock.h>
kernel: Enable SMP Now that all the pieces are in place, enable SMP for real: Initialize the CPU records, launch the CPUs at the end of kernel initialization, have them wait for a flag to release them into the scheduler, then enter into the runnable threads via _Swap(). Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2018-01-18 03:34:50 +08:00
#include <kswap.h>
kernel/include: Missed nano_internal.h -> kernel_internal.h spots Update heading naming given recent rename Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2018-02-09 01:10:46 +08:00
#include <kernel_internal.h>
kernel: Make irq_{un}lock() APIs into a global spinlock in SMP mode In SMP mode, the idea of a single "IRQ lock" goes away. Long term, all usage needs to migrate to spinlocks (which become simple IRQ locks in the uniprocessor case). For the near term, we can ease the migration (at the expense of performance) by providing a compatibility implementation around a single global lock. Note that one complication is that the older lock was recursive, while spinlocks will deadlock if you try to lock them twice. So we implement a simple "count" semantic to handle multiple locks. Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2018-01-30 01:23:49 +08:00
kernel: Rework SMP irq_lock() compatibility layer This was wrong in two ways, one subtle and one awful. The subtle problem was that the IRQ lock isn't actually globally recursive, it gets reset when you context switch (i.e. a _Swap() implicitly releases and reacquires it). So the recursive count I was keeping needs to be per-thread or else we risk deadlock any time we swap away from a thread holding the lock. And because part of my brain apparently knew this, there was an "optimization" in the code that tested the current count vs. zero outside the lock, on the argument that if it was non-zero we must already hold the lock. Which would be true of a per-thread counter, but NOT a global one: the other CPU may be holding that lock, and this test will tell you *you* do. The upshot is that a recursive irq_lock() would almost always SUCCEED INCORRECTLY when there was lock contention. That this didn't break more things is amazing to me. The rework is actually simpler than the original, thankfully. Though there are some further subtleties: * The lock state implied by irq_lock() allows the lock to be implicitly released on context switch (i.e. you can _Swap() with the lock held at a recursion level higher than 1, which needs to allow other processes to run). So return paths into threads from _Swap() and interrupt/exception exit need to check and restore the global lock state, spinning as needed. * The idle loop design specifies a k_cpu_idle() function that is on common architectures expected to enable interrupts (for obvious reasons), but there is no place to put non-arch code to wire it into the global lock accounting. So on SMP, even CPU0 needs to use the "dumb" spinning idle loop. Finally this patch contains a simple bugfix too, found by inspection: the interrupt return code used when CONFIG_SWITCH is enabled wasn't correctly setting the active flag on the threads, opening up the potential for a race that might result in a thread being scheduled on two CPUs simultaneously. Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2018-04-13 03:50:05 +08:00
#ifdef CONFIG_SMP
static atomic_t global_lock;
kernel: Make irq_{un}lock() APIs into a global spinlock in SMP mode In SMP mode, the idea of a single "IRQ lock" goes away. Long term, all usage needs to migrate to spinlocks (which become simple IRQ locks in the uniprocessor case). For the near term, we can ease the migration (at the expense of performance) by providing a compatibility implementation around a single global lock. Note that one complication is that the older lock was recursive, while spinlocks will deadlock if you try to lock them twice. So we implement a simple "count" semantic to handle multiple locks. Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2018-01-30 01:23:49 +08:00
unsigned int _smp_global_lock(void)
{
irq: Fix irq_lock api usage irq_lock returns an unsigned int, though, several places was using signed int. This commit fix this behaviour. In order to avoid this error happens again, a coccinelle script was added and can be used to check violations. Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
2018-08-15 08:57:08 +08:00
unsigned int key = _arch_irq_lock();
kernel: Make irq_{un}lock() APIs into a global spinlock in SMP mode In SMP mode, the idea of a single "IRQ lock" goes away. Long term, all usage needs to migrate to spinlocks (which become simple IRQ locks in the uniprocessor case). For the near term, we can ease the migration (at the expense of performance) by providing a compatibility implementation around a single global lock. Note that one complication is that the older lock was recursive, while spinlocks will deadlock if you try to lock them twice. So we implement a simple "count" semantic to handle multiple locks. Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2018-01-30 01:23:49 +08:00
kernel: Rework SMP irq_lock() compatibility layer This was wrong in two ways, one subtle and one awful. The subtle problem was that the IRQ lock isn't actually globally recursive, it gets reset when you context switch (i.e. a _Swap() implicitly releases and reacquires it). So the recursive count I was keeping needs to be per-thread or else we risk deadlock any time we swap away from a thread holding the lock. And because part of my brain apparently knew this, there was an "optimization" in the code that tested the current count vs. zero outside the lock, on the argument that if it was non-zero we must already hold the lock. Which would be true of a per-thread counter, but NOT a global one: the other CPU may be holding that lock, and this test will tell you *you* do. The upshot is that a recursive irq_lock() would almost always SUCCEED INCORRECTLY when there was lock contention. That this didn't break more things is amazing to me. The rework is actually simpler than the original, thankfully. Though there are some further subtleties: * The lock state implied by irq_lock() allows the lock to be implicitly released on context switch (i.e. you can _Swap() with the lock held at a recursion level higher than 1, which needs to allow other processes to run). So return paths into threads from _Swap() and interrupt/exception exit need to check and restore the global lock state, spinning as needed. * The idle loop design specifies a k_cpu_idle() function that is on common architectures expected to enable interrupts (for obvious reasons), but there is no place to put non-arch code to wire it into the global lock accounting. So on SMP, even CPU0 needs to use the "dumb" spinning idle loop. Finally this patch contains a simple bugfix too, found by inspection: the interrupt return code used when CONFIG_SWITCH is enabled wasn't correctly setting the active flag on the threads, opening up the potential for a race that might result in a thread being scheduled on two CPUs simultaneously. Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2018-04-13 03:50:05 +08:00
if (!_current->base.global_lock_count) {
while (!atomic_cas(&global_lock, 0, 1)) {
}
kernel: Make irq_{un}lock() APIs into a global spinlock in SMP mode In SMP mode, the idea of a single "IRQ lock" goes away. Long term, all usage needs to migrate to spinlocks (which become simple IRQ locks in the uniprocessor case). For the near term, we can ease the migration (at the expense of performance) by providing a compatibility implementation around a single global lock. Note that one complication is that the older lock was recursive, while spinlocks will deadlock if you try to lock them twice. So we implement a simple "count" semantic to handle multiple locks. Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2018-01-30 01:23:49 +08:00
}
kernel: Rework SMP irq_lock() compatibility layer This was wrong in two ways, one subtle and one awful. The subtle problem was that the IRQ lock isn't actually globally recursive, it gets reset when you context switch (i.e. a _Swap() implicitly releases and reacquires it). So the recursive count I was keeping needs to be per-thread or else we risk deadlock any time we swap away from a thread holding the lock. And because part of my brain apparently knew this, there was an "optimization" in the code that tested the current count vs. zero outside the lock, on the argument that if it was non-zero we must already hold the lock. Which would be true of a per-thread counter, but NOT a global one: the other CPU may be holding that lock, and this test will tell you *you* do. The upshot is that a recursive irq_lock() would almost always SUCCEED INCORRECTLY when there was lock contention. That this didn't break more things is amazing to me. The rework is actually simpler than the original, thankfully. Though there are some further subtleties: * The lock state implied by irq_lock() allows the lock to be implicitly released on context switch (i.e. you can _Swap() with the lock held at a recursion level higher than 1, which needs to allow other processes to run). So return paths into threads from _Swap() and interrupt/exception exit need to check and restore the global lock state, spinning as needed. * The idle loop design specifies a k_cpu_idle() function that is on common architectures expected to enable interrupts (for obvious reasons), but there is no place to put non-arch code to wire it into the global lock accounting. So on SMP, even CPU0 needs to use the "dumb" spinning idle loop. Finally this patch contains a simple bugfix too, found by inspection: the interrupt return code used when CONFIG_SWITCH is enabled wasn't correctly setting the active flag on the threads, opening up the potential for a race that might result in a thread being scheduled on two CPUs simultaneously. Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2018-04-13 03:50:05 +08:00
_current->base.global_lock_count++;
kernel: Make irq_{un}lock() APIs into a global spinlock in SMP mode In SMP mode, the idea of a single "IRQ lock" goes away. Long term, all usage needs to migrate to spinlocks (which become simple IRQ locks in the uniprocessor case). For the near term, we can ease the migration (at the expense of performance) by providing a compatibility implementation around a single global lock. Note that one complication is that the older lock was recursive, while spinlocks will deadlock if you try to lock them twice. So we implement a simple "count" semantic to handle multiple locks. Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2018-01-30 01:23:49 +08:00
kernel: Rework SMP irq_lock() compatibility layer This was wrong in two ways, one subtle and one awful. The subtle problem was that the IRQ lock isn't actually globally recursive, it gets reset when you context switch (i.e. a _Swap() implicitly releases and reacquires it). So the recursive count I was keeping needs to be per-thread or else we risk deadlock any time we swap away from a thread holding the lock. And because part of my brain apparently knew this, there was an "optimization" in the code that tested the current count vs. zero outside the lock, on the argument that if it was non-zero we must already hold the lock. Which would be true of a per-thread counter, but NOT a global one: the other CPU may be holding that lock, and this test will tell you *you* do. The upshot is that a recursive irq_lock() would almost always SUCCEED INCORRECTLY when there was lock contention. That this didn't break more things is amazing to me. The rework is actually simpler than the original, thankfully. Though there are some further subtleties: * The lock state implied by irq_lock() allows the lock to be implicitly released on context switch (i.e. you can _Swap() with the lock held at a recursion level higher than 1, which needs to allow other processes to run). So return paths into threads from _Swap() and interrupt/exception exit need to check and restore the global lock state, spinning as needed. * The idle loop design specifies a k_cpu_idle() function that is on common architectures expected to enable interrupts (for obvious reasons), but there is no place to put non-arch code to wire it into the global lock accounting. So on SMP, even CPU0 needs to use the "dumb" spinning idle loop. Finally this patch contains a simple bugfix too, found by inspection: the interrupt return code used when CONFIG_SWITCH is enabled wasn't correctly setting the active flag on the threads, opening up the potential for a race that might result in a thread being scheduled on two CPUs simultaneously. Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2018-04-13 03:50:05 +08:00
return key;
kernel: Make irq_{un}lock() APIs into a global spinlock in SMP mode In SMP mode, the idea of a single "IRQ lock" goes away. Long term, all usage needs to migrate to spinlocks (which become simple IRQ locks in the uniprocessor case). For the near term, we can ease the migration (at the expense of performance) by providing a compatibility implementation around a single global lock. Note that one complication is that the older lock was recursive, while spinlocks will deadlock if you try to lock them twice. So we implement a simple "count" semantic to handle multiple locks. Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2018-01-30 01:23:49 +08:00
}
void _smp_global_unlock(unsigned int key)
{
kernel: Rework SMP irq_lock() compatibility layer This was wrong in two ways, one subtle and one awful. The subtle problem was that the IRQ lock isn't actually globally recursive, it gets reset when you context switch (i.e. a _Swap() implicitly releases and reacquires it). So the recursive count I was keeping needs to be per-thread or else we risk deadlock any time we swap away from a thread holding the lock. And because part of my brain apparently knew this, there was an "optimization" in the code that tested the current count vs. zero outside the lock, on the argument that if it was non-zero we must already hold the lock. Which would be true of a per-thread counter, but NOT a global one: the other CPU may be holding that lock, and this test will tell you *you* do. The upshot is that a recursive irq_lock() would almost always SUCCEED INCORRECTLY when there was lock contention. That this didn't break more things is amazing to me. The rework is actually simpler than the original, thankfully. Though there are some further subtleties: * The lock state implied by irq_lock() allows the lock to be implicitly released on context switch (i.e. you can _Swap() with the lock held at a recursion level higher than 1, which needs to allow other processes to run). So return paths into threads from _Swap() and interrupt/exception exit need to check and restore the global lock state, spinning as needed. * The idle loop design specifies a k_cpu_idle() function that is on common architectures expected to enable interrupts (for obvious reasons), but there is no place to put non-arch code to wire it into the global lock accounting. So on SMP, even CPU0 needs to use the "dumb" spinning idle loop. Finally this patch contains a simple bugfix too, found by inspection: the interrupt return code used when CONFIG_SWITCH is enabled wasn't correctly setting the active flag on the threads, opening up the potential for a race that might result in a thread being scheduled on two CPUs simultaneously. Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2018-04-13 03:50:05 +08:00
if (_current->base.global_lock_count) {
_current->base.global_lock_count--;
if (!_current->base.global_lock_count) {
atomic_clear(&global_lock);
}
kernel: Make irq_{un}lock() APIs into a global spinlock in SMP mode In SMP mode, the idea of a single "IRQ lock" goes away. Long term, all usage needs to migrate to spinlocks (which become simple IRQ locks in the uniprocessor case). For the near term, we can ease the migration (at the expense of performance) by providing a compatibility implementation around a single global lock. Note that one complication is that the older lock was recursive, while spinlocks will deadlock if you try to lock them twice. So we implement a simple "count" semantic to handle multiple locks. Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2018-01-30 01:23:49 +08:00
}
kernel: Rework SMP irq_lock() compatibility layer This was wrong in two ways, one subtle and one awful. The subtle problem was that the IRQ lock isn't actually globally recursive, it gets reset when you context switch (i.e. a _Swap() implicitly releases and reacquires it). So the recursive count I was keeping needs to be per-thread or else we risk deadlock any time we swap away from a thread holding the lock. And because part of my brain apparently knew this, there was an "optimization" in the code that tested the current count vs. zero outside the lock, on the argument that if it was non-zero we must already hold the lock. Which would be true of a per-thread counter, but NOT a global one: the other CPU may be holding that lock, and this test will tell you *you* do. The upshot is that a recursive irq_lock() would almost always SUCCEED INCORRECTLY when there was lock contention. That this didn't break more things is amazing to me. The rework is actually simpler than the original, thankfully. Though there are some further subtleties: * The lock state implied by irq_lock() allows the lock to be implicitly released on context switch (i.e. you can _Swap() with the lock held at a recursion level higher than 1, which needs to allow other processes to run). So return paths into threads from _Swap() and interrupt/exception exit need to check and restore the global lock state, spinning as needed. * The idle loop design specifies a k_cpu_idle() function that is on common architectures expected to enable interrupts (for obvious reasons), but there is no place to put non-arch code to wire it into the global lock accounting. So on SMP, even CPU0 needs to use the "dumb" spinning idle loop. Finally this patch contains a simple bugfix too, found by inspection: the interrupt return code used when CONFIG_SWITCH is enabled wasn't correctly setting the active flag on the threads, opening up the potential for a race that might result in a thread being scheduled on two CPUs simultaneously. Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2018-04-13 03:50:05 +08:00
_arch_irq_unlock(key);
}
kernel: Make irq_{un}lock() APIs into a global spinlock in SMP mode In SMP mode, the idea of a single "IRQ lock" goes away. Long term, all usage needs to migrate to spinlocks (which become simple IRQ locks in the uniprocessor case). For the near term, we can ease the migration (at the expense of performance) by providing a compatibility implementation around a single global lock. Note that one complication is that the older lock was recursive, while spinlocks will deadlock if you try to lock them twice. So we implement a simple "count" semantic to handle multiple locks. Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2018-01-30 01:23:49 +08:00
kernel: Rework SMP irq_lock() compatibility layer This was wrong in two ways, one subtle and one awful. The subtle problem was that the IRQ lock isn't actually globally recursive, it gets reset when you context switch (i.e. a _Swap() implicitly releases and reacquires it). So the recursive count I was keeping needs to be per-thread or else we risk deadlock any time we swap away from a thread holding the lock. And because part of my brain apparently knew this, there was an "optimization" in the code that tested the current count vs. zero outside the lock, on the argument that if it was non-zero we must already hold the lock. Which would be true of a per-thread counter, but NOT a global one: the other CPU may be holding that lock, and this test will tell you *you* do. The upshot is that a recursive irq_lock() would almost always SUCCEED INCORRECTLY when there was lock contention. That this didn't break more things is amazing to me. The rework is actually simpler than the original, thankfully. Though there are some further subtleties: * The lock state implied by irq_lock() allows the lock to be implicitly released on context switch (i.e. you can _Swap() with the lock held at a recursion level higher than 1, which needs to allow other processes to run). So return paths into threads from _Swap() and interrupt/exception exit need to check and restore the global lock state, spinning as needed. * The idle loop design specifies a k_cpu_idle() function that is on common architectures expected to enable interrupts (for obvious reasons), but there is no place to put non-arch code to wire it into the global lock accounting. So on SMP, even CPU0 needs to use the "dumb" spinning idle loop. Finally this patch contains a simple bugfix too, found by inspection: the interrupt return code used when CONFIG_SWITCH is enabled wasn't correctly setting the active flag on the threads, opening up the potential for a race that might result in a thread being scheduled on two CPUs simultaneously. Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2018-04-13 03:50:05 +08:00
void _smp_reacquire_global_lock(struct k_thread *thread)
{
if (thread->base.global_lock_count) {
_arch_irq_lock();
while (!atomic_cas(&global_lock, 0, 1)) {
}
}
kernel: Make irq_{un}lock() APIs into a global spinlock in SMP mode In SMP mode, the idea of a single "IRQ lock" goes away. Long term, all usage needs to migrate to spinlocks (which become simple IRQ locks in the uniprocessor case). For the near term, we can ease the migration (at the expense of performance) by providing a compatibility implementation around a single global lock. Note that one complication is that the older lock was recursive, while spinlocks will deadlock if you try to lock them twice. So we implement a simple "count" semantic to handle multiple locks. Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2018-01-30 01:23:49 +08:00
}
kernel: Enable SMP Now that all the pieces are in place, enable SMP for real: Initialize the CPU records, launch the CPUs at the end of kernel initialization, have them wait for a flag to release them into the scheduler, then enter into the runnable threads via _Swap(). Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2018-01-18 03:34:50 +08:00
kernel: Rework SMP irq_lock() compatibility layer This was wrong in two ways, one subtle and one awful. The subtle problem was that the IRQ lock isn't actually globally recursive, it gets reset when you context switch (i.e. a _Swap() implicitly releases and reacquires it). So the recursive count I was keeping needs to be per-thread or else we risk deadlock any time we swap away from a thread holding the lock. And because part of my brain apparently knew this, there was an "optimization" in the code that tested the current count vs. zero outside the lock, on the argument that if it was non-zero we must already hold the lock. Which would be true of a per-thread counter, but NOT a global one: the other CPU may be holding that lock, and this test will tell you *you* do. The upshot is that a recursive irq_lock() would almost always SUCCEED INCORRECTLY when there was lock contention. That this didn't break more things is amazing to me. The rework is actually simpler than the original, thankfully. Though there are some further subtleties: * The lock state implied by irq_lock() allows the lock to be implicitly released on context switch (i.e. you can _Swap() with the lock held at a recursion level higher than 1, which needs to allow other processes to run). So return paths into threads from _Swap() and interrupt/exception exit need to check and restore the global lock state, spinning as needed. * The idle loop design specifies a k_cpu_idle() function that is on common architectures expected to enable interrupts (for obvious reasons), but there is no place to put non-arch code to wire it into the global lock accounting. So on SMP, even CPU0 needs to use the "dumb" spinning idle loop. Finally this patch contains a simple bugfix too, found by inspection: the interrupt return code used when CONFIG_SWITCH is enabled wasn't correctly setting the active flag on the threads, opening up the potential for a race that might result in a thread being scheduled on two CPUs simultaneously. Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2018-04-13 03:50:05 +08:00
/* Called from within _Swap(), so assumes lock already held */
void _smp_release_global_lock(struct k_thread *thread)
{
if (!thread->base.global_lock_count) {
atomic_clear(&global_lock);
}
}
#endif
kernel: Enable SMP Now that all the pieces are in place, enable SMP for real: Initialize the CPU records, launch the CPUs at the end of kernel initialization, have them wait for a flag to release them into the scheduler, then enter into the runnable threads via _Swap(). Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2018-01-18 03:34:50 +08:00
extern k_thread_stack_t _interrupt_stack1[];
extern k_thread_stack_t _interrupt_stack2[];
extern k_thread_stack_t _interrupt_stack3[];
#ifdef CONFIG_SMP
kernel: Name of static functions should not begin with an underscore Names that begin with an underscore are reserved by the C standard. This patch does not change names of functions defined and implemented in header files. Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
2018-03-07 07:08:55 +08:00
static void smp_init_top(int key, void *arg)
kernel: Enable SMP Now that all the pieces are in place, enable SMP for real: Initialize the CPU records, launch the CPUs at the end of kernel initialization, have them wait for a flag to release them into the scheduler, then enter into the runnable threads via _Swap(). Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2018-01-18 03:34:50 +08:00
{
atomic_t *start_flag = arg;
/* Wait for the signal to begin scheduling */
do {
k_busy_wait(100);
} while (!atomic_get(start_flag));
/* Switch out of a dummy thread. Trick cribbed from the main
* thread init. Should probably unify implementations.
*/
struct k_thread dummy_thread = {
.base.user_options = K_ESSENTIAL,
.base.thread_state = _THREAD_DUMMY,
};
_arch_curr_cpu()->current = &dummy_thread;
irq: Fix irq_lock api usage irq_lock returns an unsigned int, though, several places was using signed int. This commit fix this behaviour. In order to avoid this error happens again, a coccinelle script was added and can be used to check violations. Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
2018-08-15 08:57:08 +08:00
unsigned int k = irq_lock();
kernel: SMP timer integration In SMP, the system timer is used for timeslicing on auxiliary CPUs, but the base system timekeeping via _nano_sys_clock_tick_announce() is still done on CPU0 only (because the framework isn't prepared for asynchronous notification yet). Skip processing on CPU1+. Also, due to a hardware interaction* that is difficult to work around, timer initialization on the auxiliary CPUs is done at the very end of the CPU bringup, just before the swap into the scheduler. A smp_timer_init() API has been added for this purpose. * On ESP-32, enabling the timer seems to result in a near-synchronous interrupt being delivered despite my best attempts to keep it masked, then blowing things up because the CPU record isn't set up to handle it yet. Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2018-01-27 04:30:21 +08:00
smp_timer_init();
kernel: Explicitly ignoring _Swap return Ignoring _Swap return where there is no treatment or nothing to do. Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
2018-09-12 09:45:27 +08:00
(void)_Swap(k);
kernel: Enable SMP Now that all the pieces are in place, enable SMP for real: Initialize the CPU records, launch the CPUs at the end of kernel initialization, have them wait for a flag to release them into the scheduler, then enter into the runnable threads via _Swap(). Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2018-01-18 03:34:50 +08:00
CODE_UNREACHABLE;
}
#endif
void smp_init(void)
{
atomic_t start_flag;
kernel; Checking functions return Checking the return of some scattered functions across kernel. MISRA-C requires that all non-void functions have their return value checked, though, in some cases there is nothing to do. Just acknowledging it. Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
2018-09-14 02:24:30 +08:00
(void)atomic_clear(&start_flag);
kernel: Enable SMP Now that all the pieces are in place, enable SMP for real: Initialize the CPU records, launch the CPUs at the end of kernel initialization, have them wait for a flag to release them into the scheduler, then enter into the runnable threads via _Swap(). Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2018-01-18 03:34:50 +08:00
#if defined(CONFIG_SMP) && CONFIG_MP_NUM_CPUS > 1
_arch_start_cpu(1, _interrupt_stack1, CONFIG_ISR_STACK_SIZE,
kernel: Name of static functions should not begin with an underscore Names that begin with an underscore are reserved by the C standard. This patch does not change names of functions defined and implemented in header files. Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
2018-03-07 07:08:55 +08:00
smp_init_top, &start_flag);
kernel: Enable SMP Now that all the pieces are in place, enable SMP for real: Initialize the CPU records, launch the CPUs at the end of kernel initialization, have them wait for a flag to release them into the scheduler, then enter into the runnable threads via _Swap(). Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2018-01-18 03:34:50 +08:00
#endif
#if defined(CONFIG_SMP) && CONFIG_MP_NUM_CPUS > 2
_arch_start_cpu(2, _interrupt_stack2, CONFIG_ISR_STACK_SIZE,
kernel: Name of static functions should not begin with an underscore Names that begin with an underscore are reserved by the C standard. This patch does not change names of functions defined and implemented in header files. Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
2018-03-07 07:08:55 +08:00
smp_init_top, &start_flag);
kernel: Enable SMP Now that all the pieces are in place, enable SMP for real: Initialize the CPU records, launch the CPUs at the end of kernel initialization, have them wait for a flag to release them into the scheduler, then enter into the runnable threads via _Swap(). Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2018-01-18 03:34:50 +08:00
#endif
#if defined(CONFIG_SMP) && CONFIG_MP_NUM_CPUS > 3
_arch_start_cpu(3, _interrupt_stack3, CONFIG_ISR_STACK_SIZE,
kernel: Name of static functions should not begin with an underscore Names that begin with an underscore are reserved by the C standard. This patch does not change names of functions defined and implemented in header files. Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
2018-03-07 07:08:55 +08:00
smp_init_top, &start_flag);
kernel: Enable SMP Now that all the pieces are in place, enable SMP for real: Initialize the CPU records, launch the CPUs at the end of kernel initialization, have them wait for a flag to release them into the scheduler, then enter into the runnable threads via _Swap(). Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2018-01-18 03:34:50 +08:00
#endif
kernel; Checking functions return Checking the return of some scattered functions across kernel. MISRA-C requires that all non-void functions have their return value checked, though, in some cases there is nothing to do. Just acknowledging it. Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
2018-09-14 02:24:30 +08:00
(void)atomic_set(&start_flag, 1);
kernel: Enable SMP Now that all the pieces are in place, enable SMP for real: Initialize the CPU records, launch the CPUs at the end of kernel initialization, have them wait for a flag to release them into the scheduler, then enter into the runnable threads via _Swap(). Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2018-01-18 03:34:50 +08:00
}