summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Add LIGHTBAR_CMD_VERSION command to detect lightbar features.stabilize-4636.BBill Richardson2013-08-304-2/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most systems don't have a lightbar. Those that do need a way to detect that one exists. That's easily done by just sending a EC_CMD_LIGHTBAR_CMD command to the EC and checking the result. If the response is EC_RES_INVALID_COMMAND, there isn't a lightbar. But what .cmd value should we use in struct ec_params_lightbar? Future lightbar implementations (if any), could remove existing functions or add new ones, so there isn't a safe choice. This change adds a LIGHTBAR_CMD_VERSION operation to determine if any new implementation exists. Future systems should return some useful information in response to this command. Existing systems will return EC_RES_INVALID_PARAM, which is enough to distinguish them. BUG=chromium:239205 BRANCH=none TEST=manual make BOARD=link make BOARD=link runtests There are no user-visible changes in functionality to anything. Change-Id: Ibe37f74a4dcbf68dd6bfd1963530aec907e67534 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/167549 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Kirby LED driverVic Yang2013-08-304-1/+97
| | | | | | | | | | | | | 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
* Add config options for power rail controlsVic Yang2013-08-303-5/+11
| | | | | | | | | | | | | | | | 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>
* Add BQ24192 charger driverVic Yang2013-08-3010-82/+293
| | | | | | | | | | | | | | | | | 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
* Update Peppy keyboard mask for Japanese keyboardsDave Parker2013-08-301-1/+1
| | | | | | | | | | | BUG=chrome-os-partner:21798 BRANCH=peppy TEST=Run evtest. Verify correct key codes returned. Change-Id: I48b7524608c546d67eb7975de7ff48874df4568b Signed-off-by: Dave Parker <dparker@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/65624 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Update keyboard scanmatrix for Japanese keyboards.Dave Parker2013-08-302-7/+7
| | | | | | | | | | | | | BUG=chrome-os-partner:21798 BRANCH=peppy TEST=Run evtest. Push every key. Verify correct key code reported. Signed-off-by: Dave Parker <dparker@chromium.org> Change-Id: Ic6e4a38608f4bc8c66f487998912a7921ddb03cb Reviewed-on: https://chromium-review.googlesource.com/65623 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
* pit: i2c: try unwedging the bus when i2c_xfer fails at sending STARTHung-ying Tyan2013-08-291-36/+164
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | and when the bus seems wedged at i2c_init(). BUG=chrome-os-partner:19286 TEST=Manual test on peach pit. Tried the following wedged cases: (1) Bit bang a transaction but only read part of the response. (Refer to https://chromium-review.googlesource.com/#/c/66389) Command to wedge: i2cwedge 0x90 0 2 2 (2) Bit bang a transaction to do a "write" and stop while the other side is acking. (Refer to https://chromium-review.googlesource.com/#/c/66389) Command to wedge: i2cwedge 0x90 0 1 (3) Same as (1) but do a reboot instead of returning and see that the unwedge works at init time w/ no cancelled transactions. (Refer to https://chromium-review.googlesource.com/#/c/66389) Command to wedge: i2cwedge 0x90 0 6 2 (4) Same as (2) but do a reboot instead of returning and see that the unwedge works at init time w/ no cancelled transactions. (Refer to https://chromium-review.googlesource.com/#/c/66389) Command to wedge: i2cwedge 0x90 0 5 (5) Manually pull down on SCL. (Refer to https://chromium-review.googlesource.com/#/c/66063) All five cases successfully wedged the bus and were recovered by this change. BRANCH=pit [dianders: made sure we don't change SCL after SCL high, misc other bits] Change-Id: I23f16fcaa2a76ea37025f8204ab1cdb27e9ef6d1 Signed-off-by: Hung-ying Tyan <tyanh@chromium.org> Signed-off-by: Doug Anderson <dianders@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/66915
* i2c: stm32l: Don't do i2c transactions during freq changesDoug Anderson2013-08-291-1/+23
| | | | | | | | | | | | | | | | | | | | | | | Previously we could get into some pretty bad situtation around frequency changes. Specifically: * If the freq change code exectued during a transaction then it would get all messed up. * If the freq change notifier executed during a transaction then we'd reset the bus midway through transaction. Badness. BRANCH=pit BUG=chrome-os-partner:22093 TEST=With all patches together: - on AP: suspend_stress_test - on EC: battery 10000 50 Change-Id: I24be29d459fe229a6278829a7c03c1e102358e8c Signed-off-by: Doug Anderson <dianders@chromium.org> Previous-Reviewed-on: https://chromium-review.googlesource.com/167102 (cherry picked from commit deab2433c13bc3b3bb75cd33c12dad633ba6a42a) Reviewed-on: https://chromium-review.googlesource.com/167149 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* pit: pulse AP_RESET_L when resetting EC or forcing AP shutdownRandall Spangler2013-08-291-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | If the AP is suspended, it consumes little enough power that just shutting its rails off doesn't cause it to reset to a known state. This caused a problem where suspending the AP then rebooting the EC would wedge the system; the EC would think the AP was on (since XPSHOLD was asserted), but wouldn't be able to figure out how to turn it back off. Silego reset wouldn't help, because that again just reset the EC. Even setting PMIC_RESET to brown out the system wouldn't drop power for long enough. Simply pulsing AP_RESET_L low for 1 ms at EC boot (when not sysjump) or AP force-shutdown forces the AP into a good state. BUG=chrome-os-partner:22233 BRANCH=pit TEST=from root shell, 'powerd_dbus_suspend' from ec console 'reboot' - or just power+refresh system should power on normally Change-Id: I65f1239b5f6766f1c093c3064bce323df4acaf7d Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/167355 Reviewed-by: Doug Anderson <dianders@chromium.org> Commit-Queue: Doug Anderson <dianders@chromium.org>
* stm32l: Add a "PRE_FREQ_CHANGE" hook to allow other code to prepareDoug Anderson2013-08-296-2/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this change drivers had no way of knowing that a frequency change was coming. This could cause problems for some drivers (like i2c) that need to make sure that a transaction isn't happening while a frequency change is happening. The PRE_FREQ_CHANGE archiecture is very simple here and we don't allow any way to cancel it. At the moment, we guarantee: - We won't call PRE_FREQ_CHANGE with interrupts disabled, so acquiring locks / sleeping is OK. - We'll call the actual HOOK_FREQ_CHANGE after the PRE_FREQ_CHANGE. PRE_FREQ_CHANGE and HOOK_FREQ_CHANGE should not use deferred function calls. BRANCH=pit BUG=chrome-os-partner:22093 TEST=With all patches together: - on AP: suspend_stress_test - on EC: battery 10000 50 Change-Id: I2731a3e85d41e749fa571fdb74b5c9b12043cda6 Signed-off-by: Doug Anderson <dianders@chromium.org> Previous-Reviewed-on: https://chromium-review.googlesource.com/167101 (cherry picked from commit d84c0dbbf7c5a72917a820e292ecfdfa698d0fb9) Reviewed-on: https://chromium-review.googlesource.com/167148 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* pit: Move suspend/resume hook callbacks to a deferred taskDoug Anderson2013-08-291-2/+17
| | | | | | | | | | | | | | | | | | | Putting the suspend/resume hook callbacks on a deferred task allows frequency change notifications to lock mutexes. This is useful in a future change which locks the i2c bus around frequency changes. BRANCH=pit BUG=chrome-os-partner:22093 TEST=With all patches together: - on AP: suspend_stress_test - on EC: battery 10000 50 Change-Id: If5e31040cdc7c95a4c8ba62ee72512cb79617cc9 Signed-off-by: Doug Anderson <dianders@chromium.org> Previous-Reviewed-on: https://chromium-review.googlesource.com/167100 (cherry picked from commit ce31fda8695f4db1fa91f5bb224c781cf17f91c0) Reviewed-on: https://chromium-review.googlesource.com/167147 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Peppy: Make power LED turn amber when entering suspendDave Parker2013-08-291-15/+31
| | | | | | | | | | | | | | | | This fixes some jank in how the power LED works when going into suspend. Previously the power LED could turn off for up to three seconds before flashing amber when entering suspend. BUG=chrome-os-partner:21622 BRANCH=peppy TEST=Manual. Enter suspend and observe that LED goes from blue to amber without turning off first. Change-Id: Ib0bf9e998d250b0731405394d3ebb50d90de7cda Signed-off-by: Dave Parker <dparker@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/167388 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* battery: Add sleep param; make errors fatal in the loopDoug Anderson2013-08-281-2/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | If you're running the battery command in a loop: * You may need a sleep so you don't trigger watchdog resets, at least if you're running at a low clock frequency. * You probably want to break on an error. Make the sleep delay come from a parameter since you might want to avoid it if you just want to pound on the bus as fast as possible. BRANCH=pit BUG=chrome-os-partner:22093 TEST=With all patches together: - on AP: suspend_stress_test - on EC: battery 10000 50 Change-Id: I6ae6d818c06f59064e90bd6d23d6d4c782544849 Signed-off-by: Doug Anderson <dianders@chromium.org> Previous-Reviewed-on: https://chromium-review.googlesource.com/167103 (cherry picked from commit 703ce2abf2e38b0f1434224534c1be505e1244f7) Reviewed-on: https://chromium-review.googlesource.com/167160 Reviewed-by: Hung-ying Tyan <tyanh@google.com> Reviewed-by: Rong Chang <rongchang@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Falco: LED should flash white when battery is < 12%, not 7%.Bill Richardson2013-08-281-1/+6
| | | | | | | | | | | | | | | | | | | | BUG=chrome-os-partner:22159 BRANCH=Falco, ToT TEST=manual Let the battery run down. Below 12%, the LED should blink white. Original-Change-Id: I3be2da69a113134456420b1a305e4a0c159c0022 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/167080 (cherry picked from commit fdd33356a31c616457d546d2a1435282e9744355) Change-Id: I7d27ebaea2123b88ea963bf430a5da122a5071b6 Reviewed-on: https://chromium-review.googlesource.com/167139 Commit-Queue: Bill Richardson <wfrichar@chromium.org> Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
* Rename extpower_usb to extpower_springVic Yang2013-08-288-22/+15
| | | | | | | | | | | | | | | | | | | 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
* Remove normal mode in USB extpower moduleVic Yang2013-08-281-47/+8
| | | | | | | | | | | | | | | We are now only using aggressive mode. Let's remove normal mode to simplify the code. BUG=None TEST=Build and boot Spring. Check charging works. BRANCH=None Change-Id: I2ffa94c14666d35e718101c666af05be7291b775 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/67029 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* kirby: Always assume adaptor power sourceVic Yang2013-08-271-1/+1
| | | | | | | | | | | | | | 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>
* stm32l: Wait for stop condition to complete after i2c transferRandall Spangler2013-08-272-4/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | Currently, the STM32L I2C driver queues the stop condition, but doesn't actually wait for it to take effect before returning. If another back-to-back transfer is started, this may attempt to send a start condition before the stop condition completes. If this happens after a slave read, this can look to the slave like just another pulse on SCL, causing it to clock out another bit - potentially driving SDA low and hanging the bus. Instead, wait for the bus to go idle, then wait another clock period (10 us) to give the slaves plenty of time to detect bus-idle before the next start condition. BUG=chrome-os-partner:22093 BRANCH=pit TEST=repeatedly run the battery i2c command from the EC console while running 'ectool i2cxfer 0 0x48 1' from a root shell. Should not hang the I2C bus. Change-Id: I5e65ee242537dbc801fba4ae57847a5af5104186 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/66997 Reviewed-by: Douglas Anderson <dianders@chromium.org> Commit-Queue: Douglas Anderson <dianders@chromium.org>
* pit: i2c: dump after ADDR bit is cleared instead of beforeHung-ying Tyan2013-08-271-1/+2
| | | | | | | | | | | | | | | | | | | Dumping before the ADDR bit is cleared also has the effect of clearing the ADDR bit. BUG=chrome-os-partner:22235 TEST=Manual test on peach pit. Keep executing the "battery" command on the EC console while busy running flashrom on the host to read back the EC. See that there's no error produced. BRANCH=pit Signed-off-by: Hung-ying Tyan <tyanh@chromium.org> Change-Id: I10e88a8512f4e9eb90267ef1aca1df5dd214318d Reviewed-on: https://chromium-review.googlesource.com/66930 Reviewed-by: Douglas Anderson <dianders@chromium.org> Commit-Queue: Hung-ying Tyan <tyanh@chromium.org> Tested-by: Hung-ying Tyan <tyanh@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Refactor PWM moduleVic Yang2013-08-2737-319/+606
| | | | | | | | | | | | | | | | | | | | 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>
* Remove unused test configVic Yang2013-08-241-19/+1
| | | | | | | | | | | | | | 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>
* pit: Disable CONFIG_HOST_COMMAND_STATUSAndrew Bresticker2013-08-241-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Don't send IN_PROGRESS response if GET_COMMS_STATUS is unsupportedAndrew Bresticker2013-08-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | If the EC responds to the AP with IN_PROGRESS, the AP will then use GET_COMMS_STATUS to poll for completion of the previous command. If the EC doesn't support GET_COMMS_STATUS, it will return an error, confusing the AP. BUG=chrome-os-partner:20978 TEST=flashrom on Pit BRANCH=pit Original-Change-Id: I7c911ebc047042450b1eefc992ba2250d35fa078 Signed-off-by: Andrew Bresticker <abrestic@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/66702 Reviewed-by: Randall Spangler <rspangler@chromium.org> (cherry picked from commit 67efd2c100f9de6fe34d381f6145e2d795d8549f) Change-Id: If102710d30cbc53670bb5652b473734c7d9251be Reviewed-on: https://gerrit.chromium.org/gerrit/66827 Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Andrew Bresticker <abrestic@chromium.org> Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
* bolt: workaround board sequencing deficienciesAaron Durbin2013-08-233-18/+34
| | | | | | | | | | | | | | | | | | | | | | | 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>
* bolt: add board support to flash_ecAaron Durbin2013-08-231-1/+1
| | | | | | | | | | | | | | | The flash_ec utility was not honoring --board=bolt. Therefore, add it to the known variants of flash_slippy. BUG=chrome-os-partner:20372 BRANCH=None TEST=flash_ec --board=bolt dosen't fail Change-Id: I8f9c1ddcf7d40b8b579cd90af7dd5c4d90537084 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/66820 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Falco: throttle if battery current drain is too highBill Richardson2013-08-234-0/+179
| | | | | | | | | | | | | | | | I missed this requirement the first time. Now it's here. Also adding a test for it as well. BUG=chrome-os-partner:20739 BRANCH=falco TEST=manual make BOARD=falco runtests Change-Id: I88aac8d12d09f7970b04c4aa02b6986b5ea16306 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/66684 Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* Completely new thermal/fan implementationBill Richardson2013-08-2340-819/+1573
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Fix a bug that I2C error may cause incorrect LED colorVic Yang2013-08-211-1/+6
| | | | | | | | | | | | | | | | If there is an I2C transaction error while setting LED color, the three LED color channels might be in an inconsistent state. In this case, we should explicitly set the LED state to INVALID so as to force the next LED color update. BUG=None TEST=Build success BRANCH=Spring Change-Id: I1353044ef782481872d692f15748413ef539cb27 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/66314 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* Lock BOOTCFG to safe values for all LM4sBill Richardson2013-08-2110-40/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Remove default values for undefined tasks from charge state moduleDave Parker2013-08-211-7/+0
| | | | | | | | | | | | | | | | | Due to the order of pre-processing, TASK_ID_CHARGER and TASK_ID_SWITCH aren't defined even if they are in the ec.tasklist for a board. BUG=chrome-os-partner:21565 BRANCH=falco,peppy TEST=Turn device off, remove AC power. Plug AC power back in. Charging LED should light in ~1 second. Change-Id: I20ebbec71ca5e5dc8ab34da946d3dfeb91fc7849 Signed-off-by: Dave Parker <dparker@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/66466 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* kirby: Add kirby support to util/flash_ec.Jeremy Thorpe2013-08-211-1/+1
| | | | | | | | | | | | | This allows stm32mon built in kirby build directory to be used to flash EC. BUG=chrome-os-partner:21964 TEST=util/flash_ec --board=kirby --image=build/kirby/ec.bin BRANCH=None Change-Id: I38ab6de0e129996010974c8766e1f84f4e8eb3a7 Signed-off-by: Jeremy Thorpe <jeremyt@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/66005 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* Change peppy battery led error blink timingDavid Huang2013-08-211-1/+2
| | | | | | | | | | | | | | | | | | | | | (led turn on 1 sec and turn off 3 sec) BRANCH=peppy BUG=none TEST=manual Disconnect internal battery to check battery led blink timing. Conflicts: common/led_peppy.c Change-Id: I1417073448505aa5dca2e0e999185b5a9b53410e Signed-off-by: David Huang <David.Huang@quantatw.com> Reviewed-on: https://gerrit.chromium.org/gerrit/63891 Reviewed-by: Dave Parker <dparker@chromium.org> Reviewed-by: Hsu Henry <Henry.Hsu@quantatw.com> Tested-by: Dave Parker <dparker@chromium.org> Commit-Queue: Dave Parker <dparker@chromium.org>
* falco: delay backlight enable by 420msAaron Durbin2013-08-203-2/+90
| | | | | | | | | | | | | | | | | | | 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>
* Add test for console command historyVic Yang2013-08-184-8/+92
| | | | | | | | | | | | | 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
* pit: Only enable FET4 by default at cold resetDoug Anderson2013-08-161-1/+7
| | | | | | | | | | | | | | | | | | | Now that U-Boot and kernel can properly talk to the EC in pit, there's no reason to hack all the FETs on. We only need to turn on FET4 which enables SD card booting. We'll leave the old "all fets on" hack there for "puppy", though. Apparently that still needs it? BRANCH=pit BUG=chrome-os-partner:21975 TEST=Boot up and see LCD turn on. TEST=Cold reset while holding recovery and can boot from SD card. Change-Id: Iae96375ac7bd1a9eed8243367332cf003b62c48d Signed-off-by: Doug Anderson <dianders@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/66127 Reviewed-by: Katie Roberts-Hoffman <katierh@chromium.org>
* Poll and cache g781 temperature valuesDave Parker2013-08-136-19/+38
| | | | | | | | | | | | BUG=chromium:271236 BRANCH=falco,peppy TEST=Run 'ectool temps all' Verify temp. values are present for the g781. Change-Id: I2ea8aff9e256167bf04abc959f971da94fc51e77 Signed-off-by: Dave Parker <dparker@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/65597 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Add fan power enable GPIO for PeppyDave Parker2013-08-134-2/+10
| | | | | | | | | | | 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
* Remove board 'wolf' from master/ToT branch.stabilize-falco-4537.91.Bstabilize-4537.147.Bstabilize-4537.118.Brelease-R30-4537.BDave Parker2013-08-128-480/+3
| | | | | | | | | | | | | | 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>
* Add abstract "cond_t" type to detect state transitions.Bill Richardson2013-08-093-1/+202
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We often need to watch for transitions between one state and another, so that we can issue warnings or take action ONCE. This abstracts that "have I already reacted to this" stuff into a single set of functions. For example, this code reads a GPIO every time through the loop, but it only generates an event when the GPIO value changes from 0 to 1: cond_t c; cond_init_false(&c); while(1) { int val = read_some_gpio(); cond_set(&c, val); if (cond_went_true(&c)) host_event(SOMETHING_HAPPENED); sleep(1); } BUG=none BRANCH=falco,peppy TEST=manual make BOARD=falco runtests Change-Id: I42393fcf3c4eb71b9551118a0f442d55c0691315 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/65071
* Haswell: shutdown directly to G3 without pausing in S5Bill Richardson2013-08-091-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We've been pausing in S5 for ten seconds for various arcane reasons related to clock rates and USB peripherals. We don't need to do that anymore, and there are other arcane reasons why it's better if we don't. BUG=chrome-os-partner:21791 BRANCH=falco,peppy TEST=manual On the EC console, limit the output to just the chipset channel: > chan 4 Now boot the AP, then shut down. Before you'd see a ten-second pause in S5, like this: [29.586858 x86 power state 3 = S0, in 0x00df] [29.587268 x86 power state 7 = S0->S3, in 0x009f] [29.587707 x86 power state 2 = S3, in 0x009f] [29.587959 x86 power state 8 = S3->S5, in 0x009f] [29.588474 x86 power state 1 = S5, in 0x009c] [29.588733 x86 power state 1 = S5, in 0x009c] [29.603317 x86 power state 1 = S5, in 0x0094] [39.603612 x86 power state 9 = S5->G3, in 0x0094] [39.604137 x86 power state 0 = G3, in 0x0000] [39.604376 x86 power state 0 = G3, in 0x0000] With this change the pause is gone: [26.764160 x86 power state 3 = S0, in 0x00df] [26.764570 x86 power state 7 = S0->S3, in 0x009f] [26.765011 x86 power state 2 = S3, in 0x009f] [26.765262 x86 power state 8 = S3->S5, in 0x009f] [26.765777 x86 power state 9 = S5->G3, in 0x009c] [26.766220 x86 power state 0 = G3, in 0x0008] [26.766526 x86 power state 0 = G3, in 0x0008] [26.770517 x86 power state 0 = G3, in 0x0000] Change-Id: I05e19ddfe9dfa1bcc2a29103d120910c4371b88e Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/65336 Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
* Hide battery vendor params override behind config optionRandall Spangler2013-08-098-22/+11
| | | | | | | | | | | | | | | | | 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>
* Console command for g781 temperature sensor.Dave Parker2013-08-092-13/+194
| | | | | | | | | | | | | | | | | | | | | | | | Read status, set temperature alert thresholds, get and set configuration options. I2c offsets and status/config register bits are documented in temp_sensor_g781.h Usage by example: g781 - Print status info g781 settemp 0x0e 12 - Set remote low temp alarm to 12C g781 setbyte 0x09 0x40 - Enable single-shot mode g781 getbyte 0xfe - Read device ID BUG=None BRANCH=falco,peppy TEST=Manual. Run g781 console command Signed-off-by: Dave Parker <dparker@chromium.org> Change-Id: Id051f79ea643255d57c3fc694b7ae685a6611c81 Reviewed-on: https://gerrit.chromium.org/gerrit/65234 Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Dave Parker <dparker@chromium.org> Tested-by: Dave Parker <dparker@chromium.org>
* Fix leaving keyboard scanning disabled on brief power button pressRandall Spangler2013-08-091-4/+4
| | | | | | | | | | | | | | | | | | | | If the power button is pressed for a shorter period than the debounce timeout, then the debounced state never changes. This was causing the power button state machine to disable scanning (in the interrupt handler) but never re-enable it (in the deferred handler). Easy fix; just re-enable based on whether the current state is released, not whether the debounced state is transitioning to released. BUG=chrome-os-partner:21772 BRANCH=all (falco, pit, etc.) TEST=type on console. briefly flick power button. type more; should work. Change-Id: I9723a6aa10f122fcee62702b85ce7981b1c8103a Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/65238 Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
* pit: leave 1.35V rail on during warm rebootRandall Spangler2013-08-091-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This maintains the contents of AP RAM during the warm reboot. BUG=chrome-os-partner:21483 BRANCH=pit TEST=from u-boot prompt, Peach # mm 41f00000 41f00000: 00000000 ? 9 41f00004: 00000000 ? 9 41f00008: 00000000 ? 9 41f0000c: 00000000 ? 9 41f00010: 00000000 ? 9 41f00014: 00000000 ? 9 41f00018: 00000000 ? 9 41f0001c: 00000000 ? 9 41f00020: 00000000 ? 9 41f00024: 00000000 ? 9 41f00028: 00000000 ? 9 41f0002c: 00000000 ? 9 41f00030: 00000000 ? 9 41f00034: 00004000 ? 9 41f00038: 00000000 ? 9 41f0003c: 00000000 ? 9 41f00040: 00000000 ? . Peach # md 41f00000 41f00000: 00000009 00000009 00000009 00000009 ................ 41f00010: 00000009 00000009 00000009 00000009 ................ 41f00020: 00000009 00000009 00000009 00000009 ................ 41f00030: 00000009 00000009 00000009 00000009 ................ Then Alt+VolUp+R. Then repeat md command at u-boot prompt. Change-Id: I07de4df2fe4c4dd86b88bbd208e1fb87860fa9d5 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/65227 Reviewed-by: Julius Werner <jwerner@chromium.org>
* Update Wolf from Slippy.Hsu Henry2013-08-085-11/+78
| | | | | | | | | | | | | | | | | Copy from Slippy and Delete BAT_DETECT_L and related functions. (create new file battery_wolf.c) BRANCH=wolf BUG=none TEST=manual Build it with util/make_all.sh, seems fine. Change-Id: I672147c45e14d03c7f4cf8ecc6daa3f889f97c05 Signed-off-by: Hsu Henry <Henry.Hsu@quantatw.com> Reviewed-on: https://gerrit.chromium.org/gerrit/63872 Reviewed-by: Dave Parker <dparker@chromium.org> Tested-by: Dave Parker <dparker@chromium.org> Commit-Queue: Dave Parker <dparker@chromium.org>
* pit: If flash registers are disabled all blocks are protectedRandall Spangler2013-08-081-0/+7
| | | | | | | | | | | | | | | | | | This fixes a confusing indication in flashinfo, where the all_now flag is set but banks aren't shown as protected now. BUG=chrome-os-partner:20277 BRANCH=pit TEST=See bug for full test procedure. In short: 1) Enable physical write protect 2) flashwp enable 3) flashwp now 4) flashinfo shows all banks protected now Change-Id: I489e80f63a33c182629d3a04fd0a9dadfb3914ab Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/64980 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Put knowledge of task-config dependency in config.hRandall Spangler2013-08-0813-41/+41
| | | | | | | | | | | | | | | 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: remove I2C port detectionRandall Spangler2013-08-083-47/+2
| | | | | | | | | | | | | | | | 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>
* console_output: Add commands for saving / restoring print mask.Shawn Nematbakhsh2013-08-081-13/+24
| | | | | | | | | | | | | | | | | | | | | | | Saving + restoring the channel print mask previously involved running the 'chan' command with no parameters, then parsing the output. This parsing is unreliable if other tasks are also writing to the console. Add commands to save / backup the current channel mask, and later restoring it. Typical method to limit channel mask will now be: chan save chan <mask> ... chan restore BUG=chromium:269758. TEST=Run 'chan save' / 'chan 0' / 'chan restore' on EC console, verify print mask is restored. BRANCH=Peppy/Falco. Change-Id: I725c7fb5e3ac7e55ed5f435446f8fc5c54af165f Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/65208 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Use macros for C <-> K conversionsBill Richardson2013-08-078-18/+17
| | | | | | | | | | | | | | | This just replaces all the "X - 273", "Y + 273" stuff with a macro. BUG=none BRANCH=falco,peppy TEST=manual Run the EC console command "temps". It should print human-readable things. Change-Id: Icc4284c89fdbc0cd3b206a0faacf121973652a63 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/65005 Reviewed-by: Randall Spangler <rspangler@chromium.org>
View Lorry Controller Status