summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
* discovery-stm32f072: Enable SPI over USB tunnelAnton Staaf2014-10-236-19/+81
| | | | | | | | | | | | | | | | | Enable master control of SPI2 over USB for testing flashrom's ability to write to a SPI flash chip attached to the stm32. Signed-off-by: Anton Staaf <robotboy@chromium.org> BRANCH=None BUG=None TEST=make buildall -j; write image using flashrom Change-Id: I7d320acd28a03e91fcd7f7d697be40f69ea7bbdc Reviewed-on: https://chromium-review.googlesource.com/218741 Reviewed-by: Vic Yang <victoryang@chromium.org> Commit-Queue: Anton Staaf <robotboy@chromium.org> Tested-by: Anton Staaf <robotboy@chromium.org>
* Allow 5V/3A on PlanktonVic Yang2014-10-221-3/+4
| | | | | | | | | | | | | | Plankton is capable of supplying 5V at 3A. Advertise 5V/3A as well. BRANCH=None BUG=chrome-os-partner:33133 TEST=Switch plankton to 5V/12V/20V source and measure power with INA. Change-Id: Iea0545b30127b415a9dc51fceff0b7eff162c1d0 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/224986 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org>
* Fix clock bug on STM32F0 that HSI48 isn't enabledVic Yang2014-10-221-2/+13
| | | | | | | | | | | | | | | | | | | When changing the clock init code for STM32F3, I accidentally disabled HSI48 for STM32F0, which is causing all problems on all STM32F0 platforms. Re-enable it. BRANCH=Samus BUG=chrome-os-partner:32660 TEST=Boot on Ryu P1 and see console. Change-Id: Ie343cdb039d839e41b36489388fc91970e2bb7d8 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/225002 Reviewed-by: Anatol Pomazau <anatol@google.com> Tested-by: Anatol Pomazau <anatol@google.com> Reviewed-by: Todd Broch <tbroch@chromium.org> Tested-by: Todd Broch <tbroch@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org>
* Calibrated lightbar values for Samus & RyuBill Richardson2014-10-222-8/+18
| | | | | | | | | | | | | | | | | | | | | | | | | This updates the lightbar params with the values determined in the optic lab. The full-on primary colors are of uniform intensity at the brightness level used by Link. The Google colors provide the closest match to the official color palette (at full brightness) described at https://sites.google.com/a/google.com/brandsite/the-colours BUG=chrome-os-partner:33017 BRANCH=ToT,samus,ryu TEST=manual The calibration and testing was done in the optic lab. You can see the result just by looking at the lightbar. For best results, set the brightness to the max with ectool lightbar brightness ff Change-Id: I1cb64e3c547844adf733cd46bff1256319b4f612 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/224992
* ryu_p2: Fix broken build due to overlapped commitsBill Richardson2014-10-221-11/+15
| | | | | | | | | | | | | | Looks like the commit queue latency caused a breakage. Commit 7eaa290 breaks commit 00551f7. This fixes it. BRANCH=None BUG=chrome-os-partner:32660 TEST=make buildall -j Change-Id: I37ac58ae26a17bc75fae8e6da28bead9a195ba89 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/225001 Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
* samus_pd: Add BC1.2 charging and charge port + current limit selectionShawn Nematbakhsh2014-10-225-11/+163
| | | | | | | | | | | | | | | | | | | On an interrupt from the Pericom charger detection IC, check the current limit of the attached charger. Charge manager is informed of available charge from BC1.2 source and PD sources and selects the proper port + charge limit in each case. BUG=chrome-os-partner:32003 TEST=Manual on samus. Insert Apple charger, verify charge limit is selected appropriately. Insert PD charger, verify that charge port switches to PD port. Remove + reinsert chargers, verify that port / limit is selected appropriately. BRANCH=samus Change-Id: I47e1e3be1c522f1e11529a0b4ac665e695f33e14 Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/221791 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* stm32-USB: USB SPI tunnel driverAnton Staaf2014-10-224-0/+301
| | | | | | | | | | | | | | | | | | | | | Simple control of SPI for flashing over USB. This driver is working, and using the discovery board with a W25Q16 flash chip attached flashrom can read, erase, write, and verify the whole chip in 45 seconds. Signed-off-by: Anton Staaf <robotboy@chromium.org> BRANCH=None BUG=None TEST=make buildall -j Change-Id: I224f1f87cd6adc8b64c17de1df98dae0a9cfa6a5 Reviewed-on: https://chromium-review.googlesource.com/218740 Reviewed-by: Anton Staaf <robotboy@chromium.org> Tested-by: Anton Staaf <robotboy@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Anton Staaf <robotboy@chromium.org>
* ryu: enable lid switchVic Yang2014-10-226-16/+6
| | | | | | | | | | | | | | This is needed for inductive charging to work. BRANCH=None BUG=chrome-os-partner:31392 TEST=On Ryu, close the lid and check BASE_CHARGE_VDD_EN is toggled. TEST=Open the lid and see the AP booting. Change-Id: Ib153c08a803088b832c7d65261c71605c3378d5f Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/224804 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* samus: change fan RPM values, enable fast-startBill Richardson2014-10-223-16/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Updating the fan speeds according to the manufacturer's specs. The fan vendor recommends that the minimum fan speed be a 20% duty cycle. Since the built-in fan controller has a tach-based feedback loop, I'm using the RPM value instead of the duty cycle (20% is 2286 RPM, according to the vendor). The vendor also wants a 30% duty cycle to start turning, but the built-in fan controller provides support for fast-start too. The controller's minimum fast-start duty cycle is 50%, but it also has a programmable number of revolutions that it will wait before backing off. Holding my ear down close to the fans while they start and stop, it seems that the minimum 2 revolution start period is sufficient and provides the least noise. Of course, since I've never had any problems starting the fans directly at 1000 RPM this noise is a little more noticeable than that. It's quite possible that the built-in controller is smart enough to make 1000 RPM work by bumping the duty cycle up until the fans turn even if the fans don't like it. BUG=chrome-os-partner:32892 BRANCH=ToT,samus TEST=manual Listen closely and run the EC console "faninfo" command to see the fans start and stop as the system boots and idles. Change-Id: I47c9e7cef3f9f4bd815a13032fe10234decd62ed Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/224830 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* usb_pd_protocol: Add support for charge_manager and voltage reportingShawn Nematbakhsh2014-10-2212-49/+200
| | | | | | | | | | | | | | | | | | | | | | | | Integrate charge_manager and include several API changes designed for reporting voltage. 1. Make pd_choose_voltage set the chosen voltage for use by caller. 2. Add voltage parameter to pd_set_input_current. 3. Add pd_get_role to grab the sync / source state of a port. 4. Add charge manager PD + type C port initialization to the pd state machine. BUG=chrome-os-partner:32003 TEST=Manual on samus. Insert Apple charger, verify charge limit is selected appropriately. Insert PD charger, verify that charge port switches to PD port. Remove + reinsert chargers, verify that port / limit is selected appropriately. Remove battery, insert power source, verify that our power source port never becomes disabled. BRANCH=samus Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Change-Id: Idf3198c71d2ddf1e401e766fc82a4b7a02aed068 Reviewed-on: https://chromium-review.googlesource.com/223758 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* ryu_p2: Set alternate function for USB D+/D- pinsVic Yang2014-10-222-0/+7
| | | | | | | | | | | | | | | Unlike STM32F0, we need to configure alternate function for USB module on STM32F373. Adds the pin configuration for ryu_p2 and also adds the proper configuration step in USB module. BRANCH=None BUG=chrome-os-partner:32660 TEST=With changes to enable USB on ryu_p2, see the device enumerated Change-Id: I5e2cb7cfc44a1bb88bae69804021c783c8d17968 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/224789 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* ryu: enable lightbar on P2 boardsVic Yang2014-10-223-2/+7
| | | | | | | | | | | | | | | Ryu uses the same LEDs as Samus, so let's use the same brightness values for them. Also, increase the stack size for console task so that 'lightbar' command doesn't cause stack overflow. BRANCH=None BUG=chrome-os-partner:32203 TEST=See lightbar in action on Ryu. Change-Id: I89b61f6df2751c9dd6b40f9e374f01e1b0dfd504 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/224426 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Add new build target ryu_p2 for Ryu P2 boardsVic Yang2014-10-2212-8/+804
| | | | | | | | | | | | | | | | | | | | | | | | | The new build target ryu_p2 is mostly based on ryu. On ryu_p2, we have a new EC chip with bigger flash, so make the corresponding changes: - Pinout changes - HW Timer: TIM5 - USB PD Tx Timer: TIM3_CH4 - USB PD Rx Timer: TIM2_CH4 - Use UART2 for EC console - Disable UART Tx DMA as it conflicts with USB PD Tx DMA - Use 24MHz HSE x2 = 48MHz for SYSCLK BRANCH=None BUG=chrome-os-partner:32660 TEST=Sanity check on a new board: - i2cscan - PD negotiation - UART console - gettime Change-Id: I4ef6b53a928a2777721e3874032aeb0e6b2b4c92 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/221404 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* stm32: Support UART DMA on UART2Vic Yang2014-10-223-2/+16
| | | | | | | | | | | | | | | This adds the DMA channel definition for UART2 and allows selection of DMA channel for UART. BRANCH=None BUG=chrome-os-partner:32660 TEST=With the CLs to enable the new Ryu boards, check the console is working. Change-Id: I964c284899777dda67c264e622aea6aba752ea76 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/224176 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* samus: fix false shutdown due to low batteryAlec Berg2014-10-221-1/+7
| | | | | | | | | | | | | | | | Fix bug causing unit to falsely shutdown due to low battery. The shutdown warning time was not getting reset, so two false readings of battery SOC or voltage, seperated by more than 30 seconds in time would cause "charge force shutdown due to low battery" BUG=chrome-os-partner:33111, chrome-os-partner:33144 BRANCH=samus TEST=make buildall Change-Id: I6f00187516d23aa78139e5c1565febca34176ecc Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/224765
* samus: new algorithm for tmp006 object temperatureBill Richardson2014-10-226-266/+457
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The original algorithm is given in the TMP006 User's Guide (SBOU107.pdf). The algorithm we previously implemented is that, plus some additional and completely undocumented massaging of the Tdie and Vobj registers. The original meaning of that hack is now lost in the mists of time, thanks to our email retention policy. This CL introduces a new algorithm variant, but at least this time the details are in the bug report. It's essentially the same as the User's Guide algorithm, except that we apply one-stage FIR filters to the Tdie input and the Tobj output. There are five new parameters: d0, d1, ds, e0, e1. Refer to tmp006_read_object_temp_k() in ec/driver/temp_sensor/tmp006.c to see how these new parameters are applied. CAUTION: The tmp006 sensor algorithm is mostly math and magic numbers. The spreadsheet attached to the bug report has six sheets with wildly varying values for those parameters. Since the correct parameter values haven't yet been determined for Samus, all I can be sure of with this CL is that it seems to work and isn't any worse than the old one. Oh, and note that the EC's 't6cal' console command has been disabled until/unless we add support for floating point IO. Use ectool from the host to get and set the params instead. BUG=chrome-os-partner:32260 BRANCH=ToT,Samus TEST=manual After booting, look at the sensor values using ectool: localhost ~ # ectool temps all 0: 312 1: 314 2: 313 Sensor 3 not calibrated 4: 311 Sensor 5 not calibrated 6: 305 Sensor 7 not calibrated 8: 306 Sensor 9 not calibrated 10: 307 Sensor 11 not calibrated 12: 312 Sensor 13 not calibrated localhost ~ # localhost ~ # ectool tempsinfo all 0: 0 PECI 1: 1 ECInternal 2: 1 I2C-Charger-Die 3: 2 I2C-Charger-Object 4: 1 I2C-CPU-Die 5: 2 I2C-CPU-Object 6: 1 I2C-Left C-Die 7: 2 I2C-Left C-Object 8: 1 I2C-Right C-Die 9: 2 I2C-Right C-Object 10: 1 I2C-Right D-Die 11: 2 I2C-Right D-Object 12: 1 I2C-Left D-Die 13: 2 I2C-Left D-Object EC result 2 (ERROR) ... localhost ~ # There are six tmp006 object temps that need calibrating. The index used for the calibration is for the tmp006 objects, not the 3,5,7,.. numbers reported for all temp sensors. See the current values with tmp006cal: localhost ~ # /tmp/ectool tmp006cal 5 algorithm: 1 params: s0 0.000000e+00 a1 1.750000e-03 a2 -1.678000e-05 b0 -2.940000e-05 b1 -5.700000e-07 b2 4.630000e-09 c2 1.340000e+01 d0 2.000000e-01 d1 8.000000e-01 ds 1.480000e-04 e0 1.000000e-01 e1 9.000000e-01 localhost ~ # If the s0 param is zero, this sensor is uncalibrated. The params are entered in the order in which they're displayed You can change any or all of the parameters. Skip the ones you don't want to update by specifying '-' for its position. (Note: throw in an extra '--' first so that ectool doesn't think that negative numbers are command options). For example, to change s0 and b0: localhost ~ # ectool -- tmp006cal 5 1.0 - - -3.0 localhost ~ # localhost ~ # ectool tmp006cal 5 algorithm: 1 params: s0 1.000000e+00 a1 1.750000e-03 a2 -1.678000e-05 b0 -3.000000e+00 b1 -5.700000e-07 b2 4.630000e-09 c2 1.340000e+01 d0 2.000000e-01 d1 8.000000e-01 ds 1.480000e-04 e0 1.000000e-01 e1 9.000000e-01 localhost ~ # Now sensor 13 (tmp006 object index 5) is calibrated: localhost ~ # ectool temps all 0: 310 1: 315 2: 313 Sensor 3 not calibrated 4: 310 Sensor 5 not calibrated 6: 305 Sensor 7 not calibrated 8: 307 Sensor 9 not calibrated 10: 307 Sensor 11 not calibrated 12: 312 13: 313 Change-Id: I61b5da486f5e053a028c533ca9e00b9a82a91615 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/224409 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* samus: change hibernate delay to 7 daysAlec Berg2014-10-213-3/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Add macro for default hibernate delay, and set to 7 days on samus. Also, adds CONFIG_ option for hibernating early if low on battery. For samus, setting early hibernate at 1 day when battery < 10%. BUG=chrome-os-partner:33088 BRANCH=samus TEST=make buildall Added ccprintf("Target shutdown: %.6ld\n", target_time); to print out target shutdown time after setting it. Verifed the following on samus 1) If CONFIG_HIBERNATE_DELAY_SEC is left at default 3600 (samus board.h does not overwrite it), then target time is 3600s. 2) If CONFIG_HIBERNATE_DELAY_SEC is defined in samus/board.h, then target time equals that value. 3) If CONFIG_HIBERNATE_DELAY_SEC is defined as 1 week and CONFIG_HIBERNATE_BATT_PCT is defined to 10% and CONFIG_HIBERNATE_BATT_SEC is 1 day, then when battery is between 8-10% target time is 1 day and if battery is at 11%, target time is 1 week. Change-Id: Ief155ad6c327775fa348d3458fc47ee9dd8569c3 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/224520 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* cortex-m0: add more constraints on atomic implementationVincent Palatin2014-10-211-2/+2
| | | | | | | | | | | | | | | | | | | In ARMv6-m instruction set, the load/store address register can only be a "low" register : r0..r7. Update the inline assembly constraints to match the hardware. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=none TEST=make buildall Change-Id: I9872aeb437b2bb6401bed8076348e26d434320dd Reviewed-on: https://chromium-review.googlesource.com/224582 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 DisplayPort status and configure SVDMs.Todd Broch2014-10-216-35/+229
| | | | | | | | | | | | | | | | | | | | | | | Per revisements to the DisplayPort Alternate mode specification there are two additional SVDMs for DPout support: status & configure. This CL adds those SVDMs and calls them (status then config) after finding a device that supports DP Alternate mode. Future CLs will use these SVDMs to complete providing HPD over CC support. BRANCH=none BUG=chrome-os-partner:31192,chrome-os-partner:31193 TEST=manual, plug hoho/dingdong into samus and see: 1. Additional DP status [16] & DP configure [17] 2. Drives DPout properly Change-Id: I52b373085ddc330e4afb1d1883d2621bc2e4ee95 Signed-off-by: Todd Broch <tbroch@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/223260 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* pd: Correct use of console printing in USB PD policy files.Todd Broch2014-10-2110-60/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | All non-interactive console prints should use their tasks channel parameter to make it easy for developers to inhibit console output. This CL corrects printf's in the various usb_pd_policy files that belong to the USB PD task to use cprintf(CC_USBPD, ...) instead of the macro reserved for interactive console commands ccprintf. BRANCH=none BUG=none TEST=manual, set 'chan 1' and see none of the previous chatter relating to USB PD. set 'chan 0x08000000' and see it return. Output from DFP side for SVDM discovery now looks: SVDM/4 [1] ff008041 340018d1 00000000 11000008 [1119.966911 DONE] SVDM/2 [2] ff008042 ff010000 [1119.970135 DONE] SVDM/2 [3] ff018043 00100081 [1119.973437 DONE] SVDM/1 [4] ff018184 Change-Id: I47e5f4ec2d4a6a25f171177ead5ebc99409f80b6 Signed-off-by: Todd Broch <tbroch@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/224191 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* stm32f0: Pinky: Fix power leak caused by SPI at startupAlexandru M Stan2014-10-211-2/+0
| | | | | | | | | | | | | | | Seems like we were setting outputs too early during boot, sometimes causing a power leak. SPI should only turn on power levels more active than S3, not on the S5->S3 transition. BUG=chrome-os-partner:32824 BRANCH=None TEST=Pinky powers on, Scope VCC33_PMUIO and VCC33_IO, note that they're smooth Change-Id: I05c3622d124c2539222b883b895bc9092c5f0b12 Signed-off-by: Alexandru M Stan <amstan@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/224508 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Pinky: Reoganize power on sequencingAlexandru M Stan2014-10-211-28/+18
| | | | | | | | | | | | | | | | | | This is the first step to fix a leak when powering up the system. Some stuff should wait till after the rails are up. The SPI timeout was removed because there's a simpler way to determine this: SPI is only ready when the AP goes from S3->S0 BUG=chrome-os-partner:32824 BRANCH=None TEST=Pinky powers on Change-Id: Ia4281f54f7735d4efe2bc3e8ba1e462fccc51fd0 Signed-off-by: Alexandru M Stan <amstan@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/222632 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* pd: do not respond to unknown SVDMsAlec Berg2014-10-211-0/+4
| | | | | | | | | | | | | bug fix: if we see an unknown SVDM, do not respond to it. BUG=none BRANCH=samus TEST=test with third party that sends unknown SVDM Change-Id: I3ef6c38be029d57bf3784ba832b7ae137f379049 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/224179 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* pd: add data role to pd message headerAlec Berg2014-10-211-1/+3
| | | | | | | | | | | | | | Added data role bit to PD message header. The data role is currently tied to power role: source = DFP, sink = UFP. BUG=none BRANCH=samus TEST=tested with third part protocol analyzer Change-Id: Ic56ea92899d20013aace108cee794d10c3780364 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/224178 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* stm32f: Add DMA interrupt handlers for channel 1 to 3Vic Yang2014-10-214-33/+23
| | | | | | | | | | | | | | | | | | We already have interrupt handlers for channel 4 to 7. We need channel 3 for the new Ryu boards. Add the handlers for channel 1 to 3. Also, instead of copy-pasting interrupt handlers, define a macro and declare interrupt handlers with it. BRANCH=None BUG=chrome-os-partner:32660 TEST=make buildall TEST=Check PD communication on the new Ryu board (with other CLs to enable the new boards.) Change-Id: I51d6bd16739f31a7efbeb4ec19bb91a1546fe21d Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/224175 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* Add stm32mon support for STM32F37xxVic Yang2014-10-211-0/+1
| | | | | | | | | | | | | This is needed for the new Ryu boards. BRANCH=none BUG=chrome-os-partner:32660 TEST=Program STM32F373 chip. Change-Id: Ib7a58826945090300b7e086e888c43c46fb499ab Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/223893 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* Fix flash bank size for STM32F373Vic Yang2014-10-211-1/+1
| | | | | | | | | | | | | | The write protect granularity is 4-page instead of 2-page, so the bank size should be 8K. BRANCH=None BUG=chrome-os-partner:32660 TEST=None Change-Id: Ifb8be289cc0d05cbe538062ad860727c9a652943 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/223891 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* Allow full Cortex-M4 instruction set for STM32F3xxVic Yang2014-10-211-0/+5
| | | | | | | | | | | | | STM32F3xx has a Cortex-M4 core. Allow the full instruction set. BRANCH=None BUG=chrome-os-partner:32660 TEST=None Change-Id: Ibb1dc0e36eed6b3042bde60cf2870a108176d919 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/223890 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* pd: allow selection of Tx timer channelVic Yang2014-10-2110-17/+44
| | | | | | | | | | | | | | | | So far, we always use channel 1 of the Tx timer and the configuration code is hard coded. We need to support other channels for new Ryu boards. Let's make this a configurable bit. BRANCH=samus BUG=chrome-os-partner:32660 TEST=make buildall TEST=Plug in Zinger to Ryu and see 20V come up. Change-Id: Id08d4eb0d6a5721d8a03672484d0892a0714383b Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/223836 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* pd: alternate mode: Limit response to valid modes during discovery.Todd Broch2014-10-204-21/+41
| | | | | | | | | | | | | | | | | | | | | | | Previous reading of specification left some doubt about how SVDM responder to 'discover modes' command communicated the number of valid modes. It is communicated via the 'object position' field in the VDM header where: opos = modes + 1. This change adds the mode count to the opos field and sends only that amount of data back to the initiator. Initiator stores that mode_cnt so that it can correctly choose a mode when 'enter mode' phase occurs. BRANCH=none BUG=chrome-os-partner:30645 TEST=manual, 1. see SVDM responder to Discover modes only send supported number of modes for SVID. 2. 'pe 0 dump' displays correct set of discovered modes on initiator. Change-Id: I9b626dd6dd3e85e80b4f0596332300d74b1830ee Signed-off-by: Todd Broch <tbroch@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/223981 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* pd: alternate mode: simplify mode entry choice.Todd Broch2014-10-205-98/+46
| | | | | | | | | | | | | | | | | | | | | | Original implementation was complicated by belief that we'd want PD MCU to manage entry of multiple alternate modes. This simply won't be practical given the upper level system policies that would need to weigh in on these decisions as well as the seemingly endless additions to the alternate mode ecosystem. Longer term we'll need to pass the generic alternate mode discovery VDO info to the kernel/userland to implement remainder of policy. However, for short term lets implement single mode entry instead. BRANCH=none BUG=chrome-os-partner:30645 TEST=manual, mode entry is successful on both ports. Change-Id: Ia24f5ee4d59c13c62d68b30f8587b5e5fbdb2fa0 Signed-off-by: Todd Broch <tbroch@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/223980 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* Twinkie: update sniffer codeVincent Palatin2014-10-201-49/+50
| | | | | | | | | | | | | | | | | | | | | - Remove hardware double-buffering : it's complex to get right and does not provide any performance improvement. - Increase buffer size x2 to decrease overflow frequency. - Fix buffering and simplify code. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=chrome-os-partner:28337 TEST=make BOARD=twinkie do a long acquisition on a sample pattern from the function generator and verify that no packet are missing and the waveform looks good. Change-Id: I12a9e8370d3f238e8894f15ce0190e2e0fbc26d7 Reviewed-on: https://chromium-review.googlesource.com/223565 Reviewed-by: Todd Broch <tbroch@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org>
* Extend INA231 driver to support INA219 on PlanktonVic Yang2014-10-188-134/+170
| | | | | | | | | | | | | | | The register format of INA231 and INA219 are very much alike. In our use case, we only need to use different coversion coefficient. BRANCH=None BUG=chrome-os-partner:32764 TEST='ina 0' on Plankton V2. TEST=Build twinkie. Change-Id: I9c8e21e30ed844566793dcc1221f865400c3d90d Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/223370 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* samus: add tap for batteryAlec Berg2014-10-187-9/+413
| | | | | | | | | | | | | | | Adds double tap detection for samus. When user double taps in S3 or lower to show battery state of charge on lightbar. BUG=chrome-os-partner:29041 BRANCH=samus TEST=make buildall Tap the lid in S3 or lower. Change-Id: Ic5f4709bdee2472cb7e91717318337b04bae1fc8 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/221965 Reviewed-by: David Schneider <dnschneid@chromium.org>
* plankton: Implement cable flipVic Yang2014-10-187-72/+187
| | | | | | | | | | | | | | | | | | | | | | | When the cable flip button is pressed, instead of only flipping on Plankton side, we should also signal the port partner to flip. This is done by sending a custom VDM. Upon receiving the flip VDM, the port partner is responsible of flipping the DP/USB polarity. Note that the "flip" here only affects the superspeed lanes. The CC lines polarity is not changed. We need this for factory test automation, and this "flip" function should only be used for testing purpose as it clearly violates the USB PD spec and it only works on devices that accept the custom flip VDM. BRANCH=Samus BUG=chrome-os-partner:32163 TEST=COnnect Plankton and Ryu. Press the button on Plankton and make sure the polarity GPIOs on Ryu are negated. Change-Id: I7ee5ea70067de4f422a7478623fe7fe8d3724372 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/223325 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* samus: Wait for VCORE_PGOOD before asserting SYS_PWROKDuncan Laurie2014-10-181-8/+25
| | | | | | | | | | | | | | | | | | VCORE needs time to come up after PCH_PWROK is asserted and we should be waiting for VCORE_PGOOD to be 1 before proceeding. This also moves the 5ms delay for PCIe to be before SYS_PWROK since that is where it is requried according to the power sequence specification (rev 1.3 figure 2-4). BUG=chrome-os-partner:33027 BRANCH=samus TEST=build and boot on samus Change-Id: I4bd969bdb56ecf14cc68754318452861b70f0539 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/224033 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* samus: added sensor init retry logicSheng-Liang Song2014-10-181-11/+10
| | | | | | | | | | | | | | | | | - Added sensor init retry logic to avoid intermitent i2c init error. - Fixed shutdown hook to set data rate to 0 before changing sensor state. BUG=chrome-os-partner:33020 BRANCH=ToT TEST=Verified on Samus. Signed-off-by: Sheng-Liang Song <ssl@chromium.org> Change-Id: I04ccf6547114e9f6c62756b38b8df27c2bc70de9 Reviewed-on: https://chromium-review.googlesource.com/223631 Reviewed-by: Alec Berg <alecaberg@chromium.org> Commit-Queue: Sheng-liang Song <ssl@chromium.org> Tested-by: Sheng-liang Song <ssl@chromium.org>
* pd: if no SVIDS are returned, do not attempt discover modesAlec Berg2014-10-181-0/+2
| | | | | | | | | | | | | | | | | If no SVID is returned from discover SVIDS command, then don't attempt to discover modes. BUG=none BRANCH=samus TEST=test with device that does not return any SVIDS Signed-off-by: Alec Berg <alecaberg@chromium.org> Change-Id: I22201451cdc87b389734279d9294cf27d4740043 Reviewed-on: https://chromium-review.googlesource.com/223830 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Commit-Queue: Alec Berg <alecaberg@chromium.org> Tested-by: Alec Berg <alecaberg@chromium.org>
* pd: update the tPSTransition timeoutVincent Palatin2014-10-171-2/+2
| | | | | | | | | | | | | | | | | | | | The timeout when we are not seeing a PS_READY message has been updated to 450-550 ms in the PD specification, reflect that change in the code. In case we are reaching this timeout, we need to send a HARD_RESET. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=samus BUG=none TEST=plug a PD source with a 300ms delay before PS_READY. Change-Id: I116a858c42a55f2036b3f2e13730cf29392a3420 Reviewed-on: https://chromium-review.googlesource.com/223785 Reviewed-by: Alec Berg <alecaberg@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Todd Broch <tbroch@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
* pd: NACK unsupported VDM requestsVincent Palatin2014-10-171-5/+10
| | | | | | | | | | | | | | | | | | When a VDM request is not supported, return a proper NAK message rather than trying to execute a NULL pointer. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=samus BUG=none TEST=plug a power source sending discovery VDM to Samus. Change-Id: Iba60fd29d950c99fd981f9e8ecf3e911409147d5 Reviewed-on: https://chromium-review.googlesource.com/223780 Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Todd Broch <tbroch@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
* pd: fix VDM commands numberingVincent Palatin2014-10-171-2/+2
| | | | | | | | | | | | | | | | | | In structured VDMs, the ACK command is b01 and the NAK command is b10, update the defines accordingly. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=samus BUG=none TEST=interoperability test with another power source. Change-Id: I8050ae262dc5ab538d973f802111c2874358ea37 Reviewed-on: https://chromium-review.googlesource.com/223725 Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Todd Broch <tbroch@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
* pd: reset the message ID on connectionVincent Palatin2014-10-171-0/+4
| | | | | | | | | | | | | | | | | | The message ID counter in our message needs to be reset to 0 on a new connection. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=samus BUG=none TEST=dump the sequence with the USB PD protocol analyzer. Change-Id: I1bddddf4075fba646b1e8c7886059c4a11e5fec9 Reviewed-on: https://chromium-review.googlesource.com/223759 Reviewed-by: Todd Broch <tbroch@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org>
* zinger: enable hibernateAlec Berg2014-10-171-1/+1
| | | | | | | | | | | | | | | | Enable hibernate on zinger for DVT. Note: this may break some EVT zingers. BUG=chrome-os-partner:28335 BRANCH=samus TEST=make buildall Hibernate tested in CL:220837 Change-Id: I65f4776d27ad88beee101fb00d0b6221ba272a26 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/223738 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* pd: update standard revision fieldVincent Palatin2014-10-171-1/+2
| | | | | | | | | | | | | | | | | | USB Power Delivery standard for the BMC variant was finally rev'ed to 2.0 : update the revision field in the PD packets. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=samus BUG=none TEST=dump packet with the PD protocol analyzer Change-Id: I218861d74da61da388bed10e070c9faf6f81fd00 Reviewed-on: https://chromium-review.googlesource.com/223757 Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Todd Broch <tbroch@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
* hoho: Disable spi master by default.Todd Broch2014-10-161-1/+3
| | | | | | | | | | | BRANCH=none BUG=none TEST=manual, HDMI tranceiver functions correctly at power-on Change-Id: I348f22250da7290809fb39319283ec9d4bc4fcc7 Signed-off-by: Todd Broch <tbroch@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/223614 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* hoho: correct CONFIG1 GPIO direction.Todd Broch2014-10-161-1/+1
| | | | | | | | | | | BRANCH=none BUG=none TEST=manual, compile boots, can read GPIO. Change-Id: If68d56cc4fcafd3872f7df16a5578542e34d5093 Signed-off-by: Todd Broch <tbroch@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/223613 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* Fix incorrect valid and writable flash flagsVic Yang2014-10-157-17/+149
| | | | | | | | | | | | | | | | The valid and writable flags the EC sends back to the AP are incorrect. They are a little bit different on differnt chips, so let's move it to flash physical layer. This is not any causing problem, but we should fix this. BUG=chrome-os-partner:32745 TEST=make buildall BRANCH=samus Change-Id: Ibcda5ae770f5ea02cde094490997a5bc447df88f Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/222661 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* samus_pd: Initial DFP_D HPD GPIOs.Todd Broch2014-10-151-0/+2
| | | | | | | | | | | | | | | | | | | USB PD spec now calls for HPD signal to be managed across the USB PD protocal. In preparation this CL makes the HPD GPIOs outputs and initially low. This should NOT effect older revs of the design as GPIOs were unused (had unstuffed option for external XTAL). BRANCH=samus BUG=chrome-os-partner:30645 TEST=compiles & runs. With reworked board can manually trigger HPD. Change-Id: I0a64c1daf8d8c866f5de237c3daf4be028eecd63 Signed-off-by: Todd Broch <tbroch@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/223462 Reviewed-by: Alec Berg <alecaberg@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* Write protect support for STM32F0Vic Yang2014-10-157-15/+123
| | | | | | | | | | | | | | | | | | | | | | | | | | | | On STM32F0, we cannot work around the hard fault triggered when trying to protect the whole flash. Therefore, we need to go with the ALL_AT_BOOT approach. When write protect is enabled, instead of setting ALL_NOW flag to immediately lock down the entire flash, we need to set ALL_AT_BOOT and then reboot to have the protection take effect. BUG=chrome-os-partner:32745 TEST=Along with the next CL. On Ryu: 1. Enable HW WP. Check the output of 'ectool flashprotect' and see correct flags. 2. 'flashrom -p ec --wp-range 0 0x10000'. Check RO_AT_BOOT is set. 3. Reboot EC and check RO_NOW is enabled. 4. Boot the system and check ALL_NOW is set. 5. Update BIOS and reboot. Check software sync updates EC-RW. 6. 'flashrom -p ec --wp-disable' and check it fails. 7. Disable HW WP and reboot EC. Check RO_NOW and ALL_NOW are cleared. 8. 'flashrom -p ec --wp-disable' and check RO_AT_BOOT is cleared. TEST=Enable/disable WP on Spring. Check RO_AT_BOOT/ALL_NOW can be set properly. BRANCH=samus Change-Id: I1c7c4f98f2535f1c8a1c7daaa88d47412d015977 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/222622 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* discovery-stm32f072: fix USB version stringAnton Staaf2014-10-151-1/+1
| | | | | | | | | | | | | | | | | The change to a dynamic version string was lost in a rebase. This fixes it. Signed-off-by: Anton Staaf <robotboy@chromium.org> BRANCH=None BUG=None TEST=make buildall -j Change-Id: I388dcf7fc67b02dc0ab350b1cbb08f2e5d0c7000 Reviewed-on: https://chromium-review.googlesource.com/223389 Tested-by: Anton Staaf <robotboy@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Commit-Queue: Anton Staaf <robotboy@chromium.org>
View Lorry Controller Status