This would move all tegra boards to charger v2.
Also removed the unnecessary charge_keep_power_off(), which was
designed for USB power port and doesn't apply to Tegra platform.
BUG=none
BRANCH=nyan,big,blaze
TEST=build and run on nyan.
Change-Id: I9517a8885726ad6dce5a2865402da4b9551e009f
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/194384
Commit-Queue: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Devin Lu <Devin.Lu@quantatw.com>
Tested-by: Devin Lu <Devin.Lu@quantatw.com>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Added storing of FPU regs on context switches when CONFIG_FPU is defined.
On context switches, EXC_RETURN[4] is checked in order to tell which tasks
have used floating point and which have not. The FPU regs are only stored on
task stacks for tasks that use the floating point. Tasks that use floating
point will therefore require roughly an additional 128 bytes of stack space,
and context switches will take about 32 clock cycles longer for each task
involved in the switch that uses FP.
For tasks that don't use floating point, the stack usage actually decreases
by 64 bytes because previously we were reserving stack space for FPU regs
S0-S15 on every context switch for every task, even though we weren't doing
anything with them.
If a task only uses the FPU for a brief window, it can call
task_clear_fp_used() in order to clear the FP used bit so that context
switches using that task will not backup FP regs anymore.
BUG=chrome-os-partner:27971
BRANCH=none
TEST=Tested on glimmer and peppy. Added the following code, which uses the
FPU in both the hooks task and the console task. Note, I tested this for
a handful of registers, notably registers in the group s0-s15 which are
backed up by lazy stacking, and registers in the group s16-s31 which are
backed up manually.
float dummy = 2.0f;
static void hook_fpu(void)
{
union {
float f;
int i;
} tmp;
/* do a dummy FP calculation to set CONTROL.FPCA high. */
dummy = 2.3f*7.8f;
/* read and print FP reg. */
asm volatile("vmov %0, s29" : "=r"(tmp.f));
ccprintf("Hook float 0x%08x\n", tmp.i);
/* write FP reg. */
tmp.i = 0x1234;
asm volatile("vmov s29, %0" : : "r"(tmp.f));
}
DECLARE_HOOK(HOOK_SECOND, hook_fpu, HOOK_PRIO_DEFAULT);
static int command_fpu_test(int argc, char **argv)
{
union {
float f;
int i;
} tmp;
/* do a dummy FP calculation to set CONTROL.FPCA high. */
dummy = 2.7f*7.8f;
/* read and print FP reg. */
asm volatile("vmov %0, s29" : "=r"(tmp.f));
ccprintf("Console float 0x%08x\n", tmp.i);
if (argc == 2) {
char *e;
tmp.i = strtoi(argv[1], &e, 0);
if (*e)
return EC_ERROR_PARAM1;
/* write FP reg. */
asm volatile("vmov s29, %0" : : "r"(tmp.f));
} else {
task_clear_fp_used();
}
return EC_SUCCESS;
}
DECLARE_CONSOLE_COMMAND(fputest, command_fpu_test, "", "", NULL);
When you call fputest 5 from EC console before this CL, then on the next
HOOK_SECOND, the value of register s29 is 5, instead of 0x1234 because
register s29 is not saved on context switches:
Hook float 0x00001234
> fputest 5
Console float 0x00001234
Hook float 0x00000005
When this CL is in use, the register holds the correct value for each task:
Hook float 0x00001234
> fputest 5
Console float 0x00001234
Hook float 0x00001234
> fputest
Console float 0x00000005
Hook float 0x00001234
Change-Id: Ifb1b5cbf1c6fc9193f165f8d69c96443b35bf981
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/194949
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Previously, you could use EC_CMD_ACPI_QUERY_EVENT to read events that
were masked off (that is, events which would not generate SCI/SMI/wake
signals). The handlers for those signals on the host would still act
on the masked-off events - for example, causing unwanted power button
keypresses/releases.
Now, EC_CMD_ACPI_QUERY_EVENT will only return events which are unmasked.
This does not affect storing of events at event generation time.
Events are still queued; they won't be dropped until the host attempts
to read the next event. This gives the host a chance to set a mask
later in boot (but before querying any events) to capture events which
happened early in the boot process.
BUG=chrome-os-partner:26574
BRANCH=rambi
TEST=At EC console, type 'hostevent set 0x80' but don't press enter.
Hold down the power button; UI starts fading to white.
Press enter at the EC console to issue the hostevent command.
System should continue shutting down, not fade back as if the
power button were released.
Change-Id: Id2cb14b0979f49cdd42424b9a61b310a2bb506f5
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/194935
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Add LED behavior for blaze that will the same as falco and kip.
BUG=None
BRANCH=ToT
TEST=manual
Check battery LED show Amber when battery in charging.
Check battery LED show white when battery fully.
Check battery LED show blinking every 500ms when charging error.
Check PWR LED light when system power on.
Check PWR LED off when system power down.
Check PWR LED will blinking every 1sec when system into suspend.
Change-Id: I830952361d3282ff78d29a9a33bd09b64b093ee1
Signed-off-by: Devin Lu <Devin.Lu@quantatw.com>
Reviewed-on: https://chromium-review.googlesource.com/193744
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
Set battery cut off command and config battery configuration for blaze.
BUG=chrome-os-partner:27120
BRANCH=ToT
TEST=manual
build ec and flash to blaze board,
verify battery works.
Verify battery cut off function is workable.
Change-Id: I2e1f7de9c6370a2a02fb56fc4520f4bc062b4d6b
Signed-off-by: Devin Lu <Devin.Lu@quantatw.com>
Reviewed-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193000
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
1. Modify voltage_max
2. Set CP point
BUG=chrome-os-partner:27859
BRANCH=Big
TEST=Plug in AC and battery, use UART command "charger" to check
v_batt and I_in and the values are correct.
Change-Id: If83a444338e8d520e6c2f4d04ca6016c14cea8bd
Reviewed-on: https://chromium-review.googlesource.com/193584
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
Commit-Queue: Lin Cloud <cloud_lin@compal.com>
Tested-by: Lin Cloud <cloud_lin@compal.com>
Refactored keyboard scan enable/disable flag such that it is a mask of
potential disable sources. When all disable sources are off, scanning is
enabled, otherwise scanning is disabled. This fixes a recently introduced
bug in which enabling/disabling keyboard scanning due to lid angle in S3
was interfering with enabling/disabling keyboard scanning due to power
button. This also allows for easy expansion for future causes for disabling
keyboard scanning.
BUG=chrome-os-partner:27851
BRANCH=rambi
TEST=Manual tests with a glimmer. Used the ksstate console command to
check state of keyboard scanning under all permutations of power button
pressed/unpressed, lid switch open/closed, and lid angle in tablet position
vs. laptop positon.
Change-Id: Ied4c5ebb94510b1078cd81d71373c0f1bd0d6678
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/194287
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When the battery pack is missing, don't constantly spew console messages
about it. Just note it once, and move on. But if we're precharging to try to
awaken a dead battery, say so and also say so when we either give up or the
battery awakens.
BUG=chrome-os-partner:20881
BRANCH=ToT
TEST=manual
I unplugged and replugged the battery while watching the EC console. It
stops the whining.
Also tested without CONFIG_BATTERY_PRESENT_CUSTOM defined. It precharges,
gives up, continues, etc.
Change-Id: I5d4224cd1a6bf90ed6a1cf404260cdf6c61fc125
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/194113
This improves some of the smart battery mocks, and adds some more tests for
the new change state machine.
BUG=chrome-os-partner:20881
BRANCH=ToT
TEST=make coverage
Line coverage of this file jumps from 53% to 93%.
Change-Id: I4a9b8818cefaffd3022cebe08a36d592b0611295
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193690
We had duplicate values in both v1 and v2 headers. Let's consolidate them in
one place, and prefix the constants with "CHARGE_", so people don't use them
randomly.
BUG=chrome-os-partner:20881
BRANCH=ToT
TEST=make buildall -j
No functionality changes, refactor/rename only.
Change-Id: I0ee599a2e3bf0835c2c0a7e57872ad9015701a4b
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193876
When we use 'kill -9' to kill other users of the serial port then we
end up with stale lockfile warnings. Try to use a normal kill first
to be a little nicer.
BRANCH=ToT
BUG=None
TEST=flash_ec and no longer get stale lockfile messages from cu.
Change-Id: Idb39ca803a9c54b6fe972f6854515ea5a8bdab03
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/194190
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Added a sub-command to the motionsense host command (0x2b) for getting/setting
the lid angle at which the keyboard is disabled as a wake source in S3. The
value can be anywhere from 0 to 360 degrees, default set to 180. Note, this
only takes affect for boards that have CONFIG_LID_ANGLE_KEY_SCAN defined.
Modified ectool motionsense command to use new host sub-command.
Also modified the lid angle measurement in the EC to be in the range [0, 360],
instead of [-180, 180], and changed casting of lid angle as an int to round
to nearest.
BUG=none
BRANCH=rambi
TEST=Tested on a glimmer:
Using default keyboard disable lid angle of 180, made sure that when lid
angle is past 180, key presses do not wake system, and when lid angle is
less than 180, key presses do wake up system.
Used ectool motionsense kb_wake to set the keyboard disable lid angle to 0.
Made sure that keyboard never wakes up the system. Set keyboard disable lid
angle to 360 and made sure that the keyboard always wakes up the system.
Change-Id: I437164c6e38c29169ef6e20e86c9cf2a1c78f86e
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193663
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/194172
The host should be responsible for setting any required
charge throttling at resume. EC the should not restore
the previous charge current limit as the the charging and
thermal state of the device are likely to be different
when the device resumes.
BUG=chrome-os-partner:27369
BRANCH=ToT
TEST=Suspend the device with the adapter unplugged.
Plug in the adapter and resume. Verify that the charging
LED doesn't flash two or three times at resume. (tested
on squawks)
Change-Id: I1fbba0652419501193e713e130830a005c6b5a22
Origianl-Change-Id: I1e4615d99ee9a386b25e58b991e846c5d2beaa39
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/192686
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193341
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Added enum for motion sensor ID's into ec_commands.h so that the host
can easily send host commands targeting the desired accelerometer.
Changed sensor present flag to just senosr flags, currently with only a
single mask defined for sensor present. This allows for easier future
expansion of various flags.
Also, added a motion sense module flags to the dump sub-command for flags
that represent all sensors, such as is the motion sense task active.
BUG=chrome-os-partner:27321
BRANCH=rambi
TEST=Manual test on a glimmer by testing ectool motionsense command
Change-Id: Iac052269a60db9ff4506f0490c3a0c6daad5b626
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193122
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193309
Changed the ec_rate sub-command of the motion sense command. Now it
permits any value for the rate as an argument and then bounds that
to within the min and max. This matches the behavior of the other
sub-commands such that for any argument the command will return
success, but if the arg is not valid, it finds the closest valid value.
BUG=none
BRANCH=rambi
TEST=Tested on a glimmer by using the ectool motionsense command. Made
sure if you give it a value outside of the range [5, 1000], then it
simply bounds it to the closest value in that range:
> ectool motionsense ec_rate 0
5
> ectool motionsense ec_rate 100
100
> ectool motionsense ec_rate 1100
1000
Change-Id: If71299e3ab27bcfac87103c672793ac61f88100e
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/192525
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193308
Created a host command to set/get various motion sensor parameters and
added an ectool command to use that host command.
The host command is created such that the first argument is a
sub-command. Sub-commands created include:
dump: dumps all current motion sensor data
info: returns general information about each motion sensor
ec_rate: set/get the EC sampling rate of sensors
sensor_range: set/get the sensor range (ie +/- 2G,4G,8G)
sensor_odr: set/get the sensor output data rate (ie 50Hz, 100Hz, ...)
For sensor_range and sensor_odr parameters, since the host doesn't know
what are valid values for the parameter, the host can specify to round
up or down to the nearest valid value. For example, the host can specify
to set the output data rate to at least 100Hz, and the EC will return
the closest valid output data rate that is at least 100Hz.
BUG=chrome-os-partner:27321
BRANCH=rambi
TEST=Test on a glimmer using ectool from vt-2 prompt:
> ectool motionsense help
Usage:
motionsense - dump all motion data
motionsense info NUM - print sensor info
motionsense ec_rate [RATE_MS] - set/get sample rate
motionsense odr NUM [ODR [ROUNDUP]] - set/get sensor ODR
motionsense range NUM [RANGE [ROUNDUP]]- set/get sensor range
>
> ectool motionsense
Sensor 0: 0, 0, 1024
Sensor 1: 1024, 0, 0
Sensor 2: None
> ectool motionsense info 0
Type: accel
Location: base
Chip: kxcj9
> ectool motionsense ec_rate
10
> ectool motionsense ec_rate 1000
1000
> ectool motionsense odr 0
100000
> ectool motionsense odr 0 40000 1
50000
> ectool motionsense range 0 8
8
After running this I verified on the EC console that all the parameters
were set appropriately. I tested the EC sampling rate was 1000ms by
running lidangle on and making sure samples were displayed roughly every
second. I verified the sensor odr and range by defining
CONFIG_CMD_ACCELS and typing:
> accelrange 0
8
> accelrate 0
50000
Change-Id: I444e2f0eafabd607f1c7aa78b5c4e91f6cb06387
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/192064
Reviewed-on: https://chromium-review.googlesource.com/193307
Reviewed-by: Randall Spangler <rspangler@chromium.org>
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>
Samus' power sequence is not in common/power, so it was overlooked when
enabling deep sleep support. Fix it.
BUG=chrome-os-partner:27705
BRANCH=ToT
TEST=manual
Verify that the EC is not going into deep sleep while the AP is on by
looking at the EC console:
With the AP on:
> idlestat
Num idle calls that sleep: 1518647
Num idle calls that deep-sleep: 414
Time spent in deep-sleep: 0.000000s
Total time on: 316.642174s
Deep-sleep closest to wake deadline: 698us
> sleepmask
sleep mask: 00020001
>
With the AP off (or in S3):
> idlestat
Num idle calls that sleep: 1846586
Num idle calls that deep-sleep: 831
Time spent in deep-sleep: 11.089183s
Total time on: 388.695558s
Deep-sleep closest to wake deadline: 698us
> sleepmask
sleep mask: 00020000
>
Change-Id: Iba708b6d53f96ef6d49d42bcf6d21db4732399b0
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193223
Reviewed-by: Alec Berg <alecaberg@chromium.org>
This clarifies the use of the EC's memory-mapped interface to the AP. We
always end up reverse-engineering this, so I'm just documenting what bytes
are actually used.
BUG=none
BRANCH=ToT
TEST=make buildall
No code changes, only comments.
Change-Id: Icfaa794626d2f656ab5d8a8d067b3e2663cc8882
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193052
Reviewed-by: Randall Spangler <rspangler@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>
The KBD_IRQ#, SMI#, and SCI# lines on the host are sensitive to
falling edges. When generating an interrupt, wait long enough to make
sure the lines are high before pulling them low, so that it reliably
generates a falling edge. This solves a problem where calling the
IRQ-generation function twice in rapid succession could cause two low
pulses without an intervening logic-high as seen by the host (and thus
not a falling edge as seen by the host).
This is most visible on the keyboard line, because it can generate
back-to-back events on multi-byte scan codes. Once the keyboard
mailbox is full, the EC will never attempt to fill it, and thus it
also won't attempt to generate another keyboard IRQ. And since the
host missed the IRQ, it doesn't know it needs to empty the mailbox.
It could theoretically happen for the other lines, so fix them now
just to be safe.
This change should be low-impact and free from side effects. 4 usec
is a very small additional delay. Even 65 usec added delay for
SCI/SMI is small, given that SCI/SMI events are typically much less
frequent (if they're happening very frequently, something else is
tragically wrong with the system...)
BUG=chrome-os-partner:27222
BRANCH=rambi
TEST=Bang on the keyboard like a monkey. Keyboard shouldn't get stuck.
Orig-Change-Id: Id4e6de793b1f007f713bac8aa195ddd78feeea3e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193173
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
(cherry picked from commit 569651b82e309ddd86b9c165d131e34cb7f7b2b5)
Change-Id: I62a9ad0fa85121b3345c057f0e3fc6b3cc29e97e
Reviewed-on: https://chromium-review.googlesource.com/193174
Commit-Queue: Randall Spangler <rspangler@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Benson Leung <bleung@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>
This GPIO was configured as TTL. It should be open drain instead.
BUG=chrome-os-partner:27280
BRANCH=ToT
TEST=manual
Hard reboot, lightbar still works.
Try turning it off and on from the EC console:
> gpioset LIGHTBAR_RESET_L 0
lightbar goes dark.
> gpioset LIGHTBAR_RESET_L 1
> lightbar init
> lightbar on
lightbar comes on again.
Change-Id: If4d4beade8c95f3f231eeed435e35350ce866cea
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/192871
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>
These are not currently checked by gerrit, but will be at some point
in the not-too-distant future.
The board/ directory gets additional owners to make it easier for
partner eng to make changes in ToT.
BUG=chrome-os-partner:27404
BRANCH=none
TEST=none (since gerrit doesn't check owners yet)
Change-Id: Ie21b9530fcc6d708ab987d9de80676f91faa72b9
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/191947
Reviewed-by: Vincent Palatin <vpalatin@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>
On some boards, the temperature sensor doesn't route to EC.
Thus the 'ectool temps all' would get "200" for every temp sensor.
This is misleading information.
So, check the EC_MEMMAP_THERMAL_VERSION before we dump. If it is 0,
then the temp data is not filled (and properly will not be filled).
BUG=chrome-os-partner:27460
BRANCH=all
TEST=Tested on big, which doesn't have sensor routed to EC.
Change-Id: I03e9736054ed602b7cc126e9fd958e0cecea79b4
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/192149
Reviewed-by: Mao Huang <littlecvr@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Vic points out a corner case that the battery LED could be off by
the followng steps:
1. charge the battery to very full
2. disconnact the AC so that the LED is off for discharge.
3. plug AC again, then charger enters INIT state -->
IDLE0 --> IDLE where those states don't toggle LED.
BUG=none
BRANCH=big
TEST=Reproduced this bug on big. Verified this has been fixed by this CL.
Change-Id: I7125acd6b11953675ac6d4085e31e0560b384015
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/189757
These are generated files used for code cross-reference in Emacs. Let's
ignore them so repo upload doesn't keep complaining.
BUG=none
BRANCH=ToT
TEST=manual
Leave these files in place, try "repo upload .", see that it stops
complaining about uncommitted files.
Change-Id: I9c0a7182050c0b50bd36e4b10091f9b2912f6596
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/192285
Reviewed-by: Randall Spangler <rspangler@chromium.org>
add support for CRC-32, it's using the USB variant for the constants and
bit ordering (same polynom as Ethernet).
This code is using an (evil) "stateful" design to be compatible with the
hardware CRC controller : you should NOT do concurrent accesses without
external locking (but it's good enough and ligthweight for current
usage)
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=run interoperability testing against other 3rd parties USB
implementations.
Change-Id: I1a07b2c4e2e71e15f9d257611652061bcfb0de9c
Reviewed-on: https://chromium-review.googlesource.com/189865
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Add support TI BQ24773 1S/2S/3S NVDC battery charger.
This is not a "Smart Battery" compliant charger IC, it should and cannot
use the sbc_ helpers.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=on FruitPie, run "charger" command on the EC console,
add the charger task and see the battery charging.
Change-Id: I6f470184f0ce424a05007e493d802dcdb2156477
Reviewed-on: https://chromium-review.googlesource.com/191212
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
