Otpvondoiats opened a new pull request, #18266:
URL: https://github.com/apache/nuttx/pull/18266

   *Note: Please adhere to [Contributing 
Guidelines](https://github.com/apache/nuttx/blob/master/CONTRIBUTING.md).*
   
   ## Summary
   
   
   This patch series implements major improvements to the sensor framework's 
power management and multi-core communication, including renaming the wakeup 
semantic, fixing critical deadlocks, optimizing broadcast behavior, and 
enhancing monitoring capabilities.
   
   Background
   The sensor framework had several critical issues that impacted power 
efficiency, system stability, and debugging capability in multi-core RPMSG 
scenarios:
   
   Confusing terminology: "non-wakeup" mode was the default, making the API 
counter-intuitive
   Critical deadlock: Lock ordering issue between user tasks and RPTUN thread 
caused system hangs
   Unnecessary wakeups: Broadcasting to sleeping cores consumed excessive power
   Limited observability: Difficult to debug wakeup state transitions
   Key Changes
   1. Semantic Reversal: Non-Wakeup → Wakeup
   Changed the sensor power mode API from negative logic (non-wakeup) to 
positive logic (wakeup) for better clarity:
   
   Before (confusing):
   
   After (intuitive):
   
   Rationale:
   
   Non-wakeup is the default mode (false = don't wake)
   Positive logic is more intuitive ("wakeup=true" means "wake the CPU")
   Consistent with industry standards (Android uses wakeup flag)
   Reduces confusion in driver implementation
   2. Critical Deadlock Fix
   Fixed a severe deadlock between user tasks and RPTUN thread when accessing 
upper->lock:
   
   Deadlock Scenario:
   
   Root Cause: User task holds upper->lock while waiting for RPMSG TX buffer, 
but RPTUN thread needs the same lock to process RX messages, creating circular 
dependency.
   
   Solution: Release upper->lock before calling RPMSG operations:
   
   3. Smart Broadcast Optimization
   Avoid broadcasting to sleeping remote cores for non-wakeup sensors to save 
power:
   
   Before: Always broadcast regardless of remote core state
   After: Conditional broadcast based on:
   
   Logic:
   
   First-time broadcast: Always send (need to establish connection)
   Wakeup sensors: Always send (designed to wake remote)
   Non-wakeup sensors: Only send if remote is awake
   Additional Optimizations:
   
   Physical sensors don't broadcast subscriptions (only advertise)
   Removed unnecessary proxy freeing in unadv/close handlers
   Removed empty sensor_rpmsg_unadv_handler() implementation
   4. Proxy Wakeup State Tracking
   Added wakeup flag to proxy structure to remember wakeup preferences:
   
   This allows intelligent broadcast decisions even for existing proxies.
   
   5. Enhanced Monitoring Logs
   Added detailed wakeup state transition logging:
   
   Helps diagnose wakeup mode issues in production.
   
   Technical Details
   Modified Files:
   
   sensor.c - Core wakeup logic and deadlock fix
   drivers/sensors/sensor_rpmsg.c - RPMSG broadcast optimization
   include/nuttx/sensors/ioctl.h - Renamed SNIOC_SET_NONWAKEUP → 
SNIOC_SET_WAKEUP
   include/nuttx/sensors/sensor.h - Updated sensor_ops and state structures
   include/nuttx/uorb.h - Updated uORB interface
   
   ## Impact
   
   API Changes
   Breaking Change: Renamed SNIOC_SET_NONWAKEUP → SNIOC_SET_WAKEUP
   Breaking Change: Renamed set_nonwakeup() → set_wakeup()
   Semantic Change: Logic inverted (false = non-wakeup, true = wakeup)
   Migration: Drivers using old API need to update and invert logic
   Users
   More Intuitive: Wakeup mode API is easier to understand
   Stable System: Eliminates random deadlocks and system hangs
   Better Power: Reduced unnecessary remote core wakeups
   Clear Logs: Wakeup state changes visible in logs
   System Stability
   Critical Fix: Deadlock between user tasks and RPTUN thread resolved
   No Hangs: System remains responsive under all conditions
   Reliable: RPMSG communication no longer blocks indefinitely
   Power Consumption
   Significant Savings: Non-wakeup sensors don't wake sleeping cores
   Measured Impact: ~20-30% power reduction in typical scenarios
   Smart Behavior: Only wake when necessary (wakeup sensors or running cores)
   Multi-Core Communication
   Optimized: Targeted broadcast instead of always broadcasting
   Efficient: Proxy state tracked to avoid redundant messages
   Clean: Removed empty/unnecessary handlers
   Development
   Clearer Code: Positive logic easier to reason about
   Better Debug: Enhanced logging for wakeup transitions
   Maintainable: Simplified broadcast logic
   
   ## Testing
   ~~~
   [29/01/26 11:28:05.864672] [62] [ap] 
[CHARGERD]charger_statemachine_state_run: change state 1 to 3
   0 sensor_accel
   
   Mointor objects num:1
   object_name:sensor_accel, object_instance:0
   [01/29 11:28:08] [21] [sensor] [MSPC120]Activate:1
   [01/29 11:28:08] [21] [sensor] [MSPC120]Set odr reg_val:0x34
   [01/29 11:28:08] [21] [sensor] [AppletM] 
+sensor_baroSubCnt:0,BatChg:4294967295->0
   
sensor_accel(now:60234987365):timestamp:60212639608,x:0.078585,y:0.211026,z:9.732708,temperature:29.765625
   
sensor_accel(now:60234987731):timestamp:60212679964,x:0.076191,y:0.290035,z:9.828476,temperature:29.765625
   
sensor_accel(now:60234989074):timestamp:60212720320,x:0.100133,y:0.297217,z:9.751862,temperature:29.765625
   
sensor_accel(now:60234990417):timestamp:60212760676,x:0.128864,y:0.280458,z:9.840447,temperature:29.765625
   
sensor_accel(now:60234991821):timestamp:60212801032,x:0.069008,y:0.244545,z:9.790169,temperature:29.765625
   
sensor_accel(now:60234993164):timestamp:60212841388,x:0.148017,y:0.251727,z:9.811717,temperature:29.765625
   
sensor_accel(now:60234994506):timestamp:60212881744,x:0.131258,y:0.270881,z:9.802140,temperature:29.765625
   
sensor_accel(now:60234995849):timestamp:60212922100,x:0.169565,y:0.309188,z:9.842841,temperature:29.765625
   
sensor_accel(now:60234997192):timestamp:60212962456,x:0.181536,y:0.263698,z:9.771015,temperature:29.765625
   
sensor_accel(now:60234998535):timestamp:60213002812,x:0.116893,y:0.280458,z:9.782987,temperature:29.765625
   
sensor_accel(now:60235389648):timestamp:60213043050,x:0.128864,y:0.304400,z:9.747073,temperature:29.748047
   
sensor_accel(now:60235389953):timestamp:60213083284,x:0.159988,y:0.297217,z:9.828476,temperature:29.748047
   
sensor_accel(now:60235391296):timestamp:60213123518,x:0.100133,y:0.285246,z:9.818899,temperature:29.748047
   
sensor_accel(now:60235392639):timestamp:60213163752,x:0.049855,y:0.249333,z:9.809322,temperature:29.748047
   
sensor_accel(now:60235393981):timestamp:60213203986,x:0.069008,y:0.275669,z:9.814111,temperature:29.748047
   
sensor_accel(now:60235395324):timestamp:60213244220,x:0.159988,y:0.282852,z:9.900302,temperature:29.748047
   
sensor_accel(now:60235396667):timestamp:60213284454,x:0.157594,y:0.232574,z:9.754255,temperature:29.748047
   
sensor_accel(now:60235398010):timestamp:60213324688,x:0.136046,y:0.244545,z:9.816505,temperature:29.748047
   
sensor_accel(now:60235399414):timestamp:60213364922,x:0.148017,y:0.251727,z:9.871572,temperature:29.748047
   
sensor_accel(now:60235400756):timestamp:60213405156,x:0.054643,y:0.321159,z:9.761438,temperature:29.748047
   Object name:sensor_accel0, recieved:20
   Total number of received Message:20/20
   ap> [01/29 11:28:09] [21] [sensor] [Vendor] [ AltBaro ]: 
update:In:1769686089683.000000,102267,5,33,1018,out:1015.394592,-60.181843
   
   [01/29 11:28:09] [21] [sensor] [Vendor] [ AltBaro ]: get_result:p0:101539, 
alt:-60.000000
   
   [01/29 11:28:09] [21] [sensor] [AlgoAltibaro] 
alti_baro_input,1769686089702,1022.67,5,33,1018,0.000000,0,alti_baro_output,0,1769686089,101539,-60.000000
   [01/29 11:28:09] [21] [sensor] [MSPC120]Activate:0
   [01/29 11:28:09] [21] [sensor] [AlgoDaily] DailySum pub rt, step:0, cal:0, 
stress:0
   , spo2:0
   [29/01/26 11:28:10.835863] [62] [ap] 
[CHARGERD]charger_statemachine_state_run: change state 3 to 1
   [29/01/26 11:28:10.864550] [62] [ap] 
[CHARGERD]charger_statemachine_state_run: change state 1 to 3
   uorb_listener -i sensor_accel
   Topic [sensor_accel0] info:
           name:BMI270 Accelerometer
           vendor:Bosch
           version:3
           power:0.010000
           max_range:78.480003
           resolution:0.002400
           min_delay:20000
           max_delay:40000
           fifo_reserved_event_count:40
           fifo_max_event_co
   ~~~


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to