summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Clear OWNERS for factory/firmware branchfirmware-link-2695.BBrian Norris2021-09-101-0/+1
| | | | | | | | | | | | BUG=none TEST=none Change-Id: I0f03f432ada1064ffba9595be78ca7ab4d25ecd1 Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/3155200 Reviewed-by: Jack Rosenthal <jrosenth@chromium.org> Owners-Override: Jora Jacobi <jora@google.com> Tested-by: Jack Rosenthal <jrosenth@chromium.org>
* i2cwedge: Don't wiggle SDA on every bitKevin Cernekee2015-08-261-8/+0
| | | | | | | | | | | | | | Re-asserting SDA on every bit results in a very strange-looking waveform, and it may confuse some devices. BUG=chromium:458878 BRANCH=link TEST=manual Change-Id: I443251eac0fabfd893135212723691f148abd9ed Signed-off-by: Kevin Cernekee <cernekee@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/295210 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Backport i2cwedge commandKevin Cernekee2015-08-265-1/+360
| | | | | | | | | | | | | This permits testing of the backported unwedge logic. BUG=chromium:458878 BRANCH=link TEST=manual Change-Id: Ib68ee53254e2e8003a3b38d81501338fe337c9c3 Signed-off-by: Kevin Cernekee <cernekee@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/295099 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* i2c: Fix SCL unwedge logicKevin Cernekee2015-08-261-9/+10
| | | | | | | | | | | | | | | | The current logic breaks out of the for() loop if SCL gets unwedged (goes high), but still falls through to the "I2C unwedge failed, SCL is being held low" case. Fix this so that we only hit the "SCL is being held low" case if SCL actually is stuck low. BUG=none BRANCH=link TEST=manual Change-Id: Ibe3f956db90bff88c8c1e380c5413f5a340cf268 Signed-off-by: Kevin Cernekee <cernekee@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/295098 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* lm4: Backport i2c_unwedge() logicKevin Cernekee2015-08-262-2/+139
| | | | | | | | | | | | | | This causes the driver to wiggle the scl/sda lines after a transaction error, if the lines are not both high. BUG=chromium:458878 BRANCH=link TEST=manual Change-Id: I3dc2115ce80d24c835cfbf6fdbf56b7f1f9460fb Signed-off-by: Kevin Cernekee <cernekee@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/295097 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* lm4: Backport i2c utility functionsKevin Cernekee2015-08-262-0/+237
| | | | | | | | | | | | | | | | Add support for raw mode and for toggling scl/sda manually. This is not an exact match for the code in ToT because a lot of infrastructure is missing in the old link branch, particularly gpio_config_pins and common/{i2c,gpio}.c. BUG=chromium:458878 BRANCH=link TEST=compile-tested only Change-Id: I3ffea8aeec0c87d849bd9c3ac687542d6f2013dd Signed-off-by: Kevin Cernekee <cernekee@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/295096 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* lm4: Make gpio_set_flags() honor GPIO_OPEN_DRAINKevin Cernekee2015-08-261-1/+1
| | | | | | | | | | | | | | | | | | | | Currently gpio_set_flags() only enables ODR mode if the GPIO_OPEN_DRAIN flag is set in the gpio_list entry. Since we need to be able to enable and disable ODR mode dynamically from the unwedge code, check both flags (from the caller) and g->flags (from the gpio config table). Note that ToT only checks the flags passed in from the caller, but if we used that scheme it might require changing additional call sites (e.g. SPI GPIO configuration). BUG=chromium:458878 BRANCH=link TEST=manual Change-Id: I4e60db30ec5333f80e5a807709d01cfdb2fbdbbb Signed-off-by: Kevin Cernekee <cernekee@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/295095 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* link: Add definitions for I2C GPIO pinsKevin Cernekee2015-08-263-6/+20
| | | | | | | | | | | | | | | | | We're going to backport a couple of functions that use these. This patch will cause the I2C0 GPIOs to lose their power-on pinmux defaults, but that's OK because chip/lm4/i2c.c explicitly sets them up anyway. BUG=chromium:458878 BRANCH=link TEST=manual Change-Id: I78686f51aac29070911b70f301b0203c1af21009 Signed-off-by: Kevin Cernekee <cernekee@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/295094 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* keyboard: Preserve keystroke enable state.Shawn Nematbakhsh2014-04-301-3/+14
| | | | | | | | | | | | | | | | | | | | | | | Preserve the state of keystroke_enabled to prevent keystrokes from being initially disabled on RO --> RW transition. This will allow us to use the keyboard on EC cold boot. BUG=chrome-os-partner:20430. TEST=Manual. Verify keyboard works on EC cold boot on Peppy. BRANCH=None. Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/59798 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> (cherry picked from commit 6957684d304825cc6fd926c8ee7a2ccb1edb6839) Change-Id: Ide0a798c20948e8db24e1bb74b58b4d4337d2147 Original-Change-Id: Ia26ff7fc6e314f50b92d85a97f1b2cfdc7163b6e Reviewed-on: https://chromium-review.googlesource.com/197527 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Commit-Queue: Bill Richardson <wfrichar@chromium.org> Tested-by: Bill Richardson <wfrichar@chromium.org>
* Fixed two i8042 bugs. (manually cherry-pick)Louis Yung-Chieh Lo2013-12-102-13/+30
| | | | | | | | | | | | | | | | | | | | | | 1. The buffer for host i8042 command is too small so that a command is dropped (buffer full) in some cases. Enlarging it can solve bug. 2. The keystrokes are queued in buffer so that kernel driver cannot get stable CTR value. We workaround this by disabling the keystroke and clearing buffer when keyboard is disabled. BUG=chrome-os-partner:20758 BRANCH=falco,link TEST=Verified on link. Repeatedly press Ctrl + U during booting. The keyboard is working after boot. Original-Change-Id: I7d8daef8d815b8e4d08df6f6a26ab2a471e5b150 Reviewed-on: https://gerrit.chromium.org/gerrit/62986 (cherry picked from commit a1699727a83758defb2e80deab59d34a18bfe581) Change-Id: Ie8aea3be491efb28b3a3ba0d0db30bea6095d662 Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/179405 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Only waste 1 byte in queue bufferVic Yang2013-12-101-2/+2
| | | | | | | | | | | | | | | | | | | | | | For simplicity of the code, we don't allow (head == tail) when the queue is full. But currently we are wasting the size of a single unit, while we can actually just waste 1 byte. Let's fix this. BUG=None TEST=Pass the unit test. BRANCH=None Original-Change-Id: Id09c20a9345ebb3ec0cad659afe36e25b422e688 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/58058 Reviewed-by: Yung-Chieh Lo <yjlou@chromium.org> (cherry picked from commit a9541220dc92ba70d9828c6000c89dc8287bc7a1) Change-Id: I718daeb1b91c8df219006557ec77e64801a35e3a Reviewed-on: https://chromium-review.googlesource.com/179404 Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Yung-chieh Lo <yjlou@chromium.org> Tested-by: Yung-chieh Lo <yjlou@chromium.org>
* Bug fix of queue empty slot calculationVic Yang2013-12-101-2/+6
| | | | | | | | | | | | | | | | | | | | | Current implementation of queue_has_space doesn't handle the case where queue tail has wrapped around the end. This CL fixes the bug. BUG=None TEST=Pass the test in the following CL. BRANCH=link Original-Change-Id: I774f388081af50f0e930a6cbc3a723da1c8283b0 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/58031 Reviewed-by: Yung-Chieh Lo <yjlou@chromium.org> (cherry picked from commit 8bed9853d7722676e49f28e36c170166dc36c8c5) Change-Id: I81120df34bf8e1d3edb4cc7f73c1648ea3c423a4 Reviewed-on: https://chromium-review.googlesource.com/179403 Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Yung-chieh Lo <yjlou@chromium.org> Tested-by: Yung-chieh Lo <yjlou@chromium.org>
* Allow either libftdi or libftdi1 at compile time.Todd Broch2013-12-102-2/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Todd Broch <tbroch@chromium.org> BRANCH=none BUG=chromium:222299 TEST=manual, from chroot: 1. Install libftdi1 (https://gerrit.chromium.org/gerrit/#/c/44731/) 2. cd <path>/ec && make -B - compiles successfully 3. Install libftdi 4. cd <path>/ec && make -B - still compiles successfully Original-Change-Id: I6818d53faa1389937872b0a9826534db4760e448 Reviewed-on: https://gerrit.chromium.org/gerrit/47875 Tested-by: Todd Broch <tbroch@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Commit-Queue: Todd Broch <tbroch@chromium.org> (cherry picked from commit 357e508392ca37b60ea17a9ac5725f84586aac9e) Change-Id: I569368aab25fe75ae401b26b6a6b39fdfc1c5e65 Reviewed-on: https://chromium-review.googlesource.com/179402 Reviewed-by: Todd Broch <tbroch@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Yung-chieh Lo <yjlou@chromium.org> Tested-by: Yung-chieh Lo <yjlou@chromium.org>
* More supports for A20 enable/disableLouis Yung-Chieh Lo2013-12-104-3/+49
| | | | | | | | | | | | | | | | | | | | | | | | | Add i8042 output port commands (0xf0-0xff), I8042_ENABLE_A20 and I8042_DISABLE_A20. BUG=chrome-os-partner:13119, BRANCH=None TEST=Tested on W7 installer. No KB error shown on EC console. Original-Change-Id: I9ad1fd7baa10683ef18ccf13faf09dc0cefcca0a Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/34994 Reviewed-by: Stefan Reinauer <reinauer@chromium.org> (cherry picked from commit 25bbb6b5dec3e0eb9672e6d3e0acf032f9e8d8d1) Conflicts: chip/lm4/lpc.c include/lpc.h Change-Id: Ic861782fa841f6f9b2322e5c1526fea8ee96a89d Reviewed-on: https://chromium-review.googlesource.com/179401 Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Yung-chieh Lo <yjlou@chromium.org> Tested-by: Yung-chieh Lo <yjlou@chromium.org>
* Change the I8042_CMD_ENABLE (0xf4) for keystroke (not for KBC).Louis Yung-Chieh Lo2013-12-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Old code treat following commands as the same: 1. I8042_CMD_ENABLE in include/i8042_protocol.h 2. I8042_ENA_KB (0xae) in include/i8042_protocol.h 3. bit 4 of command byte, see I8042_KBD_DIS in include/i8042_protocol.h New code changes 1 in keystroke_enabled variable. Signed-off-by: Yung-Chieh Lo <yjlou@chromium.org> BUG=chrome-os-partner:17005,chrome-os-partner:17810 BRANCH=link TEST=Tested vincent's script with following scenario: 1. not-workarounded kernel: PASS more than 2767, 2946, and 7300 loops. 2. workarounded kernel: PASS more than 5000 loops. Original-Change-Id: I879a1b1f0186594e4b9dd7fc4320232ebab4a1e1 Reviewed-on: https://gerrit.chromium.org/gerrit/43006 Commit-Queue: Yung-Chieh Lo <yjlou@chromium.org> Reviewed-by: Yung-Chieh Lo <yjlou@chromium.org> Tested-by: Yung-Chieh Lo <yjlou@chromium.org> (cherry picked from commit c1b16d21e6315d6de9f697ff5a41eca288f4f754) Change-Id: I38ddcf00147041c0f87bcd37b9b672b1a6d0cc9a Reviewed-on: https://chromium-review.googlesource.com/179400 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Yung-chieh Lo <yjlou@chromium.org> Commit-Queue: Yung-chieh Lo <yjlou@chromium.org> Tested-by: Yung-chieh Lo <yjlou@chromium.org>
* Clean up i8042 moduleRandall Spangler2013-12-106-231/+162
| | | | | | | | | | | | | | | | | | | | | | | | | Remove unused code paths. Simplify interfaces. Clarify comments. Split the protocol constants into their own header file (since they're used only by keyboard.c, not i8042.c, which is really keyboard buffering... and will be renamed so in a followup CL.) This cleanup reduces binary size by about 200 bytes. BUG=chrome-os-partner:15579 BRANCH=none TEST=type on the keyboard; it should still work. Original-Change-Id: I6acbab5fe5604b4b0c516ba3622e6f41820985d1 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/36271 (cherry picked from commit 090e4f5f8e7c8de473b26a8c0c437085d7c3db79) Change-Id: Ifc477ceab2a0828c20a1dd4ba5d76157c22b77bc Reviewed-on: https://chromium-review.googlesource.com/179359 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Yung-chieh Lo <yjlou@chromium.org> Commit-Queue: Yung-chieh Lo <yjlou@chromium.org> Tested-by: Yung-chieh Lo <yjlou@chromium.org>
* Give the AP 30 sec warning before shutting down due to low batteryRandall Spangler2013-03-052-20/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows the AP to shut down cleanly. If it doesn't shut down in that time period, the EC will forcibly shut it down. BUG=chrome-os-partner:17124 BRANCH=link TEST=manual 1. With system off, - battfake 2 -> EC hibernates immediately 2. With system on, - battfake 2 -> battery shutdown event posted to AP - power off system manually within 30 sec -> EC hibernates 3. With system on, - battfake 2 -> battery shutdown event posted to AP - do not power off AP - after 30 sec, EC shuts down AP then hibernates 4. With system on, - battfake 2 -> battery shutdown event posted to AP - after 15 sec, apply AC power - system does NOT shut down - remove AC power -> battery shutdown event posted to AP (because battfake 2 is still faking 2% battery left) - after 30 sec, EC shuts down AP then hibernates (check to make sure the full 30 sec elapses; the timer should have been restarted when AC power was removed; if the EC shuts down the AP immediately this is a failure indicating the timer is still running from the first shutdown event) Original-Change-Id: I1a13765f501d705d3a580b2acbbb173d47e020ff Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/44413 (cherry picked from commit e60f1ab2246e2eac9b667690c39873baa974ab5b) Conflicts: common/charge_state.c Change-Id: I2033a50d302e63dbaa368e8f980f9a1b41bedee4 Reviewed-on: https://gerrit.chromium.org/gerrit/44693 Commit-Queue: Randall Spangler <rspangler@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Randall Spangler <rspangler@chromium.org>
* After shutting down AP, hibernate EC if battery is lowRandall Spangler2013-03-053-18/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This preserves more battery for the real-time clock. It also gets rid of one battery level/state, since the EC will now shut down at the same level (2%) as the AP. Having the EC hibernate at the same level as the AP shuts down also prevents the following weird scenario: - EC powers on at 2% battery. - EC won't power on the AP to do software sync because battery is low. - But the charge state machine won't actually hibernate the EC until 1%. - Between 2% and 1%, AC is inserted and system starts charging. - But EC-RO is what's doing the charging; we should go through software sync before charging. BUG=chrome-os-partner:17124 BRANCH=link TEST=manual On battery power, 1) With system on, battfake 2 -> system shuts down and EC hibernates 2) With system off, battfake 2 -> EC hibernates Original-Change-Id: I87d17f70d60673f3e3f1c6eb88f3f00a8c9ed4e7 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/44314 (cherry picked from commit 6971fd7a7f8a2351f011bdd60eabda664e0c3ba2) Conflicts: common/charge_state.c Change-Id: I6e819c31c9bcbd4e7adb870390ee5a80c0894f4c Reviewed-on: https://gerrit.chromium.org/gerrit/44692 Commit-Queue: Randall Spangler <rspangler@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Randall Spangler <rspangler@chromium.org>
* Wait to power on system until battery state is knownRandall Spangler2013-03-052-15/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This prevents the system from waking from hibernate at very low battery, then powering on the AP to do software sync only to find that the charge state machine shuts down the AP before software sync can complete. BUG=chrome-os-partner:17124 BRANCH=link TEST=manual On both AC and mostly-charged battery: - With lid open, reboot EC -> on - With lid open, reboot EC with power held down -> on - With lid closed, reboot EC -> system boots and does EC software sync - With system on -> battfake 2 shuts system down (and at that point, opening lid or pressing power does nothing) With a hacked charge_state.c so fake_state_of_charge starts at 2: - With lid open or closed, reboot EC -> off - Opening lid does not turn on system - Pressing power button does not turn on system - Plug power back in and press power -> system turns on Original-Change-Id: Ie1f2933060fac87b1afe68718f374d51cb8994de Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/44313 (cherry picked from commit 70cdf52ea1aec0681372a21bc41308a1e4ad20e4) Conflicts: common/charge_state.c Change-Id: I9351bf9de763fe34267c6f8009fb17df313d1ac0 Reviewed-on: https://gerrit.chromium.org/gerrit/44690 Commit-Queue: Randall Spangler <rspangler@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Randall Spangler <rspangler@chromium.org>
* Add reinit state to charge_state module to distinguish it from at-ec-boot initRandall Spangler2013-03-053-31/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a precursor to changing the switch state machine to delay powering on the AP until the charge_state module knows if there's enough power to do so (which it will know when it leaves the INIT state). BUG=chrome-os-partner:17124 BRANCH=link TEST=manual 1. Reboot EC on battery power. See charge state init->discharging 2. Plug in AC. See charge state discharging->reinit (charge state will then transition to some other charging or idle state based on battery level) Original-Change-Id: Ia02cc8b37e9b5e8d6dd8c2fbfdf14e385694b1bf Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/44291 Reviewed-by: Bill Richardson <wfrichar@chromium.org> (cherry picked from commit d86df6c38883435c9df5de3bd7ba1c2b35b67316) Conflicts: common/charge_state.c Change-Id: Iffb74a1c4784cd85f1a5d3a80ccfab646939cf61 Reviewed-on: https://gerrit.chromium.org/gerrit/44689 Commit-Queue: Randall Spangler <rspangler@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Randall Spangler <rspangler@chromium.org>
* Add console command to fake battery state of chargeRandall Spangler2013-03-052-21/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The new 'battfake' command is really handy for testing low-battery shutdown logic. BUG=chrome-os-partner:17124 BRANCH=link TEST=from EC console: reboot battfake -> using real battery level power on system -> lightbar should be blue battfake 5 lightbar turns red after a few seconds UI shows battery is very low (shows <5% due to different kernel math) 'ectool battery' from root shell shows present capacity ~5% of design capacity remove AC power battfake 4 UI shows low-battery screen and shuts down (may take a minute) battfake 50 power on system UI shows battery at 45-55% battfake 2 -> system shuts down immediately battfake -1 power on system UI shows actual battery level Original-Change-Id: I3180e321241c0f586f3baad2150fb6a2b2d2e242 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/43151 Reviewed-by: Bill Richardson <wfrichar@chromium.org> (cherry picked from commit 695289cfe6724ad349a96d1f36ddf036b3df5daa) Conflicts: common/charge_state.c Change-Id: I95b020d1a747bafed0351d982eac1d314ea22301 Reviewed-on: https://gerrit.chromium.org/gerrit/44688 Commit-Queue: Randall Spangler <rspangler@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Randall Spangler <rspangler@chromium.org>
* Rename and document battery constantsRandall Spangler2013-03-053-33/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In preparation for cleaning up low-battery logic. Make clear what comparison operator is used for each constant (<=, <, >=, >). Also remove hard-coded and unused display of design warning/low battery levels from ectool. Verified via code search that these are not used anywhere. Even if we later care about these levels, they should be battery-specific and not hard-coded as a platform-independent percentage of full capacity when ectool is compiled. BUG=chrome-os-partner:17124 BRANCH=link TEST=compile link; 'ectool battery' from root shell prints valid info Original-Change-Id: I3650e27a08f4cc77067beb0685ee1488cc56d02f Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/43119 Reviewed-by: Bill Richardson <wfrichar@chromium.org> (cherry picked from commit 9fde14da9b2e8d8944e66c5b8f4798e0c40be72e) Change-Id: Id74d55fed9bb306e9cf5a0aed86caf81ec2fe7d0 Reviewed-on: https://gerrit.chromium.org/gerrit/44686 Commit-Queue: Randall Spangler <rspangler@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Randall Spangler <rspangler@chromium.org>
* Change the I8042_CMD_ENABLE (0xf4) for keystroke (not for KBC).Louis Yung-Chieh Lo2013-02-261-4/+15
| | | | | | | | | | | | | | | | | | | | | | | Old code treat following commands as the same: 1. I8042_CMD_ENABLE in include/i8042_protocol.h 2. I8042_ENA_KB (0xae) in include/i8042_protocol.h 3. bit 4 of command byte, see I8042_KBD_DIS in include/i8042_protocol.h New code changes 1 in keystroke_enabled variable. Signed-off-by: Yung-Chieh Lo <yjlou@chromium.org> BUG=chrome-os-partner:17005,chrome-os-partner:17810 BRANCH=link TEST=Build okay only: BOARD=link make; test was done in original CL. Original-Change-Id: I879a1b1f0186594e4b9dd7fc4320232ebab4a1e1 (cherry picked from commit 69dadbd4336ba7de115283ed480c1051e9dbfd0c) Change-Id: Ide63a2c9e54ce071a7b8cd50e250cb44545395ef Reviewed-on: https://gerrit.chromium.org/gerrit/44013 Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Yung-Chieh Lo <yjlou@chromium.org> Tested-by: Yung-Chieh Lo <yjlou@chromium.org>
* link: If a required power rail drops, shut downRandall Spangler2013-02-251-8/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This protects the system from ending up in a weird state if one of the rails fails to come up, or shuts down after coming up. BUG=chrome-os-partner:17774 BRANCH=link TEST=manual - Boot system - From EC console: gpioset enable_1_5v_ddr 0 - System shuts down; EC console prints "x86 power lost input" - Press power button; system turns back on - From EC console: gpioset enable_vs 0 - System shuts down; EC console prints "x86 power lost input" - Press power button; system turns back on - Suspend system - From EC console: gpioset enable_1_5v_ddr 0 - System shuts down; EC console prints "x86 power lost input" - Press power button; system turns back on Original-Change-Id: I8ae1630deb4001716b8dfd89d7dec7300cddb5ae Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/43097 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> (cherry picked from commit c19a4db9e4935400b24bd5bb43452019ff1843b8) Change-Id: I2eb3131e1ac0e1be437d99f0d1c51c07d1bc5b5f Reviewed-on: https://gerrit.chromium.org/gerrit/43110 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Commit-Queue: Randall Spangler <rspangler@chromium.org> Tested-by: Randall Spangler <rspangler@chromium.org>
* link: Workaround for errata 3.2Randall Spangler2012-12-171-2/+3
| | | | | | | | | | | | | | | | | | | | | Reads of HIBRTCC and HIBRTCCSS are not properly synchronized and may return incorrect data. We were re-checking HIBRTC, but not HIBRTCSS. BUG=chrome-os-partner:16864 BRANCH=link TEST=from ec console, do 'rtc' command repeatedly; printed values should be strictly increasing. Original-Change-Id: I3e59dc840316ad36bb4851f03b66a3ae3df5cccd Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/39795 Reviewed-by: Bill Richardson <wfrichar@chromium.org> (cherry picked from commit eb6e08570a46fe641308ff696225acfa1643a5a8) Change-Id: If7362ce368f21bd6d21a037af12589837bcc62f3 Reviewed-on: https://gerrit.chromium.org/gerrit/39807 Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Randall Spangler <rspangler@chromium.org>
* lm4: Postfix chip name when debug mode is enabledVic Yang2012-12-101-3/+23
| | | | | | | | | | | | | | | | | | | | | This adds a '-debug' postfix to chip name when debug mode is enabled, allowing us to probe debug mode from host. BUG=chrome-os-partner:16700 TEST='mosys -k ec info' and see chip name postfixed with '-tm' Test same thing on DVT and chip name is not postfixed. BRANCH=link Original-Change-Id: Iade26f2009dd3bdb8ddbe92da0da8da5404c6e99 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/39455 Reviewed-by: Randall Spangler <rspangler@chromium.org> (cherry picked from commit 73a0bb2ecfe4a8b2dbb5a2885ddcd06fa8e1424a) Change-Id: I02feb3ce17754d3b0d2e61a46d7ec34781d94fe6 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/39539 Reviewed-by: Jon Salz <jsalz@chromium.org>
* Add more paranoia for flash write protectRandall Spangler2012-12-102-0/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the entire flash is protected (as it normally is after software sync), fail all flash write/erase operations. Add a shadow copy of the all_now flag. BUG=chrome-os-partner:16727 BRANCH=link TEST=manual Verify that flash operations work properly before all_now. Then enable HW WP and flashwp enable flashwp now and try flasherase 0x38000 0x1000 flashwrite 0x38000 0x100 Those commands should fail with error 7 From the host side ectool flasherase 0x38000 0x1000 echo 'Khaaaaaaaaaaan' > /tmp/b16727 ectool flashwrite 0x38000 /tmp/b16727 should also fail. Original-Change-Id: I99a4d2bb86080bd12c900582a8fbdfc79c99916c Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/39517 Reviewed-by: Bill Richardson <wfrichar@chromium.org> (cherry picked from commit ab727c4941ddd0112be0e0de61c2900ae60913e7) Conflicts: common/flash_common.c Change-Id: I48997c7e9348b5d88ce6f12b482f0c371743a6d8 Reviewed-on: https://gerrit.chromium.org/gerrit/39520 Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Randall Spangler <rspangler@chromium.org>
* link: Increase cold reset hibernate time to 1 secondRandall Spangler2012-12-101-1/+1
| | | | | | | | | | | | | | | | | | | | | This gives VDDC more time to bleed out before the system reboots. This will require FAFT changes to compensate for the longer cold reset time. BUG=chrome-os-partner:16600 BRANCH=link TEST=from ec console, 'reboot cold' should take a second. Original-Change-Id: I7e0e901958593262868151642560296f0c5496a7 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/39515 Reviewed-by: Bill Richardson <wfrichar@chromium.org> (cherry picked from commit 7a2e3372eef4d8eee8ee140f517a309dc7065887) Change-Id: I8953123e3460eb8491e6c6e8f0b94e014c10ccb4 Reviewed-on: https://gerrit.chromium.org/gerrit/39519 Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Randall Spangler <rspangler@chromium.org>
* Invalidate hash if flash operation changes the hashed regionRandall Spangler2012-12-103-8/+74
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This prevents the EC from returning a stale hash. BUG=chrome-os-partner:16668 BRANCH=link,snow TEST=manual, with WP disabled From EC console - Boot system and wait a second - hash --> prints valid hash - flasherase 0x20000 0x1000 - hash --> invalid - hash rw - hash --> prints valid hash - flashwrite 0x20000 0x1000 - hash --> invalid - hash rw - flasherase 0x38000 0x1000 - flashwrite 0x38000 0x1000 - hash --> still valid (since 0x38000 is outside the rw section) From root shell - ectool hash --> prints valid hash - ectool flasherase 0x20000 0x1000 - ectool hash --> invalid - ectool hash recalc RW - ectool hash --> prints valid hash - echo 'Making a hash of this' > /tmp/hashofthis - ectool flashwrite 0x20000 /tmp/hashofthis - ectool hash --> invalid - ectool hash recalc RW - ectool flasherase 0x38000 0x1000 - ectool flashwrite 0x38000 /tmp/hashofthis - ectool hash --> still valid (since 0x38000 is outside the rw section) Original-Change-Id: Id915a504a7bc70b8b8c339b5ce55dc5bad5838fe Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/39484 Reviewed-by: Bill Richardson <wfrichar@chromium.org> (cherry picked from commit ad2adc4022c24ea8f883ab2ae61b0a6989743d56) Change-Id: Ia697cec76c4980ff2c25b76e814d14d294c60669 Reviewed-on: https://gerrit.chromium.org/gerrit/39518 Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Randall Spangler <rspangler@chromium.org>
* Increase cold reset hibernate time to 200msRandall Spangler2012-12-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The hardware fix for issue 16600 adds RC delays to ENABLE_5VALW, so that +5VALW stays on during a warm reset of the EC. In the worst case, +5VALW will drop around 150ms, which could then move the +3VALW glitch right into the time frame where the EC is booting following hibernate. Increase the cold reset hibernate time from 150ms to 200ms. This ensures that +5VALW has dropped before the EC comes out of hibernate. BUG=chrome-os-partner:16600 BRANCH=link TEST=manual From the EC console, 'reboot cold' a bunch of times. The system shouldn't hang. (Alternately, you can 'ectool reboot_ec cold' a bunch of times) Original-Change-Id: I4bebdb552b8e917c6345badd6efb68b10d7d1f86 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/39340 Reviewed-by: Bill Richardson <wfrichar@chromium.org> (cherry picked from commit c26a242e947a110ea3cf0c43d8274eebb9aaeb5a) Change-Id: Ifc0edac446e4d3498f3ed400e035e8fe3e01c227 Reviewed-on: https://gerrit.chromium.org/gerrit/39355 Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Randall Spangler <rspangler@chromium.org>
* link: Enable +5VALW at boot and leave it enabledRandall Spangler2012-12-062-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This works around a problem where disabling +5VALW glitches +3VALW_EC, which may cause the EC to brown out or hang. BUG=chrome-os-partner:16600 BRANCH=link TEST=manual 1. When the system boots, look for this line as the first x86 power state: [0.004977 x86 power state 0 = G3, in 0x0001] 2. Boot the system. Should boot normally. 3. Shut down the system using the power button. 4. After ~10 seconds, you should see that line of output again. 5. At the EC console: 'gpioget enable_5valw' should output: 1* ENABLE_5VALW This should ideally be combined with a hardware fix to add 30+ ms of delay to EC_EN_5V, since when the EC is reset via power+refresh that tri-states EC_EN_5V, and it takes ~22ms for the EC to boot and start driving EC_EN_5V again. Original-Change-Id: Iba4d961d064105faf988a35c2277e9d7406e39e2 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/39334 Reviewed-by: Yung-Chieh Lo <yjlou@chromium.org> (cherry picked from commit 3d0d2adb63b9ca148216d866c772ea0b6e5e2598) Change-Id: I4a35c8534f096c767903e5ccb9085ffe7d78eadf Reviewed-on: https://gerrit.chromium.org/gerrit/39353 Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Randall Spangler <rspangler@chromium.org>
* link: Disable interrupts while reading/writing bits via onewireRandall Spangler2012-11-291-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When reading, the line must be sampled in a narrow timing window after the output pulse. Interrupts or context switches during this time corrupt the data. Similarly, when writing, the difference between a 0-bit and a 1-bit is the length of the output pulse. So a context switch or interrupt there can turn a 1-bit into a 0-bit. BUG=chrome-os-partner:15507 BRANCH=link TEST=manual 0. plug in AC power 1. hold down shift key for the duration of this test 2. powerled yellow 3. powerled red 4. repeat steps 2-3 several times 5. release shift key Power adapter LED should toggle color each time. (It may also toggle to the normally expected color during this experiment, if the charging task updates it.) Power adapter LED should NOT turn off during this test. Original-Change-Id: Ief11e6e9a5b07aa3a25c60c50e4e7744a4705713 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/38925 Reviewed-by: Yung-Chieh Lo <yjlou@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org> (cherry picked from commit 52440ef89387809af91051671a98ea9c36ce27ca) Change-Id: I19e72b0d2fc02c6d2a13b0c7f6efc464c1e54c15 Reviewed-on: https://gerrit.chromium.org/gerrit/38934 Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Randall Spangler <rspangler@chromium.org>
* Fix potential deadlock in udelay()Randall Spangler2012-11-291-4/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | If interrupts are disabled and the deadline is across a 32-bit timer boundary from the current time, udelay() can lock up. The fix is to do 32-bit math directly in udelay(). BUG=chrome-os-partner:16472 BRANCH=link TEST=manual waitms 1 -> prompt returns almost instantly waitms 500 -> prompt returns after 0.5 sec waitms 1000 -> watchdog error printed, then prompt returns waitms 2000 -> watchdog reboot Original-Change-Id: Ib8ca06cee414d48900c0142e629daa68aa0993c9 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/38924 Reviewed-by: Yung-Chieh Lo <yjlou@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org> (cherry picked from commit 108754005d86c17b6247e83e2b7aed788d93a8c9) Change-Id: Id5ad899488a77bdd923a0169280b3e81bc6714ea Reviewed-on: https://gerrit.chromium.org/gerrit/38933 Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Randall Spangler <rspangler@chromium.org>
* Handle arbitration lost on I2C portsRandall Spangler2012-11-282-9/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This seems to happen when the I2C signals come up so that the EC sees a start condition from the remote end. In this case, the EC refuses to talk on the I2C port until the EC's I2C state machine is reset. Also, don't fail on bus-busy, since that's true during a multi-part transaction such as an I2C string read. BUG=chrome-os-partner:16262 BRANCH=link TEST=boot system; 'battery' and 'temps' should give good info Then run snanda's suspend_stress_test for a while and repeat. Or a better test is to open 2 crosh shells, sudo bash in each, and 1) while true; do ectool temps all; sleep 0.5; done 2) suspend_stress_test Then watch the EC console for "I2C5 bad status" errors. These happen rarely, only on some systems. With this fix, they'll be reported when they occur, but should not cause errors to be reported by 'ectool temps all', since the I2C module will clear the arbitration-lost status before retrying. Original-Change-Id: Idfaf9cd7e8ef2abcc0130332890329dd5d2ca052 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/38686 Reviewed-by: Yung-Chieh Lo <yjlou@chromium.org> (cherry picked from commit d619cdd58f473efe7b8c67e817080fc16751b4a5) Change-Id: I44d339e4d9f6ad1763895caca11a350818fe4e02 Reviewed-on: https://gerrit.chromium.org/gerrit/38825 Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Randall Spangler <rspangler@chromium.org>
* Handle bus errors on thermal I2C busRandall Spangler2012-11-262-5/+43
| | | | | | | | | | | | | | | | | | | | | | 1) Properly report I2C errors on TMP006 as error, not device-not-powered. 2) Treat clock timeout and bus-busy I2C status as error (previously ignored). 3) If clock timeout or bus-busy, reset I2C master for that bus to clear the error. These should help with systems where the thermal I2C bus gets into a weird state on suspend/resume. BUG=chrome-os-partner:16262 BRANCH=link TEST=boot system; 'battery' and 'temps' should give good info Then run snanda's suspend_stress_test for a while and repeat. Change-Id: Iec5d6bbd357d2e5eb3dc3d361c829f353e996ab6 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/38444
* link: allow to decrease maximum battery charging currentVincent Palatin2012-11-073-0/+58
| | | | | | | | | | | | | | | | | | | | Add an interface to allow the CPU to cap the maximum battery charging current. The maximum is removed every time the machine goes to S3 or S5. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=link BUG=chrome-os-partner:16041 TEST=on Link, plug AC to charge the battery, then run "ectool chargecurrentlimit 1200" and see the charging current in "power-supply-info" decreasing to 1.2 A. Change-Id: I3490ac8134d9dde8f41809faa440360886dd208c Reviewed-on: https://gerrit.chromium.org/gerrit/37530 Reviewed-by: Sameer Nanda <snanda@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Rong Chang <rongchang@chromium.org>
* x86: set hibernation delay to 1 hourVincent Palatin2012-11-071-1/+1
| | | | | | | | | | | | | | | | | | When the system is in S5, it will go to hibernate mode after 1 hour instead of 24 hours. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=link BUG=none TEST=on Link DVT3 with servo connected, turn off the machine and see the EC going to hibernate after 1 hour (according to EC UART traces) start the machine and see it boot properly. Change-Id: I2a9886fecf312ef0f08d2fe9863c3eebf26d6d37 Reviewed-on: https://gerrit.chromium.org/gerrit/37527 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org>
* link: Fix overflow in hibernate time calculationRandall Spangler2012-10-312-1/+8
| | | | | | | | | | | | | | | | | | | The time out value passed to task_wait_event() is signed 32-bit and thus waiting for 24 hours will cause overflow. Limit max wait time. BUG=chrome-os-partner:15797 BRANCH=link TEST=Disconnect AC, shut down system, and close lid. From ec console, do 'hibdelay 8000' and then wait 2.5 hours. EC should have hibernated. (8000 is more than twice the max time for task_wait_event()) Change-Id: I8f368262edfe6bf90046705b864fc52fb3503d02 Original-Change-Id: I5fa505554182e8bad6399c12a382ff71bb123d8f Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/37096 Reviewed-by: Vic Yang <victoryang@chromium.org>
* link: Cold reboot should ignore WAKE# pinRandall Spangler2012-10-311-3/+10
| | | | | | | | | | | | | | | | | | | | | | | This fixes the EC not being able to do a cold reset while the power button is held down, because the power button asserts WAKE#. BUG=chrome-os-partner:15705 BRANCH=link TEST=manual - scope HIB# - hold down power button - from console, 'reboot cold' HIB# should stay asserted for 150ms. Before this fix, it asserted only briefly. Change-Id: I07c6bb5ee3f846544c75e7e0d4584f8434a9cd56 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/37090 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Puneet Kumar <puneetster@chromium.org> (cherry picked from commit 9a1548984d1bcfb6a2035110349af9e2e0f4531a) Reviewed-on: https://gerrit.chromium.org/gerrit/37094
* link: remove VR settings on the flyVincent Palatin2012-10-251-1/+0
| | | | | | | | | | | | | | | | | | | | | | The code to re-program the IR3570A core regulator on the fly is no longer needed as the parts should be pre-programmed correctly and it is slow. This will break the EVT and older boards which have bad pre-programmed settings. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=link BUG=chrome-os-partner:15596 TEST=on Link, run the power_Resume test and observe the firmware resume time has decreased. Change-Id: Id4f56a68d874879bf2f50047c21fbfabea16c850 Reviewed-on: https://gerrit.chromium.org/gerrit/36417 Reviewed-by: Puneet Kumar <puneetster@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org>
* link: Don't force battery to request currentRandall Spangler2012-10-241-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, the battery charging algorithm would give the battery current even when it was requesting 0 mA. BUG=chrome-os-partner:15573 BRANCH=link TEST=charge battery and leave AC plugged in Battery will eventually drop to 99% charged. At that point, it should request 0mA, not 84mA or 85mA. (When it drops farther, it will really start requesting charge.) Original-Change-Id: I464a7c8e857c928dbb9f9595f9c947d565b5f5c6 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/36526 Reviewed-by: Rong Chang <rongchang@chromium.org> (cherry picked from commit 61ebbbbbd7edb4f68fdb62f33076299d6b2fa3f8) Conflicts: common/battery_link.c Change-Id: I3877ca0aaa36d4ce0407f25a0e19fc164f3c4d15 Reviewed-on: https://gerrit.chromium.org/gerrit/36527 Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Randall Spangler <rspangler@chromium.org>
* Revert "lm4: Add chip name for lm4fs1gh5bbfig"Jon Salz2012-10-231-2/+0
| | | | | | | | | | | | | | | | | | | This reverts commit db2c527d5cab61af399694cc853d1dfce1bbd3cd BUG=chrome-os-partner:15519 TEST=none BRANCH=link Change-Id: I033916921993bffc6a3c0d6bbb70a867b73b25a9 Reviewed-on: https://gerrit.chromium.org/gerrit/36414 Commit-Ready: Jon Salz <jsalz@chromium.org> Reviewed-by: Jon Salz <jsalz@chromium.org> Tested-by: Jon Salz <jsalz@chromium.org> (cherry picked from commit 06a7508187ec38e25fe85e93fb1a38d112a764be) Signed-off-by: Jon Salz <jsalz@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/36418 Reviewed-by: Vic Yang <victoryang@chromium.org> Tested-by: Vic Yang <victoryang@chromium.org>
* lm4: Add chip name for lm4fs1gh5bbfigVic Yang2012-10-221-0/+2
| | | | | | | | | | | | | | | BUG=chrome-os-partner:15519 TEST=none BRANCH=link Original-Change-Id: I00c27eab4320a95b17c4f18572835fea1fb8cdf7 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/36307 (cherry picked from commit db2c527d5cab61af399694cc853d1dfce1bbd3cd) Change-Id: I8d6a3addf61acd6885a630cd0f8e11a85f550358 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/36308
* lm4: Report raw DID value when chip name cannot be determinedVic Yang2012-10-221-1/+26
| | | | | | | | | | | | | | | | | | | | | | We map the raw DID value to chip name in EC. If the raw value is not in the mapping table, EC just returns empty string and we lose this information from host side. Let's return raw DID value like "Unknown-10ea". BUG=chrome-os-partner:15519 TEST=remove 0x10ea from the mapping and check 'mosys -k ec info' shows 'Unknown-10ea'. BRANCH=link Original-Change-Id: I9399f44ab40db02202ee03ba3f988f3ece010d9f Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/36305 Reviewed-by: David Hendricks <dhendrix@chromium.org> (cherry picked from commit 965ec04fffdee6c85035d288ed427acbed142629) Change-Id: I31bce2ee1e56cea0aa3740d7b5831a004a897b50 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/36306
* link: Fix checking runtime keysRandall Spangler2012-10-181-2/+3
| | | | | | | | | | | | | | | | | | | | | | | This accidentally got disabled when printing keyboard scan state was turned off by default. BUG=chrome-os-partner:15466 BRANCH=link TEST=alt+volup+R should reboot system Then from console, ksstate on Then press keys; KB state should print on console Original-Change-Id: I7d410b56210fda0c73c65d9d76ccc7b4e873516c Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/35971 Reviewed-by: Simon Glass <sjg@chromium.org> (cherry picked from commit d598b64277a3d876e70d65e50073fa8216a9179a) Change-Id: I94bb18aa2041e05ad70ac3cf63b539d034df488c Reviewed-on: https://gerrit.chromium.org/gerrit/35973 Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Randall Spangler <rspangler@chromium.org>
* link: Increase EC cold reboot time to 150msRandall Spangler2012-10-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | This matches Silego's recommendation as of 10/18. BUG=chrome-os-partner:14687 BRANCH=link TEST='reboot cold' repeatedly from EC console (or 'ectool reboot_ec cold' repeatedly from root shell), then check that Power+Esc still reboots the system. Original-Change-Id: Ief2962bf66a947e83dfe934e45e18dc37d6ba326 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/35968 Reviewed-by: Simon Glass <sjg@chromium.org> (cherry picked from commit 113dd1ba16900d1ad7c0d656205a709f7e0a86f1) Change-Id: I0470912762b9f32fd1bbb2e75f43c8a91484ff82 Reviewed-on: https://gerrit.chromium.org/gerrit/35970 Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Randall Spangler <rspangler@chromium.org>
* link: host command params must be 32-bit alignedRandall Spangler2012-10-171-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes a problem where flash writes would fail because the source buffer was not 32-bit aligned. BUG=chrome-os-partner:15435 BRANCH=link TEST=from a root shell, localhost ~ # echo 1234567812345678123456781234567 > /tmp/data localhost ~ # ls -l /tmp/data -rw-r--r-- 1 root root 32 Oct 17 17:28 /tmp/data localhost ~ # ectool flasherase 0x3a000 0x4000 Erasing 16384 bytes at offset 237568... done. localhost ~ # ectool flashwrite 0x3a000 /tmp/data Reading 32 bytes from /tmp/data... Writing to offset 237568... done. If that doesn't crash, the fix works (prior to this fix, that would reboot the system). Change-Id: I2cf5b8e913e4e341fea876d36b5f1bbe6d68e73c Original-Change-Id: I8d197e7ef7a1c74825916bd788f7d450088a55cc Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/35916 Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/35920
* link: Don't print keyboard state changes by defaultRandall Spangler2012-10-171-1/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The keyboard scan module generates a lot of debug output when the user is typing on the keyboard - enough so that switching to the console, logging in as root, and typing 'ectool console' flushes the EC's console output buffer of any useful data. Default printing this to off. Add a new 'ksstate' command which will print the current keyboard scan state or toggle printing off/on. This is important for debugging LPC communication failures. BUG=chrome-os-partner:13819 BRANCH=link TEST=manual - Boot system - Type on keyboard. At EC console, should not see KB state: output - Hold down space bar. - At EC console, type 'ksstate'. Should print: ksstate [20.943886 KB debounced : -- -- -- -- -- -- -- -- -- -- -- 20 --] [20.945215 KB prev : -- -- -- -- -- -- -- -- -- -- -- 20 --] [20.945568 KB debouncing: -- -- -- -- -- -- -- -- -- -- -- -- --] Keyboard scan state printing off - Release space bar - At EC console, type 'ksstate on' - Type on keyboard. Should see KB state: output - At EC console, type 'ksstate off' - Type on keyboard. At EC console, should not see KB state: output Original-Change-Id: I4343b7b777fd13057b3222eeba77ed099c5e5a93 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/35843 Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> (cherry picked from commit 90a18599bb3ee0b0f49617a950805eb6bb77dd3f) Change-Id: I512e85bb6afcd5b27a2ad74d7f60930f228a6da8 Reviewed-on: https://gerrit.chromium.org/gerrit/35898 Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Randall Spangler <rspangler@chromium.org>
* link: don't rely on host-write interrupt statusRandall Spangler2012-10-172-36/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This works around a potential LM4 chip problem where edges on the FRMH status bit don't always trigger interrupts. The workaround is to look at FRMH for each channel in the interrupt handler rather than the interrupt status, and to trigger the interrupt every 250ms to sweep up any missed writes. We already do this for port 80 writes; this just extends the workaround to all channels. BUG=chrome-os-partner:13965 BRANCH=link TEST=manual - boot system - EC console should show a number of HC lines for host command - EC console should show a number of ACPI queries - switch to root shell; keyboard should work - ectool version should work Original-Change-Id: If02d685519c69ee88c055c8374a6c655a277e637 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/35871 Reviewed-by: Simon Glass <sjg@chromium.org> (cherry picked from commit c0640ee296acbf8ac3d4cf5246c60056015909c8) Change-Id: I3951ee5a81b60a59bfb56ec71f5b865cf1167387 Reviewed-on: https://gerrit.chromium.org/gerrit/35897 Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Randall Spangler <rspangler@chromium.org>
* Make S3 red-light flash adjustable.Bill Richardson2012-10-173-7/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This makes the timing for the S3 low-power indicator adjustable without reflashing. BUG=chrome-os-partner:8039 BRANCH=Link TEST=manual Boot, log in, run this to put the lightbar into demo mode: ectool lightbar demo 1 ectool lightbar seq s3s0 The lightbar should act as though the system is asleep. Then press the left arrow a couple of times and the down-arrow four or five times. You should see the red light pulse every 5 seconds or so. Now run ectool lightbar params > /tmp/w Edit /tmp/w to change the timing lines to this: 100 # .s3_ramp_up 100 # .s3_ramp_down Then run ectool lightbar params /tmp/w After a cycle or two, you should see the lightbar flash instead of pulse. Original-Change-Id: If815ff2fb9a158c0e1f4dbb6a269ad07e122d84c Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/35839 Reviewed-by: Randall Spangler <rspangler@chromium.org> (cherry picked from commit f574f1c37c2d72d2cb064bda6546fa7d1f047cea) Change-Id: I780a03b191bd377fbbfc2c6e9f6a9203637ff0be Reviewed-on: https://gerrit.chromium.org/gerrit/35870 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Tested-by: Bill Richardson <wfrichar@chromium.org>
View Lorry Controller Status