This reduces the number of UART interrupts by a factor of 12, and
reduces the overall interrupt rate on STM32 by a factor of 2.
BUG=chrome-os-partner:20485
BRANCH=none (not required for pit branch)
TEST=Boot pit. Ctrl+Q pauses debug output; Ctrl+S resumes it.
'crash divzero' still prints a full crash dump.
And util/makeall.sh passes builds all platforms and passes tests.
Change-Id: I86993e14b436150298dcb2c6d29086cc3c9db418
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168814
Depending on the system, the AP can be throttled in at least two different
ways - politely, where it's just asked to slow down a bit, and forcefully
using a hardware signal (like PROCHOT). In addition, the request for
throttling can come from multiple tasks.
This CL provides a single interface, specifying both the type of throttling
desired and the source of the throttling request.
For each type, any source can can start throttling, but all sources must
agree before it stops. The changes are protected by a mutex, so that
requests from multiple tasks don't interfere with each other.
BUG=chrome-os-partner:20739,chromium:287985,chromium:287983
BRANCH=ToT
TEST=manual
Build-time test:
cd src/platform/ec
make BOARD=falco runtests
Run-time test: Lower the temp thresholds, turn the fan off, and watch the
throttling turn off and on as things heat up. For example, on the EC
console:
> temps
PECI : 339 K = 66 C
ECInternal : 324 K = 51 C
G781Internal : 328 K = 55 C
G781External : 327 K = 54 C
> thermalset 0 341 343
sensor warn high halt fan_off fan_max name
0 341 343 383 333 363 PECI
1 0 0 0 0 0 ECInternal
2 0 0 0 0 0 G781Internal
3 0 0 0 0 0 G781External
>
> temps
PECI : 339 K = 66 C
ECInternal : 324 K = 51 C
G781Internal : 328 K = 55 C
G781External : 327 K = 54 C
>
> fanduty 0
Setting fan duty cycle to 0%
>
> apthrottle
AP throttling type 0 is off (0x00000000)
AP throttling type 1 is off (0x00000000)
>
[430.152000 thermal WARN]
[430.152233 event set 0x00020000]
[430.152497 event clear 0x00020000]
[430.152714 ACPI query = 18]
[430.152444 sci 0x00020000]
[430.153051 set AP throttling type 0 to on (0x00000001)]
> gpioget CPU_PROCHOT
0 CPU_PROCHOT
>
[436.153742 thermal HIGH]
[436.153979 set AP throttling type 1 to on (0x00000001)]
> gpioget CPU_PROCHOT
1* CPU_PROCHOT
> [441.155319 thermal no longer high]
[441.155587 set AP throttling type 1 to off (0x00000000)]
[442.155604 thermal HIGH]
[442.155841 set AP throttling type 1 to on (0x00000001)]
[446.156623 thermal no longer high]
[446.156890 set AP throttling type 1 to off (0x00000000)]
temps
PECI : 343 K = 70 C
ECInternal : 324 K = 51 C
G781Internal : 328 K = 55 C
G781External : 327 K = 54 C
>
[447.156827 thermal HIGH]
[447.157064 set AP throttling type 1 to on (0x00000001)]
apthrottle
AP throttling type 0 is on (0x00000001)
AP throttling type 1 is on (0x00000001)
> gpioget CPU_PROCHOT
1 CPU_PROCHOT
>
Now turn the fan back on:
> fanauto
>
[456.159306 thermal no longer high]
[456.159574 set AP throttling type 1 to off (0x00000000)]
> apthrottle
AP throttling type 0 is on (0x00000001)
AP throttling type 1 is off (0x00000000)
> temps
PECI : 341 K = 68 C
ECInternal : 324 K = 51 C
G781Internal : 328 K = 55 C
G781External : 327 K = 54 C
>
[473.163905 thermal no longer warn]
[473.164168 event set 0x00040000]
[473.164453 event clear 0x00040000]
[473.164670 ACPI query = 19]
[473.164379 sci 0x00040000]
[473.164987 set AP throttling type 0 to off (0x00000000)]
temps
PECI : 340 K = 67 C
ECInternal : 324 K = 51 C
G781Internal : 328 K = 55 C
G781External : 327 K = 54 C
>
> apthrottle
AP throttling type 0 is off (0x00000000)
AP throttling type 1 is off (0x00000000)
>
Change-Id: I9ee1491a637d7766395c71e57483fbd9177ea554
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168802
This is in preparation for enabling DMA-based UART transfers, to
improve UART performance on STM32.
BUG=chrome-os-partner:20485
BRANCH=none
TEST=Boot pit. Host commands should still be received; this verifies DMA
is still operational.
Change-Id: Ibc3b2e2cd187547eb61b85e4a086704accd7f2fb
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168810
Currently only x86 platform uses charge_state.c, and it's been tailored
to fit smart battery and bq247xx charger family.
For Kirby, we have different types of battery and charger, and thus need
to make some change to accommodate them. This includes:
- Abstract out smart battery specific bit mask
- Implement missing functions required by GAIA chipset module
- Add config flags for charging-enabled GPIO pin
- Allow battery that doesn't report desired voltage and current
BUG=chrome-os-partner:22055
TEST=Build all boards
TEST=Boot Link and check it charges/discharges battery
TEST=Test charging/discharging on Kirby along with the next two CLs
BRANCH=None
Change-Id: I910c030a45b4f775afffec0127cdc31e89b9dd55
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168005
BQ27541 is not a smart battery IC, and thus we cannot use existing smart
battery driver. Let's add a driver that implements a smart-battery-like
interface.
The 'battery' console command is also moved to battery.c so that it can
be reused by different battery driver.
BUG=chrome-os-partner:22048
TEST=Type 'battery' and check the reported values are sane.
TEST=Check 'battery' command works fine on Spring.
BRANCH=None
Change-Id: I5d1eaeb3f801478f3b9473fd43c1f2a2eda75859
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/66340
This adds EC_CMD_GET_SET_VALUE to the list of host commands. We have a bunch
of single-value getter/setter commands, which is wasteful. This is a start
towards unifying them into a simpler command.
BUG=chromium:285358
BRANCH=ToT,falco
TEST=none
There's nothing to test just yet. This just adds the command and some basic
interfaces. A future commit will make use of it.
Change-Id: Iee986b9d273b422bb06f3a0c9b7af50617f03d7f
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168083
Reviewed-by: Randall Spangler <rspangler@chromium.org>
ADC module on STM32L is clocked by HSI oscillator, and thus we need to
switch to HSI if using MSI. After the conversion, if the system is not
in S0, clock is switched back to MSI again.
There are several register bits that can only be written when ADC is
powered down. For now, let's just power down the ADC after each
conversion.
Currently ADC watchdog is not working and is disabled on STM32L.
BUG=chrome-os-partner:22242
TEST=Try multiple all-channel and single-channel reads in S0 and S5.
BRANCH=None
Change-Id: I769dda8a9c69ac9de1eb22d6d259034eef8c1ac4
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167454
Instead of checking for BOARD_<board> to determine whether the board has
control over a power rail or not, use config option for this. Boards
without control over some power rails can then undefine the option in
board.h.
BUG=chrome-os-partner:21964
TEST=Build all boards.
BRANCH=None
Change-Id: I7ee4ebdb3ea595e182845e40db165623ee271997
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167200
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The ID detection and charging circuits on Spring are very different from
that on Kirby. PWM current limit is no longer used. The ID detection
sequence is also different. Also, there is no boost circuit on Kirby.
Given those hardware issues that we had to work around on Spring, it's
unlikely that we will have another board that shares the same/similar
ID detection design with Spring. Let's rename extpower_usb to
extpower_spring to better reflect this.
BUG=None
TEST=Build and boot Spring.
BRANCH=None
Change-Id: I7c212a121eed55665593cb7e1b2b672891819940
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/67031
This unifies the PWM module interface for LM4 and STM32. Now PWM
channels are defined in board.h/board.c. Instead of calling functions
named pwm_set_fan_duty(x), one can now use pwm_set_duty(PWM_CH_FAN, x),
which prevents additional functions added when we have a new PWM
channel.
BUG=chrome-os-partner:18343
TEST=Limit input current on Spring.
TEST=Check power LED in S0/S3/S5 on Snow.
TEST=Check keyboard backlight functionality on Link.
TEST=Check fan speed control/detecting on Link.
BRANCH=None
Change-Id: Ibac4d79f72e65c94776d503558a7592f7db859dc
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/64450
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Problems with existing thermal control loop:
* Not multi-board friendly. thermal.c only supports Link and needs
refactoring. Temp thresholds and fan speeds are hard-coded.
* Only the PECI temp is used to determine the fan speed. Other temp sensors
are ignored.
* Has confusing data structures. Values in the CPU temp thresholds array mix
ACPI thresholds with fan step values.
With this change, the thermal task monitors all temp sensors in order to
perform two completely independent functions:
Function one: Determine if the host needs to be throttled by or informed of
any thermal events.
For thermal events, each temp sensor will have three threshold levels.
TEMP_HOST_WARN
* When any sensor goes above this level, host_throttle_cpu(1) will be called
to ask the CPU to slow itself down.
* When all sensors drop below this level, host_throttle_cpu(0) will be called.
* Exactly AT this level, nothing happens (this provides hysteresis).
TEMP_HOST_HIGH
* When any sensor goes above this level, chipset_throttle_cpu(1) will be
called to slow the CPU down whether it wants to or not.
* When all sensors drop below this level, chipset_throttle_cpu(0) will be
called.
* Exactly AT this level, nothing happens (this provides hysteresis).
TEMP_HOST_SHUTDOWN
* When any sensor is above this level, chipset_force_shutdown() will be
called to halt the CPU.
* Nothing turns the CPU back on again - the user just has to wait for things
to cool off. Pressing the power button too soon will just trigger shutdown
again as soon as the EC can read the host temp.
Function two: Determine the amount of fan cooling needed
For fan cooling, each temp sensor will have two levels.
TEMP_FAN_OFF
* At or below this temperature, no active cooling is needed.
TEMP_FAN_MAX
* At or above this temperature, active cooling should be running at maximum.
The highest level of all temp sensors will be used to request the amount of
active cooling needed. The function pwm_fan_percent_to_rpm() is invoked to
convert the amount of cooling to the target fan RPM.
The default pwm_fan_percent_to_rpm() function converts smoothly between the
configured CONFIG_PWM_FAN_RPM_MIN and CONFIG_PWM_FAN_RPM_MAX for percentages
between 1 and 100. 0% means "off".
The default function probably provide the smoothest and quietest behavior,
but individual boards can provide their own pwm_fan_percent_to_rpm() to
implement whatever curves, hysteresis, feedback, or other hackery they wish.
BUG=chrome-os-partner:20805
BRANCH=none
TEST=manual
Compile-time test with
make BOARD=falco runtests
On the EC console, the existing fan commands should work correctly:
faninfo - display the fan state
fanduty NUM - force the fan PWM to the specified percentage (0-100)
fanset RPM - force the fan to the specified RPM
fanset NUM% - force the fan to the specified percentage (0-100) between
its configured minimum and maximum speeds from board.h
(CONFIG_PWM_FAN_RPM_MIN and CONFIG_PWM_FAN_RPM_MAX)
fanauto - let the EC control the fan automatically
You can test the default pwm_fan_percent_to_rpm() with
fanset 1%
faninfo
The fan should be turning at CONFIG_PWM_FAN_RPM_MIN. Let the EC control it
automatically again with
fanauto
Also on the EC console, the thermal settings can be examined or changed:
> temps
PECI : 327 K = 54 C
ECInternal : 320 K = 47 C
G781Internal : 319 K = 46 C
G781External : 318 K = 45 C
>
> thermalget
sensor warn high shutdown fan_off fan_max name
0 373 387 383 333 363 PECI
1 0 0 0 0 0 ECInternal
2 0 0 0 0 0 G781Internal
3 0 0 0 0 0 G781External
>
> help thermalset
Usage: thermalset sensor warn [high [shutdown [fan_off [fan_max]]]]
set thermal parameters (-1 to skip)
>
> thermalset 2 -1 -1 999
sensor warn high shutdown fan_off fan_max name
0 373 387 383 333 363 PECI
1 0 0 0 0 0 ECInternal
2 0 0 999 0 0 G781Internal
3 0 0 0 0 0 G781External
>
From the host, ectool can be used to get and set these parameters with
nearly identical commands:
ectool thermalget
ectool thermalset 2 -1 -1 999
Change-Id: Idb27977278f766826045fb7d41929953ec6b1cca
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66688
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The BOOTCFG register configures a couple of important things: whether to
allow jumping into the builtin ROM bootloader at reset, and whether or not
to allow JTAG access for programing and debugging.
The default is "no" and "yes". But the BOOTCFG register can be locked so
that it can't be changed again, which means that if the wrong values are put
into it, the system is pretty much bricked.
On Link, we wrote a BOOTCFG value that allowed a GPIO to be used as a bypass
to optionally trigger the ROM bootloader, but on Slippy and its derivatives
that GPIO is not pulled up. If you program the Link values into BOOTCFG on a
Slippy, the system is stuck in the ROM bootloader more or less forever.
This change disables that GPIO, keeps JTAG enabled, and locks those settings
for all LM4 chips (it's a chip config now, not a board config). We've never
actually used the GPIO to invoke the ROM bootloader, but we have managed to
brick a number of systems just by having it enabled, so we're going to lock
it into a safe configuration now.
BUG=chrome-os-partner:19247
BRANCH=falco,peppy
TEST=manual
Reflash, boot, power cycle (actually unplug the EC from AC and battery) a
few times. It should continue to work.
Change-Id: Iaf1a81d6814104421a56425490e3d5164ea9b617
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66538
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:21847
BRANCH=peppy
TEST=Manual. Check state of GPIO_P5000_FAN_EN with lid open
and lid closed. Can also check with meter via TP109.
Change-Id: I8a64c14d53dd84a5d586c0abb04ccb71de0e78b3
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/65674
Only link actually used this function, but all batteries were required
to provide an (empty) implementation. Use
CONFIG_BATTERY_VENDOR_PARAMS to gate this functionality, so non-link
battery code can be simpler.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all platforms and pass unit tests
Change-Id: Ic2c6dd1163a981e48873d798f77891cc7de1f8cf
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/65257
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Rong Chang <rongchang@chromium.org>
Rather than have every board check for tasks before declaring their
config macros, have config.h know what configs are invalid without
their corresponding tasks.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all platforms and pass unit tests
Change-Id: Iecf6eb44782e15565eaaf6d69c6288ee8d2e4c4c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/65010
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Daisy systems are few and far between, and not actively used for
development now that we have pit. Remove the I2C port detection which
was used for early systems, and just hard-code the port value to the
one on my daisy.
BUG=chrome-os-partner:10622
BRANCH=none
TEST=boot daisy
Change-Id: I981a51448899f75437f35dc2aa84a0556c0018eb
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64958
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
GPIO alternate functions used to be configured throughout the code,
which made it hard to tell which ones you needed to configure yourself
in board.c. It also sometimes (chip/lm4/i2c.c) led to GPIOs being
configured as alternate functions even if they weren't used on a given
board.
With this change, every board has a table in board.c which lists ALL
GPIOs which have alternate functions. This is now the only place
where alternate functions are configured. Each module then calls
gpio_init_module() to set up its GPIOs.
This also fixes a bug where gpio_set_flags() ignored most of the flags
passed to it (only direction and level were actually used).
On stm32f, gpio_set_alternate() does not exist, and pins are
configured via direct register writes from board.c. Rather than
attempt to change that in the same CL, I've stubbed out
gpio_set_alternate() for stm32f, and will fix the register writes in a
follow-up CL.
BUG=chrome-os-partner:21618
BRANCH=peppy (fixes I2C1 being initialized even though those pins are used
for other things)
TEST=boot link, falco, pit, spring
Change-Id: I40f47025d8f767e0723c6b40c80413af9ba8deba
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64400
This moves per-test config flags from test_config.mk to test_config.h,
where one can define/undefine config flags for individual test.
BUG=chrome-os-partner:19235
TEST=Pass all tests
BRANCH=None
Change-Id: I096aded2007881433d3b6414d37f8bfdc6a2c45c
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64367
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
There's no need for it to directly access the GPIO registers. That
was only necessary at the beginning of link, when gpio_set_flags()
didn't exist.
BUG=chrome-os-partner:21612
BRANCH=none
TEST=onewire red / onewire green / onewire yellow all set the adapter LED
(tested on link, since I don't have a bolt, but the EC chip and adapter
are identical)
Change-Id: I2386962ff039bb2251be38eaadcaeae8ffd1ea7b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64375
Reviewed-by: Vic Yang <victoryang@chromium.org>
Previously, processing of arrow keys and control characters was done
in the interrupt handler itself. This increased the impact of UART
input on other interrupts and high-priority tasks. It also makes it
harder to implement DMA-based UART input on STM32L (in an imminent
CL), since the processing affected the circular UART input buffer
in-place.
This change turns uart_buffering.c back into a dumb I/O buffering
module, and puts all the command line editing and history support into
console.c.
Console history is done via a simple array of input lines instead of a
packed circular buffer of characters. This is a little less
RAM-efficient, but is easier to implement and read. History depth is
controlled via CONFIG_CONSOLE_HISTORY, and is 3 for STM32F and 8 for
other platforms. If we really need a greater history depth, we can
look into implementing a packed circular buffer again, but this time
at task time in console.c. Also added a 'history' command to print
the current console history.
BUG=chrome-os-partner:20485
BRANCH=none
TEST=console_edit unit test passes; 'history' command prints the last commands
Change-Id: I142a0be0d67718c58341e4569f4e2908f191d8b0
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64363
Reviewed-by: Vic Yang <victoryang@chromium.org>
BUG=chrome-os-partner:20145
BRANCH=falco
TEST=Hack it. Add (uint64_t)599 * MINUTE to ctx->curr.ts.val
in the timeout comparison. This makes the 10 hour timeout only
take 1 minute. Testing this directly is tricky as a healthy battery
will charge quickly. If you force it to trickle charge it will
give up before 10 hours pass.
Change-Id: I69094a07e58c2d65e322ddc6a1b2ced828da0e26
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64309
Before this change, powerinfo host command supports only one target
with USB charging. This change adds a common powerinfo host command
and console command for TPSChrome based targets.
BRANCH=None
BUG=chrome-os-partner:20326
TEST=manual
build and flash pit target, check console command 'powerinfo'.
check ectool powerinfo with and without AC adapter.
Change-Id: I2cfd8dfa011e23f819c6bae19cf22b4a7343f044
Signed-off-by: Rong Chang <rongchang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63350
Reviewed-by: Vic Yang <victoryang@chromium.org>
Some chargers can run in a "turbo" mode, which lets it draw from the battery
to provide extra power to the AP in short bursts. In order for this to work
properly, the EC has to watch the current closely to make sure specific
limits are observed. It also has to recognize specific adapters, since those
limits vary depending on the rated power that the adapter can provide.
This adds the basic functionality, plus a test for it.
BUG=chrome-os-partner:20739
BRANCH=falco,peppy
TEST=manual
make BOARD=${BOARD} runtests
On Falco, you can also use the "adapter" EC command to see what's going on.
Try replacing the adapters and running that command to be sure they're
correctly identified, too:
> adapter
Adapter 65W (590mv), turbo 1, AP_throttled 0
>
We currently support 45W, 65W, and 90W adapters. Unknown adapters are
treated as 65W, but don't enable turbo mode.
Change-Id: I7e5407db825ce7e596cb495fb8cb4d1dd1ff639c
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63372
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Rename onewire_led to led_driver_ds2413, since we may have other LED
drivers hanging off a one-wire bus in the future.
No functional changes, just renaming config options.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all platforms
Change-Id: I1d70b1c5778da94bda4ebef3b57f7c39bfba2322
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63273
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
CONFIG_FMAP is now defined by default, because all platforms other
than the host unit tests use it.
No functional changes, just renaming config options and removing dead code.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all platforms
Change-Id: Ie6496310c822491068e2fa6976933486f26badb0
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63271
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Add a CONFIG_CHIPSET_X86 option that determines if
chipset_x86_common.o is built.
BUG=chrome-os-partner:20372
BRANCH=None
TEST=built bolt and link. All other boards should be covered.
Change-Id: I980a8fc68a31162b920429e695631909c5f6a4db
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63208
Reviewed-by: Randall Spangler <rspangler@chromium.org>
No functional changes, just renaming config options.
Remove README, now that all options described in it have been moved to
config.h, and the remaining information is out of date. (Yes, we
should have a README which describes the organization of the EC
repository, but that's a matter for another CL; this one's about
cleaning up config options.)
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all platforms
Change-Id: Iafefbe94369f1217c698f11d358bc0ecac2bdfde
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63145
Reviewed-by: Vic Yang <victoryang@chromium.org>
All of these were defined on all but a few platforms, and those
explicitly #undef them. So define them as enabled by default in
config.h so the board.h files are cleaner.
No functional changes; just rearranging/renaming config constants.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all platforms; FEATURES=test emerge-falco chromeos-ec
Change-Id: I1201a1472ae29641e9e219c2a0347691ca64cd28
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63102
Reviewed-by: Vic Yang <victoryang@chromium.org>
No functional changes, just documenting and renaming.
All boards which use the PMU must provide pmu_board_init(). This was
already true - except that Daisy's pmu_board_init() was implemented as
part of pmu_init() instead of its code living in board.c; I've moved
the code there now.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all platforms
Change-Id: I85ad06dc3b6287ad917fe13acf83182f24a8f23d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/62906
Reviewed-by: Vic Yang <victoryang@chromium.org>
No functional changes, just documenting and renaming.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all platforms
Change-Id: I0b0d3cdce535d90ce437e82e96346fc3ca9be7b0
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/62673
These are now described in config.h. The various BQ chargers now also
use a consistent naming for their sense resistor options.
No functional changes, just renaming, and removal of obsolete
never-defined configs.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all platforms
Change-Id: Ie274546fe45f5ffc6fd0f26096c4622805baf8a0
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/62540
This file will soon contain the exhaustive list of all CONFIG defines
and their descriptions.
Chip-level configs are renamed to config_chip.h to avoid naming
conflicts.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all platforms
Change-Id: I9e94146f5b4c016894bd3ae3d371c4b9f3f69afe
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/62122
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
