This replaces the obsolete and temporary (ha!) EC_CMD_CHARGE_DUMP host
command with EC_CMD_CHARGE_STATE. This is used to monitor and adjust the new
charge state implementation, including any board-specific customizations.
This command is a single catch-all command with multiple subcommands
(similar to EC_CMD_LIGHTBAR_CMD) so that we don't have to keep adding new
top-level host commands just to support incremental changes.
BUG=chrome-os-partner:23776
BRANCH=ToT
TEST=manual
From the AP, try these commands:
ectool chargestate show
ectool chargestate param
ectool chargestate param <NUM>
ectool chargestate param <NUM> <VALUE>
Watch the EC console and use its "chg" command to verify the effects of
setting various params.
Note: the Samus-specific fast-charging profile override is param 0x10000.
You can check it with the EC console "fastcharge" command.
Change-Id: Iad2f773a085bc25c05073b3eed9866f122ae9d78
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193305
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Sometimes the battery happily reports that it's current temperature is
6280C, which is just a little bit high. This just treats unreasonably high
temperatures as an error.
BUG=chrome-os-partner:27527
BRANCH=ToT
TEST=manual
Make the change, watch the EC console while the AP is running and the
battery charges and discharges. The problem is intermittent, but when it
occurs it shuts the AP down immediately. With this change, it just prints a
warning instead.
I've also added a check for this to test/sbs_charging_v2.c
Change-Id: Ibfa53cf0244499ec52d4887bcd06fb9126c07a6c
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193277
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If the host somehow fails to see an edge on the keyboard IRQ line, it
won't read the 8042 data register. The EC won't ever send another
IRQ, because it only does so after filling the register. So the
keyboard will hang.
Work around this with a retry mechanism. If the AP hasn't responded
after 3 additional keyboard events, generate another IRQ. So a stuck
key will get unstuck if you tap it a few times. That's reasonable,
and matches what people do already if they have a sticky key due to
crud accumulating in the keyboard.
I've tested this when the system is booted to the OS. I don't see any
additional IRQs generated on the EC console ("KB extra IRQ"), so the
host is keeping up with the keyboard input stream.
If I'm in dev or recovery mode and bang on the keyboard right after
powering the system on (when the BIOS isn't yet paying attention to
the keyboard), I can see extra IRQs generated. This shows the retry
mechanism is working. The extra IRQs have no negative effect on the
boot process, and the keyboard works normally when the OS does
eventually boot.
BUG=chrome-os-partner:27222
BRANCH=rambi
TEST=Bang on the keyboard like a monkey. Keyboard should still work.
Change-Id: Idd41b2d133267f48f959bca0cf062a18ca6551fb
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193272
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
To help i8042 debug, add a new "8042" command. It also integrates
other 8042-related command in one place to dump all 8042 state.
Also few fixes to re-format the output.
BUG=none
BRANCH=none
TEST=Buidl and tested on squawks
Change-Id: I23d0522aa9d32b38efc864cb97217852a5ad1ea0
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193123
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Instead of printing "problem 2", print "problem 2 (set current)".
BUG=none
BRANCH=ToT
TEST=manual
Let the battery charge, watch the EC console for problems. Observe the new
messages.
Change-Id: I787c2fba4630421cdbd02050e96d8203b0268b3f
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/192873
Reviewed-by: Randall Spangler <rspangler@chromium.org>
I've filed several new bugs for things that need doing to
common/charge_state_v2.c.
This just adds those bug numbers to the comments.
BUG=none
BRANCH=ToT
TEST=make buildall
No new functionality; changes to comments only.
Change-Id: I980d743e2bcad81e469a4dd99b542b7cf223ef60
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/192882
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This is a complete rewrite of the charge_state task used by x86 platforms.
Rather than having a bunch of state-specific functions, each with their own
error handling and special cases, this is organized like so:
Forever:
1. Read everything we can from the battery and charger.
2. Figure out what we'd like to do (including error handling).
3. Allow for customization to override that.
4. Do it.
Things I need to file bugs for are marked with "TODO(wfrichar)". I'll file
the bugs after this CL goes in, so that they'll have something relevant to
refer to.
BUG=chrome-os-partner:20881
BRANCH=ToT
TEST=manual
make buildall -j
Try it on Samus, watch it charge from nearly empty to full, both with and
without fastcharge enabled.
Also undefine CONFIG_BATTERY_PRESENT_CUSTOM, plug and unplug the battery to
be sure the trickle charging logic is correct when it can't tell if the
battery is present.
Change-Id: I3935cd3b87f322eb52178f8a675a886c16b75d58
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/191767
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This ensures that modules with default priority (or later) get
an accurate response from extpower_is_present().
BUG=chrome-os-partner:27160
BRANCH=ToT
TEST=Add a default priority initializer. Verify it gets the correct
value for extpower_is_present() with and without external power
connected.
static void extpower_init_check(void)
{
CPRINTF("[%T Extpower %s]\n", extpower_is_present() ? "on" : "off");
}
DECLARE_HOOK(HOOK_INIT, extpower_init_check, HOOK_PRIO_DEFAULT);
Change-Id: Ic47c79d3ab4e7b2fdb6ad2354e4f455697cac250
Original-Change-Id: I13edc32b2a4609fad12982fd710fa95f9e81c9c2
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/191296
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/192137
Update the AC status immediately in the AC_CHANGE_HOOK handler
so the memmory-mapped value shared with the host is correct
prior to the host receiving an "AC changed" ACPI notification.
BUG=chromium:349681
BRANCH=ToT
TEST=Plug/unplug AC power. Verify that the host 'ACEX' bit is
set prior to it receiving ACPI event 4 (or cleared before
ACPI event 5). See crbug.com/349681#c12
Change-Id: I5c84e05b6886c5da9e8504cb803c80c3ec7c23fb
Original-Change-Id: I1496efe1cfac9995e88bf9d84414ee903886d9ed
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/190345
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/192136
BUG=chrome-os-partner:26838
BRANCH=ToT
TEST=Verify only one ACPI 4 event is generated
when attaching external power and that only one
ACPI 5 event is generated when removing external
power. (using the ec console)
Change-Id: I7f8efa03a18bda39152abc2326f1cda928355868
Original-Change-Id: Icaec298bd0f41708260117c26f83fe9158a7ad4e
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/189930
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/192135
This returns all the parameters of the charger that must be monitored
frequently. While some of the fields are charger-specific, all of the
parameters are present in all supported chargers.
Nothing uses this yet.
BUG=chrome-os-partner:20881
BRANCH=ToT
TEST=make buildall -j
All targets build; all tests pass.
Change-Id: Id3e00532469b193aeab3acf93e94afe3ffb8c6b6
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/191985
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This adds two battery parameters that need to be monitored constantly:
remaining_capacity and full_capacity (that one only changes occasionally,
but we have to notify the AP when it does).
It also adds the is_present field to indicate whether the battery is
physically present or not (when we can tell), so we know whether to try to
wake up a deep-discharged battery.
Along with that, we clean up the error flags to provide indication of which
fields were unable to be read, and replace the manual logical-or of all
errors as they were set with a bitmask (BATT_FLAG_BAD_ANY).
No functionality is changed, only new & better information is provided for
use in the upcoming cleanup of the charge state machine.
BUG=chrome-os-partner:20881
BRANCH=ToT
TEST=make buildall -j
All targets build; all tests pass.
Change-Id: I4312c2fdd3cf2dd9570718e90571eff796b269db
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/191917
Reviewed-by: Randall Spangler <rspangler@chromium.org>
In most cases we can't actually know whether a battery is present until
we've been able to talk to it. This adds that NOT_SURE case.
BUG=none
BRANCH=ToT
TEST=none
Nothing uses this case yet, and the only time that battery_is_present() is
called is when we have hardware to detect the battery (which always returns
YES or NO). This is just preparation for charge_state_v2, which will need
the NOT_SURE case for trickle charging.
Change-Id: Ic5793de080529d50c98860450a021a1abae168db
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/191782
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This adds explanations for all the error codes in enum ec_error_list, so
that console commands that fail can print the reason.
BUG=none
BRANCH=ToT
TEST=none
I can't find any console commands that return errors without explanations,
but I'm planning to add some. This is just preparation.
Change-Id: I26a730acb60a73c269c39ae2f24273b7e9920cec
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/191781
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Added ability to disable the keyboard to wake from suspend when the lid
is outside a certain angle range. This has been added to glimmer by
defining CONFIG_LID_ANGLE_KEY_SCAN in its board.h.
Also modified the lid angle calculation to include a reliability
flag which can be used to tell when the hinge aligns too closely
with gravity and the lid angle value is unreliable.
BUG=none
BRANCH=rambi
TEST=Tested on a glimmer:
In S3, verified that when the lid is open past ~180 deg, the keyboard
does not wake the machine. Also verified that if you align hinge with
gravity, the keyboard enabled/disabled status remains the same (since
we can't actually trust the lid angle value).
Change-Id: I45b2c7c3c4bbcae61d3a0f8b5baa461ab8dabfb0
Original-Change-Id: If1a1592d259902d38941936961854b81b3a75b95
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/190061
Reviewed-on: https://chromium-review.googlesource.com/191612
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Adding in support for accelerometer interrupt for use currently
in clapper and glimmer. This is disabled by default and can
be enabled with CONFIG_ACCEL_INTERRUPTS.
BUG=none
BRANCH=rambi
TEST=Manual test on a glimmer using accelint console command.
On console enter:
accelint 0 32
When you tap the lid, it should fire the interrupt and print msg
to console.
accelint 1 32
Tap the base and it will fire another interrupt.
Change-Id: Iaab324945e34d527140399ec4f06efd812a62840
Original-Change-Id: I0329112fdcae3c8adc0ca07e74fef7a591d4b9a1
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/190099
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/191549
The accelerometer calibration routine came up with the wrong
sign for the z-axis. Fixed that bug and flipped the sign for
glimmer in the standard reference frame rotation matrix.
BUG=none
BRANCH=rambi
TEST=Tested on a glimmer. Ran calibration routine and then
verified that if the unit is sitting flat on a table with lid
open to 90, the accelometer data send to host should read:
base = 0, 0, 1024
lid = -1024, 0, 0
When the laptop is closed and flipped over, the data should
read:
base = 0, 0, -1024
lid = 0, 0, -1024
Change-Id: I1e8bcda26c16496d9cb49dece12db0c4ea929ece
Original-Change-Id: If3bb7a095e400f5a247fab64b0050a44f4947e6c
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/190400
Reviewed-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/191579
Reviewed-by: Randall Spangler <rspangler@chromium.org>
in non-S0 states when work with DPTF.
If user sleeps/shutdown system when on battery(or when TCHG is throttled),
system will never charge while in S3 or S5.
BUG=chrome-os-partner:355015
BRANCH=rambi
TEST=with the same test system will charge in S3 or S5.
Change-Id: Idc68b2f533da0a55ad07d0ff8e3e5294c1e2143c
Signed-off-by: Kein Yuan <kein.yuan@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/191153
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
In order to achieve really tiny firmwares, make our runtime (tasks,
hooks, muxed timers, GPIO abstraction ...) optional.
Add 2 new build options for it : CONFIG_COMMON_RUNTIME and
CONFIG_COMMON_GPIO which are enabled by default, and ensure all the
source files are built according to the right configuration variable.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=make buildall
build a minimal board with no runtime.
Change-Id: Icb621cbe0a75b3a320cb53c3267d6e578cd3c32f
Reviewed-on: https://chromium-review.googlesource.com/189403
Reviewed-by: Vic Yang <victoryang@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Two accelerometer changes:
- Lower accel sampling rate when chipset is off to 10Hz. Increase
sampling rate back up to 100Hz when transitioning to S0.
- Change the default output data rate of the accelerometers to 100Hz
which matches the EC sampling rate when in S0.
BUG=none
BRANCH=rambi
TEST=manual testing. used lidangle command to verify that in S0,
EC is sampling at 100Hz, and in S3 or lower it is sampling at 10Hz.
Change-Id: Ie4e20f45f9371d674c3325a362d2729c331fac4f
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/190032
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Remove copied code from V1 implementation, reduce to bare minimum needed to
satisfy external dependencies.
Don't actually enable it for any platforms, though.
BRANCH=ToT
BUG=chrome-os-partner:23776
TEST=make buildall -j
It's used by anything and doesn't do anything if it was, but test
compilation of the changed sources by defining CONFIG_CHARGER_V2.
Change-Id: Iea37d0b4fc48c8ebf7f7088cd1674d6e275d03d4
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/190853
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Making room for a new charge_state implementation.
BRANCH=ToT
BUG=chrome-os-partner:23776
TEST=make buildall -j
No new functionality, just renaming some files.
Change-Id: I80ce861f09129a518e180cac20d32e867a93cd46
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/190852
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When we are calling the re-scheduling routine at the end of an irq
handling routine, we need to ensure that the high registers are not
currently saved on the system stack.
On Cortex-M3/M4, the compiler is normally doing tail-call optimization
there and behaving properly, but this fixes the fact that insanely large
interrupt handling routines where sometimes not compile and not running
properly (aka issue 24515).
This also prepares for one more core-specific DECLARE_IRQ routine on
Cortex-M0.
Note: now on, the IRQ handling routines should no longer be "static".
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:24515
TEST=make -j buildall
revert the workaround for 24515, see the issue happening only without
this CL.
Change-Id: Ic419369231925568df05815fd079ed191a5446db
Reviewed-on: https://chromium-review.googlesource.com/189153
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
This command wedges the I2C bus by writing part of a byte to or reading part
of the response from the slave device.
To enabled the wedge command you must define CONFIG_CMD_I2CWEDGE and you must
define I2C_PORT_HOST, the i2c port to use the wedge command.
BUG=chrome-os-partner:19286
TEST=Manual test on peach pit, spring, and glimmer. Define config in board.h
to enable the command:
On the EC console, execute the following "i2cwedge" command
i2cwedge 0x90 0 1 (wedge write)
or
i2cwedge 0x90 0 2 (wedge read)
and then "battery". Observe that the command reports an error.
Similarly, execute
i2cwedge 0x90 0 5 (wedge write + reboot)
or
i2cwedge 0x90 0 6 (wedge read + reboot)
on the EC console and observe a reboot. Then execute "battery" and observe
that the command works properly.
BRANCH=none
Change-Id: I10ccb21b047df907a4dfdbd84c0f582cfa2d939a
Signed-off-by: Hung-ying Tyan <tyanh@chromium.org>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/66389
Tested-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
Move the CLZ instruction emulation C code to the common directory, so it
can be reused for all CPU cores missing a CLZ instruction (e.g. CortexM0).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=run EC console on STM32F072B Discovery board with Cortex-M0 core,
and pass all available unit-tests on target.
Change-Id: Ief56cac7430fcb0fbced8a8925250c89cbd0bcfc
Reviewed-on: https://chromium-review.googlesource.com/188981
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Refactored the i2c unwedge code to place it in the common directory
so that any EC chip can use it.
Added to the STM32F and LM4 boards, code to automatically detect and
unwedge the i2c bus at the start of an i2c transaction. Note that STM32L
already had this ability.
To enable unwedging of the i2c port though, the gpio pins for SDA and
SCL must be defined in the i2c_ports[] array in the board.c file. This
allows the i2c module to bit bang the unwedging for the given port. If
SDA and SCL are not defined for the port, then the unwedge code will
not run.
BUG=chrome-os-partner:26315, chrome-os-partner:23802
BRANCH=none
TEST=Manual testing on machines with different EC chips.
Testing made extensive use of https://chromium-review.googlesource.com/66389
in order to force wedging of the i2c bus so that we can attempt to unwedge
it. Note that you can easily test if the bus is wedged by running i2cscan.
On pit and spring:
On pit, after each of the following, I verified that the bus was automatically
unwedged.
On spring, the unwedge only runs at reboot, so, for the non-reboot wedge
commands, I manually ran console command unwedge, and verified that the bus
became unwedged.
(1) Bit bang a transaction but only read part of the response.
Command to wedge: i2cwedge 0x90 0 2 2
(2) Bit bang a transaction to do a "write" and stop while the other side is
acking. Command to wedge: i2cwedge 0x90 0 1
(3) Same as (1) but do a reboot instead of returning and see
that the unwedge works at init time w/ no cancelled transactions.
Command to wedge: i2cwedge 0x90 0 6 2
(4) Same as (2) but do a reboot instead of returning and see
that the unwedge works at init time w/ no cancelled transactions.
Command to wedge: i2cwedge 0x90 0 5
On glimmer:
Added code to call i2c_unwedge in accel_init(). Then tested unwedging the
accelerometer with the following. One extra difficulty testing this with
the accelerometer is that sometimes the bit you stop on is high, which
means it won't be wedged at all, the next start transaction will reset
the bus. So, sometimes running i2cwedge won't wedge the bus and sometimes
it will depending on the acceleration data.
(1) Big bang transaction to do a "read" of accelerometer and stop partway:
i2cwedge 0x1c 0x0f 2 2
i2cscan to make sure bus is actually wedged
i2cunwedge
i2cscan to make sure bus is now unwedged.
(2) Bit bang transaction to do a "read" and stop partway, then reboot:
i2cwedge 0x1c 0x0f 6 2.
i2cscan to verify that the bus is working after the reboot.
Change-Id: Ie3328e843ffb40f5001c96626fea131c0f9ad9b1
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/188422
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This speeds up memset by copying a word at a time.
Ran the unit test on Peppy:
> runtest
...
Running test_memset... (speed gain: 141532 -> 32136 us) OK
...
Ran make buildall:
...
Running test_memset... (speed gain: 1338 -> 280 us) OK
...
TEST=Described above.
BUG=chrome-os-partner:23720
BRANCH=none
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: If34b06ad70f448d950535a4bea4f6556627a9b6f
Tested-by: Daisuke Nojiri <dnojiri@google.com>
Reviewed-on: https://chromium-review.googlesource.com/185936
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Daisuke Nojiri <dnojiri@google.com>
Changed speed of accelerometer i2c bus to 400kHz.
Added an accelerometers present bit to the status byte for host shared
memory so that the host knows whether this system has accelerometers or
not.
BUG=chrome-os-partner:25599
BRANCH=rambi
TEST=manual test with a glimmer.
To test speed, just ran for a while at 400kHz and made sure there were
no i2c errors and the data looked accurate using the lidangle on command.
To test the accelerometers present bit, I used the kernel patch for the
cros_ec_accel driver. First, I verified that without this patch, the kernel
driver throws an error when loading the module. Second, I verified that
with this patch the module was loaded successfully.
Change-Id: I19b8e800748b0d45dc1da6c59118e92b4908ee2f
Original-Change-Id: If931b37bf057df96659852ef9699b3e6029275c7
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187732
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/188386
Added rotation of accelerometer data into a standard reference frame
so that the host does not have to know about the orientation of the
sensors.
Also added a calibration routine to calibrate the rotation matrix to
get to the standard reference frame. Cleanup up calibration in the
process to make it more user friendly.
Changed the default accelerometer sampling rate to 100Hz.
BUG=chrome-os-partner:25599
BRANCH=rambi
TEST=Tested the full calibration routine on a glimmer at my desk.
Used 'taskinfo' and verified that the higher sampling rate does not
bog down the EC. I found that the motion sense task is running for
about 200ms every 10 seconds, so about 2% CPU load.
Change-Id: I9ca1a4252f62a54016009c7d5e43b4cb1adf7e1d
Original-Change-Id: Id554511f7cc9549dfc9ed2d6337216bfa639359d
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187172
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/188385
There's already a host command, but no console command. We should add one.
BUG=none
BRANCH=ToT, Samus
TEST=manual
From the EC console, run
lightbar version
It should display the version number and flags value.
Change-Id: Ide3517c0a71b5d78c4c4d849a952ccc1d908ea23
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187679
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Previously, the AP could only set the current wireless power state.
It couldn't determine what the EC would do in S3, nor could it get the
current wireless power state. Extend the wireless command to do so,
and add an EC console command to aid in debugging.
BUG=chrome-os-partner:25655
BRANCH=rambi
TEST=manual; expected numbers are from EC 'wireless' command
AP off -> 0x0, 0x9
AP on -> 0xd 0x9
AP suspended -> 0x9 0x9
AP on -> 0xd 0x9
ectool wireless 0x1 -> 0x1 0x9
ectool wireless 0xd -> 0xd 0x9
ectool wireless 0 0 0 0 -> 0xd 0x9 (and prints 0xd 0x9 to root shell)
ectool wireless 5 -1 -1 0 -> 0x5 0x9
AP suspended -> 0x1 0x9 (doesn't turn on 0x8, just turns off 0x4)
AP on -> 0xd 0x9
ectool wireless 0 0 0 -1 -> 0xd 0x0
AP suspended -> 0x0 0x0
AP on -> 0xd 0x9
Change-Id: I8ead2d4a4423b51ec4f638bf94c62de98726b25c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187273
After each read of the accelerometers, add accelerometer
data to LPC shared memory.
BUG=none
Original-BUG=chrome-os-partner:25599
BRANCH=rambi
TEST=Manual test by reading the LPC shared memory through cros_ec
in the kernel.
Original-Change-Id: If66df3fcb32b5423f4fa7dd471c219a1c4df7095
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186456
Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit 919ea7fe1f830235ae56829a8ee4435679dec124)
Change-Id: I10525c45e868d0b04aa84c27cab3b6baeda2b0d5
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187435
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Added motion sense task to Clapper and Glimmer. This task samples
the accelerometers and calculate a lid angle. Note that as
the machine is rotated towards the hinge angle aligning
with gravity, the lid calculation becomes less trustworthy.
Added a math_util file to hold various mathematical functions
useful for calculating lid angle that may be helpful in other
places.
For each board with accelerometers we need to define some
orientation specific data in board.c. There is a calibration
procedure through the EC console that can be enabled by
defining CONFIG_ACCEL_CALIBRATE. The calibration procedure can
help determine the orientation data required.
For debugging purposes there is a console command to regularly
print to the EC console the accelerometer data and derived lid
angle. The console command can be enabled by defining
CONFIG_CMD_LID_ANGLE.
BUG=none
Original-BUG=chrome-os-partner:24703
BRANCH=rambi
TEST=Ran the calibration procedure on a Glimmer unit, and then
rotated the machine in space. Verified that the lid angle
calculated roughly matched actual lid angle.
Original-Change-Id: I63a5e384b7f6b628b4ea01de49843355fb8d6ebe
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/184783
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Signed-off-by: Alec Berg <alecaberg@chromium.org>
(cherry picked from commit efb07945a5159fa0e7a746c666b2519ebdca9c22)
Conflicts:
board/clapper/board.c
board/clapper/ec.tasklist
board/glimmer/board.c
board/glimmer/ec.tasklist
Change-Id: Ibc492ef5c11e7084e87f01338c4d7775f9a08c18
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187433
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Previously, it would only set the fan RPM, but not actually enable the
fan so it can spin at the requested speed. Compare with setting fan
duty cycle, which always enabled the fan.
BUG=chrome-os-partner:23803
BRANCH=samus
TEST=with fans off, 'ectool pwmsetfanrpm 1000' should spin both fans,
and the ec 'faninfo' command should show both fans enabled.
Change-Id: I37d7fb05309944ab6f98333e2cf3b38ea2dd38e9
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187386
Reviewed-by: Sameer Nanda <snanda@chromium.org>
This speeds up memmove by copying a word at a time.
Ran the unit test on Peppy:
> runtest
...
Running test_memmove... (speed gain: 2156 -> 592 us) OK
...
Ran make buildall:
...
Running test_memmove... (speed gain: 143918 -> 32367 us) OK
...
TEST=Described above.
BUG=chrome-os-partner:23720
BRANCH=none
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@google.com>
Change-Id: I6a3ac6aed27a404c3bef227b6c886a59414b51d7
Reviewed-on: https://chromium-review.googlesource.com/186020
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This speeds up memcpy by copying a word at a time if source and destination are
aligned in mod 4. That is, if n and m are a positive integer:
4n -> 4m: aligned, 4x speed.
4n -> 4m+1: misaligned.
4n+1 -> 4m+1: aligned in mod 4, 4x speed.
Ran the unit test on Peppy:
> runtest
...
Running test_memcpy... (speed gain: 120300 -> 38103 us) OK
...
Ran make buildall -j:
...
Running test_memcpy... (speed gain: 2084 -> 549 us) OK
...
Note misaligned case is also optimized. Unit test runs in 298 us on Peppy while
it takes about 475 with the original memcpy.
TEST=Described above.
BUG=chrome-os-partner:23720
BRANCH=none
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: Ic12260451c5efd0896d6353017cd45d29cb672db
Tested-by: Daisuke Nojiri <dnojiri@google.com>
Reviewed-on: https://chromium-review.googlesource.com/185618
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Daisuke Nojiri <dnojiri@google.com>
This gives the AP a way to see that temperature for DPTF. Alarm
thresholds were defined on a per-sensor basis, so they come along for
free.
BUG=chrome-os-partner:25585
BRANCH=rambi
TEST=temps command shows same temp for battery as battery command (other
than rounding error; battery command shows with 0.1C accuracy).
'ectool temps all' shows the battery temp as the last temperature.
Unplug battery and temps command shows error for the battery temp,
as does 'ectool temps all'.
Change-Id: I1bce72f164d9fb1be631e7241a4ea24ddf409d7a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/185444
Reviewed-by: Dave Parker <dparker@chromium.org>
This is experimental for now; the capsense chip simply reports its buttons
as the number keys on the keyboard (1-8).
BUG=chrome-os-partner:23382
BRANCH=samus,ToT
TEST=manual
To test, you'll need a reworked and correctly programmed capsense module.
Boot the system, and switch to VT2. Touch the capsense bar and you'll see
the input appear on the console as though you were typing numbers.
Note that the capsense hardware is still buggy. Refer to the bug for
workarounds.
Change-Id: I4c3a8b70b8197ffd538c38c59c9336383365afa7
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/185434
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Dave Parker <dparker@chromium.org>
From DV2 board of pit, we'll use 3 color-LED instead of power LED on keyboard.
So, we have to add the function to control 3 color-LED in pmu driver.
BUG=chrome-os-partner:24855
TEST=Tested on the pi and pit board about all power status.
BRANCH=pit
Change-Id: I7b1df39de8fa56eab73779abfa52cf8f72427b44
Signed-off-by: Jaehoon Kim <jh228.kim@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/181588
Tested-by: Katie Roberts-Hoffman <katierh@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Wonjoon Lee <woojoo.lee@samsung.com>
Previously, setting flags=0 would disable any future timers from being
started, but not stop any timer currently in progress. With this
change, it does.
BUG=chromium:298983
BRANCH=rambi,nyan
TEST=manual
on ap, ectool hangdetect 1 60000 0
on ec, hangdet -> status=inactive
press power button
on ec, hangdet -> status=active for event
on ap, ectool hangdetect 0 0 0
on ec, hangdet -> status=inactive
Change-Id: Icf8c6e0e95ae3780d250f9f01ec6a4dda6c56176
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/184950
Reviewed-by: Daniel Erat <derat@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
BUG=chrome-os-partner:24912
BRANCH=baytrail
TEST=Manual. Enable CONFIG_POWER_BUTTON_IGNORE_LID
on a device, boot it, and go into dock mode with
external monitor attached. Fake-close the lid with a
magnet or servo. Verify the power button still sends
press/release events to the host with evtest.
Change-Id: Idb05375eee0743a8a2c459070854c03fe3afe894
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/184493
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If a key is pressed which is not in actual_key_mask, this triggers the
keyboard scan interrupt. But read_matrix() would use the key mask to
decide that no *real* keys were pressed. So it would immediately drop
out of scan mode back to interrupt mode. Which would again be
triggered. Lather, rinse, repeat, watchdog.
The fix is to use the unmasked key matrix to decide whether to stay in
scan mode. This way, the keyboard task sleeps between scans, and the
watchdog isn't triggered.
(Note that the only way you can hit this bug in real life is to have a
keyboard attached which can trigger keys not in actual_key_mask.
Which is hard to do, unless you've got a new prototype keyboard with
extra keys, or you've spilled lemon juice on your Chromebook...)
BUG=chrome-os-partner:25333
BRANCH=rambi
TEST=Zero out actual_key_mask in keyboard_scan.c. Press a key. Should
not trigger a watchdog.
Change-Id: I8c2fbc3e06fa12dfae5c06614814af8f04e24a8a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/184323
Reviewed-by: Dave Parker <dparker@chromium.org>
Tested-by: Dave Parker <dparker@chromium.org>
