michaelh/zephyr
1
0
Fork 0
Code Releases Activity
zephyr/kernel/system_work_q.c

38 lines
786 B
C
Raw Permalink Normal View History

unified: dissociate system workqueue from common workqueue module Making a reference to the common work queue code should not necessarily drag in the system workqueue, since it is possible to use a workqueue that is not the system workqueue. This is done by moving the system workqueue into its own code module. Moving the system workqueue to its own code module allows removing the NANO_WORKQUEUE and SYSTEM_WORKQUEUE kconfig options, and compiling the common workqueue code and system workqueue all the time. They are only linked in the final image if a reference to them exist, same as the other kernel modules. Change-Id: I6f48d2542bda24f4702e7c2e317818dd082b3c11 Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
2016-11-04 20:47:32 +01:00
/*
* Copyright (c) 2016 Wind River Systems, Inc.
* Copyright (c) 2016 Intel Corporation
*
license: Replace Apache boilerplate with SPDX tag Replace the existing Apache 2.0 boilerplate header with an SPDX tag throughout the zephyr code tree. This patch was generated via a script run over the master branch. Also updated doc/porting/application.rst that had a dependency on line numbers in a literal include. Manually updated subsys/logging/sys_log.c that had a malformed header in the original file. Also cleanup several cases that already had a SPDX tag and we either got a duplicate or missed updating. Jira: ZEP-1457 Change-Id: I6131a1d4ee0e58f5b938300c2d2fc77d2e69572c Signed-off-by: David B. Kinder <david.b.kinder@intel.com> Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
2017-01-19 02:01:01 +01:00
* SPDX-License-Identifier: Apache-2.0
unified: dissociate system workqueue from common workqueue module Making a reference to the common work queue code should not necessarily drag in the system workqueue, since it is possible to use a workqueue that is not the system workqueue. This is done by moving the system workqueue into its own code module. Moving the system workqueue to its own code module allows removing the NANO_WORKQUEUE and SYSTEM_WORKQUEUE kconfig options, and compiling the common workqueue code and system workqueue all the time. They are only linked in the final image if a reference to them exist, same as the other kernel modules. Change-Id: I6f48d2542bda24f4702e7c2e317818dd082b3c11 Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
2016-11-04 20:47:32 +01:00
*/
/**
* @file
*
* System workqueue.
*/
kernel: migrate includes to <zephyr/...> In order to bring consistency in-tree, migrate all kernel code to the new prefix <zephyr/...>. Note that the conversion has been scripted, refer to zephyrproject-rtos#45388 for more details. Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2022-05-06 11:04:23 +02:00
#include <zephyr/kernel.h>
#include <zephyr/init.h>
unified: dissociate system workqueue from common workqueue module Making a reference to the common work queue code should not necessarily drag in the system workqueue, since it is possible to use a workqueue that is not the system workqueue. This is done by moving the system workqueue into its own code module. Moving the system workqueue to its own code module allows removing the NANO_WORKQUEUE and SYSTEM_WORKQUEUE kconfig options, and compiling the common workqueue code and system workqueue all the time. They are only linked in the final image if a reference to them exist, same as the other kernel modules. Change-Id: I6f48d2542bda24f4702e7c2e317818dd082b3c11 Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
2016-11-04 20:47:32 +01:00
kernel: add new work queue implementation This commit provides a complete reimplementation of the work queue infrastructure intended to eliminate the race conditions and feature gaps in the existing implementation. Both bare and delayable work structures are supported. Items can be submitted; delayable items can be scheduled for submission at a future time. Items can be delayed, queued, and running all at the same time. A running item can also be canceling. The new implementation: * replaces "pending" with "busy" which identifies the active states; * supports canceling delayed and submitted items; * prevents resubmission of a item being canceled until cancellation completes; * supports waiting for cancellation to complete; * supports flushing a work item (waiting for the last submission to complete without preventing resubmission); * supports waiting for a queue to drain (only allows resubmission from the work thread); * supports stopping a work queue in conjunction with draining it; * prevents handler-reentrancy during resubmission. Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
2020-10-28 17:24:05 +01:00
static K_KERNEL_STACK_DEFINE(sys_work_q_stack,
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE);
unified: dissociate system workqueue from common workqueue module Making a reference to the common work queue code should not necessarily drag in the system workqueue, since it is possible to use a workqueue that is not the system workqueue. This is done by moving the system workqueue into its own code module. Moving the system workqueue to its own code module allows removing the NANO_WORKQUEUE and SYSTEM_WORKQUEUE kconfig options, and compiling the common workqueue code and system workqueue all the time. They are only linked in the final image if a reference to them exist, same as the other kernel modules. Change-Id: I6f48d2542bda24f4702e7c2e317818dd082b3c11 Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
2016-11-04 20:47:32 +01:00
struct k_work_q k_sys_work_q;
init: remove the need for a dummy device pointer in SYS_INIT functions The init infrastructure, found in `init.h`, is currently used by: - `SYS_INIT`: to call functions before `main` - `DEVICE_*`: to initialize devices They are all sorted according to an initialization level + a priority. `SYS_INIT` calls are really orthogonal to devices, however, the required function signature requires a `const struct device *dev` as a first argument. The only reason for that is because the same init machinery is used by devices, so we have something like: ```c struct init_entry { int (*init)(const struct device *dev); /* only set by DEVICE_*, otherwise NULL */ const struct device *dev; } ``` As a result, we end up with such weird/ugly pattern: ```c static int my_init(const struct device *dev) { /* always NULL! add ARG_UNUSED to avoid compiler warning */ ARG_UNUSED(dev); ... } ``` This is really a result of poor internals isolation. This patch proposes a to make init entries more flexible so that they can accept sytem initialization calls like this: ```c static int my_init(void) { ... } ``` This is achieved using a union: ```c union init_function { /* for SYS_INIT, used when init_entry.dev == NULL */ int (*sys)(void); /* for DEVICE*, used when init_entry.dev != NULL */ int (*dev)(const struct device *dev); }; struct init_entry { /* stores init function (either for SYS_INIT or DEVICE*) union init_function init_fn; /* stores device pointer for DEVICE*, NULL for SYS_INIT. Allows * to know which union entry to call. */ const struct device *dev; } ``` This solution **does not increase ROM usage**, and allows to offer clean public APIs for both SYS_INIT and DEVICE*. Note that however, init machinery keeps a coupling with devices. **NOTE**: This is a breaking change! All `SYS_INIT` functions will need to be converted to the new signature. See the script offered in the following commit. Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no> init: convert SYS_INIT functions to the new signature Conversion scripted using scripts/utils/migrate_sys_init.py. Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no> manifest: update projects for SYS_INIT changes Update modules with updated SYS_INIT calls: - hal_ti - lvgl - sof - TraceRecorderSource Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no> tests: devicetree: devices: adjust test Adjust test according to the recently introduced SYS_INIT infrastructure. Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no> tests: kernel: threads: adjust SYS_INIT call Adjust to the new signature: int (*init_fn)(void); Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2022-10-19 09:33:44 +02:00
static int k_sys_work_q_init(void)
unified: dissociate system workqueue from common workqueue module Making a reference to the common work queue code should not necessarily drag in the system workqueue, since it is possible to use a workqueue that is not the system workqueue. This is done by moving the system workqueue into its own code module. Moving the system workqueue to its own code module allows removing the NANO_WORKQUEUE and SYSTEM_WORKQUEUE kconfig options, and compiling the common workqueue code and system workqueue all the time. They are only linked in the final image if a reference to them exist, same as the other kernel modules. Change-Id: I6f48d2542bda24f4702e7c2e317818dd082b3c11 Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
2016-11-04 20:47:32 +01:00
{
kernel: add new work queue implementation This commit provides a complete reimplementation of the work queue infrastructure intended to eliminate the race conditions and feature gaps in the existing implementation. Both bare and delayable work structures are supported. Items can be submitted; delayable items can be scheduled for submission at a future time. Items can be delayed, queued, and running all at the same time. A running item can also be canceling. The new implementation: * replaces "pending" with "busy" which identifies the active states; * supports canceling delayed and submitted items; * prevents resubmission of a item being canceled until cancellation completes; * supports waiting for cancellation to complete; * supports flushing a work item (waiting for the last submission to complete without preventing resubmission); * supports waiting for a queue to drain (only allows resubmission from the work thread); * supports stopping a work queue in conjunction with draining it; * prevents handler-reentrancy during resubmission. Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
2020-10-28 17:24:05 +01:00
struct k_work_queue_config cfg = {
.name = "sysworkq",
.no_yield = IS_ENABLED(CONFIG_SYSTEM_WORKQUEUE_NO_YIELD),
kernel: system_work_q: Mark queue thread as essential Marking sysworkq as essential, so when it fails, the system will halt instead of continuously working, and dependent components stay in a broken state. Signed-off-by: Mohamed ElShahawi <ExtremeGTX@hotmail.com>
2024-03-29 01:13:48 +01:00
.essential = true,
kernel: add new work queue implementation This commit provides a complete reimplementation of the work queue infrastructure intended to eliminate the race conditions and feature gaps in the existing implementation. Both bare and delayable work structures are supported. Items can be submitted; delayable items can be scheduled for submission at a future time. Items can be delayed, queued, and running all at the same time. A running item can also be canceling. The new implementation: * replaces "pending" with "busy" which identifies the active states; * supports canceling delayed and submitted items; * prevents resubmission of a item being canceled until cancellation completes; * supports waiting for cancellation to complete; * supports flushing a work item (waiting for the last submission to complete without preventing resubmission); * supports waiting for a queue to drain (only allows resubmission from the work thread); * supports stopping a work queue in conjunction with draining it; * prevents handler-reentrancy during resubmission. Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
2020-10-28 17:24:05 +01:00
};
unified: dissociate system workqueue from common workqueue module Making a reference to the common work queue code should not necessarily drag in the system workqueue, since it is possible to use a workqueue that is not the system workqueue. This is done by moving the system workqueue into its own code module. Moving the system workqueue to its own code module allows removing the NANO_WORKQUEUE and SYSTEM_WORKQUEUE kconfig options, and compiling the common workqueue code and system workqueue all the time. They are only linked in the final image if a reference to them exist, same as the other kernel modules. Change-Id: I6f48d2542bda24f4702e7c2e317818dd082b3c11 Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
2016-11-04 20:47:32 +01:00
kernel: add new work queue implementation This commit provides a complete reimplementation of the work queue infrastructure intended to eliminate the race conditions and feature gaps in the existing implementation. Both bare and delayable work structures are supported. Items can be submitted; delayable items can be scheduled for submission at a future time. Items can be delayed, queued, and running all at the same time. A running item can also be canceling. The new implementation: * replaces "pending" with "busy" which identifies the active states; * supports canceling delayed and submitted items; * prevents resubmission of a item being canceled until cancellation completes; * supports waiting for cancellation to complete; * supports flushing a work item (waiting for the last submission to complete without preventing resubmission); * supports waiting for a queue to drain (only allows resubmission from the work thread); * supports stopping a work queue in conjunction with draining it; * prevents handler-reentrancy during resubmission. Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
2020-10-28 17:24:05 +01:00
k_work_queue_start(&k_sys_work_q,
sys_work_q_stack,
K_KERNEL_STACK_SIZEOF(sys_work_q_stack),
CONFIG_SYSTEM_WORKQUEUE_PRIORITY, &cfg);
unified: dissociate system workqueue from common workqueue module Making a reference to the common work queue code should not necessarily drag in the system workqueue, since it is possible to use a workqueue that is not the system workqueue. This is done by moving the system workqueue into its own code module. Moving the system workqueue to its own code module allows removing the NANO_WORKQUEUE and SYSTEM_WORKQUEUE kconfig options, and compiling the common workqueue code and system workqueue all the time. They are only linked in the final image if a reference to them exist, same as the other kernel modules. Change-Id: I6f48d2542bda24f4702e7c2e317818dd082b3c11 Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
2016-11-04 20:47:32 +01:00
return 0;
}
kernel: initialize system work queue after kernel is up The system work queue spawns a coop thread to hanlde the work items. If it is spawned before the kernel is up and the initialization dummy thread's priority is lower, there will be a context switch into the system work queue's thread at that time, before the kernel is ready to handle this. Change-Id: I879659ab58231c5a5cfaa34f2f65c2eccab99142 Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
2016-12-17 00:01:13 +01:00
SYS_INIT(k_sys_work_q_init, POST_KERNEL, CONFIG_KERNEL_INIT_PRIORITY_DEFAULT);
Copy permalink