If during PMIC initialization, it is identified that there was a VR
fault, then dump fault registers 0x16 and 0x17 to EC console. This
information is very useful during debugging sudden power losses in
field and so it is printed out to EC console.
Additionally, add panic reason with these register values as panic
data so that OS can provide this information in cros ec
panicinfo. This helps in retaining the information even if EC console
logs overflow.
BUG=b:65026806
BRANCH=eve
TEST=Verified that on a VCCIO shutdown, PMIC VR fault is
reported: "PMIC VRFAULT: PWRSTAT1=0x80 PWRSTAT2=0x00"
Change-Id: I583e513f865aeefc7dfc9860ce0ce9789808dea2
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/896163
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
CONFIG_USB_PD_DISCHARGE is now defined automatically if you specify one of
the specified options such as CONFIG_USB_PD_DISCHARGE_TCPC
BRANCH=none
BUG=none
TEST=grunt still discharges using PPC
Change-Id: I94086cfc58bebce9c62ad6aa52b7740b25276d89
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/894676
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
On ISL923x, PSYS output is always enabled when the AP is on
(provided CONFIG_CHARGER_PSYS is enabled).
We add support for charger_get_system_power function, reading PSYS
value, when CONFIG_CHARGER_PSYS_READ is defined. This will be used
by the charging algorithm on lux.
We also rename CONFIG_CMD_CHARGER_PSYS to CONFIG_CHARGER_PSYS_READ
as CONFIG_CHARGER_PSYS_READ provides both "psys" console command
and the new function. We also cleanup unneeded undefs in board
files.
Note that this does not implement the function on bd9995x, but this
could be done without too much effort.
BRANCH=none
BUG=b:71520677
TEST=On lux, without AC connected, check that "psys" output roughly
matches the output current from the battery.
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Change-Id: Ie1ce8e0ac103daacc5a08b8ccae604d1d83551b8
Reviewed-on: https://chromium-review.googlesource.com/848487
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Nearly every board had a buttons array defined in which its contents had
the standard volume buttons. This commit creates a single common
buttons array that can contain the standard volume buttons and recovery
buttons. If a board has volume up and down buttons, they can simply
define CONFIG_VOLUME_BUTTONS and it will populate the buttons array with
the standard definition. The buttons are active low and have a 30 ms
debounce period. Similiarly, if a board has a dedicated recovery
button, defining CONFIG_DEDICATED_RECOVERY_BUTTON will also populate the
buttons array with a recovery button.
BUG=chromium:783371
BRANCH=None
TEST=make -j buildall.
TEST=Flash a device with CONFIG_VOLUME_BUTTONS, verify pressing volume
buttons still work.
Change-Id: Ie5d63670ca4c6b146ec8ffb64d40ea9ce437b913
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/773794
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
The bd9995x driver was written to allow any PD port # to be VBUS or VCC,
but the mapping is broken in a few places. Since all boards use VBUS =
port 0, remove the conversion entirely.
BUG=chromium:781849
BRANCH=kevin
TEST=Verify PD and BC1.2 charging still works on kevin.
Change-Id: I3687866835d1684342d9f746d91b3a6079ab5cc4
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/755000
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Charge port / current selection often needs to be significantly altered
when a battery cannot provide sufficient charge, so have charge_manager
initially enter safe mode. After a battery with sufficient capacity has
been identified, charge manager will leave safe mode, and port / current
selection will return to standard rules.
BUG=chromium:777596
BRANCH=None
TEST=Pass charge_manager unit tests. On kevin, remove battery, attach
Apple PD charger, verify safe mode is not exited and device does not
brown out. Hot-plug battery and verify safe mode is exited. Next,
remove battery, attach to Samus, verify safe mode is not exited and
device doesn't brown out. Hot-plug battery, verify that safe mode is
exited and no active charge port, due to dual-role exclusion.
Change-Id: I7784865750087a037aad8dbbac058b22c77ba6d4
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/733954
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Most boards had an identical implementation for this function,
previously known as board_is_consuming_full_charge(). To reduce copy
paste, let's just move it to common code. Boards that charge ramp
without a battery will have to define their own implementation, but
there probably won't be any boards like that in the near future.
BUG=None
BRANCH=None
TEST=make -j buildall
Change-Id: Ic99a378ac26dfd35d7d718bf9376eacfa8609166
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/748919
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
The compass uses oversampling to produce accurate values.
MAX_ODR is functions of the repetitions setting.
80Hz is too high, calculate the frequency based on preset setting.
Currently, we use 'SPECIAL' that was calculated for Ryu.
BUG=b:68394559
BRANCH=eve,reef,poppy
TEST=Check with ectool motionsense info 3 the frequency is around 30Hz.
Before:
Min Frequency: 781 mHz
Max Frequency: 80000 mHz
After:
Min Frequency: 781 mHz
Max Frequency: 29579 mHz
Check with AIDA64 the compass is not stuck and return changing values.
Fixup of CL/570482
Change-Id: Idcfed1418f59e755e5647d018351c6a7397ffe1b
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/742146
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
According to the USB-C spec, when a debug accessory is identified, we may
optionally establish USB PD communication over CC. Some DTS partners
(eg. servo_v4) expect us to speak PD, so let's make it so. There is no
need for special ACCESSORY states, these do not exist in the PD spec.
BRANCH=servo
BUG=chromium:737755,b:65837068
TEST=On scarlet, attach servo_v4 and verify scarlet charges. Also verify
EC and cr50 consoles are available through servo_v4.
Change-Id: I59d1ca50b4766509eccf38562cdf926578138585
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/693294
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The decision on whether to ramp (and how high) depends on the quirks of
charger identification, so move the decision out of board, into the
drivers that implement usb_charger.
Also, rename CONFIG_CHARGE_RAMP to CONFIG_CHARGE_RAMP_SW, to better
contrast with the existing CONFIG_CHARGE_RAMP_HW.
BUG=None
TEST=Manual on kevin, verify ramp occurs when port plugged into Z840
workstation.
BRANCH=None
Change-Id: I5b395274133837a18a4f4ac34b59b623287be175
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/702681
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Boards that use charge_manager have identical implementations of
typec_set_input_current_limit() and pd_set_input_current_limit(), so
move these functions to charge_manager.
BUG=b:67413505
TEST=`make buildall -j`, also verify that fizz continues to power-on and
boot AP, in both protected and unprotected mode, with barrel jack power
and with zinger.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I99a5314d02c4696db944c0f8ac689405f4f1f707
Reviewed-on: https://chromium-review.googlesource.com/701412
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Replace structure member "level" in power_signal_info with "flags".
"level" has been used on all boards to indicate active-high or
active-low levels. Addition of "flags" allows easy extension of
power_signal_info structure to define various flags that might be
applicable to power signals (e.g. "level"). Going forward, additional
flag will be added in follow-up CLs.
Also, provide a helper function power_signal_is_asserted that checks
the actual level of a signal and compares it to the flags level to
identify if a power signal is asserted.
BUG=b:65421825
BRANCH=None
TEST=make -j buildall
Change-Id: Iacaabd1185b347c17b5159f05520731505b824b8
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/679979
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Reworked suzy-q and suzy-qable all provide Rp, so there is no need for
special detection handling in S5. Also, CONFIG_USB_PD_QUIRK_SLOW_CC_STATUS
is no longer relevant, since we no longer take special action when VBUS
is seen without Rp.
BUG=chromium:737755
BRANCH=None
TEST=On kevin, verify reworked suzy-q and suzy-qable are detected in S5.
Also, verify zinger works in S5 on reef.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I50967bd6415d964a038b2e7d134374132eda11ec
Reviewed-on: https://chromium-review.googlesource.com/656067
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
SYSTEM_IMAGE_RW_B hasn't been globally treated as a RW copy.
This change makes EC treat it also as a RW copy.
BUG=none
BRANCH=none
TEST=make buildall
Change-Id: Iae5a9090cdf30f980014daca44cdf8f2a65ea1f2
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/656337
Reviewed-by: Randall Spangler <rspangler@chromium.org>
we need to properly restart the anx3429 after a firmware update.
simply initializing the chip doesn't seem to get it to reload its
firmware - at least not the portion of the chip that implements the
firmware version register. so, we explicitly power down and reset the
chip before reinitializing it to force it to run the new firmware.
the chip also needs a 10ms "off" time so the reset is properly seen by
the chip, so i did a light refactoring of the code paths that reset
the anx3429.
TEST=used 2 different firmware blobs and verified it switches between
them during software sync.
BRANCH=none
BUG=b:35586895
Change-Id: I967898dd906f21bdc5bc4ce9c1dff9f873d198c1
Signed-off-by: Caveh Jalali <caveh@google.com>
Reviewed-on: https://chromium-review.googlesource.com/631976
In order to satisfy factory testing requirements we need to
boot a bare board with just an AC adapter without requiring
a power button.
However we also don't want to always allow booting of the
battery is present but cut-off (which will indicate BP_NO so
we can't use the existing battery_is_present function) or has
critically low level as it may not immediately boot.
To accomplish this add a function that allows the board to
specify a custom "hardware presence" for the battery that is
separate from the battery presence check.
This CL is taking a change done for Eve and pulling into TOT so it can
be used for other projects that have the same
requirements. https://chromium-review.googlesource.com/c/582544
BUG=b:63957122
BRANCH=none
TEST=manual
Change-Id: Ib1dc4f659adbf0eebd3dc8c3c61b39b8fa36cb4a
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/627113
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
We can re-use our pd_log FIFO for other purposes, such as TPM logging.
Carve out event_log, a generic logging module which pd_log is compatible
with.
BUG=b:63760920
TEST=On kevin, verify PD logging is still functional and entries are
seen in dmesg.
BRANCH=None
Change-Id: I8e6ad6f93e9eebc676aca64652c60f81da471a94
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/597314
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
1) Don't assert prochot by default, this signal has an inverter
and driving it high is asserting prochot until it gets deasserted
during S3->S0 transition.
2) Clear PMIC power source interrupts in pmic_init in case they
were inadvertently set by misbehaving PMIC. The BATTSHORT event
that matters for PROCHOT assertion is masked so it should never
be set anyway, but I found a system where it was set. This register
does not seem to get cleared by an LDO reset so PROCHOT was stuck on
until battery cutoff.
BUG=b:63913242
BRANCH=eve
TEST=manual testing on Eve unit
Change-Id: I5c7f7ca528160972f65bd714deea98357fa43a53
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/579904
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
With the bd99954 charger we do not need to discharge when full,
so remove this config option and the setting of 94% for "full"
battery.
Note that this only affects the battery reporting state, the
EVT systems (board <= 4) will still discharge when full (in order
to prevent the charger noise) but they will now indicate that they
are discharging in this state instead of appearing full.
Newer boards (version > 4) will behave as expected.
This is a compile time option so it isn't something I can easily
support old boards with, but I think it is more important to do
the right thing for new boards.
BUG=b:35585628
BRANCH=eve
TEST=test charge behavior when full on board version 6
Change-Id: I3dd46ae305107b17b3bf8e3ce71578d3400b0f79
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/573091
Reviewed-by: Shawn N <shawnn@chromium.org>
Eve does not use PECI so disable it and remove from the resulting binary.
BUG=b:35581264
BRANCH=eve
TEST=build EC for Eve and ensure peci module is not included
Change-Id: Ie87d789226b2b5f2162ea96cb001a5cb62359213
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/573083
Reviewed-by: Shawn N <shawnn@chromium.org>
Current LED color changes are abrupt. This CL adds a new function
which steps from one color (some RGB combo) to another gradually. When
the new or old color is white, then precomputed steps computed from
HSI space are used. Other transisions involving either just red/green
use linear steps computed dynamially based on the total change.
This CL also creates a new task for the LED code so that the color
transitions won't hold off other hook tasks for too long a period of
time. Changed the LED tick time to be 500 msec as it's no longer tied
to the hook tick.
BUG=b:35584895
BRANCH=eve
TEST=Using EC console command 'battfake', changed reported battery
charge level and verified that the LED patterns still work as
expected. In addition, had debug code which printed to the console
what the R, G, B duty cycle levels were for each transition and
verified the expected values were achieved. Visually compared version
with transitions to the previous version which changed abruptly.
Change-Id: I4e7c19556db9ed6037f2afa05cf348d19aeb18bb
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/562543
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
The Simplo_a50 battery had voltage_max = 8750 mV, which is not correct
and it should be 8800. Since the voltage_max parameter is used with
-0.5% margin, the 8750 mV value resulted in a charger setting of 8704
and does not provide enough of a voltage delta between the charger and
the battery to fully charge packs that exceed the design capacity.
In addition, had the tables for both battery types reviewed by the HW
team and updated some of the temperature parameters.
BUG=b:62483321
BRANCH=eve
TEST=Tested with a dogood unit that was failing to reach 100% charge
and showing very long "time to full" values as the battery charge
approached 90%. After adjusting the voltage_max param, tested and
verified that the battery reached 100% charge. In addition, verified
the bd9995x 0x1A register had the correct voltage setting.
Change-Id: I40e7bc111b048986e824fcb7843e57433a1def84
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/570380
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
The LED pattern for lowest battery level is supposed to indicate that
there isn't enough battery present to boot the AP. The pattern_tbl
array had this value set to 2. However, it's better to tie this to the
constant defined in board.h so that it's consistent with when the AP
will be allowed to boot. In addition, adjusted the battery level
ranges to work correctly with the <= check.
BUG=b:35584895
BRANCH=eve
TEST=Used 'battfake' console command to verify that the patterns
changed at the expected battery charge levels.
Change-Id: Ie85a448ad4803be7e612c382b8e60fa42356d257
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/562542
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
This commit adds support for the PS8805, another Parade Tech TCPC with
integrated superspeed muxes. This also creates a generic Parade Tech
TCPC driver which supports the PS8xxx series.
The current supported TCPCs are:
- PS8751
- PS8805
BUG=b:63508740
BRANCH=None
TEST=`make -j buildall`
Change-Id: I78383af414996e0e8d6220985d286f95267136f8
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/564799
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Use device events for waking the system from Deep S3.
This enables the trackpad and DSP as Deep S3 wake sources and allows
the AP to log them properly.
BUG=b:36024430
BRANCH=eve
TEST=manual testing on Eve with trackpad and DSP wake events
Change-Id: If17698a4901002e1590f4852f970fd9963964cb6
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/555633
Reviewed-by: Shawn N <shawnn@chromium.org>
The Eve board defines left and right LEDs, but the LED control loop is
checking for auto control to be disabled on the power/battery LED IDs.
This is breaking factory testing for LED colors when the battery level
is low because it is flashing RED and ignoring the colors that the
factory software attempts to set.
BUG=b:63049012
BRANCH=eve
TEST=manual testing on Eve with low battery
Change-Id: I65b822111b3054a5994d71ec4e2a089c487acf97
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/549740
Reviewed-by: Todd Broch <tbroch@chromium.org>
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>
