Skip to content

core: interrupt: factorization & renaming - #6030

Merged
jforissier merged 4 commits into
OP-TEE:masterfrom
etienne-lms:itr-1
May 23, 2023
Merged

core: interrupt: factorization & renaming#6030
jforissier merged 4 commits into
OP-TEE:masterfrom
etienne-lms:itr-1

Conversation

@etienne-lms

@etienne-lms etienne-lms commented May 17, 2023

Copy link
Copy Markdown
Contributor

This change prepares changes to move to the interrupt management API function proposed in OP-TEE/optee_docs#192 and to the generic interrupt chip framework proposed by #5954.

Commit "core: define main interrupt controller data from its driver" factorizes CPU core main interrupt controller initialization and root main native interrupt handling.

Commit "drivers: gic: factorize call to gic_init() or gic_init_base_addr()" makes gic_init() a unique entry point to initialize GIC driver.

Commit "core: interrupt: rename itr_core_handler()" renames itr_core_handler() to interrupt_core_handler() interrupt_main_handler().

Commit "core: interrupt: rename itr_init()" renames itr_init() to interrupt_core_init() interrupt_main_init().

(edited) updated from review comments

@jenswikl jenswikl left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment for "core: define main interrupt controller data from its driver"

Comment thread core/drivers/gic.c

@jenswikl jenswikl left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment for "core: define main interrupt controller data from its driver"

@jenswikl jenswikl left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment for "core: define main interrupt controller data from its driver"

Comment thread core/include/kernel/interrupt.h
Comment thread core/drivers/gic.c
Comment thread core/drivers/gic.c
Comment thread core/include/kernel/interrupt.h

@etienne-lms etienne-lms left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jforissier, do these changes make sense to you?
I'll wait for some status in this P-R before rebasing #5954.

@jforissier

Copy link
Copy Markdown
Contributor

@jforissier, do these changes make sense to you? I'll wait for some status in this P-R before rebasing #5954.

They do seem to simplify things quite a bit and the diffstat is nice (+193 -339), so I'd say: yes, I'm fine with that.

@jenswikl

Copy link
Copy Markdown
Contributor

Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>

All but one platforms define CPU core interrupt controller from their
platform main.c source file next to its main interrupt handler.
This change factorize these implementation by moving the definition
of the controller data instance straight in the controller driver
source file. This change makes each controller driver to implement
straight itr_core_handler() function, preventing a extra branch on
interrupt execution. Interrupt controller driver initialization
function now straight calls itr_core_init().

This changes treats case when CFG_CORE_WORKAROUND_ARM_NMFI is enable
to not conflict with core/arch/arm/kernel/thread.c that already
overrides itr_core_handler() weak implementation.

With this change, the main controller initialization function
(gic_init(), gic_init_base_addr(), gic_cpu_init() and hfic_init())
no more gets the controller data as input argument.

As a consequence, definition of struct hfic_data and struct gic_data
moves from their respective driver header file to the respective
driver source file.

As a consequence, gic_dump() no more requires an argument.

Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Platforms call either gic_init() or gic_init_base_addr() depending
on whether CFG_WITH_ARM_TRUSTED_FW is defined or not. This change
factorize this logic from gic_init() implementation and makes
gic_init_base_addr() local to gic.c.

For that purpose functions gic_init_base_address() and gic_dt_get_irq()
are moved inside gic.c source file.
source file.

Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Renames itr_core_handler() to interrupt_main_handler() as a later
change will modify interrupt chip API functions using interrupt_
as prefix.

Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Renames itr_init() to interrupt_main_init() as a later
change will modify interrupt chip API functions using interrupt_
as prefix.

Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
@etienne-lms

Copy link
Copy Markdown
Contributor Author

fixup commit squashed and review tag applied.

@jforissier

Copy link
Copy Markdown
Contributor

It looks like RockPi4 was broken by this PR. When testing 4.7.0-rc1, I get a panic "Secure interrupt handler not defined". Anyone has an idea what's missing? Thanks.

@etienne-lms

Copy link
Copy Markdown
Contributor Author

You get this panic trace message when no interrupt_main_handler() defines the CPU main interrupt controller.
IIUC, RockPi4 is PLATFORM=rockchip-rk3399 and embeds GIC driver core/drivers/gic.c without enabling CFG_CORE_WORKAROUND_ARM_NMFI=y hence interrupt_main_handler() should come from gic.c driver.

@jforissier

jforissier commented Jun 30, 2025

Copy link
Copy Markdown
Contributor

You get this panic trace message when no interrupt_main_handler() defines the CPU main interrupt controller. IIUC, RockPi4 is PLATFORM=rockchip-rk3399 and embeds GIC driver core/drivers/gic.c without enabling CFG_CORE_WORKAROUND_ARM_NMFI=y hence interrupt_main_handler() should come from gic.c driver.

gic.c is not compiled because CFG_GIC is not enabled due to https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/plat-rockchip/conf.mk#L4 which was introduced by commit 447c5f6. If I add this file to the build anyways, xtest hangs in regression_1003 Core internal read/write mutex.

@etienne-lms

Copy link
Copy Markdown
Contributor Author

Right! indeed. I was fooled by https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/plat-rockchip/conf.mk#L33 enforcing CFG_ARM_GICV3=y.
interrupt_main_handler() is called when the platform receives a secure (native) interrupt. What does the platform expect to do if there is no interrupt driver?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants