summaryrefslogtreecommitdiff
path: root/common
Commit message (Collapse)AuthorAgeFilesLines
* pd: fix PDO selection for low voltage boardsstabilize-7039.BVincent Palatin2015-05-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | When the policy of the board is to select lowest voltage providing enough power, the current algorithm ignores the fact that the board input current limit might be lower than the charger maximum current for a particular voltage level leading to the possibility of selected a voltage with a lower available power. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=none TEST=set a Ryu board with the following configuration : PD_PREFER_LOW_VOLTAGE PD_MAX_POWER_MW 24000 PD_MAX_CURRENT_MA 1000 PD_MAX_VOLTAGE_MV 20000 connect it a Zinger (offering 3A @ 20V, 3A @ 12V and 3A @ 5V), see it selecting 20V rather 12V before the patch. Change-Id: I8c0589bb5e5705c4d8a6035120d1cdfaacaa14df Reviewed-on: https://chromium-review.googlesource.com/269262 Reviewed-by: Vic Yang <victoryang@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org>
* pd: add explicit setting of D+/D- switch when setting type-C muxesAlec Berg2015-05-051-5/+18
| | | | | | | | | | | | | | | | | | | Add explicit setting of USB D+/D- switch when setting the type-C muxes. This fixes a bug in which we would open D+/D- switch when entering DP mode and lose USB2.0 connection. BUG=chrome-os-partner:39766 BRANCH=samus TEST=add printf to board_set_usb_switches() on samus and make sure we don't open the D+/D- switch when entering DP mode. Change-Id: I2b5bb2185298794ddb4cc457f3695ce6adabd9f8 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/268993 Reviewed-by: Todd Broch <tbroch@chromium.org> Tested-by: Todd Broch <tbroch@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Scott Collyer <scollyer@chromium.org>
* ryu: fork P4/P5 supportVincent Palatin2015-05-021-2/+2
| | | | | | | | | | | | | | | | | | | In preparation for Proto 6 board support which won't be backward compatible, fork the EC for Proto 4 and Proto 5 for people who need to support older boards. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=chrome-os-partner:39202 TEST=make buildall Change-Id: I520bbf146cc1c1dc04e55283be57807ec19ebaa1 Reviewed-on: https://chromium-review.googlesource.com/266064 Reviewed-by: Alec Berg <alecaberg@chromium.org> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
* cli: add ability to read/write memory of different bus widthVadim Bendebury2015-05-021-17/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds an optional extra parameter to the 'rw' command. When the first argument is .b or .s, the access size becomes 8 pr 16 bits respectively. BRANCH=none BUG=none TEST=on the EC console: > rw 0x10000 read 0x10000 = 0x00000000 > rw .b 0x10000 0x55 write 0x10000 = 0x55 > rw 0x10000 read 0x10000 = 0x00000055 > rw .b 0x10000 read 0x10000 = 0x55 > rw .s 0x10002 read 0x10002 = 0x0000 > rw .s 0x10002 0x1234 write 0x10002 = 0x1234 > rw 0x10000 read 0x10000 = 0x12340055 > rw .b 0x10000 read 0x10000 = 0x55 > rw .b 0x10001 read 0x10001 = 0x00 > rw .b 0x10002 read 0x10002 = 0x34 > rw .b 0x10003 read 0x10003 = 0x12 > rw .s 0x10000 read 0x10000 = 0x0055 > rw .s 0x10002 read 0x10002 = 0x1234 > rw . 0x10002 Parameter 1 invalid Usage: rw addr [.{b|s}] [value] > Change-Id: Iad1a4b3e297253ffdbf13afeede8ade9451eb11a Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/268897 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* charge_ramp: fix flaky charge_ramp testAlec Berg2015-05-021-6/+0
| | | | | | | | | | | | | | | | | | | | Fix flaky charge_ramp test. The test often delays CHARGE_DETECT_DELAY after a new charger has been plugged in. But, that is the same delay the charge_ramp module uses before starting to ramp. This creates a race condition where sometimes the test resumes before the ramp up starts and sometimes the test resumes after the ramp up starts. This change fixes the problem by modifying the test to delay by 100ms less than the charge_ramp module. BUG=chromium:483543 BRANCH=none TEST=run charge_ramp test 10 times w/o this CL and see failure 4 times. run test 20 times with this CL and observe 0 failures. Change-Id: I5f7a6a05f9293d3dd7db5517a9df7caec95c58ea Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/268798 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* cleanup: rename motion sensor CONFIG_ optionsBill Richardson2015-05-012-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | This renames some motion sensor options to start with more consistent prefixes. For gesture (tap) detection: CONFIG_GESTURE_DETECTION: CONFIG_SENSOR_BATTERY_TAP => CONFIG_GESTURE_SENSOR_BATTERY_TAP For detecting lid angle: CONFIG_LID_ANGLE: CONFIG_SENSOR_BASE => CONFIG_LID_ANGLE_SENSOR_BASE CONFIG_SENSOR_LID => CONFIG_LID_ANGLE_SENSOR_LID BUG=none BRANCH=none TEST=make buildall Change-Id: Ib8f645902a5585346e1d8d2cbf73d825c896a521 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/268777 Reviewed-by: Alec Berg <alecaberg@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* charge_manager: modify PD power HC to give more info on currentAlec Berg2015-05-012-18/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change the EC_CMD_USB_PD_POWER_INFO host command to report the input current limit and the max current theoretically possible given the charger. The input current limit field is useful for logging purposes and the max current field is useful to give to powerd to determine if we have a low power charger connected. The max current is determined by checking if the charge supplier is allowed to ramp. If the charge supplier is allowed to ramp and has not completed ramping yet, then max current is the max current that we are allowed to ramp up to. Once the ramp has completed, then max current is the stable charging current. If the charge supplier is not allowed to ramp, then max current is simply the max current as registered with charge_manager. The point here is to keep the max as high as possible until we know for sure it is lower to avoid showing the user the low power notification until we know for sure. This CL also adds a new charger type, USB_CHG_TYPE_UNKNOWN. For a short period after a charger is plugged in, the supplier type may change and PD negotiation is still in process, and therefore we tell the host we have an unknown charger type. This allows powerd to show the charging icon, but delay determining if this is a low power charger until we know for sure. BUG=chrome-os-partner:38548 BRANCH=samus TEST=tested with zinger, a DCP, an SDP, and a proprietary charger. tested that low power notification never pops up with zinger, even if you purposely wedge charge circuit with "charger voltage 7000" on EC console. tested that the other chargers all pop up low power notification once the supplier changes from UNKNOWN to the real supplier. used "ectool --name=cros_pd usbpdpower" to check current values. Change-Id: If8a9a1799504cc2a13238f4e6ec917d25d972b22 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/265066 Reviewed-by: Sameer Nanda <snanda@chromium.org>
* pd: Allow for setting USB mux when swapping into DFP roleScott2015-05-011-7/+16
| | | | | | | | | | | | | | | | | | | | | - Added config option CONFIG_USBC_SS_MUX_DFP_ONLY - If this options is enabled, then the mux is set to TYPEC_USB_MUX only is data role is DFP. - If this option is not enabled, the mux is set for both UFP and DFP (i.e. RYU) BUG=chrome-os-partner:39059 TEST=Manual samus to plankton, switching between source and sink modes. Forced data role swap via ec console command. BRANCH=Samus Change-Id: Ibc2fb0ad42d0fe415d3338d38da94ad4b041513b Signed-off-by: Scott Collyer <scollyer@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/266916 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org> Commit-Queue: Alec Berg <alecaberg@chromium.org>
* plankton: HPD over USB PD.Todd Broch2015-05-012-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | HPD needs to be transported over USB PD as both SBU lines are consumed for differential AUX signalling. This CL does the following: 1. Enables GPIO DPSRC_HPD as interrupt. 2. Sends debounced HPD across CC via the SVDM DP status message. 3. Adds polling for GPIO_DBG_20V_TO_DUT_L as it shares the same interrupt as DPSRC_HPD. 4. Configures DP redriver in presence of HPD high. Signed-off-by: Todd Broch <tbroch@chromium.org> BRANCH=none BUG=chrome-os-partner:33132,chrome-os-partner:33761 TEST=manual, 1. Connect samus -> plankton via type-C 2. Connect plankton -> DP monitor via displayport See initial SVDM discovery on samus console See EDID information See SVDM status message correct when plug/unplug DP cable from plankton 3. Press 'CHARGING_20V_TO_DUT_L' button and see below on plankton console. Button 8 = 0 Change-Id: Id95567a3bfa073ffa2c699335be8c5bf0327675f Reviewed-on: https://chromium-review.googlesource.com/229429 Reviewed-by: Alec Berg <alecaberg@chromium.org> Commit-Queue: Todd Broch <tbroch@chromium.org> Tested-by: Todd Broch <tbroch@chromium.org>
* samus_pd: Request different DP pin modes including multi-function.Todd Broch2015-04-301-0/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously samus_pd just picked pin mode E without regard to what the UFP was requesting. This change surveys the UFP's DP pin capabilities and then requests the appropriate pin config. Additionally if the UFP supports multi-function and has preferred it during the initial DP status message, samus will configure its type-c mux in 'dock' mode. Signed-off-by: Todd Broch <tbroch@chromium.org> BRANCH=samus BUG=chrome-os-partner:38728 TEST=manual, 1. hoho + samus, pin mode = 'C' 2. dingdong + samus, pin mode = 'E'. 3. apple type-C HDMI multiport + samus, pin mode = 'D' and USB device enumerates as SuperSpeed. 4. plankton + samus w/ patch asserting alternate mode with multi-function preferred sets config to 'F' now and only drives DP out on 2 lanes w/ other two allowing USB key to be seen. Change-Id: Ie4764c33f108e8a88f0052b64ddb96cb92e5a78b Reviewed-on: https://chromium-review.googlesource.com/267796 Commit-Queue: Todd Broch <tbroch@chromium.org> Tested-by: Todd Broch <tbroch@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* pd: cleanup PD receive error enumAlec Berg2015-04-291-5/+5
| | | | | | | | | | | | | | Cleanup PD receive error enum by including RX in name since we will have a different enum for TX errors. BUG=none BRANCH=none TEST=make -j buildall Change-Id: I355092e0e73a022acb4a92736374cd2289d324bf Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/267670 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* mec1322: Added task-based Port80 POST code support.Kevin K Wong2015-04-271-0/+47
| | | | | | | | | | | | | | | | | | | | | | With mec1322's EMI set to decode IO 0x800, it does not have any other interfaces to support POST code via IO 0x80. This change is to enable Port80 POST code support via polling method. Limitation: - POST Code 0xFF will be ignored. - POST Code frequency is greater than 1 msec. BUG=chrome-os-partner:39386 TEST=Verified Port80 POST code is captured in EC console. Verified "port80 task" console command will disable/enable Port80 task. Verified "port80 poll" will get the last Port80 POST code. BRANCH=none Change-Id: I27e53e84b5be1fd98464a44407dd58b93d8c798d Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com> Reviewed-on: https://chromium-review.googlesource.com/266783 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* samus: add device to dual-role charging white listAlec Berg2015-04-271-1/+1
| | | | | | | | | | | | | | Add Apple VGA charge-through adapter PID to dual-role charging white list so that we automatically charge through it. BUG=chrome-os-partner:38785 BRANCH=samus TEST=make -j buildall Change-Id: I5de757a9e97824a2b488a45497c73ab53cc1899c Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/267300 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* pd: continue dual-role toggling when detect Open/RaAlec Berg2015-04-251-14/+13
| | | | | | | | | | | | | | | | | | | | | | As a source, when we detect Open/Ra (active cable with no UFP) then do not transition to debounce CC line, instead continue dual-role toggling as if nothing is connected. BUG=chrome-os-partner:35652, chrome-os-partner:39486 BRANCH=samus TEST=test with samus and twinkie. on twinkie, simulate Open/Ra with: "tw res ra nc" and verify that we continue dual-role toggling. Then plug in zinger and verify we negotiate and start charging. Also, tested case where we initially detect Open/Rd and start debouncing, but then it turns into Open/Ra: echo "tw res rd nc" > /dev/ttyUSB0; sleep 0.05; echo "tw res ra nc" > /dev/ttyUSB0 In this case, samus transitions to SRC_DEBOUNCE briefly, then goes back to disconnected state and continues dual-role toggling. Change-Id: Idabac60b9e2f54639d7a6305d96e9984b0600519 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/267087 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* pd: ignore cable resetAlec Berg2015-04-241-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Identify and ignore cable reset PD command BUG=chrome-os-partner:39464 BRANCH=samus TEST=connect two samus'. on one samus add code to send a cable reset like such: int send_cable_reset(int port) { int off; CPRINTF("C%d Send cable reset\n", port); /* 64-bit preamble */ off = pd_write_preamble(port); /* Hard-Reset: 3x RST-1 + 1x RST-2 */ off = pd_write_sym(port, off, BMC(PD_RST1)); off = pd_write_sym(port, off, BMC(PD_SYNC1)); off = pd_write_sym(port, off, BMC(PD_RST1)); off = pd_write_sym(port, off, BMC(PD_SYNC3)); /* Ensure that we have a final edge */ off = pd_write_last_edge(port, off); /* Transmit the packet */ if (pd_start_tx(port, pd[port].polarity, off) < 0) { pd[port].send_error = -5; return -5; } pd_tx_done(port, pd[port].polarity); /* Keep RX monitoring on */ pd_rx_enable_monitoring(port); return 0; } Without this CL, the receiving samus times out and ends up causing equivalent of hard reset. With this CL, we receive cable reset and drop it. Also used twinkie to measure goodCRC delay. No measureable change in delay on samus and zinger. Samus delay is ~70us and zinger delay is ~65us. Change-Id: Ic0e871c8cf96502b861f430e05ee145881fb55fa Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/266981 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* mec1322: lfw loader + RO/RW architectureDivya Jyothi2015-04-231-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mec1322 only has 96KB program memory, vs 256KB flash space on lm4.We no longer have enough program memory to load both RO and RW at boot. We'll want to implement a small loader program that will load either RO or RW from flash, and then jump to the loaded image. CONFIG_FW_INCLUDE_RO is enabled to include RO image into the build. pack.py script is altered to load the (lfw + R)O on boot. Software sync is not added.Distinguish between RO/RW is yet to be added. flash_ec is altered to support padding 0xFFs to 256k ec.bin to match the size of the SPI flash of the board. BUG=chromium:37510 BRANCH=None TEST=Make -j buildall,Verified ec.bin to be 256k. Verified RW image at offset 0h and (lfw + RO) at offset 2000h. On boot sysjump to lfw. lfw checks in shared SRAM (currently RO) and jumps to RO image. Change-Id: Ib9b114e2f24a615d5e5bd8b3803be621d1e5bd17 Signed-off-by: Divya Jyothi <divya.jyothi@intel.com> Reviewed-on: https://chromium-review.googlesource.com/265807 Reviewed-by: Shawn N <shawnn@chromium.org> Reviewed-by: Icarus W Sparry <icarus.w.sparry@intel.com>
* Allow console-reading host commands on locked systemsRandall Spangler2015-04-211-14/+0
| | | | | | | | | | | | | | | | | | We allow reading the EC console via case-closed debugging on locked systems, so we should also allow reading it via host command. The original reason for denying this (EC printing keystrokes) no longer exists; we don't print keyboard matrix changes by default anymore. BUG=chromium:479223 BRANCH=none (well, could apply this anywhere...) TEST=on a system with both hard and soft WP enabled in the EC, 'ectool console' works instead of failing with access denied. Change-Id: Ie111bc130dd3f17cd4b658718d00d299786e3434 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/266701 Reviewed-by: Alec Berg <alecaberg@chromium.org> Reviewed-by: Sameer Nanda <snanda@chromium.org>
* lsm6ds0: Cache ODR and range on EC.Aseda Aboagye2015-04-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | For the driver functions get_range and get_data_rate, each call would end up executing an i2c transaction even if the value had not changed. Therefore, I modified the lsm6ds0 driver to cache the output data rate as well as the range. This prevents unecessary i2c transactions from occuring. BUG=chromium:476226 TEST=Flashed EC on samus and verified that the accelrange and accelrate commands still worked and that the sensors were functional. TEST=Verified Double Tap still worked. TEST=make -j buildall tests BRANCH=none Change-Id: Ie432979266dc4e4892978005de5d1df62cc0654f Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/265933 Reviewed-by: Alec Berg <alecaberg@chromium.org> Commit-Queue: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org>
* flash: Add option to move pstate inside RO imageRandall Spangler2015-04-171-38/+154
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, ECs with internal flash store the write protect state for RO in a separate write/erase block of flash. This is wasteful on chips where there are not many blocks of flash. Add a new CONFIG_FLASH_PSTATE_IN_BANK option which is defined by default. This is the old behavior, for compatibility. (And we're calling it 'bank' because that's what the existing code does, even if the terminology is somewhat etymologically... bankrupt.) If that config is #undef'd, then store the write protect flag directly inside the RO image. This uses only 4 bytes of the RO image, instead of an entire erase block. The magic numbers for the pstate values are chosen such that when protecting RO, bits are only transitioned away from their erased state. Unprotecting RO once it's protected requires reflashing RO; it's no longer possible to 'flashwp disable'. But that's ok, because realistically, the only reason to unprotect RO is if you're about to flash the RO firmware anyway. BUG=chromium:476659 BRANCH=none TEST=Without undefining CONFIG_FLASH_PSTATE_IN_BANK, make sure everything still works on samus and samus_pd. This ensures we didn't break the existing functionality: flashinfo -> no flags flashwp enable flashinfo -> ro_at_boot reboot flashinfo -> ro_at_boot flashwp disable flashinfo -> no flags Then recompile with #undef CONFIG_FLASH_PSTATE_IN_BANK and test: flashinfo -> no flags flashwp enable flashinfo -> ro_at_boot reboot flashinfo -> ro_at_boot flashwp disable -> fails with access denied flashinfo -> ro_at_boot Then reflash to verify that clears the ro_at_boot flag: flashinfo -> no flags Change-Id: Ie794b8cfed2a10c50b0e36dcf185884070b04666 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/266095 Reviewed-by: Alec Berg <alecaberg@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
* pd: add a connection flag to pd port info for hostVincent Palatin2015-04-171-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Export what the PD protocol stack thinks about the port connection state. This simplifies getting a meaningful data role/power role from the host (eg we are not really a UFP if we are simply dual-role toggling but not connected). Do not increment the command version as this is mostly backward-compatible and currently no client actually uses that field. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=samus BUG=none TEST=ectool --name=cros_pd usbpd 0 plug and unplug various accessories on the port and check the result. Change-Id: Ief3e0d47b6a288bcfc5b8fbb8156f29fd09dd336 Reviewed-on: https://chromium-review.googlesource.com/266120 Trybot-Ready: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org> Reviewed-by: Benson Leung <bleung@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org>
* i2c: Support I2C controllers with multiple portsShawn Nematbakhsh2015-04-171-1/+11
| | | | | | | | | | | | | | | | | | | Certain chips have I2C ports mapped to the same controller. In this case, it's necessary to lock out access to the controller during use. This configuration can be supported by adding CONFIG_I2C_MULTI_PORT_CONTROLLER, which can be defined at the chip level, along with an API function to map port index to controller index. BUG=chrome-os-partner:38335,chrome-os-partner:38945 TEST=Manual with subsequent commit. Verify that i2cscan is functional on strago. BRANCH=None Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Change-Id: I37ffa661a2ad6cd2235cef2ee77637cc3ab92523 Reviewed-on: https://chromium-review.googlesource.com/265942 Reviewed-by: Alec Berg <alecaberg@chromium.org> Reviewed-by: Kevin K Wong <kevin.k.wong@intel.com>
* pd: Qualify modep pointer before use.Todd Broch2015-04-141-9/+15
| | | | | | | | | | | | | | | | | | If UFP sends invalid VDM responses to the DFP its possible that modep pointer may be NULL. CL qualifies all uses of modep to guarantee that these invalid responses don't cause samus_pd to crash. BRANCH=samus BUG=chromium:476773 TEST=manual, 1. Still successfully negotiate alternate mode (both DP & GFU) with hoho. 2. passes usbpd_DisplayPortSink autotest. Change-Id: If4a611182b5e659c5534c2206132ef76d4e023db Signed-off-by: Todd Broch <tbroch@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/265620 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* panic: Fix unaligned memory access panicli feng2015-04-141-1/+1
| | | | | | | | | | | | | | | Unaligned memory access would not cause reboot on some processors. Additional condition was needed. BUG=none TEST=Verified that "crash unaligned" causes a panic on mec1322. BRANCH=none Change-Id: Icdc1b5e11634b14890755301346183e0dba723c9 Signed-off-by: li feng <li1.feng@intel.com> Signed-off-by: Divya Jyothi <divya.jyothi@intel.com> Reviewed-on: https://chromium-review.googlesource.com/263949 Reviewed-by: Shawn N <shawnn@chromium.org>
* CCD: Switch PD_NO_DEBUG logic to use system_is_lockedAnton Staaf2015-04-131-10/+5
| | | | | | | | | | | | | | | | | | | | The system_is_locked function encompases the required checks for asserting PD_NO_DEBUG. It also supports forcing a system to be unlocked at build time, as well as handling systems without flash. Signed-off-by: Anton Staaf <robotboy@chromium.org> BRANCH=None BUG=None TEST=make buildall -j Change-Id: I676acb5a2ae169f9739a19910a760706f69f5b7b Reviewed-on: https://chromium-review.googlesource.com/265463 Trybot-Ready: Anton Staaf <robotboy@chromium.org> Tested-by: Anton Staaf <robotboy@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org> Commit-Queue: Anton Staaf <robotboy@chromium.org>
* Ryu: Add PD_NO_DEBUG logicAnton Staaf2015-04-131-0/+15
| | | | | | | | | | | | | | | Signed-off-by: Anton Staaf <robotboy@chromium.org> BRANCH=None BUG=chromium:470299 TEST=make buildall -j Change-Id: I79f831c8a0b581561472470986b86c77b7f824a1 Reviewed-on: https://chromium-review.googlesource.com/264796 Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Anton Staaf <robotboy@chromium.org> Commit-Queue: Anton Staaf <robotboy@chromium.org> Trybot-Ready: Anton Staaf <robotboy@chromium.org>
* pd: samus: support vconn swap and enable on Samus when in S0/S3Alec Berg2015-04-111-7/+118
| | | | | | | | | | | | | | | | | Support VCONN swap on samus and always accept VCONN swap when in S0 or S3. In S5, we can't provide VCONN, so reject VCONN swap requests. BUG=chrome-os-partner:34978 BRANCH=samus TEST=load on two samus' and use "pd 1 swap vconn" to swap which side is source vconn. also run in S5 and verify swap request is rejected. Change-Id: I04be8d1d910a2d6c5ad8b27a790f8e33121c86ee Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/264856 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* twinkie: add simple text tracing mechanismVincent Palatin2015-04-101-5/+3
| | | | | | | | | | | | | | | | | | | | | | When using the Twinkie dongle without a protocol decoder on the host, add a simple text tracing mechanism, so the user can get the timestamped traces of the packets on the wire (in a best effort fashion). Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=none TEST=On Twinkie command-line, type "tw trace on" then plug a DingDong to Samus through Twinkie and see the PD message traces on the console. Change-Id: I4fa35d6783cc6279c95209c86f37e6d717de7301 Reviewed-on: https://chromium-review.googlesource.com/237222 Reviewed-by: Alec Berg <alecaberg@chromium.org> Reviewed-by: Todd Broch <tbroch@chromium.org> Trybot-Ready: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
* optimize printf size without the common runtimeVincent Palatin2015-04-101-3/+25
| | | | | | | | | | | | | | | | | | | | | | | When a platform is built without the common runtime to optimize for flash size, remove the 64-bit support in printf to save more space (mainly by getting rid of the uint64divmod helper). This saves 376 bytes of flash on Zinger/MiniMuffin. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=none TEST=make buildall and compare flash size with and without the change. the common runtime binaries are identical excepted the version information. Change-Id: I1e7237e693df9ea23291c8c0fe414c3b5c716848 Reviewed-on: https://chromium-review.googlesource.com/265052 Trybot-Ready: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
* pd: combine src/snk dr_swap states into one dr_swap stateAlec Berg2015-04-101-84/+45
| | | | | | | | | | | | | | | | | | | | Combine source and sink data role swap states into one data role swap state. This saves 128B of flash. Also add DUAL_ROLE_IF_ELSE macro to clean up all the places we check our role and need to know if we are DUAL_ROLE or not. BUG=none BRANCH=samus TEST=load onto two samus' and try data swaps from both sink and source sides and make sure they get rejected and go back to the correct ready state. load onto zinger and make sure we successfully data swap when connected to samus. Change-Id: I57744593ce291e512cb254b08745115de365cab4 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/264855 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* samus_pd: disable timerinfo command to save spaceAlec Berg2015-04-101-0/+6
| | | | | | | | | | | | | | Disable the timerinfo command on samus_pd to save flash space BUG=none BRANCH=samus TEST=make -j buildall From .map file, 256 bytes saved Change-Id: I6731967741cb28268499126f1753916319a1dcb4 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/264939 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* pd: Modify BIST mode according to ECR#PD2.0.1.0.004Scott2015-04-091-36/+116
| | | | | | | | | | | | | | | | | | | | | | - Changed TX BIST mode so that it transmits for 50 msec instead of transmitting forever. - Added console command to initiate TX BIST mode. - Fixed an issue with circular DMA mode which was causing watchdog. - Modified RX BIST to account for shorter TX BIST duration. BUG=chrome-os-partner:36335 TEST=Manual on Samus to Samus, manual on Zinger to Samus BRANCH=Samus Signed-off-by: Scott Collyer <scollyer@chromium.org> Change-Id: I666347de47c81b5b7a1e82c2b99345ff3ebbb7d4 Reviewed-on: https://chromium-review.googlesource.com/256194 Tested-by: Alec Berg <alecaberg@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org> Reviewed-by: Scott Collyer <scollyer@chromium.org> Trybot-Ready: Alec Berg <alecaberg@chromium.org> Commit-Queue: Alec Berg <alecaberg@chromium.org>
* console: remove CC_USBMSGwendal Grignou2015-04-071-1/+0
| | | | | | | | | | | | | | | Mass storage has been removed by https://chromium-review.googlesource.com/238763 We can remove the USBMS entry from console.h BUG=chromium:474394 BRANCH=none TEST=make -j buildall Change-Id: Ic18f205eb49be411988ad47151b6de678d08355e Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/264420 Reviewed-by: Anton Staaf <robotboy@chromium.org>
* samus: create USB PD device whitelist for allowing chargingAlec Berg2015-04-072-8/+36
| | | | | | | | | | | | | | | | | | | | | | | | Create a USB PD device whitelist for allowing charging by default from dual-role devices that don't set the externally powered bit. BUG=chrome-os-partner:38785 BRANCH=samus TEST=modify zinger and modify VID and PID to match white-listed entry. also modify zinger to remove externally powered bit and set dual-role power bits so that we treat as a dual-role device by default. when you plug in this modified zinger into samus, it still will not charge because the VID and PID are obtained after deciding to treat it as dual-role, but when you issue soft reset "pd 1 soft", it starts charging. the white-listed device will always ask for a power swap if it is a sink, so we will always get source cap after learning the VID/PID, which should correctly trigger changing the device to be treated as a dedicated charger. Change-Id: Ibe7ec57f842a0b9bfb02447baf5b3327217a9516 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/264015 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* pd: treat externally powered dualrole devices as dedicated chargersAlec Berg2015-04-071-45/+34
| | | | | | | | | | | | | | | | | | | | | Treat externally powered dualrole devices as dedicated chargers. This allows us to default to consuming power from externally powered dualrole devices and cancels a charger override when one is attached. BUG=chrome-os-partner:38785 BRANCH=samus TEST=tested with third-party dualrole device that can be externally powered. also tested with another samus that was hard-coded with externally powered bit set, and deleted it's policy for power swapping. when this externally-powered samus is plugged into a samus running this CL, we always charge from the externally-powered samus. Change-Id: I850eba668e86d311d9353aa3881fc3a518409630 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/263331 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* ensure all console channels are displaying properlyVincent Palatin2015-04-061-0/+2
| | | | | | | | | | | | | | | | | | If the number of console channels is greater than 32 (the bit size of the channel mask), the overflowing ones are silently masked. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=none TEST=add one channel and see the build failing on the assert. Change-Id: I1793b22990be85882d80aae44503bba62358fbd2 Reviewed-on: https://chromium-review.googlesource.com/264062 Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Trybot-Ready: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
* motion: do not enter S3 if it is already in S5Chris Zhong2015-04-021-0/+5
| | | | | | | | | | | | | | | | | | If sensor->active is S5, do not enter S3, since the sensor has been shut down. BUG=chrome-os-partner:38627 TEST=Gsensor works well BRANCH=firmware-veyron-6588.B Change-Id: I35ab82b8e197b3bc8f8a4d3ae7d8c3b70c17e385 Signed-off-by: Chris Zhong <zyw@rock-chips.com> Reviewed-on: https://chromium-review.googlesource.com/263628 Tested-by: 小华 王 <anndy_wang@asus.com> Tested-by: BoChao Jhan <james_chao@asus.com> Reviewed-by: Alec Berg <alecaberg@chromium.org> Reviewed-by: Alexandru Stan <amstan@chromium.org> Commit-Queue: Alexandru Stan <amstan@chromium.org>
* ec: Created lightbar params v2Aseda Aboagye2015-03-311-1/+100
| | | | | | | | | | | | | | | | | | | | The 'lightbar params' v1 command has a parameter list that exceeds 120 bytes, which will not work over i2c. Therefore, I created a params v2 command which breaks up the existing parameters into logical groups which are less than 120 bytes. TEST=Tested new lightbar params2 command and ran get/sets on all groups for samus. Repeated test on ryu as well. BUG=chromium:467716 BRANCH=none Change-Id: If0fa92e9a2f373b20257f8ce7eb66b7836d9ac60 Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/263106 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Commit-Queue: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* mighty: fix the LED bug of removed batteryZhengShunQian2015-03-311-4/+20
| | | | | | | | | | | | | | | | | | | | | | | Clear curr.batt_is_charging when the battery is not present. Add a new batt_was_removed flag to track when the battery has been removed. This causes PWR_STATE_ERROR so the LED shows error state, and triggers re-reading the static parameters from the battery when it's reattached. BUG=chrome-os-partner:38235 TEST=check the LED state on mighty BRANCH=veyron Change-Id: I400c22eda4bc0043adf7217166bd9f80c557d991 Signed-off-by: ZhengShunQian <zhengsq@rock-chips.com> Signed-off-by: Randall Spangler <rspangler@chromium.org> Signed-off-by: Doug Anderson <dianders@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/262007 Commit-Queue: Gediminas Ramanauskas <gedis@chromium.org> Tested-by: Gediminas Ramanauskas <gedis@chromium.org> (cherry picked from commit 6727e1dba2aafa81fa9572145413545106ae9626) Reviewed-on: https://chromium-review.googlesource.com/262140
* charge_state_v2: properly print static battery info errorsVincent Palatin2015-03-261-1/+1
| | | | | | | | | | | | | | | | | | | | When calling problem() with 0 as value, it's never printed on the EC console since the problem() function is de-duplicating the messages by checking against the last value (which is initialized at zero). Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=chrome-os-partner:38401 TEST=run on the current Ryu code (which has a faulty BQ27742 driver) and see the "charge problem: static update [...]" message. Change-Id: Iedfbc95e3751bc5b22452187b404a09b633160d7 Reviewed-on: https://chromium-review.googlesource.com/262448 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org>
* ACPI: Support accessing memmap data over ACPI CMD / DATA portsstabilize-6915.BShawn Nematbakhsh2015-03-255-10/+90
| | | | | | | | | | | | | | | | | | | | | | | Some platforms are unable to access the 900h-9ffh region over LPC and must instead access memmap data through the ACPI CMD / DATA ports. To avoid racing with data updates, disallow changes to multi-byte memmap data while in burst mode. Linux currently enables burst mode when accessing multi-byte data and disables it immediately afterward, though the ACPI spec defines burst mode in a more general way. BUG=chrome-os-partner:38224 TEST=Manual on Samus. Undefine LPC_MEMMAP and modify asl to move memmap data to ERAM at offset 0x20. Verify system boots cleanly and battery status is updated immediately on plug / unplug. BRANCH=None Change-Id: Ib848bdb491fdfece96ad0cee7a44ba85b4a1a50b Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/262072 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
* CCD: Add ability to enable and disable SPI bridgestabilize-6909.BAnton Staaf2015-03-231-0/+9
| | | | | | | | | | | | | | | | | | | | | This required changing the USB-SPI implementation slightly so that all work is done within the deferred callback. In particular, this allows the board specific enable and disable functions to do things that can only be done from a task context, like sleeping. Signed-off-by: Anton Staaf <robotboy@chromium.org> BRANCH=None BUG=None TEST=make buildall -j Change-Id: I3f6a01ed9d6f31a3259ba0a0f6b4e123d6d2e718 Reviewed-on: https://chromium-review.googlesource.com/260964 Trybot-Ready: Anton Staaf <robotboy@chromium.org> Tested-by: Anton Staaf <robotboy@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Commit-Queue: Anton Staaf <robotboy@chromium.org>
* spi_flash: Rework protection translation functionsShawn Nematbakhsh2015-03-173-237/+174
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously we defined separate functions to map registers to protect ranges for each supported SPI ROM. This change instead adds a protect range table + flags for each supported SPI ROM and adds common functions for translation between ranges + registers. This makes supporting new parts easier. Since we will never use most supported protection ranges, we can even simplfy the tables. The implementation is now similar to flashrom. BUG=chrome-os-partner:37688 TEST=Manual on Glower. flashwp disable + spi_flash_rsr --> 0 flashinfo --> shows no protection spi_flash_prot 0 0x10000 + spi_flash_rsr --> 0x24 flashinfo --> shows 64KB protected spi_flash_prot 0 0x20000 + spi_flash_rsr --> 0x28 flashinfo --> shows all 96KB protected spi_flash_prot 0 0x40000 + spi_flash_rsr --> 0x2c spi_flash_prot 0 0x80000 + spi_flash_rsr --> 0x10 spi_flash_prot 0 0 + spi_flash_rsr --> 0x00 spi_flash_prot 0 0x1000 --> error spi_flash_prot 0x10000 0x10000 --> error BRANCH=None Change-Id: Ie5908ce687b7ff207b09794c7b001a4fbd9e0f5a Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/259310 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* lm4: stm32: Store panic data in backup registers on hard resetShawn Nematbakhsh2015-03-141-1/+1
| | | | | | | | | | | | | | | | | | On hard reset / hibernate, RAM will be erased and panic data will normally be lost. When software panic data saving is enabled, try to save this data just before hard reset and restore it when we come back up. BUG=chrome-os-partner:37380 TEST=Manual on Samus with WP + SW sync enabled. Boot AP, then run "crash divzero" on console. After hard reset, verify that "panicinfo" dumps data and shows divzero exception code. BRANCH=Samus Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Change-Id: I9516dd4b6db12ef35e512cc4710f9b97d7e663cb Reviewed-on: https://chromium-review.googlesource.com/255912 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* pd: make source-only PD devices compatible with the common runtimeVincent Palatin2015-03-131-4/+10
| | | | | | | | | | | | | | | | | | Add the proper checks to be able to compile source-only PD devices with the common runtime. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=chrome-os-partner:37078 TEST=make buildall build honeybuns without CONFIG_USB_PD_DUAL_ROLE defined Change-Id: I7ad0b39b2e62736117ec2d7b5163502afbf14786 Reviewed-on: https://chromium-review.googlesource.com/259112 Reviewed-by: Scott Collyer <scollyer@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
* spi_flash: Add protect support for W25X40Shawn Nematbakhsh2015-03-111-15/+104
| | | | | | | | | | | | | | | | W25X40 uses a different protection register encoding than our existing W25Q64 code. Move the SPI ROM option to a config, and add support for the new part. BUG=chrome-os-partner:37688 TEST=`make buildall -j`. W25X40 protection code tested in a subsequent commit. BRANCH=None Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Change-Id: Iaaeabf42c6c62c20debc91afd2cf8671c14244c8 Reviewed-on: https://chromium-review.googlesource.com/258440 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* usb_pd: fix HPD State error under IRQ_HPDBernard Shyu2015-03-071-1/+1
| | | | | | | | | | | | | | | | The HPD State field (bit7) should be HIGH when IRQ_HPD (bit8) is asserted. BUG=none BRANCH=samus TEST=make buildall Change-Id: I27181623d5ef2f657839aa63222d6788a3257dad Reviewed-on: https://chromium-review.googlesource.com/253930 Reviewed-by: Todd Broch <tbroch@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Trybot-Ready: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Commit-Queue: Todd Broch <tbroch@chromium.org>
* samus: ryu: allow charge ramp on CDP and proprietary chargersAlec Berg2015-03-071-2/+10
| | | | | | | | | | | | | | | | | | | Modify charge ramp so that when it ramps it ramps from 500mA and up to the maximum allowed by that supplier. Also modify Samus and Ryu to use charge ramping for CDP and proprietary chargers due to the possibility that they may not be able to supply the amount that is supposed to be guaranteed by their advertisement. BUG=chrome-os-partner:37549 BRANCH=samus TEST=test on a proprietary charger, make sure we can ramp. test a DCP and make sure we also ramp as before. Change-Id: I08fd43c8f0b21aa54d114fbe5a1296c9556357e4 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/256972 Reviewed-by: Shawn N <shawnn@chromium.org> Reviewed-by: Vic Yang <victoryang@chromium.org>
* lightbar: clear all segments first before starting konami seqAlec Berg2015-03-061-0/+3
| | | | | | | | | | | | | | | | | | | Clear all lightbar segments first before starting konami sequence. If currently displaying Google colors, we need this so the start of the sequence shows up correctly. BUG=chrome-os-partner:37469 BRANCH=samus TEST=from S0 with google colors on lightbar, run "lightbar seq konami" from EC console and make sure 1st and 4th segments are cleared before starting konami sequence. Change-Id: I92ba8f29414c279895658167f8d5958fe49ea034 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/256192 Reviewed-by: David Schneider <dnschneid@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* samus: change tap for battery to not show dimmed last segmentAlec Berg2015-03-061-1/+13
| | | | | | | | | | | | | | | Change tap for battery lightbar sequence to not show the last segment dimmed as a percentage of your battery. BUG=chrome-os-partner:37335 BRANCH=samus TEST=use battfake console command to test out every increment of 10% and use "lightbar seq tap" to show tap. Change-Id: I4f38d26a8cfbecfa6efc86fcc8751ca8cb34879b Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/256191 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* samus_pd: disable i2cxfer console command to save spaceAlec Berg2015-03-061-0/+2
| | | | | | | | | | | | | | | Disable the i2cxfer console command by default to save space BUG=chrome-os-partner:37167 BRANCH=samus TEST=make -j buildall From .map file, 576 bytes of flash saved Change-Id: I0b50161ef0a49231e45c422da5042db77874aed1 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/256071 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Todd Broch <tbroch@chromium.org>
View Lorry Controller Status