sys/bhp_*: add initial support for generic Bottom Half Processor#18435
sys/bhp_*: add initial support for generic Bottom Half Processor#18435jia200x merged 4 commits intoRIOT-OS:masterfrom
Conversation
github-actions
bot
added
Area: sys
|
I have a follow up PR that adapts #18383 to this mechanism. See it in action |
|
@leandrolanzieri, @MrKevinWeiss could you please check if the Kconfig modelling looks ok? |
sys/bhp/Kconfig
Outdated
| depends on MODULE_EVENT | ||
| select MODULE_BHP |
There was a problem hiding this comment.
Seems a bit redundant to define both?
@leandrolanzieri might know better
There was a problem hiding this comment.
I think it is relatively low-risk here to select MODULE_EVENT, if that's what you mean
There was a problem hiding this comment.
Hmmm now that I see it, probably will need to change the modelling a bit.
My idea was to use MODULE_BHP as a feature request that the driver can select.
Then, another module (e.g gnrc_netif) can select MODULE_BHP_EVENT if MODULE_BHP is present. That way we don't pull BHP code when devices don't require it
There was a problem hiding this comment.
I just had an offline discussion with @leandrolanzieri and we agreed on leaving MODULE_BHP to compile sys/bhp. This is also used to indicate in Make that a driver requires a Bottom Half Processor, but it doesn't force the user to bring any of the bhp_* modules.
For Kconfig I simply added a HAVE_BHP_IRQ_HANDLER feature to the driver that indicates there's an IRQ handler expected to be offloaded.
|
if this is merged before #18383, I can adapt the kinetis radio to this BHP mechanism |
jia200x
added
CI: ready for build
miri64
added
the
Type: new feature
|
thanks for the review! |
Is it that simple? The memory model of the four methods is very different. |
It is agnostic from an interface point of view. Neither the device nor the network stack care about which underlying mechanism is being used and these can be exchanged at any time. |
6 participants
Contribution description
This PR addresses this comment and adds a generic Bottom Half Processor mechanism to be used by any device that requires ISR offloading.
The mechanism is agnostic to the underlying processing module (events, messages, thread flags), as it simply defines an interface for storing an (IRQ) handler and a context.
On top of that, a dedicated Bottom Half Processor module (
bhp_*) exposes an init function that configures the underlying mechanism and setups the callback. Then, the device driver init function sets the ISR callback tobhp_*_cband passes thebhp_*_tdescriptor as the ISR context. The module will take care of the rest.Based on this, I implemented an event based Bottom Half Processor (see
bhp_event), which allows to offload the handler to an event queue. In the future, there could be more of these implementations (bhp_thread_flags,bhp_msg,bhp_mbox, etc).Testing procedure
Unittests should pass.
Issues/PRs references
It will be come extremely handy to implement network-stack-and-device-agnostic IRQ offloaders for SPI radios (#18383)