Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

arch: arm: Add z_arch_irq_current_prio function #17301

Closed

Conversation

nordic-krch
Copy link
Contributor

Added function and extended test to cover new api.

@nordic-krch nordic-krch added the area: ARM ARM (32-bit) Architecture label Jul 3, 2019
@zephyrbot zephyrbot added area: API Changes to public APIs area: Tests Issues related to a particular existing or missing test area: Kernel labels Jul 3, 2019
@ioannisg
Copy link
Member

ioannisg commented Jul 3, 2019

What is the use case of this ARM-only aPI?

@nordic-krch
Copy link
Contributor Author

@ioannisg

What is the use case of this ARM-only aPI?

See #17293
https://github.com/zephyrproject-rtos/zephyr/blob/8de2f920eb9cdfae0c9e780873f5e08f61b209e3/drivers/clock_control/nrf_power_clock.c#L93

Function should not be called from interrupt priority higher than clock control because it may lead to deadlock since clock state will never be updated if status is read in a loop waiting for clock on and clock interrupt cannot be handled (since it has lower priority).

It maybe extended to other platforms as well if there is a use case.

@ioannisg
Copy link
Member

ioannisg commented Jul 3, 2019

Right, I need to think how this works with trustzone, there are some tricky parts there

Copy link
Contributor

@andrewboie andrewboie left a comment

Choose a reason for hiding this comment

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

I'd rather you called this z_arm_irq_current_prio() since unlike the other z_arch_* APIs there is no generic kernel API that calls it and this is only implemented on ARM.

@andyross
Copy link
Contributor

andyross commented Jul 3, 2019

Agree on the naming. Further, if the only use of this is an assert to catch priority inversion bugs, can't you do that via static analysis? For example, just make sure clock_control is at the highest available priority.

@nordic-krch
Copy link
Contributor Author

I'd rather you called this z_arm_irq_current_prio()

Done

For example, just make sure clock_control is at the highest available priority.

I wouldn't like to force that to the user, especially that this does not help if context is on the same highest, priority level.

@aescolar aescolar requested a review from andrewboie July 4, 2019 06:40
Copy link
Member

@ioannisg ioannisg left a comment

Choose a reason for hiding this comment

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

Just to contribute to the "api" discussion - would it be better to name this as bool irq_can_preempt(irq_line) or something like that? This looks more close to what you want to have for your use-case, right?

@nordic-krch
Copy link
Contributor Author

@ioannisg you mean that function would check if current context can be preempted by given interrupt?

@ioannisg
Copy link
Member

ioannisg commented Jul 4, 2019

@ioannisg you mean that function would check if current context can be preempted by given interrupt?

Yes, that's what I meant.

@nordic-krch
Copy link
Contributor Author

@ioannisg changed as you suggested to z_arm_irq_can_preempt.

@zephyrbot
Copy link
Collaborator

zephyrbot commented Jul 9, 2019

All checks are passing now.

Review history of this comment for details about previous failed status.
Note that some checks might have not completed yet.


bool z_arm_irq_can_preempt(u32_t irq_line)
{
return z_arm_irq_current_prio() > NVIC_GetPriority((IRQn_Type)irq_line);
Copy link
Member

Choose a reason for hiding this comment

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

Is this really what we want, here? What if the irq_line is, in fact, not enabled, and the priority is a trash value? Can this actually happen?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

current use case is using it in the driver which handles irq_line. I wouldn't involve enabling checking into that. What to return if interrupt is disabled? false would be correct because disabled interrupt cannot be preempt current context but that is not what we wanted to check.

By default priority in nvic is set to 0 (highest). I can add a note that only priority is checked and not the state of the interrupt.

Copy link
Member

@ioannisg ioannisg Jul 11, 2019

Choose a reason for hiding this comment

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

This all depends on what API we want to provide, see the discussion below. So, if the irq_line is not enabled, this function should return false; that's my opinion. And of course, we document this nicely. Since we named it as _can_preempt(), we need to see if it can really preempt..

@@ -153,8 +153,19 @@ extern void z_irq_spurious(void *unused);
extern void _isr_wrapper(void);
#endif

/**
Copy link
Member

@ioannisg ioannisg Jul 10, 2019

Choose a reason for hiding this comment

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

What we really need to decide for the API, is;

  • can be called by interrupts?
  • should it be thread-safe or don't care?
  • could it be generalized for all ARCHEs?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

can be called by interrupts?

yes

should it be thread-safe or don't care?

I would say don't care. Are we afraid that interrupt priority level will change after that call? How likely is that?

could it be generalized for all ARCHEs?

when use case comes some will do that. I wouldn't like to see PR pending on other platforms implementation when current use case is for peripheral driver on arm cortex.

Copy link
Member

Choose a reason for hiding this comment

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

I agree that this should be called by interrupts. We shall document that.
Also, it is fine if this is an arm-only API: we call the function z_arm_xxx and we can use a z_arch_ static inline function in include/arch/arm.

Copy link
Member

Choose a reason for hiding this comment

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

I would say don't care. Are we afraid that interrupt priority level will change after that call? How likely is that?

Now, this is problematic. If we make an API that checks if we can be preempted, we need to make sure this works in a deterministic way. I thought about it, and I don't want this to be fuzzy. We need to make this thread-safe, right?

nordic-krch and others added 3 commits July 11, 2019 12:41
Added function for checking if current context can be preempted by
given interrupt.

Signed-off-by: Krzysztof Chruscinski <[email protected]>
Extended arm_irq_vector_table test to verify z_arm_irq_can_preempt
function.

Signed-off-by: Krzysztof Chruscinski <[email protected]>
Added a simulation replacement for NVIC_GetPriority()
+
Added a function (like for ARM) to check if current context
can be preempted by given interrupt.

Signed-off-by: Alberto Escolar Piedras <[email protected]>
@carlescufi
Copy link
Member

@andyross could you please review this?

@ioannisg
Copy link
Member

ioannisg commented Oct 4, 2019

Will you continue working on this @nordic-krch or should we close the PR?

@nordic-krch
Copy link
Contributor Author

will close it for now. Maybe feature need will come back.

@nordic-krch nordic-krch closed this Oct 4, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: API Changes to public APIs area: ARM ARM (32-bit) Architecture area: Boards area: Kernel area: Tests Issues related to a particular existing or missing test
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants