User pages are mapped from the currently active address environment. If
the process is running on a borrowed address environment, then the
mapping should be created from there.
This happens during (new) process creation only.
All kernel memory is mapped paddr=vaddr, so it is trivial to give mapping
for kernel memory. Only interesting region should be kernel RAM, so omit
kernel ROM and don't allow re-mapping it.
It looks like we do not need to send the 9 clock ticks whenever we reset
the FSM. We are already doing this in i2c_reset function if necessary.
This makes the i2c transfers much faster, for example the i2c(-tool) dev
scan feature.
In addition to printing out the thread name (task name in flat mode),
print the parent process's name as well.
It is quite useful to know which process is the parent of a faulting
thread, although this information can be read from the assert dump, in
some cases the dump might be incomplete (due to e.g. stack corruption,
which causes another exception and PANIC().)
so the user could register fb device directly instead
go through the sequence of up_fbinitialize/up_fbgetvplane
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
https://man7.org/linux/man-pages/man2/memfd_create.2.html:
The name supplied in name is used as a filename and will be
displayed as the target of the corresponding symbolic link in the
directory /proc/self/fd/. The displayed name is always prefixed
with memfd: and serves only for debugging purposes. Names do not
affect the behavior of the file descriptor, and as such multiple
files can have the same name without any side effects.
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
test config: ./tools/configure.sh -l qemu-armv8a:nsh_smp
Pass ostest
No matter big-endian or little-endian, ticket spinlock only check the
next and the owner is equal or not.
If they are equal, it means there is a task hold the lock or lock is
free.
Signed-off-by: TaiJu Wu <tjwu1217@gmail.com>
Co-authored-by: Xiang Xiao <xiaoxiang781216@gmail.com>
Whenever we enter/leave a critical section, the interrupt status is
saved and, then, restored. However, for the ESP32-S3's BLE adapter,
entering/leaving a critical section is done on separate functions
that need to be registered as a callback.
The status flag was being saved as a global variable. However,
calling nested enter_critical_section would overwrite this global
variable that was storing the previous flag and, when leaving the
last critical section, the restored status would be different from
the one expected. The proposed solution for this issue is to create
a global array to store the interrupt status flags for nested calls.
This commit sets the BLE's interrupt as a IRAM-enabled interrupt,
which enables it to run during a SPI flash operation. This enables
us to create a cache to off-load semaphores and message queues
operations and treat them when the SPI flash operation is finished.
By doing that, we avoid packet losses during a SPI flash operation.
This commit provides an interface to register ISRs that run from
IRAM and keeps track of the non-IRAM interrupts. It enables, for
instance, to avoid disabling all the interrupts during a SPI flash
operation: IRAM-enabled ISRs are, then, able to run during these
operations.
When allocating a CPU interrupt, make sure to select the correct
CPU core to query for it. Simply checking for the current CPU does
not satisfy this requirement because the CPU allocation thread may
be executed by the other core: it's necessary to stick with the
intended CPU passed as an argument of the `esp32s3_setup_irq`.
The registered `task_create_wrapper` receives the `core_id`, but
the current implementation ignores this parameter while calling
`esp_task_create_pinned_to_core`. This commit fix this.
When allocating a CPU interrupt, make sure to select the correct
CPU core to query for it. Simply checking for the current CPU does
not satisfy this requirement because the CPU allocation thread may
be executed by the other core: it's necessary to stick with the
intended CPU passed as an argument of the `esp32_setup_irq`.
clock_getcycle always returns an incremented cycle value
If the hardware does not support perf event it will use arch_alarm's up_perf_gettime
Signed-off-by: yinshengkai <yinshengkai@xiaomi.com>
