When an external charger is connected, only the LED on the side the
charger is connected should be on, the other side should be off. The
existing LED behavior was incorrect in that only the side that was
charging was being updated and the other side would remain in its
previous state.
This CL adds a fix so that if only one LED is being controlled, the
other side is always turned off. In addition, the logic for double tap
events was changed slightly so that if a double tap event is in
progress and a charger is connected, the new state will be updated as
soon as the charge state is changed instead of waiting for the double
tap event to complete.
BUG=b:62481906
BRANCH=eve
TEST=Manual With battery level < 15% so that both LEDs are red when
the charger isn't connected, connect charger and verified that the LED
on the side the charger is connected turns white and the LED on the
other side turns off.
Change-Id: I7462629409496383adb43445e732dd6ca2f9f589
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/537960
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
This reverts commit 9565b8ba06.
Reason for revert: This is causing memory test failure under specific
reset conditions that is triggered by a specific FAFT test.
BUG=b:35581264
BRANCH=eve
TEST=pass FAFT test firmware_FwScreenPressPower
Original change's description:
> eve: Set VCCIO rail to 0.85 and disable low power
>
> Set the VCCIO rail to 0.85V where it should be for Y-series parts
> instead of forcing it to 1.0V. The EDS is pretty clear that pushing
> this voltage higher on Y-series parts will have significant power penalty.
> (up to 250mW at 0.95V)
>
> We also don't want this rail dropping in low power mode, which shoudln't
> be happening as S0ix is disabled so SLP_S0 shouldn't assert, but just in
> case disable this as well.
>
> BUG=b:35587084
> BRANCH=eve
> TEST=stress testing on Eve EVT units
>
> Change-Id: I5535fe0d894f283a8d453d61101dfeb6b9287b7c
> Signed-off-by: Duncan Laurie <dlaurie@google.com>
> Reviewed-on: https://chromium-review.googlesource.com/525836
> Reviewed-by: Todd Broch <tbroch@chromium.org>
Change-Id: Ie60ad319421c00df5bf41b9eca03047a37defb88
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/527513
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Set the VCCIO rail to 0.85V where it should be for Y-series parts
instead of forcing it to 1.0V. The EDS is pretty clear that pushing
this voltage higher on Y-series parts will have significant power penalty.
(up to 250mW at 0.95V)
We also don't want this rail dropping in low power mode, which shoudln't
be happening as S0ix is disabled so SLP_S0 shouldn't assert, but just in
case disable this as well.
BUG=b:35587084
BRANCH=eve
TEST=stress testing on Eve EVT units
Change-Id: I5535fe0d894f283a8d453d61101dfeb6b9287b7c
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/525836
Reviewed-by: Todd Broch <tbroch@chromium.org>
Board version 5+ has BD99954 charger which does not have audible
noise when battery is full and charger is at 20V. Disable the
discharge-on-ac workaround for these boards.
BUG=b:37228827
BRANCH=none
TEST=tested on board version 5 that discharge-on-ac is not enabled
when the battery is full.
Change-Id: I72e6870e06328d84a802c2f736659677de1f9a08
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/524222
Reviewed-by: Scott Collyer <scollyer@chromium.org>
The previous LED implementation was modelled on Kevin and enhanced to
give developer feedback. This CL implements the Eve specific LED
operation.
BUG=b:35584895
BRANCH=none
TEST=Manual
Used EC console command 'battfake' to force different charge levels
and verified that the expected LED patterns were generated.
Change-Id: I46bc2889540f320e8aadf3d9d634c36dbc38c161
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/516548
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
The buton behavior is inverted if we follow the schematic, so swap the
GPIO on these inputs so they match the expected behavior.
BUG=b:62120390
BRANCH=none
TEST=manual test of side volume button behavior
Change-Id: I0ad18b4a15fcc2832d97dfad3b03186180e4517a
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/522410
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Nominal eve ALS config is 0.3088 scale.
The default bias for sensor of -256 is a good nominal value so leave
it alone.
BUG=b:37179776
TEST=manual,
boot to linux prompt,
localhost ~ # cat /sys/bus/iio/devices/*/in_illuminance_calibscale
0.308800
localhost ~ # cat /sys/bus/iio/devices/*/in_illuminance_calibbias
-256
Change-Id: I7c8425a38b1af094a39b37b464f812f5ac875083
Reviewed-on: https://chromium-review.googlesource.com/510809
Commit-Ready: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@google.com>
The LED spec requires a double tap gesture. This CL adds the
appropriate CONFIG options to enable double tap gesture for Eve and
enables the interrupt for the bmi160. The board specific function in
this CL is just a placeholder.
BUG=b:35584895
BRANCH=none
TEST=Manual Verifed double tap is detected by seeing the console print
that's generated each time a double tap event occurs.
Change-Id: If3506cf1fbcfc2b380ac36c9d3039e0a8823eba1
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/516547
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
The config option to use interrupts for this sensor was defined,
however, the gpio interrupt for the interrupt from this sensor was not
being enabled.
BUG=b:35584895
BRANCH=none
TEST=Added a wire to the interrupt line on an Eve. Verified that when
the interrupt was triggered (verified by scope) that ISR for this gpio
was being called.
Change-Id: I9d9f6b5e6efa47665aba9a9d024b30aa10528002
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/518523
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Newer Eve boards will lose VBAT on power cycle and therefore cannot
successfully save the reset flag state.
Implement the workaround that will allow these boards to continue to
work for FAFT testing by indicating to the skylake chipset power code
that it should skip the PMIC reset when doing 'reboot ap-off'.
BUG=b:35585876
BRANCH=none
TEST=manual testing on Eve: execute 'reboot ap-off' and ensure that the
AP does not power on. Also ensure that 'dut-control power_state:rec' works
as expected and does not power off at the recovery screen due to a power
button press.
Change-Id: Ida1563593d802c00280a55a0d24a504c25fab532
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/514504
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
With the updated scancode matrix the keymask needs to be adjusted to
not mask off these particular keys.
BUG=b:36735408
BRANCH=none
TEST=build and boot on Eve
TEST=kbpress 0 3 1; kbpress 0 3 0 reports KEY_LEFTMETA as expected
TEST=kbpress 0 5 1; kbpress 0 5 0 reports MSC_SCAN but no key yet
(as expected because the kernel does not handle it yet)
Change-Id: Iba78741b8a0cd1248a799cf5219cee59ea6630ec
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/514502
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Adds min_frequency and max_frequency to struct motion_sensor_t.
New attributes min_frequency and max_frequency are now returned in
ectool's MOTIONSENSE_CMD_INFO response.
Incremented ectool's MOTIONSENSE_CMD_INFO version to version 3.
Add constants for MIN_FREQUENCY and MAX_FREQUENCY to each sensor's
header file.
BRANCH=none
BUG=chromium:615059
TEST=build/boot and verify MOTIONSENSE_CMD_INFO response on kevin,
make buildall -j passes.
Change-Id: I66db9715c122ef6bb4665ad5d086a9ecc9c7c93a
Signed-off-by: Nick Vaccaro <nvaccaro@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/482703
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Instead of using EC hibernate shut down the PMIC over I2C.
This will turn off the DSW rail and the EC completely. The existing
wake sources are still able to wake the system.
BUG=b:35647896
BRANCH=none
TEST=manual testing on Eve board to ensure that wake sources that
are expected to wake from G3 are still functional. (AC, power, lid)
Change-Id: I91b14ec360190176dba0a8e7c458b2b0ab5b6dcd
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/506719
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Enable the mutable scancode sets for EVT boards and reassign the
existing F13 scancode to instead send the new 0[e0 58] 1[e0 07]
scancode instead.
BUG=b:36735408
BRANCH=none
TEST=manual testing on Eve EVT to ensure that the key that used
to send F13 now sends the new scancode. Also test on P1 to ensure
that the key still sends F13.
Change-Id: Ia134db7b069d5bf10c931ee7ce66dd1ea85d3544
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/506718
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
power_button_x86.c and switch.c assume there is a lid switch. This
patch separate them so that a board with power button but with no
lid can be configured properly.
This patch also moves backlight control to the board directory
so that only the boards with a backlight turn it on/off when power
state changes.
BUG=none
BRANCH=none
TEST=boot fizz. make buildall.
Change-Id: If4070cdc4b1221fae68b35ec3497335d81f192fd
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/489602
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Currently, when we jump from RO to RW, we forget our USB PD state.
To recover from this, we send a SOFT_RESET (resetting the counters...),
then either the USB PD partner is happy about it and we can continue,
or it will issue a HARD_RESET to recover from our mismatched vision of
the current connection (e.g wrong role) resulting in a reset of VBUS.
The following use-case is still problematic:
if the system is not write-protected (ie it does USB PD negotiation in
RO EC) and we have no battery (or fully drained-one) as buffer, when we
are connected to a PD power supply, if it issues the HARD_RESET
mentioned above, we are going to brown-out.
It's happening with power-supplies supporting DR_SWAP, the RO EC will
negotiate a power-contract (as a sink), then try to reverse data role
(from UFP to DFP) to identify the power-supply. We end-up being
Sink/DFP, then when we sysjump to RW, we reset roles and send the
SOFT_RESET as Sink/DFP, the power-supply identifies the incorrect data
role and issues the HARD_RESET browning us out.
As a workaround, now we never ask for the DR_SWAP in RO firmware and
stays Sink/UFP.
This is not affecting regular write-protected machines (which are not
doing USB PD in RO EC). For developers, we are no longer doing the
DR_SWAP in RO mode, this is mostly innocuous for a regular power-supply,
but this would break the docking use-case. Normally, we will do it as
soon as we have jumped to RW, so the dock should still work unless the
developer is using the machine with RO EC (eg EC development with
soft-sync disabled).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=reef
BUG=b:35648282
TEST=Boot Snappy without battery. Verify RO image doesn't swap
data roles and soft reset issued by RW image as SNK/UFP is
accepted by the HP adapter.
Change-Id: Id184f0d24a006cd46212d04ceae02f640f5bda65
Reviewed-on: https://chromium-review.googlesource.com/461142
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Sam Hurst <shurst@google.com>
This mode had to be disabled for P1 because of leakages on PP3300_A
that affected the voltage levels on the CC lines. With EVT the leakage
issues have been resolved and now this feature can be enabled.
BUG=b:35648532
BRANCH=none
TEST=With lidopen attached sink only adapter to port 1. Then executed
'lidclose' via the EC console and verified that the port went into low
power mode as expected. In addition, without adapter connected,
verified that when in low power mode the EC console was not flooded
with low power messages.
Change-Id: I281497cc6fe251d48c4ea737c7b4242200d39421
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/496947
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
EVT introduced the Simplo A50 battery pack so need to add this to the
list of possible Eve battery types.
The precharge current level of the battery type is used to set both
the trickle charge and precharge current levels on the Rohm bd9995x
charger. Rohm is advising that this value be set to 256 mA. What we
observe is that when the charge has to operate in buck mode, that the
previous setting of 64 mA is too low. The value of 88 mA was required
for the Lishen P1 pack to no trip it's overcurrent limit in precharge
mode.
BUG=b:37291519
BRANCH=none
TEST=Manual With battery pack at low (~4.2 V), connect blackcat
charger and verified that the battery begins to charge. Without the
precharge current level change, the battery would never charge unless
VBUS was set to 5V.
Change-Id: Iad155de63c6ad4b342791d7024c44fa208b76ab8
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/494080
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
In npcx's fan driver, ec selected mode 5 and capturer A as tachometer's
input. Choosing TB2 as the second tachometer source is not correct since
we didn't initialize the registers for TB2. This patch modified the
second tachometer's input from TB2 to TA2 and passed the verification by
following changes.
1. Add the second fan settings in pwm_channels, fans, and mft_channels
arraies.
2. Modified ALTERNATE marco for pwm-type fans.
3. Set CONFIG_FAN from 1 to 2.
4. Set NPCX_TACH_SEL2 to 1 to test tachometer input 2. (ie.GPIO73/A6)
BRANCH=none
BUG=none
TEST=test dual fans with fanset command on npcx_evb and use faninfo for
verifying. Measure the actual rpm by scope.
Change-Id: Ia1af2732d9a64e24285d12371223eb0e77e53357
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/472310
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Before entering standby mode, bit 7 (cable_det) or analog_ctrl_0 is
cleared. This allows a new cable detect event to trigger the EC to
put the ANX4329 into normal mode. However, in some cases such as when
in S3/S5/G3 chipset power states a port will be in sink only mode and
therefore won't attach when a sink only adapter is connected to the
port. This results in the an indefinite toggle of standby<->normal
mode transitions. This constant toggle floods the EC console and more
importantly prevents the ANX4329 from remaining in standby mode and
the power consumption remains at ~9.5 mW instead of ~1.2 mW when no
adapter is connected.
This CL adds logic around clearing the cable_det bit so that it's only
cleared if both CC lines are open or if an Emark cable is
attached. Emark cable is determined from the presence of Ra on one CC
line and no Rd on the other CC line. The special consideration for an
Emark cable is reqiured because when an Emark cable is connected, the
USB PD auto toggle state may require some number of iterations until
the attach event is recognized.
In order to support handle cases where the drp mode is changed via
either the EC console command or host command, added a call to
tcpm_set_drp_toggle whenever the drp state is updated. Since the drp
mode is updated upon chipset resume events, the chipset resume hook in
board.c for anx74xx_cable_det_handler() became redundant and hence it
was removed.
BUG=b:35775019,b:35586188
BRANCH=reef
TEST=Tested the following cases:
- Sink, source adapters in chipset S0. Verified that adapters
connected as expected. Also, used Emark cable to connect to both USB
PD chargers (source) and Pixel phone (sink).
- Run 'lidclose' on EC console then connect Type C -> A adatper
[3490.370125 TCPC p0 reset!]
[3490.389588 TCPC p0 Low Power Mode]
It no longer toggles indefintely and after running 'lidopen' verified
that port 0 is now in SRC_DISCOVERY.
- In S3/G3 connected USB PD charger with regular and Emark typeC
cable. Verified that port 0 is in SNK_READY state.
- use 'pd dualrole sink' and test with Type C -> A adatper. Verified
that tcpc wakes up, but goes into standby mode until entering 'pd
dualrole on'.
- When sink only adapter is connected in S3/G3, measure power level
~1.2 mW as opposed to ~10 mW in S0.
- Repeated similar tests on port 1 (parade tcpc) to verify that
adapters connected as expected.
Change-Id: Ib8de666f72723934186fee7869f9dda01381c7a8
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/463991
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: S Wang <swang@analogix.corp-partner.google.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
The cable_det signal is used to signal to the EC that the tcpc has
detected a cable being connected when low power mode is
configured. The driver then needs to take the tcpc out of suspend
state by setting PWR_EN and RESET_N high. Then bit 7 of analog_ctrl_0
needs to be set properly.
The code that is handling this transition was attempting to access the
tcpc via I2C before putting the chip in normal mode when
transitioning from suspend to normal. In addition there are issues
with calling the driver function directly from the hook task (in the
delayed ISR handler) and from the USB PD task.
This CL changes the delay ISR handler to only set the TCPC_RESET
indication so that the call to put the ANX3429 into normal from
standby to normal mode only happens in the USB PD task. The TCPC_RESET
event is only set if cable_det is high, but reset_n (to the ANX3429)
is low which indicates that the ANX3429 is currently in standby mode.
BUG=b:35775019
BRANCH=reef
TEST=Manual
Tested with various adapters in both S0 and S3/G3 chipset
states. Verified that adapters connected as expected. When in S3/G3
connecting a sink only adapter still causes an indefinite toggle, but
all calls into the driver are executed from within the USB PD 0 task
and all ANX3429 I2C accesses work as expected.
Change-Id: I6e4843e43f59afbf5ca3251feb68981b815c1c78
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/457103
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
The accelerometer sensors are not needed in S5, and having them get
enabled early in boot is causing issues on a subset of boards.
Similarly, the magnatometer is supposed to be disabled in S3/S5.
BUG=b:36919184
BRANCH=none
TEST=successfully boot on board that was previously failing
Change-Id: I3c079a83b21b2f1875330ac16ef8d3f9da267f9f
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/468686
Reviewed-by: Todd Broch <tbroch@chromium.org>
If we go to sleep with a lid close event, the trackpad is immediately
waking the system. Since we don't want to accidentally wake if the
trackpad got input while the lid is closed anyway this change will
disable trackpad wake when the lid is closed.
BUG=b:35587072
BRANCH=none
TEST=manual testing on Eve P1b:
1) enter suspend by closing lid and ensure it stays in suspend
2) enter suspend by idle, and then close the lid, and ensure
it stays suspended
Change-Id: Ied73dde61e99231f057504ca56c473432aa30e4b
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/457865
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
In order to support waking from Deep S3 the trackpad interrupt
is routed to the EC.
The EC needs to enable this interrupt when going into S3, and
disable it otherwise.
It also needs to filter events and only wake the system when it
is not in tablet mode.
This is accomplished with the following rules:
1) Enable trackpad wake in S0->S3 transition, if !tablet_mode
2) Disable trackpad wake in S3->S5 transition
3) Disable trackpad wake in S3->S0 transition
4) Disable trackpad wake when entering tablet mode in S3
5) Enable trackpad wake when lid angle is <180 degrees and in S3
And finally a check in the trackpad interrupt itself to ensure that
it only sends the wake event if not in tablet mode.
The function to enable or disable trackpad wake uses a static variable
to keep track of the enable state because when enabling the GPIO for
wake it first clears pending events and if multiple transitions are
happening (suspending, plus lid angle rotation) this can get called
multiple times in quick succession.
Currently a placeholder KEY_PRESSED event is used to wake the AP
since we do not have device specific events. Fixing this behavior
is tracked in b/36024430.
BUG=b:35587072
BRANCH=none
TEST=manual testing on eve P1b:
1) ensure that trackpad wake in clamshell mode works
2) ensure that trackpad wake in tablet mode does not waork
3) ensure that if in S3 during transition to or from tablet
mode the wake event is enabled appropriately
Change-Id: Ib2020b5010bdde396a3b05243894431b67edb503
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/450954
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
The led_get_brightness_range and led_set_brightness functions are only
used by the led control host command and exercised via ectool for
factory testing.
Currently the ectool inputs must be inverted to get expected behavior:
ectool led power red=100 green=100 blue=20 << blue
Instead we can invert them in the EC to get more intuitive behavior for
the user input values, and use the led_id parameter to split the control
so they can be addressed individually for testing:
ectool led left red=0 green=0 blue=80 << blue
ectool led right red=100 green=13 blue=0 << amber
BUG=b:36150361
BRANCH=none
TEST=Tested manual control of indivual LEDs using ectool
Change-Id: I6551656f3faf26930749d1e9d45a176088c6646c
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/453303
Reviewed-by: Scott Collyer <scollyer@chromium.org>
To improve robustness of booting under low battery condidtions,
increased the thershold CONFIG_USB_PD_TRY_SRC_MIN_BATT_SOC from 1 to
2. The effect of this change is that try srouce mode will be disabled
until the battery has >= 2% of charge. This prevents the port from
disconnecting, when a USB PD charge is connected under this low
battery condition.
BUG=b:36093023
BRANCH=None
TEST=Verfied that when the battery charge was < 2% the USB PD state
machine on Eve did not go to state 15 (SRC_DISCONNECTED) after
initially attaching as a sink device. When the battery charge is >= 2%
then observed that the transition to state 15 happens.
Change-Id: I50123bc4f98e7a8dc793d9a9844d1d9961fde121
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/452739
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
In order to prevent noise when using the system with a full
battery the EC can disable charging at full until it reaches
97% and then turn on charging again.
However this needs additional LED handling to ensure that the
charging LED is shown green in this state.
BUG=b:36024657
BRANCH=none
TEST=manual test with full battery on Eve P1b, ensure that the
LED is still green when battery is full and discharging.
Change-Id: Iad2b1462ad85163dc9702ff1154f3ff10eb0f7ca
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/450953
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Limit max input current to 95% for safety.
(changes ported from reef)
BUG=b:36024657
BRANCH=none
TEST=manual testing on Eve P1b board
Change-Id: I6beb3fc4ac62e40bb7c8dfc8463e6a0d177997d9
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/450952
Reviewed-by: Scott Collyer <scollyer@chromium.org>
To prevent in rush current from the charger when attached, enable
discharge on AC until the charger is detected.
This required enabling charger profile override which was previously
not getting called, so discharging was never disabled.
BUG=b:36024657
BRANCH=none
TEST=build and boot on eve, ensure battery charges with AC attached
Change-Id: Ie5912c1d4981d894366f36f31607d5f66a04c346
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/450951
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Limit battery charge voltage to prevent battery over-charge due to
regulation inaccuracy.
(ported from reef board)
BUG=b:36024657
BRANCH=none
TEST=build and boot on reef and ensure charging is still functional
Change-Id: I90dd8bda3d67a6c50aa39bbd096239565c73b7c5
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/450950
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Remove the MP2949 workaround as it was only needed for P0 boards.
The fix is "sticky" so any P0 board will already have fixed
values in the MP2949 EEPROM.
BUG=chrome-os-partner:58666
BRANCH=none
TEST=build and boot on Eve P1
Change-Id: I2cb13a6c5ff5ec521e75d51e31fb8356a5081193
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/446594
Reviewed-by: Scott Collyer <scollyer@chromium.org>
When debugging PWM on eve I noticed that every tick was adjusting
the pwm duty cycles for all LEDs, even if nothing changed. To keep
that from happening keep track of the current led state and only
adjust if it changes.
This also modifies the "on+charging" state to not set both LEDs to
blue and then change on to amber, but keep track of which side is
charging and set both LEDs to their expected colors.
Finally it fixes a bug with suspend and a full battery not blinking
the other side white to indicate suspend state.
BUG=chrome-os-partner:58666
BRANCH=none
TEST=ensure LEDs still behave as expected with charging and full
battery while in S0, S3, S5 states.
Change-Id: I98e5d5ad04b3e71da6fa4056e95f3661a9271ecf
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/446593
Reviewed-by: Scott Collyer <scollyer@chromium.org>
P1B adds 2 new GPIO signals to explicitly control the 1.5 vs 3.0
current limit selection. In addition, the use case for the 5V enable
gpio changes to on/off and no longer needs to be toggled between input
and output.
This change is tied to the board version so that the operation for P1
and older boards is unaffected.
BUG=chrome-os-partner:61431
BRANCH=none
TEST=Manual
Connected display adapter into C0 port and verified gpio signals:
1 USB_C0_5V_EN
0* USB_C1_5V_EN
1* EN_USB_C0_3A
0 EN_USB_C1_3A
Then connect another adapter to C1:
1 USB_C0_5V_EN
1* USB_C1_5V_EN
0* EN_USB_C0_3A
0 EN_USB_C1_3A
Remove adapter from C0:
0* USB_C0_5V_EN
1 USB_C1_5V_EN
0 EN_USB_C0_3A
1* EN_USB_C1_3A
Also tested P1 system to verify that the correct board version is read
and the signals match the expected value.
Change-Id: Iebab84304a33282c766b8963dba4a56052a295c7
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/447866
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Until we can understand and fix the reset loop when we enable
low power for the TCPC mux lets just disable that feature.
BUG=chrome-os-partner:63204
BRANCH=none
TEST=build and boot on eve, verify that TCPC does not get in
a reset loop when the system is off.
Change-Id: I646948066a76ab25758e437498f3fb7f533ba6a5
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/446592
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Eve should be able to use the low power idle mode for the npcx EC
to get lower power in S3, and in S5 before we enter hibernate.
BUG=chrome-os-partner:63026
BRANCH=none
TEST=build and boot on Eve, enter S3 or S5 and observe that
dsleep gets enabled after the 15 second console idle timeout.
Change-Id: I7ffb2f56dde1593ec5b041522aa62e075a69b4c9
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/446618
Reviewed-by: Scott Collyer <scollyer@chromium.org>
The TPS61161DRVR used for keyboard backlight expects an input frequency
of 5 to 100 kHz but is currently only getting 100Hz.
With this change the keyboard backlight duty cycle curve behaves as
expected and you no longer need 50% duty cycle to get it to turn on.
Also the keyboard backlight does not need to be enabled in DSLEEP
since that is only possible in S3/S5, so remove the DSLEEP flag.
BUG=chrome-os-partner:61464
BRANCH=none
TEST=test brightness range in sysfs to ensure backlight is visible
at low settings.
Change-Id: I9737827ad4dbd39e342ad370aef46475c273a6bc
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/446617
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Added interrupt handler for CABLE_DET signal on both port 0/1. This
allows us to define CONFIG_USB_PD_TCPC_LOW_POWER.
BUG=chrome-os-partner:63067
BRANCH=none
TEST=Connected USB mouse, keyboard and USB stick to both ports and
verified the devices were recognized and attached properly. Verified
that ports 0/1 always worked with blackcat typeC charger.
Change-Id: I4d8a8bdba4f95e73333e2e01f11fe1d48453a2fe
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/444315
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Added Si114x light sensor to the motion sense struct and enabled it in
polling mode. Also added backward compatibility for the ALS to report
readings via ACPI.
BUG=chrome-os-partner:61470
BRANCH=none
TEST=Enter 'accelinfo on 1000' on the EC console and verify light
readings are present and they increase/decrease as the light pointed
to the sensor changes. Also verifed with AIDA64 app in arc++
Change-Id: I22e0b87034150d2e987987da053de3c312fcc98b
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/440378
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
There are two batteries being evaludated for Eve and there needs to be
a batteery_info struct for each one for situations where the gas gauge
can't be read and the charge state machine uses these parameters.
BUG=chrome-os-partner:62711
BRANCH=none
TEST=Verifed that battery_type is read correctly for both LG and
LISHEN battery units.
On Lishen unit Drain battery completely, then reconnect type C
charger. Verified that battery is now charging. Prior to this CL, the
LISHEN bat would not charge because the internal overcurrent protection
mode would not tolerate the 256 mA precharge current that's specified
for the LG battery.
Tested that both Lishen and LG recovered after forcing a battery
disconnect.
Change-Id: I201eaf61ad03d3dc0d199ab441b07c371bceddde
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/440514
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
The trackpad interrupt is input only to the EC and should not ever
be driven from here.
BUG=chrome-os-partner:58666
BRANCH=none
TEST=build and boot on eve p1
Change-Id: I3ffa2ddb4990550b57c9191b5d721ab0ba206aca
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/439829
This removes CONFIG_USB_PD_TCPC_FW_VERSION.
board_print_tcpc_fw_version is removed since it's no longer called.
PD chip info is printed in usb_pd_protocol.c.
BUG=none
BRANCH=none
TEST=buildall. Boot Electro, verify chip info is printed.
Change-Id: I2ff860c2a1b17ceea124644ba8feb356b9cca2eb
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/434911
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
- Use amber for charge when in suspend/off states and leave red
to indicate something is wrong.
- Blink non-charging LED in S0ix/S3 states.
BUG=chrome-os-partner:60797
BRANCH=none
TEST=verify led operation in s3/s5 while charging
Change-Id: I16660942bf93f7cf6c951c19548c1c6838aabb72
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/438707
Reviewed-by: Scott Collyer <scollyer@chromium.org>
The lid and base matrix were wrong, chrome would enter tablet mode while
in clamshell mode.
Sensors are powered in S3 and S5.
Enable lid angle to disable keyboard while in tent mode.
Disable Trackpad in S5, but just block the interrupt while in tablet
mode and not in S0.
Allow reporting tablet switch mode to AP via ACPI event.
BUG=chrome-os-partner:62385
BRANCH=eve
TEST=When device is laying on a table, lid angle at 180, both sensors
report gravity along Z axis:
ectool motionsense
Motion sensing active
Sensor 0: 368 -368 16752
Sensor 1: 828 -820 16293
When on the base bottom edge, report gravity along Y axis:
ectool motionsense
Motion sensing active
Sensor 0: 256 16160 -976
Sensor 1: 993 16362 -391
Sensor 2: 0 0 0
Sensor 3: 0 0 0
When on its left side, report gravity along X axis:
ectool motionsense
Motion sensing active
Sensor 0: 15968 368 1920
Sensor 1: 16503 219 2430
Sensor 2: 0 0 0
Sensor 3: 0 0 0
Power down machine. Power back up. Check sensors are still working.
Check we can not resume machine while in tent mode from keyboard.
Resuming from trackpad does not work yet.
Change-Id: I4ee6efc57f217d76e5eb97683efa56ceb211cad8
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/437906
Reviewed-by: Alexandru Stan <amstan@chromium.org>
Eve has two charge LEDs. This CL adds support to set a given color for
either left, right, or both LEDs. In addition, the LED policy for Eve
has been enhanced to accommodate separate charge LEDs.
Added amber and white color option plus console command 'led' can
choose the left/right side by adding 0|1 after the color.
S0: Default both LEDs are blue. If charger is connected, then the
active charging port's LED will be amber or green based on battery
level.
S3: If not charging, then both LEDs are blinking white. If charging
then follow same policy as S5.
S5: If not charging, then both LEDs are off. If charging then follow
previous policy, but applied only to the charging port's LED. The port
that isn't actively charging will have its LED off.
BRANCH=none
BUG=chrome-os-partner:60797
TEST=manual Verified the LEDs follow the operation as defined above.
Change-Id: I6f91d8a28999360aa620c7178d48c41625a1fa54
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/437404
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-by: Todd Broch <tbroch@chromium.org>
