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>
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>
The charger driver code has no dependency on the charger task,
we do not need to force the de-activation when the charger task is not
running.
This allow to debug new charger code without the task acting in
background and should not have any drawback.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=make buildall
and run "charger" command on Fruitpie without the charger task.
Change-Id: I49a4885a2abf0e5d9e652e037941b1c4672beb7a
Reviewed-on: https://chromium-review.googlesource.com/191211
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@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>
Added a mutex in kxcj9 accelerometer driver to prevent concurrent
accesses when writing to critical registers on sensor.
Also added more console debugging functions behind CONFIG_CMD_ACCELS
to allow writing a new range, resolution, or data rate to each
sensor.
BUG=chrome-os-partner:26884
BRANCH=rambi
TEST=Tested by defining CONFIG_CMD_ACCELS and playing around with
writing/reading various parameters on each sensor and making sure
that the accelerometer is still reporting data every so often using
the lidangle on command.
Change-Id: Ic009951d508b125d1c479d042455713c9c8de761
Original-Change-Id: I2038f167fc8ca51723b0d1330aa090ab5158cf15
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/191173
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/191611
According to the kionix datasheet, you are supposed to disable the
accel before writing to various critical registers. We haven't had
a problem thus far, but better to match the datasheet to avoid future
problems.
BUG=none
BRANCH=rambi
TEST=ran on glimmer. made sure accels still work using lidangle command.
Change-Id: I363435862ed473b315afdf6d2aea64cebe3bac55
Original-Change-Id: If2d86c39c24c6ba13e118850c5e3f6c0174f4eb7
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/190486
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/191610
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>
This prevents other task events from continuing the ADC
conversion prematurely; potentially leading to a panic
if the conversion interrupt occurs after the ADC has
been powered down.
BUG=chrome-os-partner:26919
BRANCH=rambi
TEST=Perform ADC conversions while running a deferred function
calling itself on a 10mSec delay. Verify no panics after ~6 hours.
Change-Id: Ic3894849c154b3f058e812b2da816e7cffb12cbf
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/191302
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This can be helpful when debugging "Imprecise" data bus errors.
BUG=None
BRANCH=None
TEST=Write to a memory-mapped register such as LM4_ADC_ADCISC
for a hardware block that is powered down.
Check the exception trace for a "Precise" error.
Change-Id: Ia246c3661b482e212bb0ce37b9c2d383021de639
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/191392
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>
Using minimal runtime to fit the charger flash and RAM size.
It is currently more an experiment than the final layout written in the
stone.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=run on STM32F051 Discovery with
limited RAM and Flash to mimic STM32F031.
Change-Id: I10ee1decfd1f1448edbc909f0e997367921c4b53
Reviewed-on: https://chromium-review.googlesource.com/189405
Reviewed-by: Vic Yang <victoryang@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Looks like this board just missed a change to temporarily fork the
charger code while it is being refactored.
BUG=None
BRANCH=nyan,blaze
TEST=make -j BOARD=blaze
Change-Id: I4ca630cc5210486928fbeda9af3e9c11ddbc8daa
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/191214
