summaryrefslogtreecommitdiff
path: root/chip
Commit message (Collapse)AuthorAgeFilesLines
* mec1322: i8042 interfaceVic (Chun-Ju) Yang2013-12-172-0/+62
| | | | | | | | | | | | | This implements i8042 keyboard interface at LPC 0x60/0x64. BUG=chrome-os-partner:21407 TEST=Enable keyboard and keystroke from host ACPI commands. Short KSO pins and KSI pins, and read different key codes from host. BRANCH=None Change-Id: Ie4e5e236bdeefd7e44974f92fcbafab5e4af2b30 Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/179940
* rambi: Add duplicate GPIO outputs for proto 2.0 boardRandall Spangler2013-12-161-0/+12
| | | | | | | | | | | | | | | | | | | Proto 2.0 makes these changes: KBD_IRQ# moves from PM4 to PM3. EC_PWROK moves from PH2 to PJ1. Since PM3 and PJ1 are unused on proto 1.5, it's harmless to duplicate the current functionality on those outputs. We can remove the old outputs when we deprecate the 1.5 boards. BUG=chrome-os-partner:24424 BRANCH=none TEST=boot rambi Change-Id: Iff77651ef575a8405878fe75f025a0507b02b771 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/180081 Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
* Rename mixed-case config constantsRandall Spangler2013-12-169-33/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | This renames constants used in compiler conditionals to uppercase. BOARD_foo CHIP_foo CHIP_FAMILY_foo CHIP_VARIANT_foo CORE_foo Mixed-case constants are still defined by the makefile, but are now no longer used. I will make one more pass in a week or so to catch any that are part of someone else's CL, since otherwise this change might silently merge correctly but result in incorrect compilation. Then I will remove defining the mixed-case constants. BUG=chromium:322144 BRANCH=none TEST=Build all boards. Also, "git grep 'BOARD_[a-z]'" should return no results (similarly for CHIP, CORE, etc.) Change-Id: I6418412e9f7ec604a35c2d426d12475dd83e7076 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/179206 Reviewed-by: Vic Yang <victoryang@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* mec1322: ACPI and host event supportVic (Chun-Ju) Yang2013-12-141-6/+157
| | | | | | | | | | | | | | | | | This wires 0x62/0x66 to ACPI module and also implements the host event functions. BUG=chrome-os-partner:24107 TEST=ACPI memory test and compliment memory test. TEST=Set SCI mask and host event to trigger SCI. Check SCI pin pulse low. TEST=Query host event from ACPI. BRANCH=None Change-Id: Ib1f557e995a861c92a603491229ad361e17d2129 Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/179942 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Implement DPTF thermal thresholdsBill Richardson2013-12-131-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Any of the EC's temp sensors can have up to two independent thresholds attached to them. When the temperature crosses the threshold (rising or falling), a EC_HOST_EVENT_THERMAL_THRESHOLD event is sent to the AP. It's up to the AP to read the sensor values and figure out why the event was sent. The thresholds are set and enabled with ACPI writes to three registers in the EC interface space: EC_ACPI_MEM_TEMP_ID, EC_ACPI_MEM_TEMP_THRESHOLD, and EC_ACPI_MEM_TEMP_COMMIT. Refer to the comments in ec_commands.h for details on their use. ACPI does not provide any means to read the threshold settings (the AP will just have to remember), but there is an EC console command "dptftemp", that can be used to examine the current settings. BUG=chrome-os-partner:23970 BRANCH=none TEST=manual On the EC console, check the current threshold settings and temperatures: > dptftemp sensor thresh0 thresh1 0 --- --- PECI 1 --- --- ECInternal 2 --- --- I2C-Charger-Die 3 --- --- I2C-Charger-Object 4 --- --- I2C-CPU-Die 5 --- --- I2C-CPU-Object 6 --- --- I2C-Left C-Die 7 --- --- I2C-Left C-Object 8 --- --- I2C-Right C-Die 9 --- --- I2C-Right C-Object 10 --- --- I2C-Right D-Die 11 --- --- I2C-Right D-Object 12 --- --- I2C-Left D-Die 13 --- --- I2C-Left D-Object > > temps PECI : 318 K = 45 C ECInternal : 306 K = 33 C I2C-Charger-Die : 309 K = 36 C I2C-Charger-Object : Not calibrated I2C-CPU-Die : 309 K = 36 C I2C-CPU-Object : Not calibrated I2C-Left C-Die : 306 K = 33 C I2C-Left C-Object : Not calibrated I2C-Right C-Die : 307 K = 34 C I2C-Right C-Object : Not calibrated I2C-Right D-Die : 307 K = 34 C I2C-Right D-Object : Not calibrated I2C-Left D-Die : 306 K = 33 C I2C-Left D-Object : Not calibrated > In this case, the PECI temp is 318 K, so let's set a threshold at 322 K. On the AP: [ "$#" -eq "2" ] || return; iotools io_write8 0x66 0x81 iotools io_write8 0x62 $1 iotools io_write8 0x62 $2 } Back on the EC console, we see that the threshold has been set: [768.176648 DPTF sensor 0, threshold 49 C, index 1, enabled] > dptftemp sensor thresh0 thresh1 0 --- 322 PECI 1 --- --- ECInternal 2 --- --- I2C-Charger-Die ... Now do something on the AP to increase the temperature (webgl aquarium, etc). When the temp goes above 322 K, the EC console reports it and sends a host event, and the "dptftemp" command indicates the over-temp condition: [815.367442 DPTF over threshold [0][1] [815.367878 event set 0x00000100] [815.368069 sci 0x00000100] [815.368619 event clear 0x00000100] > dptftemp sensor thresh0 thresh1 0 --- 322* PECI 1 --- --- ECInternal 2 --- --- I2C-Charger-Die ... Log out and wait for the temp to drop. You'll see that trigger a host event as well: [854.375713 DPTF under threshold [0][1] [854.376147 event set 0x00000100] [[854.376396 event clear 0x00000100] > dptftemp sensor thresh0 thresh1 0 --- 322 PECI 1 --- --- ECInternal 2 --- --- I2C-Charger-Die ... Change-Id: I6bb34c615f37477ccf37163caaa94737baed8dae Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/179962 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* mec1322: keyboard scan supportVic (Chun-Ju) Yang2013-12-134-0/+81
| | | | | | | | | | | | | | | | | | | | | This adds keyboard scan module driver. Keyboard scan task is not enabled yet as the LPC layer is not finished and thus i8042 protocol cannot be enabled. Since KSO00-KSO03 are used as JTAG, we use KSO04-KSO16 so as to preserve JTAG functionality. Unfortunately we don't have enough KSO pins, so trace debug port must be disabled, as done in this CL. BUG=chrome-os-partner:24107 TEST=Set 'ksstate on'. Short KSI pins and KSO pins, and see corresponding key shown as pressed. TEST=Check keypress is detected when console shows 'KB wait'. BRANCH=None Change-Id: I366a27453ef95030d251e525313eb4627eb4340f Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/179319 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Change PECI_TJMAX to a board config optionChromeOS Developer2013-12-131-13/+4
| | | | | | | | | | | | | BUG=chrome-os-partner:24455 BRANCH=none TEST=Manual: Verify that CONIFG_PECI_TJMAX set per-board matches the value queried over the PECI bus with the restricted "peciprobe" command. Change-Id: I8e99a23a66f26d6101e01cc751d0a8ca79686321 Signed-off-by: Dave Parker <dparker@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/179682 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* Move ACPI stuff out of chip/lm4 and into commonBill Richardson2013-12-122-105/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The port 62/66 ACPI commands were implemented in chip/lm4/lpc.c. They should be handled in common instead of being tied to a particular EC. BUG=chrome-os-partner:23774 BRANCH=none TEST=manual read EC_ACPI_MEM_VERSION # iotools io_write8 0x66 0x80; iotools io_write8 0x62 0; iotools io_read8 0x62 0x01 write & read EC_ACPI_MEM_TEST # iotools io_write8 0x66 0x81; iotools io_write8 0x62 1; iotools io_write8 0x62 0xa5 # iotools io_write8 0x66 0x80; iotools io_write8 0x62 1; iotools io_read8 0x62 0xa5 # iotools io_write8 0x66 0x80; iotools io_write8 0x62 2; iotools io_read8 0x62 0x5a # iotools io_write8 0x66 0x81; iotools io_write8 0x62 1; iotools io_write8 0x62 0xbb # iotools io_write8 0x66 0x80; iotools io_write8 0x62 1; iotools io_read8 0x62 0xbb # iotools io_write8 0x66 0x80; iotools io_write8 0x62 2; iotools io_read8 0x62 0x44 read & write EC_ACPI_MEM_KEYBOARD_BACKLIGHT # iotools io_write8 0x66 0x81; iotools io_write8 0x62 3; iotools io_write8 0x62 100 (keyboard lights up) # iotools io_write8 0x66 0x80; iotools io_write8 0x62 3; iotools io_read8 0x62 0x64 # iotools io_write8 0x66 0x81; iotools io_write8 0x62 3; iotools io_write8 0x62 50 (keyboard dimmer) # iotools io_write8 0x66 0x80; iotools io_write8 0x62 3; iotools io_read8 0x62 0x32 # iotools io_write8 0x66 0x81; iotools io_write8 0x62 3; iotools io_write8 0x62 0 (keyboard goes dark) # iotools io_write8 0x66 0x80; iotools io_write8 0x62 3; iotools io_read8 0x62 0x00 read & write EC_ACPI_MEM_FAN_DUTY # iotools io_write8 0x66 0x81; iotools io_write8 0x62 4; iotools io_write8 0x62 100 (fan on full) # iotools io_write8 0x66 0x80; iotools io_write8 0x62 4; iotools io_read8 0x62 0x64 # iotools io_write8 0x66 0x81; iotools io_write8 0x62 4; iotools io_write8 0x62 50 (fan on half speed) # iotools io_write8 0x66 0x80; iotools io_write8 0x62 4; iotools io_read8 0x62 0x32 # iotools io_write8 0x66 0x81; iotools io_write8 0x62 4; iotools io_write8 0x62 0 (fan off) # iotools io_write8 0x66 0x80; iotools io_write8 0x62 4; iotools io_read8 0x62 0x00 # iotools io_write8 0x66 0x81; iotools io_write8 0x62 4; iotools io_write8 0x62 0xff (fan back to EC control) # iotools io_write8 0x66 0x80; iotools io_write8 0x62 4; iotools io_read8 0x62 0xff test EC_CMD_ACPI_QUERY_EVENT # iotools io_write8 0x66 0x84; iotools io_read8 0x62 0x00 On EC console: > hostevent set 0x0f000000 # ectool eventget Current host events: 0x0f000000 # iotools io_write8 0x66 0x84; iotools io_read8 0x62 0x19 # iotools io_write8 0x66 0x84; iotools io_read8 0x62 0x1a # iotools io_write8 0x66 0x84; iotools io_read8 0x62 0x1b # iotools io_write8 0x66 0x84; iotools io_read8 0x62 0x1c # iotools io_write8 0x66 0x84; iotools io_read8 0x62 0x00 # ectool eventget Current host events: 0x00000000 Change-Id: I011a5a2051171ec1d37e55ce03e1ce74b93a7e14 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/179692
* lm4: Fix potential false over-temperature on entry to S0Alec Berg2013-12-091-1/+9
| | | | | | | | | | | | | | | | | | | This fixes a rare problem in which the EC could shutdown due to a false over-temperature when entering S0 on Haswell architectures. The fix involves requiring two valid reads of the temperature sensor (out of the last 4 readings) in order to report it. BUG=chrome-os-partner:24204 BRANCH=none TEST=See bug report for a patch that recreates the bug at a significantly higher rate then it would occur on its own. Using that patch, I implemented this fix, and made sure that there were no false over-temperatures reported. Change-Id: I0454eca1b96fd2fa1833b080026ed8f1caeeddc4 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/177963 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* mec1322: I2C driverVic (Chun-Ju) Yang2013-12-064-1/+378
| | | | | | | | | | | | | | | | | | This adds the driver for MEC1322 I2C controller. BUG=chrome-os-partner:24107 TEST=Hook up TSU6721 to eval board. Do the following tests: - 'i2cscan' and see TSU6721. - Read device ID register and get correct value. - Add 3 tasks randomly doing I2C read and writes. Check there is no error. BRANCH=None Change-Id: I465f73fe8177a8df6b56c57e594cd733caea37d4 Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/178591 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* extract common core codeVincent Palatin2013-12-051-0/+5
| | | | | | | | | | | | | | | | | | | | | | Move the non-core dependent code out of core/$(CORE) directory to common/ directory. Put all panic printing code in common/panic_output.c Put timer management code in common/timer.c Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=chrome-os-partner:23574 TEST=./util/make_all.sh use "crash divzero" and "panicinfo" on Link. Change-Id: Ia4e1ebc74cd53da55fe24f69e96f39f512b9336d Reviewed-on: https://chromium-review.googlesource.com/178871 Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Jeremy Thorpe <jeremyt@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
* mec1322: Fan control driverVic (Chun-Ju) Yang2013-12-043-0/+178
| | | | | | | | | | | | | | | | | | | | This adds the driver for PWM duty cycle based and RPM based fan control. BUG=chrome-os-partner:24107 TEST='fanset 5000' and fan spins up. 'fanset 8000' and fan spins faster. 'fanset 0' and fan stops. 'fanduty 30' and fan spins up. 'fanduty 50' and fan spins faster. 'fanduty 30' and fan slows down. 'fanset 6000' and fan goes to ~6000 RPM. Unplug fan power and see 'fan 0 stalled'. Plug power back and doesn't see stall warning anymore. BRANCH=None Change-Id: Ice3e5c03686cde57894e888e34ae2070c33b4e4d Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/178402
* mec1322: LPC host command supportVic (Chun-Ju) Yang2013-12-044-1/+178
| | | | | | | | | | | | | | | | | | | With this, basic host command functionality is working. We don't have the correct description of LPC memory BAR register yet, so we have to use EMI (embedded memory interface) module for 0x800-0x9ff region. This requires a slightly different protocol, which is in the next CL. BUG=chrome-os-partner:24107 TEST=Wire EVB to Stumpy. 'ectool hello' and 'ectool version' working. BRANCH=None Change-Id: I873b4a455cf692e479321a5c6e18c8f33df60e66 Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/178250 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* mec1322: Add support for CONFIG_WATCHDOG_HELPVic (Chun-Ju) Yang2013-12-021-5/+81
| | | | | | | | | | | | | | | | | | If CONFIG_WATCHDOG_HELP is defined, a 16-bit timer is used as an auxiliary timer to interrupt us 50ms before the watchdog expires. When the auxiliary timer expires, the stack trace is printed. Watchdog then expires 50ms after and reboots the system. BUG=chrome-os-partner:24107 TEST=Define CONFIG_WATCHDOG_HELP, and see stack trace on 'waitms 2000'. TEST=Undefine CONFIG_WATCHDOG_HELP, and check watchdog still works without printing stack trace. BRANCH=None Change-Id: I2555d3f86a15c83bb03a00c6807f77d9dddaf333 Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/178284 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* mec1322: Add PWM driverVic (Chun-Ju) Yang2013-12-024-0/+94
| | | | | | | | | | | | | | | | This adds a PWM driver, which now generates 30KHz PWM output. Note that this is different from fan control module driver. BUG=chrome-os-partner:24107 TEST=Set GPIO136 to PWM1. Attach logic analyzer to monitor its output. - Set to active high and 30%, see 30% duty PWM at ~29.1KHz. - Set to active low and 20%, see 80% duty PWM at ~29.1KHz. BRANCH=None Change-Id: I5f1001d5a4701e19fa87c4cabfd4ae5ae7ccb30c Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/178391 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* mec1322: Check/save reset causeVic (Chun-Ju) Yang2013-12-021-0/+38
| | | | | | | | | | | | | | | | So far we can only reliably sense a watchdog reset, but this saving/checking reset cause will at least make 'ap-off' flag work. BUG=chrome-os-partner:24107 TEST='waitms 2000' and see reset cause = 'watchdog' TEST='reboot ap-off' and see reset cause includes 'ap-off' TEST='reboot preserve' and see previous reset cause is preserved. BRANCH=None Change-Id: Id47a72d615489c9d9cd0b8761cfa699f08c724df Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/178277 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* mec1322: Add support for VBAT backed RAMVic (Chun-Ju) Yang2013-12-022-0/+17
| | | | | | | | | | | | | | This will be used for saving data across reboots. BUG=chrome-os-partner:24107 TEST=Enable scratchpad command and check value is preserved across watchdog reboot. BRANCH=None Change-Id: Ifd68541a3f842c466b6ff49bcc654c92df48aac6 Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/178276 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* mec1322: remove the ugly DUMMY() macro in system.cVic (Chun-Ju) Yang2013-12-021-5/+15
| | | | | | | | | | | | | | DUMMY() is ugly and DUMMY_int() makes repo complain. Replace them with explicit functions. BUG=chrome-os-partner:24107 TEST=Build mec1322_evb BRANCH=None Change-Id: I155b769c12cafaf432c7f53fd46806feada3cfca Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/178275 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* mec1322: Deassert iRESET_OUT on initVic (Chun-Ju) Yang2013-11-271-0/+3
| | | | | | | | | | | | | | | | iRESET_OUT must be deasserted before the host can boot, and it's also the gating source of the internal nSIO_RESET signal. There is a delay between deasserting iRESET_OUT and nSIO_RESET inactivated, so let's deassert iRESET_OUT as early as possible. BUG=chrome-os-partner:24107 TEST=Boot EVB and check iRESET_OUT value BRANCH=None Change-Id: I6647da00567e2651c2b49e1e767adee2d5276493 Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/178171 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* mec1322: Add more register address and IRQ numbersVic (Chun-Ju) Yang2013-11-271-0/+95
| | | | | | | | | | | | | No functional changes. Just adding more chip-specific constants. BUG=chrome-os-partner:24107 TEST=Build mec1322_evb BRANCH=None Change-Id: I649ad2656da941c28a2a738007ced955cd25ea75 Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/178170 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* mec1322: Add GPIO interrupt supportVic (Chun-Ju) Yang2013-11-261-3/+116
| | | | | | | | | | | | | | | | | | With this, we can now define and trigger interrupt on GPIO status. BUG=chrome-os-partner:24107 TEST=Test GPIO036 with following cases: - Pulled up and rising edge trigger. Pull down externally and then release. - Pulled up and falling edge trigger. Pull down externally. - Pulled up and both edge trigger. Pull down and then release. - Pulled up and low level trigger. Pull down externally. BRANCH=None Change-Id: Id9bfd2ba9dd8a75bcf2c5691ffe2aa6518076925 Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/177560 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* mec1322: Add script for packing EC binary into SPI flashVic (Chun-Ju) Yang2013-11-261-0/+159
| | | | | | | | | | | | | | | | This script is needed for packing EC binary into SPI flash for MEC1322. This includes adding tag and header at appropriate location and signing the image. Signing key, for obvious reason, is not included here until we are sure what key we want to check in. BUG=chrome-os-partner:24107 TEST=Build and boot on eval board BRANCH=None Change-Id: I92db7d2ba2c76c14a9c6611a04dbd6a2c3eb8d83 Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/177324 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* mec1322: Add watchdog supportVic (Chun-Ju) Yang2013-11-262-0/+33
| | | | | | | | | | | | | | | This implements the basic watchdog support. For now, the watchdog doesn't warn us before it expires. This functionality will be added later using a basic timer. BUG=chrome-os-partner:24107 TEST='waitms 700' and the EC stays alive. TEST='waitms 1200' and the EC reboots. BRANCH=None Change-Id: I1cc48978ed09577ae88cc2f7a6087867e5854973 Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/177736
* gpio: Make GPIO_INT_BOTH explicitly RISING|FALLINGRandall Spangler2013-11-234-9/+9
| | | | | | | | | | | | | | | | | | | | | | | For historical reasons on LM4, we defined GPIO_INT_F_BOTH separately from GPIO_INT_F_RISING and GPIO_INT_F_FALLING. This means that the code has weird checks like BOTH || (RISING && FALLING), which have propagated in error-prone ways across the other chips. Instead, explcitly define BOTH to be RISING|FALLING. Ideally, we would have called it GPIO_INT_EDGE to match GPIO_INT_LEVEL, but changing that now would be a big find-replace. Which might still be a good idea, but that is best done in its own CL. BUG=chrome-os-partner:24204 BRANCH=none TEST=build and boot pit, spring, and link; that covers STM32F, STM32L, and LM4. Change-Id: I23ba05a3f41bb14b09af61dc52a178f710f5c1bb Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/177643 Reviewed-by: Jeremy Thorpe <jeremyt@chromium.org> Reviewed-by: Vic Yang <victoryang@chromium.org>
* Remove bolt, daisy, kirby, puppy, slippy boardsRandall Spangler2013-11-211-22/+2
| | | | | | | | | | | | | | | | | | These boards are unloved and unsupported. They'll never grow up to be laptops, and hardware is increasingly hard to come by. Comparable functionality is available in the other, more-loved boards. Removing these boards speeds up util/make_all.sh by 40%. (If you're not running that before every upload, you should be...) BUG=chrome-os-partner:24062 BRANCH=none TEST=build all remaining platforms and pass unit tests Change-Id: I4d8a49e4d52d7393471f1b1cbef059c8db4a4f77 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/177373
* Add DPTF interface for fan dutyBill Richardson2013-11-211-1/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds include/dptf.h to define the DPTF interface functions. As the first DPTF feature, it also adds a register to the EC's ACPI interface block. Register 0x04 is used to get and set the fan's target duty cycle, as a percentage value. Writing a 0 to this register will set the target duty cycle to 0, writing a 100 (0x64) will set it to 100%. Writing any other value will return the fan control to the EC, rather than driving it manually from the host. Likewise, reading from this register returns the current fan target duty cycle, as a percentage. If the EC is controlling the fan automatically, the returned value will be 0xFF. BUG=chrome-os-partner:23972 BRANCH=none TEST=manual You can monitor the fan state from the EC console with the "faninfo" command. From the host side, test this interface from a root shell. Read fan duty: iotools io_write8 0x66 0x80 iotools io_write8 0x62 4 iotools io_read8 0x62 Set fan duty to 100%: iotools io_write8 0x66 0x81 iotools io_write8 0x62 4 iotools io_write8 0x62 100 Set fan duty to 50%: iotools io_write8 0x66 0x81 iotools io_write8 0x62 4 iotools io_write8 0x62 50 Set fan duty to 0%: iotools io_write8 0x66 0x81 iotools io_write8 0x62 4 iotools io_write8 0x62 0 Set fan control back to automatic: iotools io_write8 0x66 0x81 iotools io_write8 0x62 4 iotools io_write8 0x62 -1 Change-Id: I91ec463095cfd17adf452f0967da3944b254d558 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/177423 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* lm4: add option for using gpio as kebyoard interruptAaron Durbin2013-11-211-2/+18
| | | | | | | | | | | | | | | | | | | | On certain boards it's no feasible to use the SERIRQ method for generating the kebyboard interrupt. To that end provide CONFIG_KEYBOARD_IRQ_GPIO option which specifies the negative edge-triggered gpio for the keyaboard interrupt. BUG=chrome-os-partner:23965 BRANCH=None TEST=Built and booted rambi using this option. Keyboard works in kernel with interrupts for i8042 device. Change-Id: I64f7e9530841c184d2a33821126ec446c96bb0f0 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/177188 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Tested-by: Bernie Thompson <bhthompson@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* mec1322: initial commitVic (Chun-Ju) Yang2013-11-2111-0/+766
| | | | | | | | | | | | | | | | | | | | This is the initial commit of mec1322 support. This includes: - Basic GPIO driver. Interrupt not supported yet. - Microsecond timer - UART driver The script to pack the firmware binary will be checked in in following-up CL. BUG=chrome-os-partner:24107 TEST=Build and boot on eval board BRANCH=None Change-Id: I9013c908049d1f740f84bb56abca51b779f39eef Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/175716 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* stm32f: Disable UART receive DMARandall Spangler2013-11-193-2/+11
| | | | | | | | | | | | | | | | | | Not sure why, but it doesn't seem to work consistently on my Spring. Transmit works fine, but on some boots receive doesn't seem to pick up received characters. Rather than churning Spring to fix this, just disable receive DMA - which doesn't benefit Spring much anyway, because it never downclocks its core to 1 MHz. BUG=chrome-os-partner:24141 BRANCH=none TEST=Boot Spring; typing into console works. After 'apshutdown', typing still works (including arrow keys). Repeat 20 times. Repeat on Pit. Change-Id: I5d9875b583c8e2a38b9070c4dfa31fd5a982a144 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/177352 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* stm32: Flush UART buffer before changing EC core clock speedRandall Spangler2013-11-191-1/+7
| | | | | | | | | | | | | | | | | Otherwise UART output gets garbled because there's a delay between changing core clock and the UART divider. Fortunately, the glitch is cosmetic and doesn't affect proper EC operation. BUG=chrome-os-partner:23982 BRANCH=none TEST=power on, power off on pit or nyan --> no UART glitch Change-Id: I32bef119b850a340fc616b83a4b088b20f17267f Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/177087 Reviewed-by: Yung-chieh Lo <yjlou@chromium.org> Tested-by: Yung-chieh Lo <yjlou@chromium.org> Commit-Queue: Yung-chieh Lo <yjlou@chromium.org>
* lm4: allow the lpc module to use GPIO for SCIAaron Durbin2013-11-151-0/+6
| | | | | | | | | | | | | | | | | | The LPC module has a dedicated control for SCI#. However, certain situations require a dedicated GPIO for asserting the SCI# signal. Introduce CONFIG_SCI_GPIO to meet this requirement. BUG=chrome-os-partner:24003 BRANCH=None TEST=Built and booted rambi with dependency change. 'lidclose' and 'lidopen' cause ACPI interrupts. Change-Id: I34c5f0ba5ff60151972921f251c71d3769a9ef8b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/176804 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* stm32: Don't use a stack buffer for i2c_read_string()Randall Spangler2013-11-072-17/+15
| | | | | | | | | | | | | | | | | | We read a counted string (byte 0 = count, bytes 1 - count = chars) and convert it to a null-terminated string. Since both have a 1-byte overhead, we can use the destination buffer instead of using a stack-based buffer. BUG=chrome-os-partner:23928 BRANCH=none (pit is affected, but battery console command isn't used on end user systems) TEST=battery command shows correct strings (SDI / 4302D40 / LiP), and doesn't stack overflow. Change-Id: Ic0f111cde2d57b41d6ce9287e0c771acc09a8869 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/176116 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Move core-specific toolchain configuration to core/ directoryVincent Palatin2013-11-072-0/+6
| | | | | | | | | | | | | | | | This is preparatory work to introduce a second core architecture. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=chrome-os-partner:23574 TEST=./util/make_all.sh Change-Id: Icae8a7e475a4ba2a13f0d8f95629e8498a5a61da Reviewed-on: https://chromium-review.googlesource.com/175419 Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
* lm4: Fixed low power idle doesn't always wake up.stabilize-4920.6.Brelease-R32-4920.BAlec Berg2013-11-051-12/+26
| | | | | | | | | | | | | | | | | | | | | Temporary fix to the bug in which we miss wake events when in deep sleep with the LFIOSC (32kHz) clock and the EC is cold. This fix involves simply using a faster clock, 250kHz, when in low speed deep sleep. This fix consumes more power but solves the bug. Renamed EC console command dsleepmask to dsleep. BRANCH=none BUG=chrome-os-partner:23678 TEST=Go in to low speed deep sleep by going into either S3 or G3 and letting the EC console timeout. Then freeze-spray the EC chip. Wake up the EC via the console and make sure that the idlestats show that we have not missed a deadline. Change-Id: I4f9844f1937bc8c95cf1540502f7d8fb4cbc097e Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/175614 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Clean up hook priorties on LM4Randall Spangler2013-11-042-2/+2
| | | | | | | | | | | | | | | | | | | | Fan no longer needs a special priority to wait for the host memmap to become available, since LPC inits earlier. I2C and PECI don't need explicit ordering on freq change. Thermal now uses the explicit prio for temp sensors done. Commented hook test. BUG=chromium:314768 BRANCH=none TEST=boot link; enable/disable PLL; verify fanset and temps commands work afterwards. Change-Id: I71766614dff2950dd307acd0635405e6b59e330a Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/175601 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* cortex-m: ensure we use the right subset of the instruction setVincent Palatin2013-11-022-1/+5
| | | | | | | | | | | | | | | | | | | | | | | Cortex-M3 and Cortex-M4 are not using exactly the same instruction set. Cortex-M3 is using ARMv7-M ISA which is a subset of the ARMv7E-M used by the Cortex-M4 core (even though the delta is small). Let's restrict each core to the right subset of instruction by pushing the -mcpu/-march configuration in the chip specific area. Note: GCC 4.8 is now using the full ARMv7E-M instruction set and will emit "undefined instruction" on Cortex-M3 without this patch. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=chromium:314194 TEST=build *and* run on Spring and Link. Change-Id: I2f9b87fec689e8d1097809cab437a2bd32dfa194 Reviewed-on: https://chromium-review.googlesource.com/175487 Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
* Provide multiple fan support within the EC itselfBill Richardson2013-11-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds explicit "int fan" args to the exported functions from common/fan.c: fan_set_percent_needed() and fan_percent_to_rpm(). Within that file, multiple fans are handled independently. This is not complete, though. Host commands and sysjump support still only handle a single fan, so at the moment multiple fans are treated identically in those cases. BUG=chrome-os-partner:23530 BRANCH=none TEST=manual All boards build, "make runtests" passes. On a multi-fan system, the EC command "faninfo" displays multiple results: > faninfo Fan 0 Actual: 0 rpm Fan 0 Target: 0 rpm Fan 0 Duty: 0% Fan 0 Status: 0 (not spinning) Fan 0 Mode: rpm Fan 0 Auto: yes Fan 0 Enable: yes Fan 1 Actual: 0 rpm Fan 1 Target: 0 rpm Fan 1 Duty: 0% Fan 1 Status: 0 (not spinning) Fan 1 Mode: rpm Fan 1 Auto: no Fan 1 Enable: no > and the "fanduty", "fanset", and "fanauto" all require the fan number as the first arg: > fanduty 0 30 Setting fan 0 duty cycle to 30% > fanset 1 2000 Setting fan 1 rpm target to 2000 > fanauto 0 > fanauto 1 On single-fan systems, there is no visible change. Change-Id: Idb8b818122e157960d56779b2a86e5ba433bee1b Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/175368 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* cleanup: Still more TODO commentsRandall Spangler2013-11-023-17/+20
| | | | | | | | | | | | | More of same. Comment changes only; no code changes. BUG=chrome-os-partner:18343 BRANCH=none TEST=build all platforms; pass unit tests Change-Id: I8c42ed7d332cd9d461067e1aeac670855106cbcd Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/175405 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* lm4: Verify data buffer is aligned for flash writesRandall Spangler2013-11-021-0/+4
| | | | | | | | | | | | | | | | | | | All the current data buffers *are* aligned, but we should check anyway just to avoid unpleasant surprises in the future. This matches what we do on STM32L. On STM32F, we copy a byte at a time so alignment of the source data doesn't matter. BUG=chrome-os-partner:9526 BRANCH=none TEST=manual flasherase 0x20000 0x1000 flashwrite 0x20000 0x200 -> succeeds flashwrite 0x20201 0x200 -> fails Change-Id: Id1a0fd8f6871e1fcdc3f55ec25eea40f33b5214c Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/175532 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* lm4: ADC clock management bug fixAlec Berg2013-11-011-3/+27
| | | | | | | | | | | | | | | | | | | | | | | Fixed bug in which two different tasks reading two different ADC channels could interfere and cause the ADC clock to get disabled when a read is still in progress, thus causing a reboot. Added a runtime assert to verify that developers don't sample the same ADC channel from multiple different tasks, which could cause hard to trace reboots. BRANCH=none BUG=chromium:313872 TEST=1) Added console command to continuously read an ADC channel not read anywhere else. Verified that when running this console command I could reproduce the bug every few minutes. 2) Wrote code in adc.c to protect the ADC clock resource. 3) Ran console command from step 1 for ~2 hours with no reboots. Change-Id: Ic1905dde12871a4b93957702f7f31a25a2762bb4 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/175404 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* cleanup: Even more TODO commentsRandall Spangler2013-11-015-12/+24
| | | | | | | | | | | | | | | Update comments with more info, or remove if no longer applicable. No code changes. BUG=chrome-os-partner:18343 BRANCH=none TEST=build all platforms; pass unit tests Change-Id: I5b56eeb500bc0f00e84e91ef99684f4b1b310972 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/175418 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* cleanup: Update more TODO commentsRandall Spangler2013-11-014-23/+39
| | | | | | | | | | | | | | | Add bug links, reword, or remove as applicable. No code changes, just comments. BUG=chrome-os-partner:18343 BRANCH=none TEST=build all boards; pass unit tests Change-Id: Id55dd530c10091d7ab9d0f942f750168fca793b4 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/175326 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* cleanup: Improve / remove more TODO commentsRandall Spangler2013-11-013-13/+9
| | | | | | | | | | | | | Add bug references. Remove one assert that can no longer be triggered. BUG=chrome-os-partner:18343 BRANCH=none TEST=build all boards; pass unit tests Change-Id: I3f4d2e4f2f3343a8d0531cb0715d151eaa4d0b50 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/175293 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* cleanup: Assorted TODO commentsRandall Spangler2013-10-312-5/+15
| | | | | | | | | | | | | | | Remove comments if no longer applicable, or assign bug numbers if they still are. Tidy some debug output. No code changes other than the debug output. BUG=chrome-os-partner:18343 BRANCH=none TEST=build all platforms, pass unit tests Change-Id: I2277e73fbf8cc93f3b1b35ee115e0f2f52eb8cf9 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/175215 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Rename CONFIG_FAN to CONFIG_FANSBill Richardson2013-10-301-1/+1
| | | | | | | | | | | | | | | | | | Instead of just configuring fan support as yes/no, we'll use it to specify the number of fans on the board. Undefined (not zero!) means no fan support at all. Syntax change only. No new functionality. BUG=chrome-os-partner:23530 BRANCH=none TEST=manual make runtests, build all platforms, build and test on Link. Change-Id: Iff65efa69e05f3e1a54fdc2a8da9001b4e8487ca Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/175150
* Separate common fan behavior from implementationBill Richardson2013-10-305-472/+117
| | | | | | | | | | | | | | | | | | This looks like a lot, but it's really just moving the non-board-specific stuff from chip/lm4/fan.c into common/fan.c, updating the appropriate headers, and renaming functions to better match the new location. This is entirely code refactoring and renaming. No new functionality. BUG=chrome-os-partner:23530 BRANCH=none TEST=manual make runtests, build all platforms, build and test on Link. Change-Id: I7dc03d6732bad83cf838a86600b42a7cff5aa7aa Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/175012
* lm4: fix enabling RTC alarmRandall Spangler2013-10-302-1/+16
| | | | | | | | | | | | | | | | | | | | | | All hibernate register writes must wait for the WC bit. When we're enabling the RTC alarm, it's important to wait for the WC bit afterwards, too, or else we could go into deep sleep before the write to HIBIM is committed. Also make sure that the normal hibernate() path enables the RTC alarm if it has a timeout. This bug wasn't noticed until the low-power idle code called system_reset_rtc_alarm(), since before then HIBIM was initialized to 1 and just stayed there. BUG=chrome-os-partner:23678 BRANCH=anywhere we use low power idle (wolf/leon, too) TEST=with hacked firmware, note that HIBIM=1 just before the wfi instruction in chip/lm4/clock.c Change-Id: Ie01b106ac6a6c5894811f9a333715b22ef896f82 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/175013 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* lm4: Properly identify TM4 chip used on haswell/baytrail systemsRandall Spangler2013-10-301-6/+9
| | | | | | | | | | | | | | | This chip returns ver/family/partno = 0x10de, as indicated by the datasheet. Also switch the identification code to use a switch statement rather than re-reading the DID1 register in if-then-else. BUG=chrome-os-partner:23679 BRANCH=none (maybe haswell branches, but it's largely cosmetic) TEST=version command on rambi identifies the chip as ti tm4e1g31h6zrb B1 Change-Id: I4a3748413de65d3116feb7c444f5a2af5953eecd Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/175008 Reviewed-by: Vic Yang <victoryang@chromium.org>
* Start separating LM4 pwm logic from fan logic.Bill Richardson2013-10-305-201/+271
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On the LM4, all pwm functions are implemented through hardware "fan" modules. This change abstracts the hardware fan stuff from the higher level pwm and fan control logic. Those are still chip-specific at the moment, but may be moved into common with a future CL. BUG=chrome-os-partner:23530 BRANCH=none TEST=manual Code refactoring only, no new behavior. All tests build and pass, and I tested on Link with some manual pwm and fan commands on the EC console. > fanduty 30 > faninfo Should report ~4500 RPM > fanset 7000 > faninfo Should report ~48% duty cycle. > fanauto Back to automatic control. > kblight 0 > kblight 10 > kblight 50 > kblight 100 Keyboard backlight should glow appropriately. Change-Id: I7558f36b2626e555fc8dabdd12660fa484a93b7f Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/174991 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Remove QEMU testsstabilize-4886.BVic Yang2013-10-294-349/+0
| | | | | | | | | | | | | | | | | | | | | | QEMU tests served us well, but it has been more and more difficult to maintain as we now have more chips and use more functionality from each EC chip. With emulator tests in place to test common code and hardware test to test per-chip/per-board drivers, it's time to remove QEMU tests to simplify our code base. QEMU tests that are covered by other emulator tests are removed completely; tests that are not covered are left alone for now to preserve the test logic. BUG=chrome-os-partner:18343 TEST=util/make_all.sh BRANCH=None Change-Id: I5a4dd2f5ac42f7f66f86fdce0b62dbd2c65bf66a Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/174669 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
View Lorry Controller Status