Support for the basic development board built by STmicro with STM32L152
chip.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=none
TEST=See that LEDs can be driven from the console, button can be read. With
additional print statement, see that button hook is called.
BRANCH=none
Change-Id: I494ab525f17e08b57595ee49489ade63b3305f2a
Reviewed-on: https://chromium-review.googlesource.com/170920
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Jeremy Thorpe <jeremyt@chromium.org>
Tested-by: Jeremy Thorpe <jeremyt@chromium.org>
The old backlight_x86 code did
(backlight enable) = (lid is open) && (GPIO request from AP)
Newer systems will AND those signals in hardware. Support those
systems by separating CONFIG_BACKLIGHT_LID and
CONFIG_BACKLIGHT_REQ_GPIO, and add tests for the case where the enable
signal is dependent only on the lid position.
BUG=chrome-os-partner:22960
BRANCH=none
TEST=pass unit tests
Change-Id: I1909426e49f00a8acd5047fd88c801cba1dacd76
Reviewed-on: https://chromium-review.googlesource.com/170925
Tested-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Randall Spangler <rspangler@chromium.org>
This checks x86 backlight passthrough by toggling lid switch and PCH
backlight output, and also by host command.
Also fix a bug that backlight switch host command can never be invoked
due to incorrect version mask.
BUG=chrome-os-partner:19236
TEST=util/make_all.sh
BRANCH=None (unless some platform needs backlight switch host command)
Change-Id: Iefc5f4b7387c4d2aa43059d073bd70aed879fe34
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170758
Reviewed-by: Randall Spangler <rspangler@chromium.org>
For testing, we are now mocking things at function-level instead of
file-level. No need to have separate header file for smart battery
functions now. Merge them back to smart_battery.h.
Just moving code. No functional change.
BUG=chrome-os-partner:18343
TEST=util/make_all.sh
BRANCH=None
Change-Id: I4de1f73def447e75458118c1148c598794ddc091
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170751
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The kernel driver now correctly handles EC_RES_IN_PROGRESS.
This reverts commit 62e9444161.
BRANCH=pit
BUG=chrome-os-partner:22825
TEST=Run flashrom, bang on the keyboard, and issue i2c commands to
TPSCHROME. Observe that I2C_PASSTHRU and MKBP_STATE commands do not
interleave with GET_COMMS_STATUS commands
Change-Id: I8589552f6c7a1506a32b5510fe340dba29702e13
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170844
Reviewed-by: Simon Glass <sjg@chromium.org>
This checks power button and lid switch states are updated correctly to
memory-mapped region.
BUG=chrome-os-partner:19236
TEST=Pass power_button and lid_sw tests
BRANCH=None
Change-Id: Ia49b5a3142b5fd47985bc6f53b1bbffd6d4bbeac
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170438
Reviewed-by: Randall Spangler <rspangler@chromium.org>
With the PWM interface refactoring, only the CPU fan uses the fan.h
interface. All other PWM channels (keyboard backlight, etc.) use the
pwm.h interface. Remove the unused constants, and rename FAN_CH_CPU
to CONFIG_FAN_CH_CPU so it fits with the other fan config options.
No functional changes; just renaming things.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all targets; pass unit tests
Change-Id: I391fbeaf54afcc29a11c2799a4520b7ad8784796
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170534
Reviewed-by: Vic Yang <victoryang@chromium.org>
This should have all the correct GPIO mappings.
Chipset and charger tasks are currently disabled, until we bring up
the voltage rails and I2C communication.
BUG=chrome-os-partner:22895
BRANCH=none
TEST=compiles; everything else needs to wait until we get hardware
Change-Id: Iea49fe7ab8bd17f61c8cc6c71f236a503418ee28
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170540
Reviewed-by: Vic Yang <victoryang@chromium.org>
switch.c currently assumes that all boards have GPIO_RECOVERY_L. This
is not true for Rambi, and also isn't true for ARM boards (which
should also eventually use the common switch implementation).
Add a new CONFIG_SWITCH_DEDICATED_RECOVERY option to control whether
to compile this support.
BUG=chrome-os-partner:22893
BRANCH=none
TEST=compile all boards; pass unit tests
Change-Id: If6f34d1afd580c9d79a8edcdda18833068e70f66
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170489
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The value of start_charging_min_c and charging_min_c is 5 degrees C. To
meet the samsung specification, we have to change these values as 0
degrees C like pit.
BUG=chrome-os-partner:22882
TEST=Already checked the charging LED and the EC log in the oven.
Change-Id: Id6b6e1e61d5d8c2a3fcca7ff2ccc46e430ec2d7d
Signed-off-by: Jaehoon Kim <jh228.kim@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/170476
Reviewed-by: Wonjoon Lee <woojoo.lee@samsung.com>
Reviewed-by: Katie Roberts-Hoffman <katierh@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
On bolt this pin is connected both to the PCH and the EC.
As designed, it was intended for both parts to treat this
as an open-drain circuit.
Signed-off-by: Paul Stewart <pstew@chromium.org>
BUG=chrome-os-partner:22175
BRANCH=none
TEST=No good test yet, since PCH appears to drive all the time
Change-Id: Ib6ca16b4f797c8c334fb9f030f20cdbbc756f3fb
Reviewed-on: https://chromium-review.googlesource.com/170257
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
For bringup, we need to be able to compile a binary with the chipset
task disabled. Chipset functions should be stubbed to do nothing in
that case.
BUG=chrome-os-partner:22820
BRANCH=none
TEST=compile falco, pit, link with chipset task commented out in ec.tasklist
Change-Id: I73a4e09effb049f19b1a128e643b267d6469037b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170221
The charger interrupt is active-low. Snow and Spring properly
triggered on falling (asserting) edge, but Pit (and Daisy/Puppy)
didn't. Fix those boards, and rename the signal to end in _L so we
don't make that mistake again.
BUG=chrome-os-partner:22827
BRANCH=pit
TEST=unplug/replug AC adapter on pit; see debug output as follows:
[batt] state charging -> idle0
Charger IRQ received.
[batt] state idle0 -> charging
Charger IRQ received.
Change-Id: I1f5c9370d1118461dc033955ba77aab2cebb7ece
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170256
Reviewed-by: Jaehoon Kim <jh228.kim@samsung.com>
Tested-by: Jaehoon Kim <jh228.kim@samsung.com>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Now that we have a better test framework in place, mock
implementations go in either chip/host/ or board/host/, depending on
whether they're mocking chip or common/board functionality. Move the
remaining mocks there. Also, several mocks were neither compiled nor
used, and haven't kept pace with other refactoring; delete those.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all board; pass all unit tests
Change-Id: Ie2a81c3ccd4506679192d979aa87fe7ed6c1c5a0
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/169873
Ensure that the backlight is off whenever the lid is closed,
independently of whether the AP asserts SUSPEND_L.
BUG=None
TEST=On Kirby, toggle lid switch closed and see that backlight turns off
immediately.
BRANCH=None
Change-Id: I1516be3b139a8cbb07a8a81229c8143c88118e91
Signed-off-by: Jeremy Thorpe <jeremyt@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/169875
Reviewed-by: Randall Spangler <rspangler@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>
The console task should be higher priority than the host command task,
since that allows debugging problems with host commands.
The keyboard scanning task should be higher priority than both of
them, since it's extremely latency-sensitive. As currently written,
long-running host commands such as I2C passthru can interfere with
keyboard scanning.
BUG=chrome-os-partner:22681
BRANCH=none (potentially affects pit, but apparently not noticeably)
TEST=type bursts of 6-8 characters quickly while doing a flash update
of the EC; should not drop characters.
Change-Id: I48db014053750a5f1fae5d06df34768975bb8297
Reviewed-on: https://chromium-review.googlesource.com/169334
Tested-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Randall Spangler <rspangler@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
This timing values act as most similar with 8042 which we used in snow
And some keyscan jig can not regognize current debounce timing, It based
on 8042 timing.
BUG=chrome-os-partner:22019
TEST= build and update ec, reboot and see keyscan is fine
Change-Id: I48f01f2e1247db5fa324b0896301616c42032585
Signed-off-by: Wonjoon Lee <woojoo.lee@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/168003
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Randall Spangler <rspangler@chromium.org>
Much like the backlight signal the LCD VCC enable signal
needs to be delayed to ensure the panel timings are correct.
It's problematic because the LVDS bridge is a black box. The
signals need to be scoped to ensure everything eventually matches
up.
BUG=chrome-os-partner:21234
BRANCH=falco
TEST=Built and booted. Panels still come up. Dexter determined the
proper delay.
Change-Id: I6e61d1dfa9ad03be1735d05d8d8ff2549a7b0db2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167620
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
At normal AP shutdown, Haswell systems skip S5 entirely and go directly to
G3. It's sometimes handy to pause in S5 as the other systems do, for things
like power-cycle tests that use the RTC to do a delayed wake from S5.
This CL adds a console command and a host command to enable/disable that
pause in S5.
The default is to skip S5, and the override value is not persistent across
EC reboots, so whenever the EC hibernates or reboots (Refresh + Power, software
sync), you'll have to re-enable it again.
BUG=chrome-os-partner:22346
BRANCH=falco,ToT
TEST=manual
On Haswell systems only.
To enable the pause in S5 at shutdown, do either of these:
EC console: gsv s5 1
root shell: ectool pause_in_s5 on
Shut the AP down politely, and it should pause in S5 for 10 seconds before
continuing to G3. You can see this by watching the EC console.
To disable the pause in S5 at shutdown, do any of these:
EC console: gsv s5 0
root shell: ectool pause_in_s5 off
or
press Refresh + POWER
Boot the system, then politely shut down. This time it should go directly to
G3 without pausing in S5.
Change-Id: I324e6e2373bc20b61a731b4ef443d7bb8edb6b83
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168086
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Now that we have battery and charger drivers, let's enable charging.
BUG=chrome-os-partner:22055
TEST=Test charging/discharging on Kirby
TEST=Unplug battery and see 'error' state
TEST=Plug battery and doesn't see error anymore
BRANCH=None
Change-Id: Idff513b38c9f5bb90700877750f3d2e2154d4b23
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168007
This is only for initial bringup that requires OTG to boot kernel. Note
that we are expecting firmware for USB ID detection and hardware change
to charger chip, so this is likely going to be thrown away.
BUG=chrome-os-partner:21964
TEST=Plug in OTG dongle and check VBUS voltage is ~5V
TEST=Unplug and check it's ~0V.
BRANCH=None
Change-Id: Iee66bef117188fea14a76459945be3bf5afef0dd
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167832
When the AP is powered on, turn on backlight. Also turn off backlight
when going into S3/S5.
BUG=chrome-os-partner:21964
TEST=Power on and see backlight lit. Power off and see it turned off.
BRANCH=None
Change-Id: I77141848466db3209aa0eba2613057002bd3432a
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167800
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 signal is active low (1=no AC, 0=AC good.) Renaming it to
AC_PRESENT_L so that it's not confusing.
BUG=chrome-os-partner:21964
TEST=Build kirby
BRANCH=None
Change-Id: I17b555945c647f4a24b1920cdb8992b3a5767462
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167458
Kirby has the same ADC channels as Spring, but with different scales and
pin assignments.
BUG=chrome-os-partner:22055
TEST=Read ADC channel voltage
BRANCH=None
Change-Id: Ibb618a77647c0477eeb0e8d983df07a258fdb75a
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167460
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
Temperature sensor read is delegated to functions defined in board.c.
Let's mock that function instead of the one in temp_sensor module.
BUG=chrome-os-partner:19236
TEST=Pass thermal test.
BRANCH=None
Change-Id: Ic0387bd6a49e3f032e593c11c6f80bd36f8474e7
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167761
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
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 is just a simple driver that provides a function to set LED color
and also a console command for testing.
BUG=chrome-os-partner:22056
TEST=Change LED color and brightness with the console command.
BRANCH=None
Change-Id: I66ece63310a0547127698d1b242a5a1c130abff6
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167450
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>
This is the initial version of BQ24192 charger driver. For now, it only
probes for BQ24192 chip on initialization and get BQ24192 into host
mode.
Also, charger_closest_current() is identical across all charger drivers.
Let's move it to charger_common.c.
BUG=chrome-os-partner:22238
TEST=Build all boards. Boot Kirby and see BQ24192 initialized.
BRANCH=None
Change-Id: I5291362ff0e69b281bffd6d609ce6dc48eb10898
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167457
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
Until we can properly detect power source type, always assume adaptor
power source to allow more input current.
BUG=chrome-os-partner:22055
TEST=Plug in adaptor and see 0x84 from BQ24192's register 0x8.
BRANCH=None
Change-Id: Ic6adc0d459f9cc038870e3dd2b680549c4b5df39
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/66934
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>
Test config is now in test/test_config.h. Let's remove the unused config
lines in board/host/board.h.
BUG=chrome-os-partner:19235
TEST=Pass all tests.
BRANCH=None
Change-Id: Ic8f7f4dcf8e0ad5f8800fe8ad2ae89b604a239f4
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66742
Reviewed-by: Randall Spangler <rspangler@chromium.org>
With CONFIG_HOST_COMMAND_STATUS, the EC can respond to a command
with EC_RES_IN_PROGRESS, indicating to the AP that it should poll
for completion of the command with EC_CMD_GET_COMMS_STATUS. The
kernel, however, only guarantees the atomicity of single commands.
As a result, i2c passtrough or keyboard commands could be issued
while the AP is polling for completion of a flashrom command. By
disabling CONFIG_HOST_COMMAND_STATUS, we eliminate polling of the
EC status by the AP so that there is no interleaving of commands.
BUG=chrome-os-partner:20978
TEST=flashrom on Pit
BRANCH=pit
Original-Change-Id: I48b29a0dbbcc56fc55f72ca64b8aff51036740e3
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66703
Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit 2db4fcfb267b938fcc35af2a0d2e374f99551743)
Change-Id: Iac7c15ec337d618cd6d95439d4b922bf3ec43916
Reviewed-on: https://gerrit.chromium.org/gerrit/66828
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
The bolt board has the PP1050 regulator's pgood
output connected to VCCST_PWRGD on the chipset. However,
that is inappropriate because VCCST_PWRGD is the signal
used when the 1.05V rail is good when transitioning to
S0. The PP1050 regulator needs to be up while in S5
to supply the 1.05V suspend rail. To work around this
mismatch, the PP1050_PGOOD signal which is routed to
the EC needs to be changed to an open-drain output.
It's driven low until the transition to S0 in order
to properly sequence the chip.
BUG=chrome-os-partner:20372
BRANCH=None
TEST=Built and booted on handful of boards.
Change-Id: Ic85eab8f295f6e76d9b33f440e68c82096976683
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66821
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
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>
In order to meet the panel power sequencing requirements the
backlight enable needs to be delayed by 420ms. As the EC has
direct control over the panel backlight, it's difficult to
align with the reset of the panel signals which are controlled
by an LVDS bridge. In order to not affect other boards the
backlight implementation has been moved within falco's
board directory.
BUG=chrome-os-partner:21234
BRANCH=falco
TEST=Built with a printf to verify rough timing transitions.
Change-Id: I5d6cd2989f17cc5c188d307f6ceacb52341a87b4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66238
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This tests that command history is as expected. Also fix a bug that some
checks in console_edit test are skipped.
BUG=chrome-os-partner:19236
TEST=Pass console_edit test.
BRANCH=None
Change-Id: Ifbd3d1690f25b35bf5efe523e656b013aa534d26
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64837
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
Firmware development for this board is happening on the
firmware-wolf-4389.24.B branch.
BUG=chrome-os-partner:21815
BRANCH=None
TEST=Run util/make_all.sh. Verify all is made.
Change-Id: I4b58a982a87562231453f3f201024b809c6a24fb
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/65514
Reviewed-by: Randall Spangler <rspangler@chromium.org>
