mirror of
https://github.com/Telecominfraproject/OpenCellular.git
synced 2025-12-31 11:01:19 +00:00
266b36d54b
If there's a task switching occurred between loading waiter and unlocking the lock, the task with higher priority won't wake up since the local variable, waiter, doesn't contain its ID bit before task switching. In this situation, the higher priority task only can be awakened when the other tasks execute mutex_unlock() again. But consider the following conditions: (For example, the driver of charger bd9995x.) 1. There are more than one mutex for the usage path of i2c port. 2. There are more than one task access this usage path of i2c port and one of these tasks, task A, met the situation above. 3. The other tasks have no chance to execute mutex_unlock() of i2c since the task A still occupied the mutex of charger. All the tasks used the same i2c port or the other hardware will sleep forever. This CL makes loading waiter and unlocking the lock as atomic to solve this issue. BRANCH=none BUG=chrome-os-partner:60617 TEST=make BOARD=snappy; make BOARD=oak; Executed charger factory test on 4 units of snappy for 3 days and no symptom occurred. Change-Id: Id976fc47955b33ca83bb2182b197d9f2781c341b Signed-off-by: Mulin Chao <mlchao@nuvoton.com> Reviewed-on: https://chromium-review.googlesource.com/423285 Commit-Ready: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
For an overview of the Embedded Controller firmware, refer to http://www.chromium.org/chromium-os/2014-firmware-summit For instructions on building from source, refer to http://www.chromium.org/chromium-os/ec-development/getting-started-building-ec-images-quickly