Use the EC to check if PD MCU has crashed. The EC knows this
by checking the PD status bits: if PD MCU was in RW, and is
now in RO, AND it did not get to RO via a sysjump, then it
must have crashed. When the EC detects this, the EC will also
panic and reboot the entire system, so that we can software
sync to a known good state.
Also, when EC panics due to PD crash, it will log panic info.
BUG=chrome-os-partner:36636
BRANCH=samus
TEST=load onto samus EC and PD, try sysjump'ing back and forth
on PD MCU console and verify EC does not do anything. Crash
the PD MCU when in RW by reboot command and crash divzero command,
and make sure the EC panics with PD crash panic message. Crash
the PD MCU when in RO (before sysjumping to RW) and make sure
EC does not panic.
Change-Id: I57961028e6b23a878b8e477a9d8e180cb121a742
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/250100
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Make non-exception "software" panics such as stack overflow and assert
failure save a panic log. Log the panic type in r4, and misc. panic data
in r5 so that panic reasons can be distinguished.
BUG=chrome-os-partner:36744
TEST=Manual on samus_pd. Run 'crash divzero' then 'panicinfo' after
reboot. Verify that panic info is printed with "r4 :dead6660". Trigger
stack overflow, verify that panic info is printed with "r4 :dead6661".
BRANCH=Samus
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I5f7a8eb0a5c2ac5799d29bb241deb24fabf38f68
Reviewed-on: https://chromium-review.googlesource.com/249912
Tested-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
This adds CONFIG_FAN_UPDATE_PERIOD to limit the frequency at which
the fan speeds are updated. Short version: the CPU core temp
fluctuates rapidly, causing the fans turn off and on annoyingly
often (assuming you have good hearing and are in a quiet room).
With this CL, we limit the speed changes to only once every N
seconds. N should be long enough to be less annoying, yet short
enough that the CPU doesn't overheat while we're not looking.
BUG=chrome-os-partner:34789
BRANCH=ToT,samus
TEST=manual
Let it sit quietly, then visit a busy webpage, then let it sit a
while. The fan speed should only change every 10 seconds or so,
not every second.
Change-Id: Id985350394f24d56dc4a1e51af09487ac643285b
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/250501
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Add new charge_ramp module which works with charge_manager to
slowly increase input current limit in order to find the optimal
charging current. To do this it looks for either VBUS drooping
too low or for the charger to over-current.
BUG=chrome-os-partner:34946
BRANCH=samus
TEST=tested with a variety of BC1.2 chargers, type-C only chargers,
and PD chargers to make sure we always stabilize charging at an
appropriate current limit.
Change-Id: Icc95aa2738ddb221f163f91c14a342a0674f9e0f
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/247304
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
When we find that charging is in a wedged state, we may wish to write a
PD log entry, but the PD MCU cannot detect such a state on its own.
Therefore, add a new command to ask the PD MCU to write a log of a given
type, and add a new board-specific custom log event.
BUG=chrome-os-partner:36668
TEST=Manual on samus:
./ectool --dev=1 pdwritelog charge 0
./ectool --dev=1 pdwritelog charge 1
./ectool --dev=1 pdwritelog 1 0
./ectool --dev=1 pdwritelog 2 0
./ectool --dev=1 pdlog
Verify log output matches expectation:
2015-02-12 11:12:49.290 P0 SRC
2015-02-12 11:12:49.296 P1 SNK Charger PD 20286mV max 20000mV / 3000mA
2015-02-12 11:12:49.303 P0 New connection
2015-02-12 11:12:49.310 P0 Board-custom event
--- END OF LOG --
Also, verify kernel logging of wedged event:
[ 181.378420] PDLOG 2015/02/12 19:13:44.019 P0 Event 02 (0000) []
Also, trigger wedged state on Samus and verify log entry is written.
BRANCH=Samus
Change-Id: I55c7c839cf8300fcd3931dccdaaf16c1065e31a8
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/248981
Reviewed-by: Alec Berg <alecaberg@chromium.org>
If 2 interrupts happen at the same time, there is a chance that the nested
interrupt will not call svc_handler when it needs to. In extreme cases this
could lead to tasks not getting woken up when they're supposed to and watchdog
resetting.
The reason stuff worked was because there were enough other interrupts
around to eventually call the scheduler and switch to the ready task.
This change modifies the interrupt calls to not call the scheduler directly
(because in nested interrupt situation this causes problems), but defer the
call to scheduling until after the irq finishes by triggering a low priority
interrupt which will for sure call svc_host at the end. The PendSV irq was
used for this purpose.
BUG=chrome-os-partner:36193
TEST=No more SPI errors caused by scheduler problems
TEST=usleeps now are more accurate, they're guaranteed to not take forever now
BRANCH=veyron
Change-Id: I42acde6b3eb7be2540a0de9a8562dee2ea2be7ab
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/248902
Tested-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
Previously, we tried to minimize log spew by keeping track of previous
log entries and not writing new entries in some cases. Instead, we can
write a log on the following events only:
1. A port becomes active or
2. A port becomes inactive or
3. The active charge port power limit changes or
4. Any supplier change on an inactive port
Also, make charge_manager_save_log a non-static charge manager API
function, so that other modules can record a log, if they have reason to
believe a port has changed outside of a charge manager change.
BUG=chrome-os-partner:33248
TEST=Manual on Samus. Make various power actions and observe logging.
BRANCH=Samus
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I5d5d3e186e85fdb1c59797ffbfb2f5a6ec04d94d
Reviewed-on: https://chromium-review.googlesource.com/247891
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Since charge manager is now informed of all capability changes as they
happen, it makes sense to store the port capability within charge manager,
rather than storing in pd.
BUG=chrome-os-partner:36390
TEST=Manual on Samus. Insert 1A Apple charger, verify correct detection.
Run 'chgoverride -2' to prevent charging, then repeatedly insert +
remove a dual-role charger on the other charge port. Verify that
charging is still prevented. Finally, insert a dedicated charger and
verify that the override is removed. Also, pass unit tests and verify
correct detection in various scenarios with various chargers.
BRANCH=Samus
Change-Id: I3669050b37ddd67f6608bf790a07e74f86b6ac01
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/247724
Reviewed-by: Alec Berg <alecaberg@chromium.org>
The debounce timer might be too slow to actually update the state of
debounced_power_pressed by the time we do power_button_is_pressed in the S3->S5
state transition. Solution is to move the power_button_wait_for_release function
here and make sure there are no deferreds active.
BUG=chrome-os-partner:35948
TEST=During dev mode screen, press power button, note the device stays off
TEST=Print debounced_power_pressed in power_button_is_pressed(void), note it's
not 0 when power button is actually pressed
BRANCH=veyron
Change-Id: I8258e9e5524bd65d6ea9c77ea5649304d2195bf0
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/244590
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If a dual-role charger is plugged, we will not realize it is dual-role
until after we see a type-C charge source. It can cause us to briefly
charge from a dual-role charger, which has bad side effects related to
charge override and the lightbar. Fix this by not charging from a port
until we are fairly certain that it is a dedicated charger (based upon
PD discovery timeout).
BUG=chrome-os-partner:36390
TEST=Manual on Samus. Insert 1A Apple charger, verify correct detection.
Run 'chgoverride -2' to prevent charging, then repeatedly insert +
remove a dual-role charger on the other charge port. Verify that
charging is still prevented. Finally, insert a dedicated charger and
verify that the override is removed. Also, pass unit tests and verify
correct detection in various scenarios with various chargers.
BRANCH=Samus
Change-Id: Ia4154f34dd0a850b6e72bebadbd938f034532f14
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/247130
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Some EC chips (mec1322) use external SPI flash which is not mapped
into the EC CPU's address space. These must explicitly read data from
flash when calculating the vboot hash or reading the version string of
the image which isn't currently loaded into code RAM.
To test this bug, I used a board with known working mapped flash, and
temporarily patched it to act like it didn't have mapped flash.
Also add a flashread console command, useful for manually testing.
BUG=chrome-os-partner:35308
BRANCH=glower,strago
TEST=manual
1. Apply this patch to samus
2. Check result for 'vboot hash RW'
3. Check result for 'version'
4a. In board/samus/board.h, #undef CONFIG_FLASH_MAPPED and
#define CONFIG_CMD_FLASH
4b. In chip/lm4/flash.c, add the following:
int flash_physical_read(int offset, int size, char *data)
{
const char *src;
if (offset > CONFIG_FLASH_SIZE ||
offset + size > CONFIG_FLASH_SIZE)
return EC_ERROR_INVAL;
src = (const char *)((uintptr_t)CONFIG_FLASH_BASE + offset);
memcpy(data, src, size);
return EC_SUCCESS;
}
Steps 4a,4b will make the LM4 chip act like it doesn't have
memory-mapped flash.
5. From the dev system, util/flash_ec --board=samus --ro
6. Check result for 'vboot hash RW'. Should be same as 2.
7. Check result for 'version' for RW version. Should be same as in 3.
8. From the dev system, util/flash_ec --board=samus
9. sysjump rw
10. Check result for 'version' for RO version. Should be same as in 3.
11. Compare 'flashread 0x100 0x100' with 'md 0x100 0x40'. The results
should be the same (but endian-swapped, since flashread is byte
ordered and md is 32-bit ordered).
12. Revert changes from steps 4a-4b.
Change-Id: I951d6f5603a84e326740936e4e84dfe6296a0f59
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/246200
Reviewed-by: Shawn N <shawnn@chromium.org>
Motion sense calculations do not require huge amounts of precision, so
fixed point is plenty accurate. And fixed point works on Cortex-M0,
which lacks a FPU.
BUG=chrome-os-partner:36126
BRANCH=minnie (samus already works with the FPU, but could grab this if we
want additional testing)
TEST=manual
1. Boot system
2. At EC console: accelinfo on 250
3. Move lid through several different angles (30 degrees to max open) and
see that it updates correctly and relatively smoothly. A few degrees
of angle jitter is normal.
4. At several angles, rotate the chromebook around and see that the lid
angle remains relatively stable.
5. If the hinge is made normal to the ground (or within 15 degrees of
vertical), the angle should read 500, since the acceleration vectors
don't yield good results in that orientation (for either fixed or float
math).
And run 'make buildall -j', which tests arc_cos() and lid angle calculations
Change-Id: I70a0d08b8914629a3e21ae5578cbe8e50f29ad68
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/244116
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Fix bug on samus that the battery status doesn't always show on
lightbar when AC is plugged/unplugged. It doesn't show when the
battery is full is S3 or S5 because in these states we turn off
CHARGE_EN so that ACOK to the EC never toggles.
Instead, what we want to do is display battery status whenever the
active charge port changes. This will happen when AC is plugged or
unplugged OR if a user has AC on both ports and toggles between
them using the charge override hot-keys.
BUG=chrome-os-partner:36317
BRANCH=samus
TEST=test plugging and unplugging AC on both sides when battery is
full and unit is in S0, and when unit is in S5. also tested lightbar
flashes battery percentage when two zingers are plugged in and you
switch between them using Ctrl+Search+0|1|2.
Change-Id: I5cd7fff4f466adf857f1e63f07f3b0c7ae8422c7
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/245922
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Occasionally the charge circuit on samus gets wedged and will not
charge. This change detects when the charge circuit has failed
and automatically recovers from it. It uses the BQ PROCHOT warning
to detect the failure by setting PROCHOT to trigger when the BQ
thinks input current is higher than the input current limit. When
the failure is detected, the EC disables charging and tells PD MCU
to disable CHARGE_EN, then a couple seconds later, it re-enables
charging.
This CL also adds more communication between EC and PD for the EC
to be able to set the charge state for the PD. Valid charge states
are: No charging allowed, 5V charging only, and max charging. The
EC uses this as such:
- When the EC gets AC present interrupt, it sets off a deferred
function to change charge state to max charging after some delay
to give time for the charge circuit to settle down.
- When the EC gets AC disconnect interrupt, it disables charging
briefly, enables learn mode, and then sets 5V charging allowed.
This allows for the same starting conditions in the charge circuit
for every AC attach.
- When the EC detects a wedged charge circuit, it disables charging
and waits a few seconds before re-enabling 5V only charging.
Additionally, this change moves the charging cutoff in S3/S5/G3 when
the battery is full to the EC. With the added control for the EC
to set the PD charging state, it is more convenient for the EC to
manage cutting off charging when battery is full.
BUG=chrome-os-partner:36081
BRANCH=samus
TEST=test the basics:
- connect/disconnect zinger a bunch of times
- connect and disconnect two zingers in different order
- connect two zingers and charge override between the two
test the automatic charge wedge recover:
- wedge the charge circuit by setting charger voltage under battery
voltage: "charger voltage 7000"
- wait a few seconds for the system to recover and check it is charging
with "battery" command
test full battery charge cutoff:
- added console command to change battery soc in board/samus/extpower.c:
static int cmd_battfake(int argc, char **argv)
{
char *e;
battery_soc = strtoi(argv[1], &e, 10);
batt_soc_change();
return EC_SUCCESS;
}
DECLARE_CONSOLE_COMMAND(battfake, cmd_battfake, "", "", NULL);
- in S0, tested "battfake 100" does not disable charging.
- in G3, tested "battfake 100" disables charging and "battfake 99"
re-enables charging.
- set "battfake 100" and tested transitioning to S0 enables charging and
transitioning to S5 disables charging.
- attached two chargers and used charge override to select active port.
then toggled "battfake 100" to "battfake 99" back and forth and verified
charge override port is still the same.
test third-party 12V charger:
- plug in a bunch of times and make sure we stay at 5V for 500ms and then
transition to 12V
test with no battery:
- tested five different units with no battery and just zinger. 3/5 boot,
while the other 2 don't. But, the 2 that don't boot without battery also
can't boot w/o battery when this CL is reverted, so I don't think this
change is causing the problem, I think there is an electrical limitation.
test with EVT zinger:
- EVT zingers (P2 - C2) negotiate very quickly after connection, which
can cause INA problems w/o this CL. Tested an EVT zinger with samus and
did a bunch of connections and disconnections and verified that we always
wait at 5V for 500ms and that we don't wedge the INA circuit on connect.
test backwards compatibility:
- test new PD with old EC and make sure we can charge with zinger.
(note that if the charge circuit wedges, we won't be able to unwedge it).
- test old PD with new EC and make sure we can charge with zinger.
Change-Id: I7703b7a2ab1209d7f559b265b03517e79c74b16a
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/245253
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Add hook for battery state of charge change. Hook will be used
to cleanup the samus charging workarounds to follow.
BUG=none
BRANCH=samus
TEST=make -j buildall
Change-Id: I99cbb8264783802139cac689804b056623063695
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/245252
Reviewed-by: Shawn N <shawnn@chromium.org>
mcdp_info is a logging payload, so related structures need to be moved
to the public include file.
BUG=chrome-os-partner:35935
TEST=make buildall -j
BRANCH=Samus
Change-Id: Idb939db884821fa85faafbfe643e713f5bcdbc59
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/244780
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Current simplified implementation allows single mode entry. Specification
allows multiple mode entry and its advantageous for things like flashing RW
while staying in DisplayPort mode on video dongles.
CL adds capability on DFP to track as many alternate modes as supported by the
DFP. Initial mode entered is still the default supported mode ( 1st entry, 1st
opos). Policy manager can then use host command, EC_CMD_USB_PD_SET_AMODE, to
enter additional supported modes.
On the UFP (hoho, dingdong) a small modification to track multiple svid mode
entries was made.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:33946
TEST=manual, On hoho
1. Still successfully enter default mode DP
2. Using ectool's pdsetmode can successfully enter/exit multiple modes.
For example,
# port:1 svid:18d1 opos:1 cmd:1==enter
ectool --name cros_pd pdsetmode 1 0x18d1 1 1
Checking with pdgetmode shows both modes entered.
3. Works across hard & soft resets
4. Can flash via ectool --name cros_pd flashpd 4 <port> <RW image>
5. Still drives external display. With bootarg drm.debug=0x6 and following
command: 'tail -f /var/log/messages | grep "Received HPD" &'
I see HPD assert & deassert when switching between GFU and DP mode.
If both modes entered screen stays lit (after reboot) during write.
Change-Id: I7a21ebea377402eb1b0a0cf1d29df59694e301b1
Reviewed-on: https://chromium-review.googlesource.com/241790
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Renaming this to 'opos' for consistency with USP-PD specifications
'object position' in VDM header.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:35495
TEST=manual, On hoho
1. Still successfully enter default mode DP
2. Using ectool's pdgetmode pdsetmode can successfully enter/exit
other modes
3. Works across hard & soft resets
Change-Id: I08cb8e003ced4de481adcb503bcba3437ebb1ab7
Reviewed-on: https://chromium-review.googlesource.com/241718
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Change the charge override hot keys to ctrol+search+0|1|2
BUG=none
BRANCH=samus
TEST=use the hot keys and verify that the PD console shows
charge override host command
Change-Id: I5551190743ea064a967164b9d95143cc966662e1
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242832
Reviewed-by: Shawn N <shawnn@chromium.org>
Poll USB PD accessories for event log entries only after we have
performed a Discover Identity and identified them as a Google device
(USB VID = 0x18d1) in order to avoid confusing third party devices with
our logging VDM.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:35858
TEST=connect Zinger to Samus and see the proper PD log entries.
Change-Id: I022fa0d19dc012e46a27b786a724ff251280eeaf
Reviewed-on: https://chromium-review.googlesource.com/242871
Reviewed-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
For dual-role USB ports (host/device), let the AP know whether we are
currently DFP (USB host) or UFP (USB device) by exporting the data role
in addition to the power role in the EC_CMD_USB_PD_CONTROL response.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=none
TEST=ectool --name=cros_pd usbpd 0
plug various accessories on the port and see properly "SRC DFP" for the
USB key, "SNK DFP" for the power supply and "SNK UFP" for a regular
C-to-A charging cable.
Change-Id: I292da15fa8cf3566109dd05995ef1d00bed6f92d
Reviewed-on: https://chromium-review.googlesource.com/242012
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
This adds a sensor-specific attentuation factor, which will be
applied to the ALS raw sensor readings on the EC. This is to
account for the attenutation due to glass, tinting, etc.
BUG=chrome-os-partner:34590
BRANCH=ToT,Samus
TEST=manual
In a root shell, run this:
cd /sys/bus/acpi/drivers/acpi_als/ACPI0008:00/iio:device1
while true; do cat in_illuminance_raw; sleep 1 ;done
Shine a flashlight on the ALS. Note that the readings are 5X
higher than they were before this CL.
Change-Id: I2a53872ecb5fab62e5f443d43588a26d3d7e697f
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/241191
Reviewed-by: Bryan Freed <bfreed@chromium.org>
Do not request a voltage that is within the deadband where we
aren't sure if the boost or the boost bypass is on.
BUG=chrome-os-partner:34938
BRANCH=samus
TEST=test on samus with zinger. change the deadband to [10V, 20V]
and see that we only negotiate to 5V. change the deadband to
[13V, 20V] and see that we negotiate to 12V. change the deadband
to [10V, 13V] and see that we negotiate to 20V.
Change-Id: Id761aef35eeadfa2ab7d2ca31a48d4324625ab32
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/241528
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The AP informs us of the latest update image for a given device through
the EC_CMD_USB_PD_RW_HASH_ENTRY command. If the latest update image is
equivalent to our RW, we don't need to request an update.
BUG=chrome-os-partner:35510
TEST=Manual on Samus. Flash latest RW FW to Zinger. Verify that
subsequent Zinger insertion doesn't trigger the FW update host event.
Insert RO-stuck Zinger and verify that FW update host event is
triggered.
BRANCH=Samus
Change-Id: I300b150b3469e3fe32307e61273880a1a052ac5a
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/241172
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Chipset sometimes needs I2C, therefore i2c_init should have a higher priority
than power_common_init so i2c is available by the time the chipset might be
talking to the battery.
BUG=chrome-os-partner:35502, chrome-os-partner:35173
TEST=There is no "battery not responding" message at startup on veyron
TEST=EC boot takes less than 1 second on veyron
BRANCH=none
Change-Id: Ib10b653decc7703e706d4dd1976abf0fdbc25ac2
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/241102
Reviewed-by: Randall Spangler <rspangler@chromium.org>
More updates to connection state machine. Adds CONFIG option
for backwards compatible DFP (used on zinger), and change UFP
state machine to debounce CC while VBUS is not present.
BUG=chrome-os-partner:33680
BRANCH=samus
TEST=load on samus and zinger and connect a bunch of times. also
test samus to samus connection.
Change-Id: Ia967eb6a17b10aa0c05a30686235fbf8a24e9a7b
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240587
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Certain platforms may wish to have a longer shutdown timeout, so make
the timeout a config option.
BUG=chrome-os-partner:35188
TEST=Manual on Samus with subsequent CL. Set config option to increase
timeout, verify that timeout is extended.
BRANCH=Samus
Change-Id: I69feb0d31fdc53e533671dec1e88ba96cc4553c2
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240815
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Add a FIFO to log important events on the PD MCU and coming from the PD
accessories.
The retrieval of the accessories log from the accessories by the PD MCU
is not implemented yet.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:32785
TEST=execute "ectool --name=cros_pd pdlog"
before and after plugging Zinger charger.
Change-Id: If96d73e711ff6ad64cfb99bd3e4d2d8f2643f19a
Reviewed-on: https://chromium-review.googlesource.com/238854
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Assuming the dut has red/green battery led and a single power led
CONFIG_LED_POLICY_STD implements the chromeos spec:
* power led on in S0
* power led off in S5
* power led pulsing in S3
* battery led amber when charging
* battery led green when fully charged with AC
* battery led off when discharging
* battery led pulsing red when battery error
BUG=chrome-os-partner:35355
TEST=The Charging led behavior should match the cros spec
BRANCH=None
Change-Id: I645a939ecc2d44d73d2f52b295f9c7e8c923f77b
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240705
Reviewed-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:35312
BRANCH=none
TEST=make buildall -j
I added a debug message to nrf51/hwtimer.c to show when the timer overflowed.
"forcetime 4 0xfffff000" overflows to 5.00000000 in 4096 microseconds.
Define CONFIG_CMD_FORCETIME to enable it.
Change-Id: I30835d038ef8cd639565ffb7a638979d95d0a684
Signed-off-by: Myles Watson <mylesgw@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/239968
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Add npcx_evb in board folder for testing
Add shared-spi arch support in common layer.
Modified drivers for
1. Fan.c: console command “pwmduty”.
2. Pwm.c: for the issue when set duty to 0.
3. System.c: for hw reset only during system reset.
4. Flash.c: Fixed access denied bug of the flash driver for host command.
5. Comments from Patch Set 1
6. Comments from Patch Set 3 (except sha256.c)
7. Add openocd and flash_ec support for npcx_evb
8. Add little FW and spi-flash upload FW in chip folder
9. Add optional make rules for PROJECT_EXTRA
10.Replace CONFIG_SHRSPI_ARCH with CONFIG_CODERAM_ARCH and remove changes
in common layer sources for shared-spi arch. (except sysjump)
11.Find the root cause of JTAG issue and use workaround method
with SUPPORT_JTAG in clock.c
12 Execute hibernate in low power RAM for better power consumption
13 Add workaround method for version console command
14 Modified coding style issues by checkpatch.pl tool
BUG=chrome-os-partner:34346
TEST=make buildall -j; test nuvoton IC specific drivers
BRANCH=none
Change-Id: I5e383420642de1643e2bead837a55c8c58481786
Signed-off-by: Ian Chao <mlchao@nuvoton.com>
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233742
When displaying the temps, if the sensor has valid entries to
control the target fan speed, show them. This lets us see which
sensor is the main player in the cooling needed without doing a
bunch of math.
BUG=none
BRANCH=none
TEST=manual
On the EC console:
> thermalget
sensor warn high halt fan_off fan_max name
0 368 370 372 316 358 PECI
1 0 0 0 0 0 ECInternal
2 0 0 0 314 328 I2C-Charger-Die
3 0 0 0 0 0 I2C-Charger-Object
4 0 0 0 308 322 I2C-CPU-Die
5 0 0 0 0 0 I2C-CPU-Object
6 0 0 0 301 317 I2C-Left C-Die
7 0 0 0 0 0 I2C-Left C-Object
8 0 0 0 302 316 I2C-Right C-Die
9 0 0 0 0 0 I2C-Right C-Object
10 0 0 0 303 317 I2C-Right D-Die
11 0 0 0 0 0 I2C-Right D-Object
12 0 0 0 316 327 I2C-Left D-Die
13 0 0 0 0 0 I2C-Left D-Object
Then, before this CL:
> temps
PECI : 308 K = 35 C
ECInternal : 309 K = 36 C
I2C-Charger-Die : 307 K = 34 C
I2C-Charger-Object : Not calibrated
I2C-CPU-Die : 304 K = 31 C
I2C-CPU-Object : Not calibrated
I2C-Left C-Die : 302 K = 29 C
I2C-Left C-Object : Not calibrated
I2C-Right C-Die : 303 K = 30 C
I2C-Right C-Object : Not calibrated
I2C-Right D-Die : 303 K = 30 C
I2C-Right D-Object : Not calibrated
I2C-Left D-Die : 306 K = 33 C
I2C-Left D-Object : Not calibrated
After this CL:
> temps
PECI : 308 K = 35 C 0%
ECInternal : 309 K = 36 C
I2C-Charger-Die : 307 K = 34 C 0%
I2C-Charger-Object : Not calibrated
I2C-CPU-Die : 304 K = 31 C 0%
I2C-CPU-Object : Not calibrated
I2C-Left C-Die : 302 K = 29 C 6%
I2C-Left C-Object : Not calibrated
I2C-Right C-Die : 303 K = 30 C 7%
I2C-Right C-Object : Not calibrated
I2C-Right D-Die : 303 K = 30 C 0%
I2C-Right D-Object : Not calibrated
I2C-Left D-Die : 306 K = 33 C 0%
I2C-Left D-Object : Not calibrated
Change-Id: I12bca5826e8a5a3325710fa5d39cec88f1cc95b1
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240517
prevent_hot_discharge and prevent_deep_discharge are near-identical
copies of one another, and can be combined without the loss of any
useful functionality.
BUG=chrome-os-partner:35188
TEST=Manual on Samus. Charge to 2% and boot system with 5V power supply.
Verify that warnings print to console and AP powers down after 30s. Also
pass unit tests.
BRANCH=Samus
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I0f1da5248825a3884f7910babc742dfa7eadf5a3
Reviewed-on: https://chromium-review.googlesource.com/240033
Another fix for redundant requests. This time there can be
redundant requests if the maximum allowed voltage changes,
but we still fall into the samus PDO index and therefore are
asking for the same voltage. This fixes by checking the voltage
value we actually request vs. the max value we can request.
BUG=none
BRANCH=samus
TEST=samus to samus was causing redundant requests and now it's
not.
Change-Id: Ie49add1a42b86de97cee87f9d4637dd0578e2ce3
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/239950
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Implement the new type-C connect state machine which removes
lock and hold times and adds a debounce time to make sure
CC lines settle before going into the attached state.
This also adds detection of accessories, but doesn't do anything
when an accessory is detected.
BUG=chrome-os-partner:33680
BRANCH=samus
TEST=test samus connected zinger and samus connected to samus. make
sure that the connection is always formed. also tested with a third
party with old state machine implementation and formed a connection
every time.
Change-Id: I91a7a6031bc35082cc19d7697142e4aa92ef46f2
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/238210
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
If the EC controls the lightbar and sets the sequence when
it notices the chipset transitioning between states, we can't
make exceptions for cases where we don't want to activate the
lightbar, such as in dark resume. Instead, let's make it a
separate command that we expect from the kernel.
BUG=chrome-os-partner:32181
TEST=build on samus, verify lightbar does correct thing with
manual control set
BRANCH=ToT
Signed-off-by: Eric Caruso <ejcaruso@chromium.org>
Change-Id: I5dc619cbbf2498e2ef03ce622831b33e14c7c495
Reviewed-on: https://chromium-review.googlesource.com/239215
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
