drivers/sensors: Add non-wakeup mode support and optimize RPMSG communication part 4. #18134
+157
−30
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
support set_nonwakeup ops for sensor driver to save power Signed-off-by: dongjiuzhu1 <dongjiuzhu1@xiaomi.com>
Otpvondoiats
requested review from
Donny9,
acassis,
jerpelea,
linguini1 and
xiaoxiang781216
as code owners
github-actions
bot
added
Area: OS Components
when remote core connect. using worker instead of rptun thread to broadcast advertisement message because the rptun thread can't process rx message when it calls the ns_bound function. And the advertisement message to remote core will generate many the advertisement ack message from remote core, these advertisement ack messages can't be processed at times by rptun thread. This can cause rptun thread to block when the number of advertisement message exceeds the number of ipc buffers between local core and remote core. Signed-off-by: dongjiuzhu1 <dongjiuzhu1@xiaomi.com>
change non-wakeup as default mode. Signed-off-by: dongjiuzhu1 <dongjiuzhu1@xiaomi.com>
set nonwakeup mode as initialize state. Signed-off-by: dongjiuzhu1 <dongjiuzhu1@xiaomi.com>
Otpvondoiats
force-pushed
the
lk-power
branch
from
0e784ab to
f6ab250
Compare
jerpelea
approved these changes
Jan 23, 2026
xiaoxiang781216
approved these changes
Jan 23, 2026
acassis
requested changes
Jan 23, 2026
Contributor
acassis
left a comment
acassis
left a comment
There was a problem hiding this comment.
@Otpvondoiats I think the details you add to Summary could be moved to our new RPMsg Documentation. Could you please add it?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Note: Please adhere to Contributing Guidelines.
Summary
This patch series adds power-saving non-wakeup mode support for sensor drivers and optimizes the sensor RPMSG communication mechanism in multi-core scenarios.
Key Changes
Added support for set_nonwakeup operation to allow sensors to operate in a low-power mode where they don't wake up the remote CPU when it's in sleep state.
How it works:
Introduced nonwakeup flag in sensor user state and upper state structures
When all users set non-wakeup mode, the sensor driver switches to non-wakeup operation
In RPMSG context, non-wakeup sensors skip data transmission when remote CPU is sleeping
Default mode is set to non-wakeup to optimize power consumption from initialization
API Changes:
Added SNIOC_SET_NONWAKEUP ioctl command
Added set_nonwakeup() callback to sensor_ops_s structure
Added nonwakeup field to sensor_ustate_s and sensor_state_s
2. RPMSG Advertisement Broadcast Optimization
Changed the advertisement message broadcasting mechanism to use work queue instead of RPTUN thread context.
Problem Solved:
RPTUN thread cannot process RX messages while executing ns_bound callback
Advertisement messages to remote core generate many ACK messages from remote
When advertisement count exceeds IPC buffer capacity, RPTUN thread blocks
This deadlock prevents normal sensor communication
Solution:
Use HPWORK queue to broadcast advertisement messages asynchronously
RPTUN thread can continue processing incoming messages
Prevents IPC buffer exhaustion and thread blocking
3. Mode Initialization Optimization
Set non-wakeup mode as the default initialization state for power efficiency
Ensures sensors start in low-power mode unless explicitly changed by users
Optimizes overall system power consumption
Technical Details
Modified Files:
drivers/sensors/sensor.c - Core sensor driver with non-wakeup logic
drivers/sensors/sensor_rpmsg.c - RPMSG communication with power management
include/nuttx/sensors/ioctl.h - Added SNIOC_SET_NONWAKEUP command
include/nuttx/sensors/sensor.h - Extended sensor operations and state structures
include/nuttx/uorb.h - Added non-wakeup support to uORB interface
Key Implementation:
Impact
Users
Power Savings: Significant reduction in power consumption for sensor applications
Flexibility: Users can control sensor wakeup behavior per-subscription
Reliability: Eliminates RPMSG communication deadlocks in multi-core systems
Performance
Improved: Asynchronous advertisement broadcasting reduces IPC latency
Optimized: Non-wakeup sensors don't generate unnecessary interrupts
Stable: No more RPTUN thread blocking issues
Compatibility
API Extension: New set_nonwakeup operation is optional for drivers
Backward Compatible: Existing drivers continue to work without modification
Default Behavior: Non-wakeup mode is default, can be changed via ioctl
Multi-Core Communication
Fixed: RPMSG thread blocking when advertising multiple sensors
Improved: Better handling of IPC buffer constraints
Robust: Worker-based broadcasting prevents deadlocks
Power Management
Optimized: Sensors in non-wakeup mode don't wake sleeping remote cores
Configurable: Per-user control over wakeup behavior
Efficient: Default non-wakeup mode reduces unnecessary power consumption
Testing