Some platforms are unable to access the 900h-9ffh region over LPC and
must instead access memmap data through the ACPI CMD / DATA ports. To
avoid racing with data updates, disallow changes to multi-byte memmap
data while in burst mode.
Linux currently enables burst mode when accessing multi-byte data and
disables it immediately afterward, though the ACPI spec defines burst mode
in a more general way.
BUG=chrome-os-partner:38224
TEST=Manual on Samus. Undefine LPC_MEMMAP and modify asl to move memmap
data to ERAM at offset 0x20. Verify system boots cleanly and battery
status is updated immediately on plug / unplug.
BRANCH=None
Change-Id: Ib848bdb491fdfece96ad0cee7a44ba85b4a1a50b
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/262072
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The Rp resistor on CC1 is set for a 3.0A capability,
so Vnc (no-connection voltage) is 2.45 V.
CC2 is not connected (captive cable), so for a PD source, it's identical
to being always pulled-up to 3.3V (no sink connection).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:37078
TEST=connect to Samus and see PD activity
Change-Id: I8df0561cea59896d65d9be6523d4eed953851129
Reviewed-on: https://chromium-review.googlesource.com/259301
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Modified version of /board/fruitpie.
Attempted to capture GPIO definitions. Other changes
consisted of modifying functions to enable compilation.
No real functionality as of yet.
TEST=Serial console and I2C functions have been verified
BUG=chrome-os-partner:37078
BRANCH=samus
Change-Id: Iedfc724a058e4220176193ef0f66e5bf45eabbd9
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/252426
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
W25X40 uses a different protection register encoding than our existing
W25Q64 code. Move the SPI ROM option to a config, and add support for
the new part.
BUG=chrome-os-partner:37688
TEST=`make buildall -j`. W25X40 protection code tested in a subsequent
commit.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Iaaeabf42c6c62c20debc91afd2cf8671c14244c8
Reviewed-on: https://chromium-review.googlesource.com/258440
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Previously the EC UART connected to the SensorHub console
was being driven push/pull potentially fighting with a
connected servo. This way servo wins, but at least we
don't drive the line in opposite directions causing a
large current flow.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Change-Id: I02b8e09af6c902b523494b757f4bc7ea4365df2e
Reviewed-on: https://chromium-review.googlesource.com/255954
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Trybot-Ready: Anton Staaf <robotboy@chromium.org>
1. Override the panel backlight enable signal from SoC in llama board,
force the backlight off on lid close.
2. Revise the function llama_lid_event to mtk_lid_event, makes more sense.
BRANCH=master
BUG=none
TEST=lid switch to open/close, observe the LCD backlight behavior.
the backlight should be off, when lid is close.
the backlight should be on, when lid is open.
BOARD=llama
Change-Id: Id1bff440c8bb6cee19c82615e916b8a2f2aa62ac
Signed-off-by: Ben Lok <ben.lok@mediatek.com>
(cherry picked from commit a90516b0a5493a55536e29d550f65cc743156710)
Reviewed-on: https://chromium-review.googlesource.com/255441
Reviewed-by: Rong Chang <rongchang@chromium.org>
Modify charge ramp so that when it ramps it ramps from 500mA and
up to the maximum allowed by that supplier. Also modify Samus and
Ryu to use charge ramping for CDP and proprietary chargers due
to the possibility that they may not be able to supply the amount
that is supposed to be guaranteed by their advertisement.
BUG=chrome-os-partner:37549
BRANCH=samus
TEST=test on a proprietary charger, make sure we can ramp. test
a DCP and make sure we also ramp as before.
Change-Id: I08fd43c8f0b21aa54d114fbe5a1296c9556357e4
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/256972
Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
Limit input current to 2A when battery is near full and we are using
a charger below the boost bypass threshold in order to prevent
charging noise from the charge circuit.
This also changes the threshold at which 5V ramping is allowed to
90% because this is roughly the threshold at which the battery stops
drawing full current.
BUG=chrome-os-partner:36534
BRANCH=samus
TEST=load onto samus. use battfake EC console command to test
various battery states of charge:
- With zinger, verify that at 20V we never limit input current based
on battery SOC.
- With zinger at 5V, verify that >= 90% we limit input current to
2A, and < 90% it's still 3A.
- With 5V BC1.2 DCP, verify that >= 90% we don't ramp, <90% we do.
Change-Id: I868828b5807572736ea58f62bf3596f6416533d2
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/256072
Reviewed-by: Shawn N <shawnn@chromium.org>
Previously the USB Stream buffer sizes were fixed at
USB_MAX_PACKET_SIZE (currently 64 bytes). But that
ended up using up too much packet RAM, a very limited
resource. This change makes them configurable and
adds asserts to insure that the sizes are valid for
the underlying hardware.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Verify that USART forwarding on discovery works
Change-Id: Ib19c0dcfa9b16f23c1d72a5a7fc18026ab103f05
Reviewed-on: https://chromium-review.googlesource.com/255232
Trybot-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Previously the USART and USB Stream drivers exposed in_stream
and out_stream interfaces, which don't allow for sharing their
queues easily. This change converts these drivers over to the
producer/consumer model and updates the two uses.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Verify that the discovery echo functionality is unchanged.
Change-Id: I29f043ab1712373f638e1621378df98647d736cf
Reviewed-on: https://chromium-review.googlesource.com/252820
Trybot-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
For factory testing, when purposely discharging on AC, don't
automatically detect and unwedged charge circuit.
BUG=chrome-os-partner:37171
BRANCH=samus
TEST=plug in AC and run: "ectool chargecontrol discharge". check
on ec console that battery is discharging. let sit for 3 minutes
and make sure charge circuit unwedge code never runs. run
"ectool chargecontrol normal" and make sure battery starts charging
again.
Also force discharge with "ectool chargecontrol discharge" and then
unplug and replug AC, make sure battery is not charging nor
discharging, then set mode back to normal and make sure we start
charging again.
Tested without this CL and everytime you force discharge the charge
unwedge is activated and messes everything up.
Change-Id: Icc7a504c148e1e08777e7aafce64ff4cc38a32c5
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/254722
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
If we're sourcing VBUS, there is no need to proceed with the pericom
debounce / reset procedure, since we know that we're not charging.
BUG=chrome-os-partner:37137
TEST=Manual on Samus. Insert USB keyboard, verify that pericom reset
doesn't occur. Insert SDP port + Apple charger, verify that pericom
reset / redetection still occurs.
BRANCH=Samus
Change-Id: I1a616f6e2287cd474b94e8fb61c19514d2ec2042
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/254140
Reviewed-by: Alec Berg <alecaberg@chromium.org>
The npcx chip and evb use a SPI flash chip to hold the EC image. They
don't need pstate, and should use the SPI flash status register
directly.
1. Remove CONFIG_FLASH_PSTATE from npcx_evb.
2. Remap WP_L GPIO to GPIO 93 (this should be the same as the write protect
line to the SPI flash chip).
3. Change the npcx flash driver so that it directly reads/writes the SPI
status register instead of mucking with pstate.
BUG=chrome-os-partner:34346
BRANCH=none
TEST=manual
Add a switch or jumper to the EVB so R1 can be closed.
Toggle the switch and see that WP_L state changes. Leave enabled.
flashinfo -> nothing is protected, WP_L is enabled (=0)
(also do this after each flashwp command to check the protection status)
flashwp enable -> RO is protected now and at boot.
reboot
flashwp enable -> RO is still protected.
flashwp disable -> RO is still protected. (because WP switch is enabled).
Toggle the switch so WP_L is disabled (=1)
flashwp disable -> Succeeds, flash is not protected
Change-Id: Ifa959bce69f8eb4724057ecaa6a6c5075783c19d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/253633
Reviewed-by: Shawn N <shawnn@chromium.org>
This signs the RW firmware (with a non-secret key). The RO
firmware will verify the RW firmware and jump to it if it's good.
Note that this isn't the final solution, just the beginning.
BUG=chrome-os-partner:37071
BRANCH=none
TEST=manual
Build and install it. You'll see something like this:
--- UART initialized after reboot ---
[Reset cause: reset-pin hard]
[Image: RO, cr50_v1.1.2929-27e1b82-dirty 2015-02-24 14:36:29 wfrichar@wfrichar-glaptop]
[0.000444 Verifying RW image...]
[0.423742 RW image verified]
[0.423946 Jumping to image RW[0.428492 UART initialized after sysjump]
[Image: RW, cr50_v1.1.2929-27e1b82-dirty 2015-02-24 14:36:29 wfrichar@wfrichar-glaptop]
[0.428931 Inits done]
Console is enabled; type HELP for help.
>
> sysinfo
Reset flags: 0x00000c02 (reset-pin sysjump hard)
Copy: RW
Jumped: yes
Flags: unlocked
>
Change-Id: Icafa554baca135ff1f80cbce4dad5f980e7fc122
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/253081
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Refactoring effort to unify the set of PD intialization tasks that
need to occur. Those areas include:
1. host mode as it relates to power & pull-ups/downs
2. PD tx init
3. PD mux settings
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:36481
TEST=manual,
1. compiles and functions on samus_pd
2. If sysjump w/ dongle connected than alternate mode re-entered
properly including muxing and HPD
Change-Id: I47f32acaeccbd7745e1e01a8b085b1804c4c5000
Reviewed-on: https://chromium-review.googlesource.com/249273
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
Issues fixed on 0216:
1.Modified CONFIG_KEYBOARD_COL2_INVERTED support in keyboard_raw.c
2.Modified warm_reset checking in gpio.c
3.Modified system_get_chip_name in system.c for package info.
4.Modified fan.c and pwm.c for:
● If the DCRn value is greater than the CTRn value, the PWM_n signal is always low.
● Fan stall condition event:
If the measured fan speed is lower than the lowLimit value (unless the Fan Speed Low Limit value is 0) or in case of erroneous measurement, the userCallback is called.
5. Change cycle_pluses to 480 in board.c
Issues fixed:
1. Jump data at top of RAM is getting corrupted. Changed the flag to
RESET_FLAG_RESET_PIN. Added a workaround method to fix VCC1_RST
issue.
2. Hibernate wake need to report whether wake reason was GPIO or RTC
3. Hibernate wake must be distinguishable from watchdog reset. The
booter will log reset reason in Code RAM. I copy the log data to
battery-backup RAM in little FW. And system driver will refer this
data to distinguish if it's watchdog reset or not.
4. Watchdog reset flag is not set. Same fix as 3.
5. Should return error if unable to clear SPI flash status register.
6. Remove chip_temp_sensor.c
7. Remove use of pstate from flash driver
8. Remove support for watchdog warm reset
9. Keyboard raw driver must support COL2 inverted
10. LPC memory mapped data must be read-only from host
11. LPC should support PLTRST# signal
12. Problems reading chip type/version. Use core registers and ROM data to read IDs.
13. When chip type/version is unknown, report hex value.
14. Watchdog does not consistently print panic information.
15. Remove console force enable logic.
16. Enable only the peripheral clocks that are needed. Please notice
user should add bit mask in CGC_XXX_MASK if they want to enable
additional module. For example, if user wants to enable PWM3, he must
add PWDWN_CTL2_PWM3_PD bit in CGC_PWM_MASK.
Please see HOOK_FREQ_CHANGE and HOOK_INIT these two hook functions.
If I turn off all I2C modules in system_pre_init and turn on the
modules I need in i2c_init, I found its freq is not correct. The root
cause is hook_notify(HOOK_FREQ_CHANGE) is executed first (in
clock_init) before i2c_init. At this time, i2c modules are power-down
and writing to freq register is useless. I re-execute freq-changed
hook function after turning on modules again.
17. MPU properly configured to prevent code execution from data RAM
18. Partial nvcontext implementation. Copy these 16 bytes in our battery-backup RAM.
Additional items we also modified:
1. pwm.c: Support open-drain IO type of PWM. (PWM IO-Type cannot by
determined by GPIO, we use bit 1 & 2 of function byte of gpio_alt_func
array to support it)
2. ec_npcxflash.c: Use definition to replace constant value. Stop
watchdog during flash programing.
3. npcx_cmds.tcl: Adjust script sequence for robustness. Add unlock
MPU commands for Data RAM.
BUG=chrome-os-partner:34346
BRANCH=none
TEST=manually verify changes
Change-Id: I722a77d29e7543b054819480c7b7477af4263119
Signed-off-by: Ian Chao <mlchao@nuvoton.com>
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/248670
Make sure the EC sends the battery state of charge to the PD every
time it changes.
BUG=none
BRANCH=samus
TEST=create command to fake battery percentage in
driver/battery/smart.c:
static int cmd_battfake(int argc, char **argv)
{
char *e;
if (argc > 1)
batt_fake = strtoi(argv[1], &e, 0);
return EC_SUCCESS;
}
DECLARE_CONSOLE_COMMAND(battfake, cmd_battfake, NULL, "", NULL);
and in battery_get_params():
if (batt_cap > -1)
batt_new.remaining_capacity = batt_cap;
On samus use battfake command to change battery percentage back and
forth every few seconds for minutes and make sure the PD receives
host command 0x100 and that it is still happy.
Change-Id: Ic69ab2af900fa2a38e3d2f6562675684487f556e
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/252350
Reviewed-by: Shawn N <shawnn@chromium.org>
Change USB type-A ports to default to CDP. The port will
automatically revert back to SDP if it needs to.
BUG=chrome-os-partner:36876
BRANCH=samus
TEST=load on samus, make sure ports advertise as CDP by
connecting A to C port to charge itself (note this causes
other problems, but good enough to make sure we detect
CDP).
Change-Id: Ic09b31788557d2c6ff4292c62a2ac0168b136c64
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/251834
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Add charge ramp module to samus. For BC1.2 DCPs allow ramping
up to 2A, and for BC1.2 SDPs allow ramping to 1A.
BUG=chrome-os-partner:34946
BRANCH=none
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: I63d4ba38f2e137aff32831386f1bde2cc7c57850
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/249934
Commit-Queue: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
Remove resetting pericom 30 seconds after detecting SDP. This
is not helpful anymore since we have fixed pericom detection
problems and have a charge ramp for SDPs.
BUG=chrome-os-partner:36813
BRANCH=samus
TEST=connect samus A port to samus C port. this detects as
SDP and ramps to 1A, but every 30 seconds resets the pericom.
with this change it detects SDP, ramps to 1A and stays constant.
Change-Id: I2400a06d237cef8c03f921960954dcf54d93de1e
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/251583
Reviewed-by: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
The VCORE_PGOOD signal to the EC goes through a buffer which is
powered by PP1050_VCCST that itself is gated by SLP_S3. Until
this point the input is invalid and may be oscillating so only
enable it as an interrupt once we are in S3->S0 state.
BUG=chrome-os-partner:36864
BRANCH=samus
TEST=boot on samus to ensure power sequencing still works properly
Change-Id: I90ad3b578297a5194c110407be1cba2d65226290
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/251324
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Since we have RAM to spare, increase the stack sizes of certain tasks
that may come close to stack overflow.
BUG=chrome-os-partner:36914
TEST=Manual on samus / samus_pd. Run task_info, verify new task stack
sizes.
BRANCH=Samus
Change-Id: Id667f963bffbf7776e7cbe07b7e7d34f4ac27398
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/251420
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Add i2c retries to backlight control. Also check return value,
if i2c transfer fails, do not continue.
Also modified backlight control so that we only send I2C commands
when backlight chip is enabled (in S0 and lid is open).
BUG=chrome-os-partner:36803
BRANCH=samus
TEST=test suspend/resume and booting and make sure panel always
comes up.
Change-Id: I0dd71c12d0c3f64a08fb389c37f64b1b0ac16fb8
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/250670
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This separates the configuration of the ARM core GPIOs from the
routing of internal peripherals to external pins. Both are still
described in the gpio.inc file, but are less dependent on each
other.
BUG=chrome-os-partner:33818
BRANCH=none
TEST=manual
Before this CL, running "sysjump rw" or trying to use more than 8
GPIOs caused hangs and reboots. Now it doesn't.
Change-Id: If962a7c5ad4136837b2ea00ae016a440f07d7e23
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/251015
Reviewed-by: Sheng-liang Song <ssl@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
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>
Add charge ramp module to samus. For BC1.2 DCPs allow ramping
up to 2A, and for BC1.2 SDPs allow ramping to 1A.
Charge ramp is disabled when in RO and write protected.
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.
tested in RO and write protected, BC1.2 chargers do not ramp. when
you jump to RW it does ramp.
Change-Id: I7c36c8fb0a34139c69a475307c325f891099b3dd
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/249933
Reviewed-by: Shawn N <shawnn@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>
Make new VBUS charge supplier for Samus and Ryu which allows
default 500mA charging when VBUS is present. Before this was
accomplished via the type-C supplier, but type-C supplier should
only be used for 1.5A and 3A pull-up. VBUS supplier is lowest
priority so that any other supplier will take precedence over
the default charging rate.
This work is done in preparation for charge_ramp module where
we don't want to ramp for typeC supplier.
BUG=chrome-os-partner:34946
BRANCH=samus
TEST=make sure we can boot without battery on samus, and test
other chargers including legacy chargers, zinger, and donette.
Change-Id: I89f1e9520e4bf9e5debbaf8dd2de1262154eecf8
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/250312
Reviewed-by: Shawn N <shawnn@chromium.org>
Change unwedge code to not attempt unwedging circuit if VBUS is
at 5V because the circuit can't wedge itself at 5V. If BQ PROCHOT
is high, we should just read it to clear it, and move on.
BUG=chrome-os-partner:36081
BRANCH=samus
TEST=test with ramp code. make sure ramp never gets stuck at
minimum value because we are in the middle of unwedging the
circuit when ramp starts.
also test that manually wedging charge circuit with zinger using
"charger voltage 7000" is still recovered from.
Change-Id: I209bf324eab39bdca1948b7764870a909ea480c8
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/250463
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Fix booting without battery by avoiding waking the extpower task
until it has run extpower_board_hacks() the first time.
The problem was if there was no battery and AC was attached,
extpower_board_hacks() would run twice on boot, once in extpower
task initialization, before the while(1) loop, and a second time
due to the AC_PRESENT interrupt. This would cause
extpower_board_hacks() to think that AC had transitioned from 1
to 1, which represents a glitch on ACOK, so it would disable
charging, thus causing us to lose power.
BUG=chrome-os-partner:35570
BRANCH=samus
TEST=load on a samus and boot with and without battery
Change-Id: Idf6d0022f7dbedbb66a2fbe1c2b7dd885eabc43b
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/250301
Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Increase extpower task stack size due to occasional stack
overflow in extpower task on plugging/unpluggin AC.
BUG=chrome-os-partner:36760
BRANCH=samus
TEST=load onto samus, connect/disconnect a bunch of times
and check high water mark on stack usage: 368/512
Change-Id: I4531176ce6f15356a2267cdecf907a7694567da9
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/249920
Reviewed-by: Shawn N <shawnn@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>
This is another workaround for charge circuit wedging. It appears
that the BQ PROCHOT is not entirely reliable at detecting charge
circuit wedged, so let's take a big hammer to this and say if
we have a >5V charger and we haven't been charging for a while,
then attempt to unwedge the charge circuit. Only impact on user
is the battery won't charge quite as fast since we stop charging
briefly to unwedge the circuit.
BUG=chrome-os-partner:36081, chrome-os-partner:36620
BUG=chrome-os-partner:36636
BRANCH=samus
TEST=remove the PROCHOT check and wedge the circuit using "charger
voltage 7000" and make sure that we unwedge after 10s (or 2min
if we never recovered from last time).
Change-Id: I6a0d83aef5fcfdecaeb85367d8207aeea7a99c06
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/248940
Reviewed-by: Shawn N <shawnn@chromium.org>
Commit-Queue: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
VCONN should be off at the start of pd task. This is handled
initially by the defaults in gpio.inc. However in the case of a
sysjump after a RW only firmware update the previous state would be
preserved.
This in turn would allow us to evaluate polarity incorrectly if an
accessory was connected in the CC2 polarity and subsequently enable
both VCONNs which would leave the port with both CCx lines at 3.3V.
This change adds a new function, pd_config_init, which initializes
VCONN(s) to off. Future CLs will evaluate other PD related GPIOs that
may be left unitialized as a result of sysjump.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:36481
TEST=manual,
1. Boot samus w/ samus_pd in RO
2. connect hoho | dingdong in CC2 polarity to type-C port
3. sysjump to RW
4. unplug / plug hoho | dingdongs
No longer see both VCONNs enabled.
Change-Id: Ia53c06ea8face4da6829f9667f4f44a9034183be
Reviewed-on: https://chromium-review.googlesource.com/248831
Trybot-Ready: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
Fix bug recently introduced in 1ab9aac that causes some units to not
charge after an EC reboot with zinger plugged in. The problem is that
we don't log the previous state of ACOK on initialization of the
extpower task. So, the PD MCU gets stuck in charge state NONE when
you unplug zinger because the EC thinks that ACOK transitioned from
low to low.
Fixed in two ways: first, the EC stores the initial state of ACOK when
extpower task first runs. second, changed extpower_board_hacks() to
run the same code when ACOK goes from low to low as it does when it
goes high to low.
BUG=chrome-os-partner:36596
BRANCH=samus
TEST=Found a unit that reliably shows the problem. loaded this fix in
RO and ToT in RW. sysjump RW with AC plugged in, then when you unplug
AC, the PD goes to chgstate NONE and won't ever charge on subsequent
attaches. sysjump RO with AC plugged in, then when you unplug AC, the
PD acts as normal and goes to chgstate NONE and then 5V, and will
allow charging every time AC is subsequently attached.
Change-Id: I4124535b17d43a5711586ff2894df67a3bd49ec6
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/248170
Reviewed-by: Shawn N <shawnn@chromium.org>
