Previously if you were working on a single board you had to add BOARD=
to all of your make command lines. Now if you are in a board directory
you can just use "make", or "make clean", or any other top level make
command.
This commit also adds support for a top level "make flash" command that
can be used from the board directories as well. This command uses
openocd and requires that the board provides an openocd-flash.cfg file.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=none
TEST=(from a few board directories) make clean; make -j
(from the discovery-stm32f072 directory) make flash
Change-Id: Ie09a74881371169a2c3cd9cd9922f39f4873f1a6
Reviewed-on: https://chromium-review.googlesource.com/209669
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
This is a straightforward conversion of existing tables
into X-Macro style definitions for the GPIO alternate
functions. This change in itself, is not particularly
powerful, but having all GPIO settings in a single file
makes a board easier to understand.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=none
TEST=make buildall -j
Followed by manual testing of interrupt on change and UART
functionality on STM32F0 based discovery board.
Change-Id: Ib7f1f014f4bd289d7c0ac3100470ba2dc71ca579
Reviewed-on: https://chromium-review.googlesource.com/207987
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
These files are tabular data more than source code. We discussed
and concluded that the 80-column limit makes them harder to read,
not easier. This commit reformats them to take advantage of
longer lines, mainly by putting per GPIO comments on the end of
the line that defines the GPIO.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=none
TEST=make buildall -j
Change-Id: I60f3e3620680196eb9462f97b34c453289240465
Reviewed-on: https://chromium-review.googlesource.com/205672
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Previously each board.h and board.c contained an enum and an array
for gpio definitons that had to be manually kept in sync, with no
compiler assistance other than that their lengths matched.
This change adds a single gpio.inc file that declares all gpio's
that a board uses and is used as an X-macro include file to
generate both the gpio_signal enum and the gpio_list array.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=none
TEST=make buildall -j
Change-Id: If9c9feca968619a59ff9f20701359bcb9374e4da
Reviewed-on: https://chromium-review.googlesource.com/205354
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
With change b610695b61, we fixed a problem
with the number of FP regs that were being saved on the stack. That change
decreased the required stack size for non-FP tasks by 64 bytes, but
increased the size needed for FP tasks (such as the lightbar).
The lightbar task was previously using within 64 bytes of its alloted stack,
so handling the task switching correctly meant that it now overflowed.
The hooks task had the same problem, but was hidden by the lightbar task.
This CL bumps the LARGER_TASK_STACK_SIZE up a bit, and switches the lightbar
task to use it instead of the default size.
BUG=chrome-os-partner:27971, chrome-os-partner:28407
BRANCH=ToT
TEST=Try it on both Link and Samus.
Before this change, the Samus lightbar was overflowing its stack every time
the AP booted (causing the lightbar to do things). With this change, it
doesn't. Here are typical stack sizes after this CL:
Task Ready Name Events Time (s) StkUsed
0 R << idle >> 00000000 28.394913 328/512
1 HOOKS 00000000 0.534085 640/768
2 R LIGHTBAR 10000000 5.359356 520/768
3 CHARGER 00000000 0.094674 384/512
4 CHIPSET 00000000 0.003353 320/512
5 KEYPROTO 00000000 0.002814 312/512
6 HOSTCMD 00000000 0.002942 244/512
7 R CONSOLE 00000000 0.193776 340/768
8 POWERBTN 00000000 0.000392 248/512
9 KEYSCAN 00000000 0.409337 332/512
Change-Id: Ica93608c8adb225410a62ec3a0a27944c479270a
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197733
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Making room for a new charge_state implementation.
BRANCH=ToT
BUG=chrome-os-partner:23776
TEST=make buildall -j
No new functionality, just renaming some files.
Change-Id: I80ce861f09129a518e180cac20d32e867a93cd46
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/190852
Reviewed-by: Randall Spangler <rspangler@chromium.org>
For the better naming for power/common.h, we rename CONFIG_CHIPSET_X86
to CONFIG_POWER_COMMON (no one is actually using it). But keep
CONFIG_CHIPSER_TEGRA for power/build.mk.
BUG=chrome-os-partner:25068
BRANCH=nyan,falco,link,peppy,rambi,samus,squawks
TEST=build only
Change-Id: Ibf1a4c24088dfddac39b38a95b3b887c195152d5
Signed-off-by: Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182732
Vboot hash calculation takes ~350 ms during EC boot. Since the hash
task is higher priority than the hook task, this starves all the hooks
during boot.
We could, in theory, fix that simply by swapping the priority of the
hook and hash tasks. But then watchdog detection (in the hook task)
wouldn't detect hangs in the hash task.
A better fix (implemented here) is to convert the hashing operation to
a series of deferred function calls. This gets rid of the hash task
entirely, and allows all pending hooks and other deferred function
calls to take place between each chunk of hashing.
On STM32-based boards, we need to bump up the hook task stack size,
since hashing is called from several layers deep in the hook task
instead of at the top of its own task, but this is still a net win of
several hundred bytes of SRAM.
BUG=chrome-os-partner:24892
BRANCH=rambi
TEST=Boot EC; look for "hash start" and "hash done" debug output.
'taskinfo' shows at least 32 bytes of unused stack for HOOKS task.
'hash ro' runs properly from EC console.
Change-Id: I9e580dc10fc0bc8e44896d84451218ef67578bbe
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181954
Renaming file names is the first step. Please see issue tracker
for more details.
BUG=chrome-os-partner:24832
BRANCH=link,falco,samus,rambi,peppy
TEST=build all x86 boards.
make clean BOARD=link && make -j32 BOARD=link && \
make clean BOARD=falco && make -j32 BOARD=falco && \
make clean BOARD=samus && make -j32 BOARD=samus && \
make clean BOARD=rambi && make -j32 BOARD=rambi && \
make clean BOARD=peppy && make -j32 BOARD=peppy
Change-Id: I3a296a0c14f6bebefa858438b1320061ac71dd38
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181400
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This lowers, the WARN, HIGH, and HALT temp thresholds
for x86 boards to below their CONFIG_PECI_TJMAX value.
Also lowers the FAN_MIN and FAN_MAX temps by 5 degrees on
Haswell boards to compensate for lowering TJ_MAX by 5 degrees
in an earlier patch.
BUG=chrome-os-partner:24455
BRANCH=none
TEST=Manual. Run boards without a fan and without any host-side
throttling. Verify that board either reaches a steady state temp
due to throttling or hits SHUTDOWN and turns off before EC reset
is triggered.
Change-Id: I499baa0b4100201525e69752af3465feb592262c
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179886
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
AP throttling in the thermal task ends up calling a pretty deep nested
set of calls, and in the worst case can overflow the stack. Bump up
the stack size for the hook task on x86 platforms to compensate.
BUG=chrome-os-partner:24536
BRANCH=peppy/falco
TEST=taskinfo shows hook task increased from 512 to 640 bytes stack
shmem shows at least 4000 bytes free
Change-Id: I63da7c47b993c935d895f91d787844655071da0d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180684
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This make minor syntactic changes and renames some camel-cased symbols
to keep checkpatch from complaining. The goal is to reduce the
temptation to use 'repo upload --no-verify'.
This is a big furball of find/replace, but no functional changes.
BUG=chromium:322144
BRANCH=none
TEST=build all boards; pass unit tests
Change-Id: I0269b7dd95836ef9a6e33f88c003ab0f24f842a0
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180495
BUG=chrome-os-partner:24455
BRANCH=none
TEST=Manual: Verify that CONIFG_PECI_TJMAX set per-board matches
the value queried over the PECI bus with the restricted
"peciprobe" command.
Change-Id: I8e99a23a66f26d6101e01cc751d0a8ca79686321
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179682
Reviewed-by: Alec Berg <alecaberg@chromium.org>
In board.c, we initialize this struct:
struct i2c_port_t {
const char *name; /* Port name */
int port; /* Port */
int kbps; /* Speed in kbps */
};
extern const struct i2c_port_t i2c_ports[];
The port field refers to the physical I2C bus on the EC.
Meanwhile, in board.h, we've identified the bus where each I2C device is
attached:
Up until this CL, we've been picking one of those device-to-bus macros to
initialize port fields of the i2c_ports[] array. That's wrong and confusing.
This change specifies the physical channel with the physical number.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=manual
Renaming only. There should be no change in observed behavior.
Change-Id: I5427c26290572133f060b6cf0d9ebea5015adba1
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176176
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
There is a logical difference between PWM controls for things like
backlights and fan controls for actual fans. This change separates them into
two different data structures, for better abstraction.
BUG=chrome-os-partner:23530
BRANCH=none
TEST=manual
make runtests, make all boards, test on Link and Falco.
Change-Id: Ib63f2d1518fcc2ee367f81bf5d803360c1aa5c76
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175151
Instead of just configuring fan support as yes/no, we'll use it to specify
the number of fans on the board. Undefined (not zero!) means no fan support
at all.
Syntax change only. No new functionality.
BUG=chrome-os-partner:23530
BRANCH=none
TEST=manual
make runtests, build all platforms, build and test on Link.
Change-Id: Iff65efa69e05f3e1a54fdc2a8da9001b4e8487ca
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175150
To conform to our mutating naming conventions, let's rename the
chip-specific PWM header file to have the string "_chip" in it.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all platforms; pass unit tests
Change-Id: I6584be8e54fd24c8638559817e150c707bc0edb5
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174884
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Update the comments in several board.c files to accurately describe which
pwm control circuit is being used for what purpose.
BUG=chrome-os-partner:23530
BRANCH=none
TEST=none
No code changes, comments only.
Change-Id: I29cef5a2bfee4d7d44bedd092783d9f1d2ea5ef3
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174901
This is tidier than every board defining its own module_id enum, and
encourages standard naming of modules.
A subsequent CL will do more cleanup (standardizing on MODULE_LED
instead of MODULE_POWER_LED and MODULE_LED_KIRBY), but it's easier to
do that as a separate CL than part of this one.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all platforms; pass unit tests
Change-Id: If0fcef284fb3aa2fa145bc9ff3d1f3f2d25a2e47
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174382
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Device-specific headers belong in driver/ or chip/. The include/
directory should be for common interfaces.
Code should not normally need to include driver-specific headers. If
it does, it should use the full relative path from the EC project root
(for example, drivers/charger/bq24715.h).
Change-Id: Id23db37a431e2d802a74ec601db6f69b613352ba
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173746
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Every chipset had its own header file just to declare a GPIO interrupt
handler. Since this seems to be a common feature of the power
interface, make a standard power_interrupt() API provided by
chipset.h. This lets us get rid of 4 include files, and makes it
easier to add more chipsets in the future.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all boards; pass unit tests
Change-Id: I1fc5612d42625ea46e0a8e16a83085b66d476664
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173745
Add some missing descriptions in config.h and rename a few defines to
be more consistent.
No functional changes, just comments and symbol renaming.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all platforms; pass unit tests
Change-Id: I05a9a2ed6fd7bc8b14a18a0dc57d7d22430de21a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173111
Reviewed-by: Vic Yang <victoryang@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>
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
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>
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>
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>
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>
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>
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>
The battery files contain board-specific constants and a few small
methods like battery-detect and battery-cut. Most of these aren't
reused across platforms. The battery files have also been cleaned up
so those board-specific constants basically all that's left in them.
Where a file is used by a single board only, move it to
board/(boardname)/battery.c. Batteries used by more than one board
(e.g. battery_link.c used by both link and bolt) are still in
common/battery_*.c, since that's cleaner than duplicating the file in
each board's directory.
No code changes, just moving files.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all boards and pass unit tests
Change-Id: I946c8eb874672c77f9b77105e5b900f98fa48d0f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/169893
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
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
GPIO_INPUT is defined as 0, and any GPIO flag cannot be examined against
GPIO_INPUT. Change GPIO_INPUT to non-zero value to avoid this.
BUG=chrome-os-partner:22275
TEST=On Kirby, set a GPIO to output and pull it low, and then set it back to
input. Check it can be pull high externally.
TEST=Build all boards.
TEST=Boot link and spring.
BRANCH=None (unless this bug hits some other boards.)
Change-Id: I84b9936c24af538ac59c36129fda27ca879bf9d1
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167190
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
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>
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>
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
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>
We've been declaring a bunch of statically-sized arrays:
extern struct foo_t foo[FOO_COUNT];
And then initializing them like so:
struct foo_t foo[FOO_COUNT] = {
/* blah */
};
That only catches cases where we initialize with too many entries. It
doesn't catch cases where we haven't initialized enough. This change tests
for both cases like so:
extern struct foo_t foo[];
struct foo_t foo[] = {
/* blah */
};
BUILD_ASSERT(ARRAY_SIZE(foo) == FOO_COUNT);
The affected arrays are:
adc_channels[ADC_CH_COUNT]
gpio_list[GPIO_COUNT]
temp_sensors[TEMP_SENSOR_COUNT]
x86_signal_list[X86_SIGNAL_COUNT]
i2c_ports[I2C_PORTS_USED]
BUG=chrome-os-partner:18343
BRANCH=falco,peppy
TEST=build all platforms
All platforms should still build, all tests should still pass.
Change-Id: Ibb16dc3201f32df7cdc875648e89ba4ffb09f733
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63833
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>
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>
