This is to add nyan board support:
- new files in board/nyan folder, including battery.c
- new common/chipset_tegra.c, which is mostly based on
chipset_gaia.c
- new include/tegra_power.h
- modified build.mk and flash_ec for nyan
BUG=none
BRANCH=nyan
TEST=tested on Venice 2 board
Change-Id: I36895f34f2f4d144a9440aff358c8274797ebbd6
Signed-off-by: Yen Lin <yelin@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/168078
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
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>
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>
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>
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>
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 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>
STM32 has a single-byte mailbox for UART I/O. When the core clock
runs at 16Mhz we can service interrupts fast enough to handle 115200
baud input, but when we drop to 1MHz we drop characters. Using DMA to
receive input solves this problem.
The STM32 DMA engine can only generate interrupts when the transfer is
half-done / all-done, so we need to poll the DMA receive-head-pointer
to see if individual characters have been received. Do this in the
tick task (every 250ms). When a character is received, poll more
quickly for a bit (5 times before the next tick) so the input console
is more responsive to typing.
BUG=chrome-os-partner:20485
BRANCH=none
TEST=Console is responsive to debug commands. For example, help -> prints help
apshutdown -> shuts down AP
arrow keys -> move cursor and scroll through command history
Ctrl+Q, help, wait a second, Ctrl+S -> help output printed after Ctrl+S
Then in chip/stm32/config_chip.h, comment out #define CONFIG_UART_RX_DMA
and rebuild/reflash the EC. When the AP is up, the console works normally
but after 'apshutdown', the EC drops to 1MHz core clock, and the arrow
keys don't work. (This step confirms that adding DMA support did not
change the behavior of systems where CONFIG_UART_RX_DMA is not defined.)
Change-Id: I199448354824bd747c7b290ea7fd5ccf354c11bb
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/169406
Reviewed-by: Simon Glass <sjg@chromium.org>
If CONFIG_HOOK_DEBUG is defined, the maximum run time of each hook is
recorded. Also, record the delayed amount of time of HOOK_TICK and
HOOK_SECOND firing. The statistics are available through console command
'hookstats'.
Also fix a bug that CC_HOOK is used but not defined when
CONFIG_HOOK_DEBUG is defined.
BUG=chrome-os-partner:21801
TEST=Build with HOOK_DEBUG and check 'hookstats'
BRANCH=None
Change-Id: I3acba3abdd487cf20d9a532429f766cdddea2e93
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/169274
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>
