:orphan: .. title:: CONFIG_RISCV_SOC_CONTEXT_SAVE .. kconfig:: CONFIG_RISCV_SOC_CONTEXT_SAVE CONFIG_RISCV_SOC_CONTEXT_SAVE ############################# *Enable SOC-based context saving in IRQ handlers* Type: ``bool`` Help ==== .. code-block:: none Enable low-level SOC-specific context management, for SOCs with extra state that must be saved when entering an interrupt/exception, and restored on exit. If unsure, leave this at the default value. Enabling this option requires that the SoC provide a soc_context.h header which defines the following macros: - SOC_ESF_MEMBERS: structure component declarations to allocate space for. The last such declaration should not end in a semicolon, for portability. The generic RISC-V architecture code will allocate space for these members in a "struct soc_esf" type (typedefed to soc_esf_t), which will be available if arch.h is included. - SOC_ESF_INIT: structure contents initializer for struct soc_esf state. The last initialized member should not end in a comma. The generic architecture IRQ wrapper will also call \_\_soc_save_context and \_\_soc_restore_context routines at ISR entry and exit, respectively. These should typically be implemented in assembly. If they were C functions, they would have these signatures: ``void __soc_save_context(soc_esf_t *state);`` ``void __soc_restore_context(soc_esf_t *state);`` The calls obey standard calling conventions; i.e., the state pointer address is in a0, and ra contains the return address. Direct dependencies =================== \ :kconfig:`SOC_OPENISA_RV32M1_RISCV32 ` || \ :kconfig:`SOC_OPENISA_RV32M1_RISCV32 ` || \ :kconfig:`RISCV ` *(Includes any dependencies from ifs and menus.)* Defaults ======== - y if \ :kconfig:`SOC_OPENISA_RV32M1_RI5CY ` - y if \ :kconfig:`SOC_OPENISA_RV32M1_RI5CY ` Symbols selected by this symbol =============================== - \ :kconfig:`RISCV_SOC_OFFSETS ` Symbols that select this symbol =============================== - \ :kconfig:`SOC_ANDES_V5_HWDSP ` - \ :kconfig:`SOC_ANDES_V5_PFT ` - \ :kconfig:`TELINK_B91_HWDSP ` - \ :kconfig:`TELINK_B91_PFT_ARCH ` - \ :kconfig:`SOC_ANDES_V5_HWDSP ` - \ :kconfig:`SOC_ANDES_V5_PFT ` - \ :kconfig:`TELINK_B91_HWDSP ` - \ :kconfig:`TELINK_B91_PFT_ARCH ` Kconfig definitions =================== At ``/riscv/openisa_rv32m1/Kconfig.defconfig:27`` Included via ``Kconfig:8`` → ``Kconfig.zephyr:25`` → ``/kconfig/Kconfig.soc.defconfig:1`` Menu path: (Top) .. code-block:: kconfig config RISCV_SOC_CONTEXT_SAVE bool default y if SOC_OPENISA_RV32M1_RI5CY depends on SOC_OPENISA_RV32M1_RISCV32 ---- At ``/riscv/openisa_rv32m1/Kconfig.defconfig:27`` Included via ``Kconfig:8`` → ``Kconfig.zephyr:27`` Menu path: (Top) .. code-block:: kconfig config RISCV_SOC_CONTEXT_SAVE bool default y if SOC_OPENISA_RV32M1_RI5CY depends on SOC_OPENISA_RV32M1_RISCV32 ---- At ``/riscv/Kconfig:52`` Included via ``Kconfig:8`` → ``Kconfig.zephyr:39`` → ``/Kconfig:12`` Menu path: (Top) → RISCV Options → RISCV Processor Options .. code-block:: kconfig config RISCV_SOC_CONTEXT_SAVE bool "Enable SOC-based context saving in IRQ handlers" select RISCV_SOC_OFFSETS depends on RISCV help Enable low-level SOC-specific context management, for SOCs with extra state that must be saved when entering an interrupt/exception, and restored on exit. If unsure, leave this at the default value. Enabling this option requires that the SoC provide a soc_context.h header which defines the following macros: - SOC_ESF_MEMBERS: structure component declarations to allocate space for. The last such declaration should not end in a semicolon, for portability. The generic RISC-V architecture code will allocate space for these members in a "struct soc_esf" type (typedefed to soc_esf_t), which will be available if arch.h is included. - SOC_ESF_INIT: structure contents initializer for struct soc_esf state. The last initialized member should not end in a comma. The generic architecture IRQ wrapper will also call \_\_soc_save_context and \_\_soc_restore_context routines at ISR entry and exit, respectively. These should typically be implemented in assembly. If they were C functions, they would have these signatures: ``void __soc_save_context(soc_esf_t *state);`` ``void __soc_restore_context(soc_esf_t *state);`` The calls obey standard calling conventions; i.e., the state pointer address is in a0, and ra contains the return address. *(The 'depends on' condition includes propagated dependencies from ifs and menus.)*