Summary:
- SP_SECTION was introduced to allocate spinlock in non-cachable
region mainly for Cortex-A to stabilize the NuttX SMP kernel
- However, all spinlocks are now allocated in cachable area and
works without any problems
- So SP_SECTION should be removed to simplify the kernel code
Impact:
- None
Testing:
- Build test only
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
Summary:
- This commit introduces spinlock_t for #ifndef CONFIG_SPINLOCK
which is useful for the non-SMP case because it does not consume
memory
Impact:
- None:
Testing:
- N/A
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
use the default testset implement on single core platform
that does not support test-and-set, more flexibility for
SMP drivers(using spinlock) if configured in a single-core mode.
Signed-off-by: chao.an <anchao@xiaomi.com>
Summary:
- This commit introduces SP_WFE() and SP_SEV() to be used for spinlock
- Also, use wfe/sev instructions for ARMV7-A to reduce power consumption
Impact:
- ARMV7-a SMP only
Testing:
- sabre-6quad:smp (QEMU, dev board)
- maix-bit:smp, esp32-devkitc:smp, spresense:smp sim:smp (compile only)
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
libs/libc/pthread/pthread_spinlock.c: Resolve several TODO issues by accessing up_testset() via the boardctl() interface rather than attempting to call it directly.
configs/boardctl.c, include/sys/boardctl.h: Add access to architecture-specific up_testset() via boardctl().
arch/Kconfig's, sched/Kconfig, and include/nuttx/spinlock.h: Spinlocks are not available unless the architecture supports the up_testset() operation.
These APIs are used in sched_note.c to protect instumentation data.
The deffrence between these APIs to exsiting spin_lock() and spin_unlock()
is that they do not perform insturumentation to avoid recursive call
when SCHED_INSTRUMENTATION_SPINLOCKS=y.
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
This commit corrects this. This is matching logic in sched_addreadytorun to avoid starting new tasks within the critical section (unless the CPU is the holder of the lock). The holder of the IRQ lock must be permitted to do whatever it needs to do.
