Change tap sequence so that it only gets the battery percentage
once. This means we won't dynamically change color and level if
the battery percentage changes mid sequence, but that's ok.
BUG=chrome-os-partner:45878
BRANCH=none
TEST=run tap sequence
Change-Id: I2183343b69d01f4835302e291a2e1a0a2c658b1e
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/302685
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Fix bug in get_battery_level() where we attempt to apply hysteresis
to the battery percentage when it jumps between levels. The problem
is if the battery jumps up multiple levels, then it won't always
update the battery level. For example, using level thresholds of
{14, 40, 99}, if you jump from 0% to 99%, it won't update the battery
level because it compares the new percentage, 99%, with the
battery threshold for the new level + 1 (100%).
BUG=chrome-os-partner:45878
BRANCH=smaug
TEST=use the battfake console command to jump from 5% to 99% and
verify that the lightbar goes from all red to google colors. note:
without this CL, the lightbar stays all red.
Change-Id: I5ae658c8c92469ebc7f516a04bda7b7fbcd32146
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/302684
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This moves battfake console command to the battery driver.
This fixes a race condition with using the 'battfake' command
where charge_state_v2 could return the real battery percentage
even when a faked percentage is specified, if a higher priority
task uses the battery state of charge in between when the
battery is read, and when the fake state of charge overwrites
the battery parameter.
BUG=chrome-os-partner:45878
BRANCH=none
TEST=use tap for battery with a faked state of charge. the tap
for battery queries the battery percentage a lot, so without
this CL, the tap sequence often temporarily jumps to different
percentages and colors. with this CL, the tap sequence works
great.
Change-Id: I3ae0866d1ff7bb8d0c51355cd6b958310766f19e
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/302711
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Set maximum input power to 45W, (20V at 2.25A)
BUG=chrome-os-partner:46149
BRANCH=none
TEST=load on glados, plug in zinger, make sure we request
20V, 2.25A, and that we set input current limit to 2250mA
Change-Id: If6d9eba19dc422ed704799e03bd05af5817efeb5
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/304082
Reviewed-by: Shawn N <shawnn@chromium.org>
According to MEC1322 datasheet, ADC VREF is 3V.
With the voltage divider on Kunimitsu, R1=180K and R2=20K,
so full ADC is equal to 30V if ADC VREF is 3V.
BUG=none
BRANCH=none
TEST=Checked value returned by adc console cmd.
20xxx mV is returned by Zinger.
14xxx mV is returned by Apple charger.
Change-Id: I155ce03e3c840740c1dc3a985a1d5cfcf3b40c30
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/304192
Reviewed-by: Shawn N <shawnn@chromium.org>
This patch updates the EC codebase to match the suggested USB build
(20151005_041713). The spiflash utility must come from the same
tarball.
BRANCH=none
BUG=none
TEST=as follows:
- programmed the FPGA, it now reports the following when reset:
BootRom 0.8.91hw
- booted the new image using the latest spiflash version.
- disconnected the FPGA upgrade port, rebooted the device, entered
on the device console:
> spstp off
> spste
run on the workstation:
$ examples/spiraw.py -l 10 -f 800000
FT232H Future Technology Devices International, Ltd initialized at 857142 hertz
and observe on the DUT console:
Processed 10 frames rx count 11604, tx count 5512, tx_empty 10, max rx batch 11
>
Change-Id: Iff778087149ae3e7570f8fd4d81c2857a4ea5367
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/304123
Reviewed-by: Marius Schilder <mschilder@chromium.org>
When the PD received status that the EC is going to hibernate, have the
PD go to hibernate. The wake pin will toggle from low (hibernate state)
to high (default state) when the EC leaves hibernate or resets.
BUG=chrome-os-partner:45010
TEST=Manual on glados with subsequent commit. Run 'hibernate' on EC
console, verify that both EC and PD go to hibernate. Plug zinger and
verify that both EC and PD wake, AP boots, and battery begins charging.
BRANCH=None
Change-Id: I653aea87480437da742b6e203858f194833db553
Reviewed-on: https://chromium-review.googlesource.com/302713
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
On some systems, we may wish to have the PD follow the EC into
hibernate. Add a status field to EC_CMD_PD_EXCHANGE_STATUS to support
this.
BUG=chrome-os-partner:45010
TEST=Manual on glados with subsequent commit. Run 'hibernate' on EC
console, verify that both EC and PD go to hibernate. Plug zinger and
verify that both EC and PD wake, AP boots, and battery begins charging.
BRANCH=None
Change-Id: I0476bc8a47ffb0fe113dccda9d4f8074105c1c84
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/302712
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Export the board version through the usual EC_CMD_GET_BOARD_VERSION.
Add an option to use the board-specific board_get_version() callback
rather than doing the generic GPIO binary decoding since here the
version is ternary encoded.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=smaug
BUG=none
TEST=execute 'ectool boardversion' on the AP and see the right number.
Change-Id: I89c328573d09be02232756797ba3fdd5979b0292
Reviewed-on: https://chromium-review.googlesource.com/303368
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
(cherry picked from commit 6c620c51e5ab812b4e6751e4c630da2e6bee4b74)
Reviewed-on: https://chromium-review.googlesource.com/303803
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Add a build option CONFIG_BATTERY_CRITICAL_SHUTDOWN_CUT_OFF to perform a
battery cut-off when we reach the battery critical low level.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=smaug
BUG=none
TEST=Discharge a Ryu device down to the critical level, see the message
and verify we cannot restart with the power button. Also check that
plugging the charger revives the device and starts charging.
Change-Id: Ic132a658de5c5131a6a1dd1ce343196b68d480f6
Reviewed-on: https://chromium-review.googlesource.com/303549
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
(cherry picked from commit 80b3c99319771312d5733b126b6b3eb839addde9)
Reviewed-on: https://chromium-review.googlesource.com/303812
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Added code to enable the system power monitoring functionality to get the
details of the system power consumption.
And also added EC console command "psys" to get the system power consumption.
BUG=none
TEST=Manually tested on Kunimitsu.
Power = Voltage * Current, reading is equal to the power readings
from the psys command.
BRANCH=none
Change-Id: I62519ac96800363b67cab23cd9eb0dcac229cb47
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/302472
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
When building with -j, it's easy to miss errors. If you don't
have your shell configured to warn you about nonzero exit, you
may not even notice that "make buildall -j" failed. To make it
more obvious, we'll do one level of recursion for that target.
That will ensure that the last line of output is always a
pass/fail message.
BUG=none
BRANCH=none
TEST=make buildall -j (with and without errors)
Before this CL, a successful "make buildall -j" ends with this:
MV ec.bin
OBJCOPY ec.hex
LD RW/ec.RW.elf
NM RO/ec.RO.smap
OBJCOPY RO/ec.RO.flat
NM RW/ec.RW.smap
OBJCOPY RW/ec.RW.flat
CAT ec.obj
OBJCOPY ec.bin
COPY_RW ec.bin
MV ec.bin
buildall completed successfully!
(cr) ((fa7baa6...)) ~/trunk/src/platform/ec $
while a failing one looks like this:
MV ec.bin
OBJCOPY ec.hex
LD RW/ec.RW.elf
NM RO/ec.RO.smap
OBJCOPY RO/ec.RO.flat
NM RW/ec.RW.smap
OBJCOPY RW/ec.RW.flat
CAT ec.obj
OBJCOPY ec.bin
COPY_RW ec.bin
MV ec.bin
(cr) ((fa7baa6...)) ~/trunk/src/platform/ec $
Did you see the difference? I suspect some people miss it.
With this CL, a failing "make buildall -j" looks like this:
NM RW/ec.RW.smap
OBJCOPY RW/ec.RW.flat
CAT ec.obj
OBJCOPY ec.bin
NM RW/chip/mec1322/lfw/ec_lfw-lfw.smap
OBJCOPY RW/chip/mec1322/lfw/ec_lfw-lfw.flat
COPY_RW ec.bin
MV ec.bin
COPY_RW ec.bin
MV ec.bin
OBJCOPY ec.bin
COPY_RW ec.bin
MV ec.bin
make[1]: Leaving directory '/mnt/host/source/src/platform/ec'
Makefile.rules:93: recipe for target 'buildall' failed
make: *** [buildall] Error 2
(cr) (stopit) ~/trunk/src/platform/ec $
Change-Id: Id9b47d2869f61e8e3e44b3c618399ca9223f0a71
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/303811
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
[chip config]
1. No hardware specific udelay().
2. Enable watchdog.
[watchdog]
3. Watchdog period is "CONFIG_WATCHDOG_PERIOD_MS" of config.h.
4. Watchdog auxiliary timer period is "CONFIG_AUX_TIMER_PERIOD_MS".
[task and irq]
5. Write 1 to clear interrupt pending status, no |.
6. A global variable for store interrupt number of software interrupt.
[uart]
7. Always reset UART module before config it.
[hwtimer]
8. Use more external timers for HW timer module.
[task]
9. Fix task profiling.
Signed-off-by: Dino Li <dino.li@ite.com.tw>
BRANCH=none
BUG=none
TEST=[watchdog]
1. console "waitms 1100", only pre-watchdog warning message.
2. console "waitms 1600", warning message and watchdog reset.
[hwtimer]
3. console commands "gettime", "timerinfo", and "forcetime".
4. enable hook debug and there is no delayed by more than 10%
warning message over 48 hours.
5. There is no watchdog reset too.
[task]
6. console 'taskinfo'
Task Ready Name Events Time (s) StkUsed
0 R << idle >> 00000000 32.927724 308/512
1 HOOKS 00000000 0.034267 372/768
2 R CONSOLE 00000000 0.116763 468/768
3 HOSTCMD 00000000 0.000641 372/512
4 KEYPROTO 00000000 0.000042 212/512
5 KEYSCAN 00000000 0.000908 356/512
IRQ counts by type:
38 2932
155 1
158 261
160 67
Service calls: 87
Total exceptions: 3348
Task switches: 167
Task switching started: 0.001999 s
Time in tasks: 33.282819 s
Time in exceptions: 0.164717 s
Change-Id: I234085cec231cd855d2a5e639ea1b0966c61d796
Reviewed-on: https://chromium-review.googlesource.com/296939
Commit-Ready: Dino Li <dino.li@ite.com.tw>
Tested-by: Dino Li <dino.li@ite.com.tw>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
According to the stm32 databook, we cannot enter deep sleep when an i2c
slave interface is addressed until it sees a stop condition.
BUG=chrome-os-partner:45010
TEST=Enable deep sleep on glados_pd, verify that the PD state machine
doesn't toggle between disconnect and debounce (no console spam)
BRANCH=None
Change-Id: I2016c30bccec916d1c22df93303acf50331bd318
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/303404
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Modified drivers:
1. register.h: Add marco field operation funcs for muti-bits field of register.
2. adc.c/fan.c/pwm.c: Simplify field operations by marco funcs.
3. adc.c: Add support for ADC_CH3/4
4. pwm.c: Add PWM_CONFIG_DSLEEP_CLK flag
6. fan.c: Support multi-fans mechanism
BUG=chrome-os-partner:34346
TEST=make buildall -j; test nuvoton IC specific drivers
BRANCH=none
Change-Id: Iaaeb6c4ae8d55b4245a1cefb9c20feae4c0fdec2
Reviewed-on: https://chromium-review.googlesource.com/300673
Commit-Ready: Mulin Chao <mlchao@nuvoton.com>
Tested-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When a PD charger is found, we typically update charge manager
voltage / current limits to what we want to request, set a 500mA ceiling,
and then wait for negoiation to complete. If it completes as expected,
we simply remove the 500mA ceiling.
When we're already negotiated with a port and we receive a new power
request, we may switch to a different voltage / current limit. If we do
so, charge manager won't get updated with the existing design because we
don't get new source cap information. Therefore, update charge manager
whenever we receive PD_CTRL_PS_RDY as a sink. Typically, the update will
have no effect because we'll be writing identical values. In the new
power request case though it will serve to inform charge manager of the
new mode.
BUG=chrome-os-partner:45932
TEST=Manual on ryu. Insert zinger, run `pd 0 dev 5` followed by `bq` to
verify 3A limit is set as expected.
BRANCH=ryu
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I8cc3ac0a3eb603cdeb45ea437906303abcaedac0
Reviewed-on: https://chromium-review.googlesource.com/302844
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
cl:302176 did not fully fix the issue:
- sampling rate would be unnecessary truncated to integer.
- Because the sensor can slightly oversample (15Hz -> 25Hz, 10Hz ->
12.5Hz), we would skip samples for long period of time.
In both cases we skip samples in low speed tests, noticed by CTS tests.
BUG=b:24367625
BRANCH=smaug
TEST=Before we would fail some
android.hardware.cts.SingleSensorTests#testMagneticField_X,
Now pass.
Change-Id: Ic555e2add47ba89a0a0657f5eb492a5e7ca441d5
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/303010
Reviewed-by: Alec Berg <alecaberg@chromium.org>
This patch brings in the enhanced signer utility published along with
FPGA version 20150925_21715, and the image.cc file updated to fix the
bug where it was not picking up the initialized data segment from the
elf file.
The new signed image header format, among other things, describes
memory areas as read-only and read-execute, which allows the bootrom
to configure the MMU appropriately.
Makefiles had to be modified to reflect the fact that the signed image
now depends on .elf, not on .raw, and that building the signer
requires more source files. Note that some signer features are not yet
being utilized (like processing xml files describing fuses or
retrieving keys from gnubby), the source are kept for completeness.
BRANCH=none
BUG=chrome-os-partner:43791
TEST=build the cr50 image and boot in on the FPGA board using the
spiflash utility outside chroot. Observe the target starting the
console session.
Change-Id: Ib59b8ebbeb98a8146d4d997e1f78178c4fbc031a
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/303070
Commit-Ready: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
This patch upgrades the hardware definition to the latest released
FPGA image, which is reported as follows:
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
m3.0.0> info
IDCODE: 2ba01477
DPCTRL: f0000000
m3.0.0> Note: MD5Sums match: 77e8a79e
m3.0.0> Note: CPU0 halted at @ a76
m3debug serial: 0x0
PROJECT: haven revB1
DATE(yyyymmdd): 20150925
TIME(hhmmss): 21715
XML MD5SUM: 0x77e8a79e
HDR MD5SUM: 0xfd9218ab
P4 last CL: 73753
Xml file name include/havenTop.xml
m3.0.0>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This latest FPGA image includes a more sophisticated bootrom,
requiring a differently signed firmware image. The signer update is in
the next patch.
BRANCH=none
BUG=chrome-os-partner:43791
TEST=verified that the image boots fine when signed by the updated
signer (which comes in the next patch).
Change-Id: I9a5d8e9e786dfa905619f1c629fe75b82c565490
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/302803
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
After fixes CL:300630, motion_lid test is fixed:
motion_sense task was exiting during the tests.
BRANCH=smaug
BUG=chrome-os-partner:42855
TEST=motion_lid test now pass.
Change-Id: I7bc464fb2766684093de9b3e479fb5ac3718df04
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/302861
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Some sensors are in forced mode, motion sense must be scheduled at
their ODR. However the host may not want the data right away,
so motion task may not wake up the host that often.
Add a new variable motion_int_interval that defines the maximum interval
between FIFO host event.
BRANCH=smaug
BUG=chrome-os-partner:43800
TEST=Check that light sensor is polled at ODR frequency.
Check that when AP does not want any event, no FIFO host event are
requested.
Check CTS tests work as before.
Reenable motion_lid unit test.
Change-Id: Ie25e6cbe28fed899073856057855ffa03c0cd9fd
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/301134
Reviewed-by: Alec Berg <alecaberg@chromium.org>
When flashrom performs a flash read following an erase and we do not
wait in between for the erase to complete, we read 0x00 instead of
0xFF. Flashrom detects this and does not proceed further. Inserting
a wait after erase solves this issue.
Also added a wait following a flash write operation to preempt future
issues, and moved spi_flash_wait() calls from Host Command APIs to
lower level spi_flash_* functions.
BUG=chrome-os-partner:43160
BRANCH=none
TEST=Manually tested on Kunimitsu FAB3.
flashrom -p ec -w ec.bin is successful
Signed-off-by: Shamile Khan <shamile.khan@intel.com>
Change-Id: I00925aa2da3709a6f3e73a40543b079112906e0a
Signed-off-by: Shamile Khan <shamile.khan@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/302683
Reviewed-by: Shawn N <shawnn@chromium.org>
Fix bug where sometimes on suspend tap for battery would never work,
but open a resume and suspend again it would work fine. Problem is
that if suspended when accel circular buffer index is 1, then
we would never run the detection algorithm, because the check for
if the history buffer has been initialized is incorrect.
This also fixes the algorithm so that on suspend, it requires the
full sensor history buffer be filled up again before starting to
detect the double tap.
BUG=chrome-os-partner:45930
BRANCH=samus
TEST=go in to suspend when history_index is 1 and verify that tap
for battery works. wrote following console command to pause the
circular buffer at a specific index.
static int pause_index = -1;
static int check_pause;
static void gesture_chipset_resume(void)
{
/* disable tap detection */
check_pause = 1;
}
DECLARE_HOOK(HOOK_CHIPSET_RESUME, gesture_chipset_resume,
GESTURE_HOOK_PRIO);
void gesture_calc(void)
{
if (check_pause) {
if (pause_index < 0 || history_idx == pause_index) {
ccprintf("Paused at %d\n", pause_index);
tap_detection = 0;
pause_index = -1;
check_pause = 0;
}
}
...
static int command_tap_pause(int argc, char **argv)
{
char *e;
int v;
if (argc == 2) {
v = strtoi(argv[1], &e, 0);
if (*e)
return EC_ERROR_PARAM1;
pause_index = v;
}
return EC_SUCCESS;
}
DECLARE_CONSOLE_COMMAND(tappause, command_tap_pause,
"",
"", NULL);
Change-Id: I2ba4ab2c807ec6ac1885a4829efedac3c83b32f1
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/302648
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
RAM need not be preserved between jumps from the loader to RO/RW images,
so there is no need for a separate region of loader RAM. Remove
redundant CONFIGs which define this unneeded region.
BUG=None
TEST=Verify glados boots and sysjumps successfully.
BRANCH=None
Change-Id: I2567f17a973c6f9f00bcfd97a4581d6c4b6fd6f0
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/302586
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Increase the change of false positive, but make double feels like Samus:
- increase time beetwen tap to 500ms
- decrease tap threshold to 100mg (actually 62.5mg)
- increase ODR during TAP.
BRANCH=smaug
BUG=b:24440423
TEST=check Ryu and Samus side by side, their tap behavior is more
similar.
run cts -c android.hardware.cts.SingleSensorTests
Change-Id: I260ad95136cb2be71ef4d71efc4bee0b28afa8e0
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/302627
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Sandwich wake up event between timestamp.
Otherwise HAL will think the event came from a long time ago.
With two timestamp, the wake event timestamp will be - more - accurantly
set at the time it occurs.
BRANCH=smaug
BUG=chrome-os-partner:45704
TEST=Pass com.android.cts.verifier.sensors.SignificantMotionTestActivity
Change-Id: I6be76820d71d2571d069542564f569a623001190
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/302642
Reviewed-by: Alec Berg <alecaberg@chromium.org>
cl/296213 had another bug that prevent Significant motion gesture to be
set: In set_activity, activity is a number, not a bitfield.
BRANCH=smaug
BUG=chrome-os-partner:45704
TEST=With ectool motionsense set_activity and list_activity,
check we can set/reset the significant motion activity.
Change-Id: Iff921f3f5edcee74ed3540139f13da301f149173
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/302641
Reviewed-by: Alec Berg <alecaberg@chromium.org>
cl:298688 was wrong and oversampling calculation, used to drop
events that AP does not want was incorrect.
We were comparing mHz with Hz.
BUG=b:24367625
BRANCH=smaug
TEST=Before, we would fail all
android.hardware.cts.SingleSensorTests#testAccelerometer tests where
frequency was lower than 100Hz. After, we pass thoses tests.
Change-Id: I487feb4e235a21f78d367397b5890ebcc5864b22
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/302176
Reviewed-by: Alec Berg <alecaberg@chromium.org>
This commit adds the "hibdelay" command which will set the time before
the EC hibernates.
BUG=chrome-os-partner:45608
BUG=chrome-os-partner:44831
BRANCH=None
TEST=Build and flash samus EC with hibernation delay host command
added. Use ectool to set the hibernation delay and verify that the
hibernation delay was changed.
CQ-DEPEND=302197
Change-Id: I91141ee48a648c1052f0a3930a810ea4f551e0a4
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/302198
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
gpio_config_module() and gpio_config_pins() had very similar code. This
commit moves the functionality of gpio_config_module into
gpio_config_pins. That is, gpio_config_pins() can now configure an
entire module. This is accomplished by passing in GPIO_CONFIG_ALL_PORTS
as the port parameter.
BUG=chromium:533539
BRANCH=None
TEST=Build and flash on samus. Verify that lightbar, charging, power
button, sensors, all functional.
TEST=make -j buildall tests
Change-Id: I7c9122ebf7b0e2716af2d55b842c4806d8099a63
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/302479
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Currently, the only way to prevent a system from hibernating is via the
EC console command "hibdelay". This commit adds the host command
equivalent so that it can be set elsewhere. The host command takes the
amount of time in seconds to delay hibernation by and responds with the
current time in the G3 power state, the time remaining before
hibernation should be invoked, and the current setting of the
hibernation delay.
BUG=chrome-os-partner:45608
BUG=chrome-os-partner:44831
BRANCH=None
TEST=Build and flash on samus. Issue the host command from EC
console. Verify that the hibernation delay was updated by checking with
the hibdelay command.
Change-Id: I34725516507995c3c0337d5d64736d21a472866c
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/302197
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
For signed EC RW images (CONFIG_RWSIG), there's no point in
embedding the public key or signature into the image itself since
it will just be replaced by the signer (either as the next step
in the build process, or after the fact for MP releases). This
takes that out and just points to where the pubkey and signature
will be placed.
BUG=none
BRANCH=none
TEST=make buildall
I also checked the signatures with
futility show -t build/*/ec.bin
They still look good, and the one signed image I booted (Cr50)
works as before.
Change-Id: Ib39b7c508914851f81a1bebb2450e08ef0def76c
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/302630
Reviewed-by: Randall Spangler <rspangler@chromium.org>
1. No need for loader data ram
2. 97K code size
3. shifting down RO/RW image location in RAM by 1Kbyte.
(loader code space: 4k to 3k)
BUG=none
TEST=1. build image with big code additions.(like low power idle patch)
and check if there is flash size related error message.
2. check if EC's RO image can boot from loader.
3. use EC console command, "sysjump RO/RW" and check if it works.
4. Verified in Cyan and Kunimitsu.
BRANCH=none
Change-Id: Ie4daf44cdba944e3e58894ca80183fcdb0fdbc7c
Signed-off-by: Kyoung Kim <kyoung.il.kim@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/302149
Commit-Ready: Kyoung Il Kim <kyoung.il.kim@intel.com>
Tested-by: Kyoung Il Kim <kyoung.il.kim@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
This makes sure to clear all segments before turning on lightbar
for tap for battery. Without this, the previous colors are stored
and flash briefly before starting the tap for battery pattern.
BUG=chrome-os-partner:45835
BRANCH=smaug
TEST=tested on ryu. go to s5, type 'lightbar seq tap' and see that
the tap sequence starts without first blinking google colors.
note that this doesn't affect samus because for samus in s5, the
lightbar is not powered, so when we do tap for battery, we first
power the lightbar and the registers are cleared.
Change-Id: Ic7ae8c580005e786ba35656d8feeedac56e35cfd
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/302147
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
(cherry picked from commit 962d0b2595b1dbb5ef162b7e6b4db7ce8a65e6c5)
Reviewed-on: https://chromium-review.googlesource.com/302447
