| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
run_test is called by the "runtest" console command. Console commands
can take arguments, so pass along the arguments to run_test to allow
parameters to be passed to run_test.
The following command was used for automatic replacement:
git grep --name-only 'void run_test(void)' |\
xargs sed -i 's#void run_test(void)#void run_test(int argc, char **argv)##'
BRANCH=none
BUG=b:155897971
TEST=make buildall -j
TEST=Build and flash flash_write_protect test
> runtest 1
Signed-off-by: Tom Hughes <tomhughes@chromium.org>
Change-Id: Ib20b955d5ec6b98f525c94c24aadefd7a6a320a5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2209418
Reviewed-by: Yicheng Li <yichengli@chromium.org>
Commit-Queue: Yicheng Li <yichengli@chromium.org>
Tested-by: Yicheng Li <yichengli@chromium.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently the motion sense loop bases its sleep time based on the
fastest active sensor. This method has several flaws:
1. It does not take into account any task switching overhead
2. With a mix of interrupt driven and forced sensors the sleep time gets
recalculated every time there is an interrupt causing the loop to
oversleep
3. If multiple sensors do not have rates that are in sync the timing of
the slower sensor will be off. For example if there was a sensor running
at 50 Hz and one running at 20 Hz the slower sensor would end up being
sampled at about 16 Hz instead of 20 Hz
This change calculates an ideal read time for every forced mode sensor
and calculates the sleep time based on the nearest read time. Every time
a sensor is read the next read time is calculated based on the ideal read
time not the actual read time so that reading does not drift because of
system load or other overhead.
BUG=b:129159505
TEST=Ran sensor CTS tests on arcada, without this change the
magnetometer was failing 50 Hz tests at about 38 Hz with 30% jitter
with this change in place 50 Hz was spot on with about 10% jitter
BRANCH=none
Change-Id: Ia4fccb083713b490518d45e7398eb3be3b957eae
Signed-off-by: Mathew King <mathewk@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1574786
Reviewed-by: Jett Rink <jettrink@chromium.org>
|
|
|
Use code from ash/wm/tablet_mode/tablet_mode_controller.cc, in
particular TabletModeController::HandleHingeRotation()
to calculate lid angle.
Add unit tests based on
ash/wm/tablet_mode/tablet_mode_controller_unittest.cc and the data file
accelerometer_test_data_literals.cc.
BUG=b:120346412
BRANCH=none
TEST=Check unit tests pass, check it compile on FPU based EC, EC without
FPU and no 64 bit support (ampton).
Check lid calculation is correct on eve:
- with "while true ; do ectool motionsense lid_angle ; sleep 1 ; done"
Check when hinge is almost vertical lid angle is close to constant or
marked are unrieliable.
Check when shaking device, lid angle is also unreliable
Check with evtest SW_TABLET_MODE event is trigger when lid angle is
available and cross 180 region.
Change-Id: I545f7333ed9b53accedb75f238f747f66bae1f5d
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1388844
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Jett Rink <jettrink@chromium.org>
|
