| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This includes:
- Enabling SBU path for debug USB usage in USB mode (not in DP mode)
- Add a console command to enable DFU mode for lab devices. This
requires the additional Silego chip on the device.
BRANCH=None
BUG=None
TEST=Hook up a Ryu with the additional Silego chip. Issue 'dfu' command
and see DFU device in 'lsusb' output. Issue the command again and the
device goes away.
Change-Id: I3f942c6abe52784351f2242c9b0b6400e9b2b6fd
Signed-off-by: Vic Yang <victoryang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/247350
Tested-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vic Yang <victoryang@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug fix for the new samus charging software workarounds. The problem
occurs occasionally, especially with 5V chargers, and causes the
new software workarounds to get out of sync with the actualy state
of the charging circuit such that when ACOK actually goes high, we
stop charging, and then when ACOK goes low we start charging, and
we end up in a high frequency loop of enabling/disabling charging.
The fix is to add a 100ms delay when ACOK goes low before allowing
charging again. This guarantees that the circuit will settle down
before we try charging again.
BUG=chrome-os-partner:36081
BRANCH=samus
TEST=can reproduce with an EVT2 samus connected to a DVT samus at
~15% battery. On the DVT samus, allow charging from the other other
samus with charge override. Without this change, most of the time
the PD console goes back and forth between enabling and disabling
charging. With this change, we don't can actually charge briefly,
although there is still a problem where VBUS can dip too low and
cause ACOK to actually go low.
Change-Id: If83def862fb58ef3938e2a443e1a081bd27713ec
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/247460
Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On some systems, recovering from charge circuit being wedged doesn't
happen immediately, and we end up constantly detecting charge circuit
wedged problems and recovering from it. This CL adds a counter to
check_charge_wedged() and reads PROCHOT but does not trigger the
charge circuit wedged until after a certain number of checks after
the last charge wedged condition. This allows more time for the
condition to magically go away before intervening.
BUG=chrome-os-partner:36081
BRANCH=samus
TEST=found two units that were regularly detecting charge circuit
wedged and recovering from it (every 4 seconds, 2 seconds before
detecting the issue and 2 seconds to recover). on one unit, the
problem went away on its own. On the second unit, I loaded this CL
into RO, and ToT in RW, then verified that RO does not continually
trigger charge circuit wedged problems, while RW still does.
Change-Id: I4c4e5c52ad382f178696d61c7b36faf9e8978926
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/247160
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we power swap from a source to a sink and begin charging, VBUS will
never be marked as present, which has bad side-effects when VBUS
disappears and we wish to stop charging.
BUG=chrome-os-partner:36389
TEST=Manual on Samus. Connect Samus-to-Samus and initiate charge
override on the port. Verify that charging from the port begins. Unplug
the cable and verify that the in-OS charge icon disappears. Repeat 10x.
BRANCH=Samus
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I83206c341c0d74991ad60eef411d71d30b5c67a5
Reviewed-on: https://chromium-review.googlesource.com/246781
Reviewed-by: Alec Berg <alecaberg@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With DBC, the backlight transitions are fairly perceptible at low
brightness levels. Smoothing out backlight transitions over a 200ms
period makes these far less perceptible.
BRANCH=samus
BUG=chrome-os-partner:36245
TEST=The following command should read back the value of 0xe7 after
system boot, resume as well as after panel off/on sequence:
ectool --dev=0 i2cread 8 0 0x58 0x15
Change-Id: Ia24b87a0ead179d968cfc1239be757c1822450e4
Signed-off-by: Sameer Nanda <snanda@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/246741
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
REG_CONTROL has two sets of reserved bits:
- Bits 5 thru 7 are read x, write 0.
- Bits 1 and 3 have undocumented function and should not be changed from
read value.
BUG=chrome-os-partner:36360
TEST=Manual on Samus. Cold boot unit and insert 2.4A charger. Verify
that charger is correctly detected.
BRANCH=Samus
Change-Id: I240d352817910eda404b72be13e2c913a4b76079
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/246560
Reviewed-by: Alec Berg <alecaberg@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These are needed for fixed-point math calculations.
Taken from the same public repo where we got the 32-bit divide
routines for Cortex-M0. With minor modifications to match changes
we've made so far for the existing divide routines (put each function
in its own section, delete dead code, etc.)
BUG=chrome-os-partner:36126
BRANCH=minnie
TEST=hack in a debug console command to allow arbitrary int64 divide, see that
it works as expected
Change-Id: I987dbca7c806c71bc38fa816971ac3a54c1641a5
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/244501
Reviewed-by: Alec Berg <alecaberg@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a waste of code, since it trades off a 5-byte buffer for a
4-byte pointer.
BUG=chrome-os-partner:36362
BRANCH=none
TEST=make buildall -j
Change-Id: I2b3336ba2c4804f2781592d2c939ae28e83c846b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/246180
Reviewed-by: Vic Yang <victoryang@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When INA doesn't have power, in order to unwedge it properly,
we need to disable charing AND enable learn mode to disable the
BQ. Without turning on learn mode, the BQ can backboost and
cause ACOK to remain high.
BUG=chrome-os-partner:36081
BRANCH=samus
TEST=load on a samus and test getting the INA wedged using
"charger voltage 7000" and make sure it recovers all the time.
Change-Id: Icc4c508f9db1210e2384cb741a33f50afee191e7
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/245841
Reviewed-by: Duncan Laurie <dlaurie@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Non-SDP ports can be identified as SDP on slow plug insertion. To ensure
no long-term misdetection, automatically do a single re-detection 30
seconds after detecting an SDP port.
BUG=chrome-os-partner:36166
TEST=Manual on Samus. Slow-plug a 1A Apple charger, verify that
detection is originally 500mA. After 30s, verify that detection becomes
1000mA. Also verify that only one additional re-detection is triggered.
BRANCH=Samus
Change-Id: I2babaecdf2252436d1f6b35f5654c14eff9c526b
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/245153
Reviewed-by: Alec Berg <alecaberg@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ignore battery readings over 100%. This fixes a samus bug
where a false battery SOC reading causes charging to
stop.
BUG=chrome-os-partner:36115, chrome-os-partner:36081
BRANCH=samus
TEST=add following code to common/smart.c:
static int reset_soc;
in battery_get_params():
if (reset_soc) {
batt_new.state_of_charge = 65535;
reset_soc = 0;
}
after battery_get_params():
static int command_battsoc(int argc, char **argv)
{
reset_soc = 1;
return EC_SUCCESS;
}
DECLARE_CONSOLE_COMMAND(battsoc, command_battsoc,
"",
"",
NULL);
This changes the battery state of charge to 65535% for one
loop through charge state machine. w/o this CL, on samus the
battery stops charging when you call this, but with this CL
it is fixed.
Change-Id: I44f054a4e84260bd7cd7b77e44b1698645ab6c35
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/244346
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Alex did the reset workaround in power_on function.
<https://chromium-review.googlesource.com/#/c/214360/>
Now, the new version RK808 has fixed this issue, so we needn't this
workaround.
BUG=chrome-os-partner:35976
BRANCH=veyron
TEST=The BUCK1_ON_VSEL register default value is 0x18, and coreboot and
kernel will change this register to other value, but never set 0x18 to
it. So we can read this register in coreboot and print out to console to
check whether the RK808 reset to default after cold reboot. With this
patch, the value always reset to 0x18. I have test on jerry, mighty,
speedy.
TEST=Use "i2cset -f -y 0 0x1b 0x21 0x0f"
Power up system: it should power back up
TEST=Use "i2cset -f -y 0 0x1b 0x21 0x0f"
Press refresh-power: system should reboot
TEST=Use "i2cset -f -y 0 0x1b 0x2a 0x00"
Shut down and power back up.
Use "i2cget -f -y 0 0x1b 0x2a". Confirm back to 0xff.
TEST=Use "i2cset -f -y 0 0x1b 0x2a 0x00"
Press refresh-power: system should reboot
Use "i2cget -f -y 0 0x1b 0x2a". Confirm back to 0xff.
Change-Id: Icfdd3a7eeadce2c597bf286b36bea0aa58cfe4c4
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243202
Reviewed-by: Douglas Anderson <dianders@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When inductive charging just starts, there might be a blip on
CHARGE_DONE signal and it'd cause our charging control logic to shut
down charging. Fix this by waiting for a second before we start
monitoring CHARGE_DONE.
Also, once we see CHARGE_DONE=1 and disable charging, CHARGE_DONE will
go low. Handle this by ignoring all subsequent CHARGE_DONE change until
the next time the lid is opened.
BRANCH=Ryu
BUG=None
TEST=Pass the updated unit test.
TEST=Charge a base on Ryu P3.
Change-Id: I9d911cd689d8e88ebcd66e6eca7c86dd70704880
Signed-off-by: Vic Yang <victoryang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/243365
Tested-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vic Yang <victoryang@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows us to charge at a faster rate.
BRANCH=Ryu
BUG=None
TEST=Charge Ryu P3 in S5 and check charging current.
Change-Id: If8fbaa42d34df45f3d4db35ba50031c511b0c7af
Signed-off-by: Vic Yang <victoryang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/242666
Tested-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vic Yang <victoryang@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allow power button presses which turn the AP off.
TEST=Manual on Samus. Boot system with depleted battery, hit power
button at dev screen and verify AP powers off.
BUG=None
BRANCH=Samus
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I68c9b6c07520992ebba9dcbeccc60ebfb41ca112
Reviewed-on: https://chromium-review.googlesource.com/243710
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Signed-off-by: Todd Broch <tbroch@chromium.org>
BUG=chrome-os-partner:35935
TEST=manual
# With dingdong in C0 & hoho in C1
# Enter GFU mode for dingdong & hoho
ectool --name cros_pd pdsetmode 0 0x18d1 1 1
ectool --name cros_pd pdsetmode 1 0x18d1 1 1
# read logs
ectool --name cros_pd pdlog
2015-01-26 14:36:54.787 P0 SRC
2015-01-26 14:36:54.780 P1 SRC
2015-01-26 14:36:53.680 P0 DP mode enabled
2015-01-26 14:36:53.375 P1 HDMI Codec: family:000e chipid:0001 irom:1.0.0 fw:0.0.0
2015-01-26 14:36:53.771 P1 DP mode enabled
# remove hoho & plug in zinger instead
ectool --name cros_pd pdlog
2015-01-26 14:44:36.991 P1 SNK Charger Type-C 5153mV max 5000mV / 3000mA
2015-01-26 14:44:37.011 P1 SNK Charger PD 5021mV max 20000mV / 3000mA
2015-01-26 14:44:37.116 P1 SNK Charger PD 20211mV max 20000mV / 3000mA
Change-Id: I0289cfd1d43ef1a22123b437bc8df86920fbf1a7
Reviewed-on: https://chromium-review.googlesource.com/243375
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:35935
TEST=manual, see new events for dingdong & hoho. Note must be in GFU
mode to facilitate.
Change-Id: I1b79237512748796cf98765a553af8c9978cb594
Reviewed-on: https://chromium-review.googlesource.com/243374
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BRANCH=samus
BUG=chrome-os-partner:35935
TEST=manual, port & size params are no longer reversed when running
ectool --name cros_pd pdlog
Change-Id: I83e5ad92c260ff71330b7b5c69b30cf3b7e81a98
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243373
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In preparation for supporting multiple mode entry this CL cleans up access to
the mode array via get_modep. Follow-on Cls will enhance that to include svid
lookup for multi-mode support.
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
other modes (check w/ pdgetmode)
3. Works across hard & soft resets
4. Can flash via ectool --name cros_pd flashpd 4 <port> <RW image>
5. adding CONFIG_CMD_USB_PD_PE define still works for 'pe dump'
6. 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.
Change-Id: I7c50c76034bc0ae73b5b019361291c0ff2c21b2a
Reviewed-on: https://chromium-review.googlesource.com/241719
Reviewed-by: Vincent Palatin <vpalatin@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most GPIO/peripheral interrupts are enabled in HOOK_INIT or some other
*_init() functions that are called before task_start(). Quite a lot of
these IRQ handler wake some task to process the interrupt, and this
causes a race condition. If the interrupt is triggered before
task_start() is called, the system may crash/hang/whatever.
Fix this by only allowing rescheduling tasks if task_start() is called.
This is basically the cortex-m version of commit e541eeb2.
BRANCH=Ryu
BUG=None
TEST=Without this fix, my Ryu P3 always crashes when cold resetting from
bootloader mode. After applying this fix, it doesn't anymore.
Change-Id: I0f81e90482ff97469c4f0423d6aa060f2ac76f74
Signed-off-by: Vic Yang <victoryang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/243626
Tested-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vic Yang <victoryang@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The PROCHOT assertion that happens when PECI temp crosses the
Thigh threshold has a severe impact to performance so raise
this value a bit to compensate for the 5C degree change that
was made for broadwell.
This still leaves a few degrees between Thigh and Thalt for
PROCHOT to cool down the system before power will be cut.
BUG=chrome-os-partner:35483
BRANCH=samus
TEST=build and boot on samus, verify table with 'thermalget'
Change-Id: Id29d5100b90c68c59b275592b7f4e1738dd33878
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243243
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we put the touchscreen in reset solely based on the lid state then
we do not allow the kernel driver to properly save and restore controller
state when entering suspend from a lid close event.
Since we want to always have touchscreen in reset in suspend/off state
and not in reset when the system is on then we can just remove this hook
because there is already logic in power_handle_state for that behavior.
BUG=chrome-os-partner:35879
BRANCH=samus
TEST=manual testing on samus:
1) put the device to sleep with lid open and powerd_dbus_suspend,
verify that TOUCHSCREEN_RESET_L=0
2) put the device to sleep with lid close and verify that
TOUCHSCREEN_RESET_L=0
3) check for kernel errors to ensure that there are no issues
saving touchscreen controller registers in the suspend path.
Change-Id: I5bff6356c54f064879a164e9ad4e67f1b2bcce6a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243242
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Misidentifications are still occurring on slow plug insert, so double
the debounce time.
BUG=chrome-os-partner:35633
TEST=Manual on Samus. Plug 1A Apple charger and verify detection is
correct. Test various plug speeds and verify detection is correct on all
but intentional slow plugs (first contact to fully plugged > 1s).
BRANCH=Samus
Change-Id: I1c34a6b8cfd1550d1ae5d3f45d9709277e39c51d
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243328
Reviewed-by: Alec Berg <alecaberg@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Turn off prochot warning on bq24773 by default because our
battery can always supply enough power for the whole system
so we don't need to throttle the CPU if the BQ senses too much
input current.
BUG=chrome-os-partner:34885
BRANCH=samus
TEST=force BQ into it's prochot condition on samus by setting
the charging voltage temporarily below the battery voltage, which
causes INA to turn off and the BQ to think IADP is > 4.1A. in
this condition PROCHOT is normally asserted and CPU slows down,
but with this patch PROCHOT is not asserted and the CPU does not
slow down.
Change-Id: I658dbe568b7bfe94944ef90d6d59656a0683c8a0
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243231
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Several modifications to samus fast charging to fix bug where
charging circuit stops charging the battery.
- Fix bug: if we have a bad temperature reading, fast charging should
ignore it.
- Change the fast charging high temperature profile to set a charging
voltage equal to the maximum of 8.3V and the current battery voltage.
- Divide the normal temperature profile into two phases, low voltage
charging and high voltage charging. Once we transition to second
phase, don't allow it to go back to phase 1 unless AC is removed.
On samus, we have to make sure we never command the BQ to a charging
voltage that is below the present battery voltage or else the INA will
lose power and we will not be able to charge the battery until AC
is disconnected.
This also changes charge_state_v2 so that the fast charging profile
override is called even when AC is disconnected to avoid jumps in
temperature as seen by the fast charging code.
Also changes the voltage threshold for transitioning from phase 1 to
phase 2 of normal temp charging so that the transition is taken a little
earlier to match the desired profile slightly better.
BUG=chrome-os-partner:35491
BRANCH=samus
TEST=Added custom console command to be able to directly control the
battery temperature that charger_profile_override() uses:
static int command_chgtemp(int argc, char **argv)
{
char *e;
if (argc < 2)
return EC_ERROR_PARAM_COUNT;
chg_temp = strtoi(argv[1], &e, 10);
if (*e)
return EC_ERROR_PARAM1;
return EC_SUCCESS;
}
DECLARE_CONSOLE_COMMAND(chgtemp, command_chgtemp,
"",
"",
NULL);
Using this command, I jumped back and forth between all three temperature
fast charging regions and made sure that (1) we never set a charging voltage
below the present battery voltage and (2) we never stop charging the battery.
I ran this test at low battery and high battery percentage and with low load
(G3) and high load (S0 with webgl aquarium).
Change-Id: I035603a4ab48a156ab43f8c93f21200c4b664aab
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243143
Reviewed-by: Duncan Laurie <dlaurie@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add battery cutoff to samus.
BUG=chrome-os-partner:35744
BRANCH=samus
TEST=tested "cutoff" console command cuts off battery
and "ectool batterycutoff" from host cuts off battery
Change-Id: I88194c9c601594dee144933cabef5b1dc536ab0d
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242830
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:35859
TEST=manual, with CONFIG_CMD_USB_PD_PE and hoho in C1
> pe 1 dump
IDENT:
[ID Header] 6c0018d1 :: AMA, VID:18d1
[Cert Stat] 00000000
[2] 50100001 [3] 1100000b
SVID[0]: ff01 MODES: [1] 00000485
SVID[1]: 18d1 MODES: [1] 00000001
MODE[1]: svid:ff01 caps:00000485
Now see only the 2 additional product type VDOs (product, AMA)
Bits still make sense.
[2] 50100001 == 5010:Pid 0001:bcdDevice
[3] 1100000b == 1:hw vers 1:fw version
b:vbus req, USB 2.0 billboard only
Change-Id: Ie8fb74fa55a25ee760009d5a2858a62b0f696c92
Reviewed-on: https://chromium-review.googlesource.com/243080
Trybot-Ready: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Samus panels are spec'ed at 23mA max LED current. Limit the max
current to that.
BRANCH=samus
BUG=chrome-os-partner:35816
TEST=The following command should read back the value of 0x4 after
system boot, resume as well as after panel off/on sequence:
ectool --dev=0 i2cread 8 0 0x58 0x11
Signed-off-by: Sameer Nanda <snanda@chromium.org>
Change-Id: I8f94a8bdc987ca5169ca3b6f8236ab7263ee4ef2
Reviewed-on: https://chromium-review.googlesource.com/242971
Reviewed-by: Eric Caruso <ejcaruso@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: Sameer Nanda <snanda@chromium.org>
Commit-Queue: Sameer Nanda <snanda@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To achieve higher power efficiency, we want the input voltage to be as
low as possible. If the PD source advertise several choices over
PD_MAX_POWER_MW, choose the one with the lowest voltage.
BRANCH=Ryu
BUG=None
TEST=Plug in Ryu to Zinger and check that 12V is selected.
Change-Id: Id8c4da65bfd3dfd174e1fd5528af9f7df7da2a74
Signed-off-by: Vic Yang <victoryang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/242670
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To prevent overloading inductor L2, we can't really draw too much power
from the type-C power. The voltage at L2 is around 4V, and we want to
keep the current below 6A, so let's limit the input power to 24W.
BRANCH=Ryu
BUG=None
TEST=Charge the battery on Ryu while the system is up.
Change-Id: I80f46d7992c64765f4de985e3a9f9492c719907b
Signed-off-by: Vic Yang <victoryang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/242602
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, we only use PD_MAX_POWER_MW for battery power source and
PD_MAX_CURRENT_MA for other sources. This change makes it so that both
limits are honored no matter what the power source is.
BRANCH=Ryu
BUG=None
TEST=Set current limit to 1A on Ryu and charge from Zinger. Make sure
only 1A is pulled.
Change-Id: If9b2451f1351c6548b831d36c8162b2f86f42492
Signed-off-by: Vic Yang <victoryang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/242629
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The battery driver is not reporting battery present state, and as a
result, is_present flag always remain NOT_SURE. Fix it.
BRANCH=Ryu
BUG=None
TEST=On Ryu, 'chgstate' and see 'is_present = YES'.
Change-Id: I84bedc390158797bf1e67e612d0bb3f526292dfa
Signed-off-by: Vic Yang <victoryang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/242970
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Design capacity and Design Energy need to be multiplied by the scaling factor.
BUG=None
TEST=Manual test with hadoken without charging enabled. Observed the battery
level decreasing.
BRANCH=NONE
Change-Id: Icb5f74766c2416128277df4fe1bb00fc7307f5e5
Signed-off-by: Myles Watson <mylesgw@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242890
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
| |
TEST=manual test with the console command. Reset flags are set correctly.
BRANCH=NONE
BUG=None
Change-Id: I3ea4301206be6fe4e79a4b49c002c020980c516d
Signed-off-by: Myles Watson <mylesgw@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242901
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The definitions for the watchdog registers are needed for hard reset.
BRANCH=NONE
BUG=None
TEST=make buildall -j
Change-Id: Ief73b98fbe6fc198c3eda28394e76bdf05568fef
Signed-off-by: Myles Watson <mylesgw@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242900
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix bug if we are executing a power swap to a sink, and we don't
get PS_RDY from port partner, then we transition to SNK_DISCONNECTED
without switching our power role to sink, which could cause us to
get wedged in the wrong state if we also receive a hard reset a
little later because we will have Rd asserted but are will transition
to source role and can never get out of it.
BUG=none
BRANCH=samus
TEST=load onto two samus' and executing a bunch of power swaps. load
custom code on one samus to never send PS_RDY when switching from sink
to source and make sure when power swap occurs the state machine does
not get wedged with the wrong role.
Change-Id: I7eb2bd4d48f32770b8d7a754fee8ac8da35fa949
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242760
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new toolchain is putting again the __enter_hibernate function in
flash (.text) rather than in SRAM (.iram.text) after inlining both the
hibernate() and __enter_hibernate() function.
Workaround this issue by forcing "noinline" on __enter_hibernate().
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=all
BUG=chrome-os-partner:35774
TEST=make BOARD=samus dis
and check the disassembly, the __enter_hibernate is called in SRAM
through a veneer.
Change-Id: I015928ebe18ba8fd93252eece3e8a0fcf4b2a037
Reviewed-on: https://chromium-review.googlesource.com/242691
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the MPU region to modify is empty (size == 0) returns EC_SUCCESS
rather than EC_ERROR_INVAL, so we are not failing MPU activation on
systems without anything in the .iram.text section.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=all
BUG=chrome-os-partner:35774
TEST=on Samus, with WP, try "sysjump disable" on the EC command line
and see "RAM locked. Exclusion 20006ee0-20006ee0" message.
Change-Id: I0103e0f7aa81ee64a70dd47ffb1c50067ce5a6ee
Reviewed-on: https://chromium-review.googlesource.com/242690
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we don't do this, some code later on (like the S3 hook) might check the
POWER_GOOD too early, note that it's on and move to the wrong state:
[8.457344 power button not released in time]
[8.457541 long-press button, shutdown]
// power_off() happens:
[8.459853 power shutdown complete]
[8.593443 power state 7 = S0->S3, in 0x0001]
[8.593653 power state 2 = S3, in 0x0001]
// power_get_signals check happens here ^^^, but POWER_GOOD did not have enough
// time to fall and cause the power_update_signals interrupt
[8.593863 power state 6 = S3->S0, in 0x0001]
[8.594132 power state 3 = S0, in 0x0000]
// system is actually off here
BUG=chrome-os-partner:34816
TEST=Hold Power+Refresh, release after about 10 seconds, the ec should not
have an assertion error and reboot
BRANCH=veyron
Change-Id: Ic7a06a5d255f2b8d056b0b454fc32a4c05c998b4
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242620
Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit 5f954620fa3d36e8e1a88bf7d3963dc7996ec445)
Reviewed-on: https://chromium-review.googlesource.com/242711
|