First implementation of a low power idle task for the LM4 chip. The
low power mode is selected by defining CONFIG_LOW_POWER_IDLE in a
board.h file. This commit turns it on for Peppy, Slippy, and Falco
only because those are the only boards tested.
When using the low power idle task, the chip goes in to deep sleep
when it can. Deep sleep disables clocks to most peripherals and puts
the onboard flash and RAM into a low power mode. The chip is woken
out of deep sleep using the RTC in the hibernate module. Increased
the idle task stack size to handle more involved idle task.
In board.c, the array of GPIO info can be used to select which GPIO
points can wake up the EC from deep sleep. Currenlty selected are
the power button, lid open, AC present, PCH_SLP_S3, and PCH_SLP_S5.
Additionally the port with the KB scan row GPIO point is also
enabled to wake up the EC from deep sleep.
Signed-off-by: Alec Berg <alecaberg@chromium.org>
BUG=None
BRANCH=none
TEST=Passes all unit tests. Runs on slippy, peppy, and falco with no
noticeable side affects. Verified that the power consumed by the EC
is lower when in S3, S5 and G3 by scoping the sense resistor
powering the chip.
Change-Id: I83fa9a159a4b79201b99f2c32678dc4fc8921726
Reviewed-on: https://chromium-review.googlesource.com/172183
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
Tested-by: Alec Berg <alecaberg@chromium.org>
When the EC CPU is running at a decreased clock frequency, frequent
keyboard scans can starve other EC tasks of CPU and lead to dropped
data or watchdog timeouts.
Enforce a minimum number of EC clocks between keyboard scans to
prevent this from happening. The default chosen (16000 clocks) is
equal to the shortest post-scan delay (1 ms) of any current board when
the AP is in S0, so this should have no effect when the AP is in S0.
When the AP is in S3 or S5, we don't need to scan the keyboard as
frequently anyway. This can be overridden on a per-board basis for
future boards if needed.
BUG=chrome-os-partner:23247
BRANCH=pit
TEST=apshutdown, then hold down a key for 10 seconds. Should not see a
watchdog reset.
Change-Id: I228f53a32ad4769f6a137a9ab06903111bea115d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172895
Reviewed-by: Vic Yang <victoryang@chromium.org>
Rambi's Silego chip inverts the pull as well as the signal. So it has
a pulldown for the signal instead of a pullup. The EC must drive the
signal push-pull, since open-drain only works for signals with pullups.
BUG=chrome-os-partner:23198
BRANCH=none
TEST=type on keyboard; C/D/E/3/F1-F4 should all work
Change-Id: Iaea4f540c523824571a568b70cca3e0fb467f79c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172915
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
On HASH_START command, we should also fill in hash status in response so
that the caller sees BUSY status in response.
BUG=chrome-os-partner:23067
TEST=Along with u-boot change, corrupting EC RW followed by a warm reset
doesn't result in shutdown.
BRANCH=All
Change-Id: Ie0c1b35d71bc0420b011f0413f92feb88138db4d
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172380
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This is an initial version of power sequencing for the rambi rev.1
boards. It has a workaround for a rev.1 board problem; this requires
turning on PP5000 early.
BUG=chrome-os-partner:22895
BRANCH=none
TEST=AP should power on to S0 (PLTRST# deasserts) automatically when EC boots
Then 'apshutdown' should drag it back to G3.
Then 'powerbtn' should take it back to S0.
Change-Id: Id9bc6fe9b55fce3eb46ce1265891724ec7a4ae20
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172675
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The Silego chip used on Rambi inverts column 2. So the EC should pull the signal low when NOT scanning column 2, and release it at all other times.
BUG=chrome-os-partner:23198
BRANCH=none
TEST=not yet; need to probe on scope
Change-Id: If6a784493533f11ae54d18f27591697e69aa2282
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172674
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Created a new function to enable or disable clocks to various
peripherals. This new function makes it easy to specify if you
want the clock enabled in run mode, sleep mode, and/or deep
sleep mode.
Added infrastructure to specify which GPIOs should interrupt the
EC from deep sleep.
BUG=none
BRANCH=none
TEST=Passes all unit tests. Ran on a peppy and verified that
the clock gate control registers in run mode (LM4_RCGC regs)
were the same before and after this change.
Change-Id: Ia5009ac8c837f61dca52fe86ebdeede2e1a7fe4d
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172454
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Fixes hibernate delay logic for chipset x86. With this change
the machine will go in to hibernate one hour after going into G3
when running off battery.
BUG=chrome-os-partner:23224
BRANCH=none
TEST=Used console command hibdelay to set a reasonable hibernate
delay time and tested all combinations of running off battery vs.
AC and shutting off before or after the machine has been on for
a hibdelay amount of time.
Change-Id: Idd94d3677669dcd405732195b8cbbc1edca1e171
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172512
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
PWRBTN_L is pulled up to PP3300_PCH_S5 through a 30K resistor. However,
the PWRBTN_L pin was configured push-pull. So we are leaking into that
rail. Fix this by configuring it to be open drain.
BUG=chrome-os-partner:23221
BRANCH=None
TEST=Loaded new EC with change and noted the PP3300_PCH_S5_PG is driven
low correctly once the PP5000_DSW rail is up an SUSP_VR_EN=0.
Change-Id: Id6d5079ca0c11c36b00ed913be378f53b48f27f3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172520
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If we do this:
enum foo_v {
FOO_A,
FOO_B,
FOO_COUNT
};
struct foo_t foo[] = {
{...},
{...},
};
BUILD_ASSERT(ARRAY_SIZE(foo) == FOO_COUNT);
Then we can be sure we're at least initialized all the elements of foo,
although there's no particular guarantee that the order is correct.
However, if we use this:
struct foo_t foo[] = {
[FOO_A] = {...},
[FOO_B] = {...},
};
and we accidentally get one wrong:
struct foo_t foo[] = {
[FOO_B] = {...},
[FOO_B] = {...},
};
Then the assertion still passes, but we've only initialized one element.
Don't do that.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=manual
Refactoring only. Build everything. It should still work.
Change-Id: I58f659207990f18c6fb74b1cac2ec1163cdb07ea
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172115
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Rambi has a pair of LEDs which are attached to the PWM fan controller.
Add support for them. Also add a generic 'pwmduty' command which can
be used to get/set the duty cycle for any PWM channel.
Also fix rounding errors in pwm module, so that set/get duty doesn't
keep rounding down.
BUG=chrome-os-partner:22895
BRANCH=none
TEST=Boot rambi. LEDs are off.
pwmduty -> both are 0%
pwmduty 0 10 -> green LED on dimly
pwmduty 1 10 -> red LED on dimly
pwmduty 0 99 -> green LED on brightly
pwmduty 1 100 -> red LED on brightly
pwmduty 1 0 -> red LED off
pwmduty 1 -1 -> red LED turns back on because fan controller is disabled
pwmduty -> channel 0 at 99%, channel 1 disabled
Build all platforms. Pass all unit tests.
Change-Id: Ib0a6289a757554e696a9a0153a85bdc34e2ee2ae
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172094
battery.h is the high-level interface. battery_smart.h is the
low-level interface. Most things don't need the low-level interface,
but were including smart_battery.h solely to get at battery.h. Fixed
this. Also merged battery_pack.h into battery.h, since it was odd to
split that data across multiple header files. Tidied the function
comments in battery.h as well.
No functional changes, just renaming files and adding comments.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all boards; pass unit tests
Change-Id: I5ef372f0a5f8f5f36e09a3a1ce24008685c1fd0d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171967
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The LED state machine ends up being very board-specific, as does the
specific configuration of LEDs and whether they're PWM'd or just
GPIOs. dparker has some clever ideas for how to move more of the
functionality to common/led_common.c (used at present only by peppy);
that will be done as a follow-on to this CL.
There's a unit test for the spring LED implementation. To keep that
compiling, just use a symlink to the spring-specific implementation.
No code changes; just moving around files.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all boards; pass unit tests
Change-Id: I5973e701a29a72575db9a161dc146855ab21cca6
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171771
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
We only used I2C_PORTS_USED to iterate through the list of hardware ports
actually in use, but we defined it in board.h at the same place where we
matched particular I2C devices to the (possibly shared) buses they're on.
This CL makes I2C_PORTS_USED into a global constant, so it can be set
automatically where we initialize the ports, and doesn't have to be
related to the list of attached devices.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=manual
Build everything, run all tests, should still work.
Change-Id: I65f22f5cadfc4b3afe51af48faa5fb369bc3aa09
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171884
The fan was not spinning enough to cool the system because it thought
the max fan speed was 5000.
BUG=none
BRANCH=bolt
TEST=build and boot on bolt, generate load and see that the fan comes
on to a reasonable level to cool the system.
Change-Id: Ifa5023534a6be8625abf7df7fa44aed649f4fabc
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171969
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Copied from Bolt.
This is so the 30-second wait when no battery is installed can be skipped.
Note that if we ever decide to monitor the battery temp through the BAT_TEMP
line, we'll have to rethink how battery_is_connected() is implemented, since
we can't reliably treat that GPIO as both digital and analog simultaneously.
BUG=chrome-os-partner:22870
BRANCH=none
TEST=manual
cd src/platform/ec
make BOARD=samus
make runtests
Change-Id: Ifea952c8f99b2b40c2fab382e949958a2f71d157
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171796
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This is so the 30 second wait when no battery is installed
can be skipped.
Since Bolt needs a complete AC+Battery disconnect when updating
the BIOS this 30 second wait is aggravating.
BUG=chrome-os-partner:20448
BRANCH=bolt
TEST=disconnect AC+Battery, then connect AC and watch it boot
without waiting for 30 seconds.
Change-Id: Ibaf42fe1dba9c74aa465aa0a1a5381ba6981f66e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171689
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Dave Parker <dparker@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
include/config.h should have the canonical list of all CONFIG_* macros used
everywhere else. This fixes some that weren't included, and some that had
been changed in one place but not in others.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=manual
Build everything. It should still work.
cd src/plaform/ec
make runtests
for i in bds bolt daisy discovery falco kirby link mccroskey peppy pit puppy rambi samus slippy snow spring; do make BOARD=$i || touch died.$i; done
There shouldn't be any died.* files.
Change-Id: I0a1ec2d57668509c514dc5a521e547836a3e9894
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171690
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This is the first attempt at wiring the GPIOs for Samus. More to come, of
course.
BUG=chrome-os-partner:22870
BRANCH=none
TEST=manual
The only thing we can check is that it compiles and doesn't break anything.
cd src/platform/ec
make BOARD=samus
make runtests
Change-Id: Ia9dc94c420c21551c5db3e28e749954cea3055a1
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171528
Slippy, Peppy, and Falco should learn to spell.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=manual
make runtests
Nothing uses this, it's just annoying to look at.
Change-Id: I61e09fc6a804c1de972b34520db1db8f0b874dbe
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171567
Link is the only platform that uses smart usb ports. Link's board.h defines
USB_CHARGE_PORT_COUNT, yet the usb_port_power_smart.c file is peppered with
assumptions that that constant is always 2.
This moves the constant into usb_port_power_smart.c where it belongs.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=manual
make runtests
Code refactoring only, no visible changes,
Change-Id: Id45e11d88585a98348105b1399c7e18c554add50
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171565
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The PMU charger loop is conservative. And there is no need to set
hardware low charging current termination.
BRANCH=pit
BUG=chrome-os-partner:22946
TEST=manual
Discharge the battery to level < 40%.
Issue console command 'pmu', check register 0x09 output.
The NOITERM bit(5) should be set to 1. That means no low charging
current termination.
Signed-off-by: Rong Chang <rongchang@chromium.org>
Change-Id: I45532dcaab3bab566407b209f26693e2c3451014
Reviewed-on: https://chromium-review.googlesource.com/170906
Reviewed-by: Hung-ying Tyan <tyanh@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Jaehoon Kim <jh228.kim@samsung.com>
Tested-by: Jaehoon Kim <jh228.kim@samsung.com>
Every board other than link does the same thing - filter out the power
button event, then set the WAKE_L gpio level based on the remaining
events. This code doesn't need to be duplicated 7 times, so make it common.
Link didn't filter out the power button wake signal, but works fine
with the common implementation. Like the other boards it gets a power
button wake event via the dedicated PCH PWRBTN# signal.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=suspend link, then wake using power button press
compile all platforms; pass unit tests
Change-Id: Ib3a6d310d0f5e337374b3c331ab2872fe377bdf6
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171405
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The Bolt board does not use the standard CHIPSET_HASWELL
and with a recent commit that meant haswell_interrupt() was
defined to NULL and it would not turn on the panel power.
BUG=chrome-os-partner:20372
BRANCH=bolt
TEST=build and boot on bolt and see magic working panel
Change-Id: I6174e2b4a8337acc2f395b8b2b18a00107661af1
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171112
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Randall Spangler <rspangler@chromium.org>
We don't use the EEPROM block on the LM4 chip, but if we ever do we'll
want this off-by-one error fixed.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=Build bds, since that's the only board which even compiles this code.
Pass unit tests.
Change-Id: I598f043cf00ebc1eca75fa6e6b7815d85a61e353
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171141
This was previously done in a board-specific function across 4 boards.
Except that the board-specific function was identical in all cases
(that is, not really board-specific). Put it back in the common
implementation to get rid of duplicated code, and use
CONFIG_TEMP_SENSOR_POWER_GPIO to indicate which GPIO rail controls the
sensor power.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all boards; pass unit tests
Change-Id: I29de40001d5d4dc873e5ba8f3abb328c6271f235
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171140
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
For all GPIOs, the current values are recorded. A test can then change
the value of a GPIO input by gpio_set_level(). The changed value is
recorded and also interrupt is fired if the change fits the interrupt
flags defined in board/host/board.c.
BUG=chrome-os-partner:19235
TEST=Pass all tests
BRANCH=None
Change-Id: If8e547e5adf4a20dcb118f5fe2187293005d4ca3
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170907
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This just does a copy/rename from Bolt. Tweaking for Samus' peculiarities
will come next.
BUG=chrome-os-partner:22870
BRANCH=none
TEST=manual
The only thing we can check is that it compiles:
cd src/platform/ec
make BOARD=samus
Change-Id: Ied95ebdd1137548b21334b4a65a298c68482c517
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171081
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If keyboard scanning is active when the lid closes, it will disable
scanning put the scan task to sleep. We need a corresponding task
wake when the lid opens, or scanning will be stuck off (until
something else happens, like poking the power button).
BUG=chrome-os-partner:22190
BRANCH=peppy
TEST=Hold down a key. Use a magnet to trigger the lid switch. Scanning
should stop while the lid is "closed", and restart when the magnet is
moved to "open" the lid again.
Change-Id: I0a900f17f65b75cbdb45950cea7f50190d2bf9b1
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170993
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The battery command takes a long time to run if given a high repeat
count. Since it doesn't sleep at all between iterations by default,
this will unsurprisingly starve all other tasks and cause a watchdog
timeout.
Reset the watchdog between iterations, to give the rest of the system time
to do things. This is similar to what we do in the i2cscan command.
BUG=chrome-os-partner:22232
BRANCH=none
TEST=apshutdown, then battery 1000 = no watchdog
Change-Id: I3ce55e15d90a6dfda34b1e2e332d7f7828922e78
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170968
Add the ChipID for the stm32l152c board to stm32mon. Add discovery to the list
of supported boards in flash_ec.
BUG=None
TEST=With modified servo connector, see that image can be loaded onto
stm32l152c discovery board.
BRANCH=none
Change-Id: Ie16c64d17c907f7de765b09de98f534c486ae04c
Signed-off-by: Jeremy Thorpe <jeremyt@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170981
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Support for the basic development board built by STmicro with STM32L152
chip.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=none
TEST=See that LEDs can be driven from the console, button can be read. With
additional print statement, see that button hook is called.
BRANCH=none
Change-Id: I494ab525f17e08b57595ee49489ade63b3305f2a
Reviewed-on: https://chromium-review.googlesource.com/170920
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Jeremy Thorpe <jeremyt@chromium.org>
Tested-by: Jeremy Thorpe <jeremyt@chromium.org>
The old backlight_x86 code did
(backlight enable) = (lid is open) && (GPIO request from AP)
Newer systems will AND those signals in hardware. Support those
systems by separating CONFIG_BACKLIGHT_LID and
CONFIG_BACKLIGHT_REQ_GPIO, and add tests for the case where the enable
signal is dependent only on the lid position.
BUG=chrome-os-partner:22960
BRANCH=none
TEST=pass unit tests
Change-Id: I1909426e49f00a8acd5047fd88c801cba1dacd76
Reviewed-on: https://chromium-review.googlesource.com/170925
Tested-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Randall Spangler <rspangler@chromium.org>
This checks x86 backlight passthrough by toggling lid switch and PCH
backlight output, and also by host command.
Also fix a bug that backlight switch host command can never be invoked
due to incorrect version mask.
BUG=chrome-os-partner:19236
TEST=util/make_all.sh
BRANCH=None (unless some platform needs backlight switch host command)
Change-Id: Iefc5f4b7387c4d2aa43059d073bd70aed879fe34
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170758
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This checks charge state machine goes into error state when battery is
not responding.
BUG=chrome-os-partner:19236
TEST=Pass sbs_charging test
BRANCH=None
Change-Id: I61970c4d88cbb0d6242613cdc87b88da7ae3f2f4
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170753
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This provides an interface to detach and re-attach fake I2C devices,
which can be used to test I2C connection failure.
BUG=chrome-os-partner:19235
TEST=Pass sbs_charging test along with the next CL
BRANCH=None
Change-Id: Ibfee79b13d45e62377d894aa28547e77bef2189e
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170752
Reviewed-by: Randall Spangler <rspangler@chromium.org>
For testing, we are now mocking things at function-level instead of
file-level. No need to have separate header file for smart battery
functions now. Merge them back to smart_battery.h.
Just moving code. No functional change.
BUG=chrome-os-partner:18343
TEST=util/make_all.sh
BRANCH=None
Change-Id: I4de1f73def447e75458118c1148c598794ddc091
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170751
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The kernel driver now correctly handles EC_RES_IN_PROGRESS.
This reverts commit 62e9444161.
BRANCH=pit
BUG=chrome-os-partner:22825
TEST=Run flashrom, bang on the keyboard, and issue i2c commands to
TPSCHROME. Observe that I2C_PASSTHRU and MKBP_STATE commands do not
interleave with GET_COMMS_STATUS commands
Change-Id: I8589552f6c7a1506a32b5510fe340dba29702e13
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170844
Reviewed-by: Simon Glass <sjg@chromium.org>
This adds a test for LP5562 LED control. The test mocks charging and
battery status and check LED behavior is as expected.
BUG=chrome-os-partner:19236
TEST=Pass the new test
BRANCH=None
Change-Id: Iac6b538b24c555bf48b6824f880091cd11a585d4
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170597
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This checks power button and lid switch states are updated correctly to
memory-mapped region.
BUG=chrome-os-partner:19236
TEST=Pass power_button and lid_sw tests
BRANCH=None
Change-Id: Ia49b5a3142b5fd47985bc6f53b1bbffd6d4bbeac
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170438
Reviewed-by: Randall Spangler <rspangler@chromium.org>
With the PWM interface refactoring, only the CPU fan uses the fan.h
interface. All other PWM channels (keyboard backlight, etc.) use the
pwm.h interface. Remove the unused constants, and rename FAN_CH_CPU
to CONFIG_FAN_CH_CPU so it fits with the other fan config options.
No functional changes; just renaming things.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all targets; pass unit tests
Change-Id: I391fbeaf54afcc29a11c2799a4520b7ad8784796
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170534
Reviewed-by: Vic Yang <victoryang@chromium.org>
This should have all the correct GPIO mappings.
Chipset and charger tasks are currently disabled, until we bring up
the voltage rails and I2C communication.
BUG=chrome-os-partner:22895
BRANCH=none
TEST=compiles; everything else needs to wait until we get hardware
Change-Id: Iea49fe7ab8bd17f61c8cc6c71f236a503418ee28
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170540
Reviewed-by: Vic Yang <victoryang@chromium.org>
switch.c currently assumes that all boards have GPIO_RECOVERY_L. This
is not true for Rambi, and also isn't true for ARM boards (which
should also eventually use the common switch implementation).
Add a new CONFIG_SWITCH_DEDICATED_RECOVERY option to control whether
to compile this support.
BUG=chrome-os-partner:22893
BRANCH=none
TEST=compile all boards; pass unit tests
Change-Id: If6f34d1afd580c9d79a8edcdda18833068e70f66
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170489
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
We've removed a few constants from the exported header file since the last
big sync. Just in case some of them are still in use (coredump, flashrom),
let's make it easy to redistribute the header unchanged. We can remove them
for real next time.
BUG=chromium:251441
BRANCH=none
TEST=manual
Compile, test, run, etc. This CL just adds back some unused (by the EC)
constants that were previously removed, so nothing should change.
Change-Id: Ia9889db89a90d56c8154fea1e8c8a483fdcae805
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170522
Reviewed-by: Randall Spangler <rspangler@chromium.org>