summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* zinger: do an intermediate step when discharging from 20V to 5Vstabilize-storm-6683.BVincent Palatin2015-01-101-19/+54
| | | | | | | | | | | | | | | | | | | | | | If we discharge directly the output voltage from 20V to 5V under load, an undershot happens and we dip below the 5V UVP threshold. So when doing a down voltage transition from 20V to 5V, split it into 2 steps : a 20V->12V transition then once we are reached 12V, a 12V->5V transition. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=samus BUG=chrome-os-partner:33794 TEST=connect Zinger to a Firefly and an electronic load. Using Firefly, ask for 20V->5V, 12V->5V and 20V->12V transitions, check the VBUS waveforms on the scope. Change-Id: Ie1e091ae6f1fee1fb7d4e3bd72edbe7491acd5ea Reviewed-on: https://chromium-review.googlesource.com/229732 Reviewed-by: Alec Berg <alecaberg@chromium.org> Commit-Queue: Alec Berg <alecaberg@chromium.org> Tested-by: Alec Berg <alecaberg@chromium.org>
* pd: make VDO responses fasterAlec Berg2015-01-101-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allow VDO responses to be sent faster by taking out the check for incoming packet when a VDO is pending. This check isn't needed because we already check if the PD state machine is busy sending something. With this change, the turn around time for responding to Discover Identity on zinger is ~200us. BUG=chrome-os-partner:35327 BRANCH=samus TEST=loaded onto zinger and used twinkie to verify that discover identity is responded to in ~200us every time. used ectool to perform remote update on zinger, now takes ~18s (compared to ~55s). Also, used following bash loop to constantly sent PD voltage requests: while true; do dut-control "usbpd_uart_cmd:pd 1 dev 5"; sleep 0.3; dut-control "usbpd_uart_cmd:pd 1 dev 20"; sleep 0.3; done Used bash loop while updating zinger via ectool. I programmed zinger ~50 times and verified: - we never missed a PD voltage request - never got any PD protocol or phy layer errors (no collisions) - zinger successfully jumped to RW after each (no packets missed) Note: sending any other PD traffic while programming zinger does obviously slow down zinger update (~30s with my bash loop above). Change-Id: I94d1ac01440d096671972fa9c21c149ea432863f Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/240150 Reviewed-by: Todd Broch <tbroch@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* zinger: pre-compute RW hashVincent Palatin2015-01-101-6/+12
| | | | | | | | | | | | | | | | | To ensure we respond fast enough to the Discover Identity VDM (which timeout after 30ms), we need to pre-cache the RW hash at startup. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=samus BUG=chrome-os-partner:35327 TEST=plug Zinger to a PD sink and check the PD protocol trace on Twinkie Change-Id: I9decdff358dd1ab9ac373ce8bfdd0402f5e21f04 Reviewed-on: https://chromium-review.googlesource.com/240080 Reviewed-by: Alec Berg <alecaberg@chromium.org> Tested-by: Alec Berg <alecaberg@chromium.org> Commit-Queue: Alec Berg <alecaberg@chromium.org>
* pd: ensure power role matches CC pull resistor after hard resetAlec Berg2015-01-101-0/+14
| | | | | | | | | | | | | | | | | | | | Make sure the power role and the CC pull resistor match after receiving hard reset command in the middle of a swap. BUG=none BRANCH=samus TEST=on samus connect left and right ports together with C to C cable. note that after some collisions and some hard resets, it eventually stabilizes with one port in SNK_READY, the other in SRC_READY. without this CL, we get stuck executing a power swap and our power role and CC resistor get out of sync, requiring a reboot. Change-Id: Ia1385eb3a1c503052ad5bfd0d1595ecc096cd5f4 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/239976 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Todd Broch <tbroch@chromium.org>
* pd: avoid multiple role swaps on connectAlec Berg2015-01-101-1/+11
| | | | | | | | | | | | | | | | | | Avoid multiple power and data swaps on connect by clearing our local flag for checking our role when we receive a role swap. This means if the port partner sends a role swap on connect before us and we accept, then we will not turn around and ask for another swap. BUG=none BRANCH=samus TEST=connect samus to samus and make sure only one swap on connect. Change-Id: I2414b5bd5ffc54701b5758047e5d7e51ca3ff596 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/239951 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Todd Broch <tbroch@chromium.org>
* pd: fix possible redundant requests (again)Alec Berg2015-01-103-17/+13
| | | | | | | | | | | | | | | | | | | Another fix for redundant requests. This time there can be redundant requests if the maximum allowed voltage changes, but we still fall into the samus PDO index and therefore are asking for the same voltage. This fixes by checking the voltage value we actually request vs. the max value we can request. BUG=none BRANCH=samus TEST=samus to samus was causing redundant requests and now it's not. Change-Id: Ie49add1a42b86de97cee87f9d4637dd0578e2ce3 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/239950 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Todd Broch <tbroch@chromium.org>
* pd: implement new type-C connect state machineAlec Berg2015-01-106-129/+279
| | | | | | | | | | | | | | | | | | | | | Implement the new type-C connect state machine which removes lock and hold times and adds a debounce time to make sure CC lines settle before going into the attached state. This also adds detection of accessories, but doesn't do anything when an accessory is detected. BUG=chrome-os-partner:33680 BRANCH=samus TEST=test samus connected zinger and samus connected to samus. make sure that the connection is always formed. also tested with a third party with old state machine implementation and formed a connection every time. Change-Id: I91a7a6031bc35082cc19d7697142e4aa92ef46f2 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/238210 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* samus_pd: remove PWM moduleAlec Berg2015-01-102-1/+5
| | | | | | | | | | | | | | Remove PWM module which is not being used in order to save flash space. BUG=chrome-os-partner:34489 BRANCH=samus TEST=make -j buildall. view .map file and see we save ~760 bytes. Change-Id: Id107fb402a60c5ac7510982f8ace6bad46fb14d0 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/239912 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* lightbar: Don't let EC control suspend/resume sequenceEric Caruso2015-01-103-4/+31
| | | | | | | | | | | | | | | | | | | If the EC controls the lightbar and sets the sequence when it notices the chipset transitioning between states, we can't make exceptions for cases where we don't want to activate the lightbar, such as in dark resume. Instead, let's make it a separate command that we expect from the kernel. BUG=chrome-os-partner:32181 TEST=build on samus, verify lightbar does correct thing with manual control set BRANCH=ToT Signed-off-by: Eric Caruso <ejcaruso@chromium.org> Change-Id: I5dc619cbbf2498e2ef03ce622831b33e14c7c495 Reviewed-on: https://chromium-review.googlesource.com/239215 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* samus_pd: Remove CONFIG_CONSOLE_HISTORY to save flash spaceShawn Nematbakhsh2015-01-091-0/+1
| | | | | | | | | | | | | | | | History is written by the victors, except when they run out of flash space. BUG=chrome-os-partner:34489 TEST=Build samus_pd, check ec.RO.map and verify 756 bytes were saved. Verify that 'history' no longer works on console and up arrow has no function. BRANCH=Samus Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Change-Id: If512fe31f01cc35b0ef6fa60714b9df125818d64 Reviewed-on: https://chromium-review.googlesource.com/239971 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* ryu: Debounce BC1.2 charger detection due to asynchronous pin contactVic Yang2015-01-092-37/+78
| | | | | | | | | | | | | | | | This is basically ryu version of CL:237241. BRANCH=ryu BUG=None TEST=Repeatedly plug in a DCP charger, and verify that it's detected correctly. Change-Id: I036d1b2a52249234f38428e98a3e5fd5db2354b9 Signed-off-by: Vic Yang <victoryang@google.com> Reviewed-on: https://chromium-review.googlesource.com/239914 Tested-by: Vic Yang <victoryang@chromium.org> Reviewed-by: Shawn N <shawnn@chromium.org> Commit-Queue: Vic Yang <victoryang@chromium.org>
* ryu: add charge managerAlec Berg2015-01-098-10/+178
| | | | | | | | | | | | | | | | Add charge manager to ryu to set how much current to draw from the port. BUG=none BRANCH=samus TEST=make buildall Signed-off-by: Alec Berg <alecaberg@chromium.org> Change-Id: Ia545532e1bf6586566c0b964d966b5d69c0d4b61 Reviewed-on: https://chromium-review.googlesource.com/230760 Tested-by: Vic Yang <victoryang@chromium.org> Reviewed-by: Shawn N <shawnn@chromium.org> Commit-Queue: Vic Yang <victoryang@chromium.org>
* samus: pd: fix potential junk at end of tx transmissionstabilize-6670.BAlec Berg2015-01-095-93/+94
| | | | | | | | | | | | | | | | | | | | | | | | | | | Fix potential junk at end of PD TX transmit by adding to the DMA transmit complete interrupt a blocking wait for SPI to finish and then immediately disable SPI clock. This means we block in an interrupt function for approximately 45us at the end of every transmit. But, this is the highest priority thing going on anyway. Note, there is still a potential for junk if both ports are transmitting at the same time and finish very close to the same time. BUG=chrome-os-partner:34600 BRANCH=samus TEST=load onto samus and test communications with zinger. tested specifically with an old zinger CL, https://chromium-review.googlesource.com/#/c/226118/11, which watchdogs when samus has junk at end of transmit. Tested without this CL and verified we could never successfully flash zinger over PD due to this watchdog and verified on scope presence of junk. Then tested with this change and was able to successfully flash zinger using ectool on both ports in both polarities. Change-Id: If0cd9ab0551d36a7d7dc10232b6476dd56735972 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/239244 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* pd: Queue initial DFP HPD till after DP Config VDM.Todd Broch2015-01-093-5/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | VESA DisplayPort Alt Mode on USB Type-C Standard specifies: When DisplayPort Configuration is not selected (and the converter is driving its HPD output low), the converter shall track the current state of HPD, ready for appropriate indication when DisplayPort Configuration is subsequently selected. Not only are we violating specification here but it also causes a race between enabling DPout muxes to AUX line which in turn causes GPU to timeout trying to read EDID/DPCD on occasion. Change adds post_config function for DFPs alternate mode and in the case of DP it sets the dp_on flag there. This allows attention function to correctly defer HPD_HI that may accompany 'DP status' VDM to be queued (deferred) until such time that AUX muxes are enabled properly. Signed-off-by: Todd Broch <tbroch@chromium.org> BRANCH=samus BUG=chrome-os-partner:35219 TEST=manual, using hoho & dingdong With kernel bootarg drm.debug=0x6 following cases all show these drm debug lines: [drm:i915_hotplug_work_func], Connector DP-2 (pin 5) received hotplug event. [drm:intel_dp_get_dpcd], DPCD: 12 14 c4 01 01 00 01 00 02 02 06 00 00 00 00 [drm:intel_hpd_irq_event], [CONNECTOR:38:DP-2] status updated from disconnected to connected case1: boot connected to external display case2: attach dongle to external display then samus case3: attach dongle to samus then to external display case4: connect/disconnect rapidly on type-C side case5: connect/disconnect rapidly on external display side. Change-Id: I40eab797fdd5090c8ad13fae2cd053b740d9a307 Reviewed-on: https://chromium-review.googlesource.com/239420 Trybot-Ready: Todd Broch <tbroch@chromium.org> Tested-by: Todd Broch <tbroch@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Commit-Queue: Todd Broch <tbroch@chromium.org>
* twinkie: build a combined firmwareVincent Palatin2015-01-087-10/+85
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Build a Twinkie firmware image with the regular Twinkie sniffer firmware in the RO partition and a firmware behaving as a USB PD sink in the RW partition. The user can call the "twinkie sink" command to switch the USB PD sink firmware in the RW partition (and call "reboot" if he changes his mind and wants the sniffer back). Restore the ability of building different tasklists which was broken where the tests build was simplified. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=none TEST=make buildall ./board/twinkie/build_rw_variant Try "twinkie sink" command on a Twinkie with the combined firmware. Change-Id: Ie489ce97a774ae7a22ac639c49a3d6e412e62de8 Reviewed-on: https://chromium-review.googlesource.com/237221 Reviewed-by: Todd Broch <tbroch@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org> Trybot-Ready: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org>
* usb: fix sysjumpVincent Palatin2015-01-081-0/+2
| | | | | | | | | | | | | | | | | | | | Ensure that we can re-etablish a proper USB communication after a sysjump by properly disabling the USB stack before jumping. So the host sees a USB disconnection and can properly re-initialize the device when it re-appears. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=samus BUG=none TEST=On Twinkie, use the "sysjump RW" command on the USB console and see the prompt coming back after a few seconds. Change-Id: Iaf4498333eb4e7a1dda0f51ee8be19a0c9f10349 Reviewed-on: https://chromium-review.googlesource.com/239227 Reviewed-by: Anton Staaf <robotboy@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
* disable DMA before sysjumpingVincent Palatin2015-01-085-0/+35
| | | | | | | | | | | | | | | | | | | | | It's not safe to sysjump with a DMA enabled as it can led to memory corruption after we have landed in the new image before that piece of hardware is re-configured. Implement and call dma_disable_all() on all platforms with generic DMA. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=all BUG=chrome-os-partner:34865 TEST=on various boards, call "sysjump rw". Change-Id: I2a6b63ff19c2d932a5e31bc375bf468bc8ae5125 Reviewed-on: https://chromium-review.googlesource.com/237340 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
* twinkie: fix sink firmwareVincent Palatin2015-01-081-0/+6
| | | | | | | | | | | | | | | | | add a dummy pd_custom_vdm() function to be able to build again a Twinkie firmware in "PD sink" mode. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=none TEST=./board/twinkie/build_rw_variant Change-Id: Ib0f82ecd1197300cf7b36f0f43c6b1cd03203557 Reviewed-on: https://chromium-review.googlesource.com/239234 Reviewed-by: Alec Berg <alecaberg@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
* twinkie: turn on/off VCONN INAVincent Palatin2015-01-081-0/+12
| | | | | | | | | | | | | | | | | | | | the VCONN INA is off by default to avoid a leakage path on CC2. Turn it on when asking for a VCONN measurement ("twinkie vconn"), then off aftwerwards. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=none TEST=On the Twinkie command-line, "tw vconn" with the Twinkie interposed between a Samus and a DingDong. Change-Id: I8cd78b285512644af0824a44c735585b684fee66 Reviewed-on: https://chromium-review.googlesource.com/239212 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>
* charge_manager: fix initialization bug of best_port_powerAlec Berg2015-01-081-1/+1
| | | | | | | | | | | | | | Fix bug, local var best_port_power was uninitialized. BUG=none BRANCH=samus TEST=make -j buildall Change-Id: I15bcc52453e63dab8957625bf596dc2a7a0c4153 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/239423 Reviewed-by: Shawn N <shawnn@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* pd: Return immediately to host from erase RW.Todd Broch2015-01-083-16/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With CL: 5ef45ad pd: Add timeout for HC flash commands. I thought I'd licked the timeout related issues with flashing dingdong & hoho. With further testing however I found I was occassionally hitting the failure where I couldn't return from 'flash erase' on PD peripheral prior to the 1 second limit for host command timeout. That could be remedied by retrying the erase on the host side which then succeeds quickly. That solution seems non-optimal however. Additionally, even when erase does succeed in <1sec we have the shared i2c bus pending. That too is non-optimal. For those reasons I've decide to return immediately from flash erase command and instead put the burden of waiting the necessary time on the host which at least does have some wider perspective on what the system is attached to and doing. CL also adds following related changes: 1. corresponding ectool edit to delay 3sec after RW erase. 2. fixup to error returns from hc_remote_flash for timeouts. Signed-off-by: Todd Broch <tbroch@chromium.org> BRANCH=samus BUG=chrome-os-partner:33947 TEST=flashing dingdong/hoho via ectool works reliably. Change-Id: I8fbfb592f760273b26bcb16b67210d569454eee2 Reviewed-on: https://chromium-review.googlesource.com/239253 Trybot-Ready: Todd Broch <tbroch@chromium.org> Tested-by: Todd Broch <tbroch@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org> Commit-Queue: Todd Broch <tbroch@chromium.org>
* pd: Refactor exit mode.Todd Broch2015-01-083-24/+33
| | | | | | | | | | | | | | | | | | | Refactor pd_exit_mode to be only a DFP function. Additionally make pe_init a public function and call it during hard reset. Signed-off-by: Todd Broch <tbroch@chromium.org> BRANCH=samus BUG=chrome-os-partner:33946 TEST=manual, using pdsetmode from later patches see proper exit and resetting of pe struct. Change-Id: I45afe1f82926f1c32f4d84eb60c65f1f39b19d81 Reviewed-on: https://chromium-review.googlesource.com/236958 Reviewed-by: Alec Berg <alecaberg@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Commit-Queue: Todd Broch <tbroch@chromium.org> Tested-by: Todd Broch <tbroch@chromium.org>
* charge_manager: Prefer current active port in best port selectionShawn Nematbakhsh2015-01-082-5/+39
| | | | | | | | | | | | | | | | If two identical suppliers are capable of supplying equal power, select the port which is currently active. BUG=chrome-os-partner:34912 TEST=Manual on Samus. Plug Zinger into right port, verify that it becomes active. Plug a new Zinger into left port, verify that the right port stays active. BRANCH=Samus Change-Id: Ib1baf4bd3f619169f0e31ec509a2fe7dbd8c897e Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/238766 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* pd: remove clearing of type-c current limit in hard resetAlec Berg2015-01-081-1/+0
| | | | | | | | | | | | | | | | | | Remove clearing of the type-C pull-up supplier current limit on hard reset. Hard reset is a PD command and should clear the PD supplier current limit, but the type-C pull-up is independent and is still connected, so should not reset. BUG=none BRANCH=samus TEST=load on samus and plug in donette. without this CL, the charging icon flashes off then on. with this CL, it doesn't flash and still draws 3A. Change-Id: I90f87f3970754ca3618d87466412c97acc0a4d6f Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/239269 Reviewed-by: Shawn N <shawnn@chromium.org>
* samus: Fix flaw in power up inhibitShawn Nematbakhsh2015-01-081-7/+9
| | | | | | | | | | | | | | | | | | | | | | | Power up inhibit is intended to stop the AP from booting when the battery is in certain states. It works most of the time, but sometimes IN_PCH_SLP_S5_DEASSERTED is already set by the time we get to S5 and we incorrectly boot the AP. Thinking about this more, it's better to check the battery state in G3, before we transition to S5, to prevent the needless transition back to G3 if power up is indeed inhibited. BUG=chrome-os-partner:35182 TEST=Manual on Samus. Drain battery to 1% and attach charger. Press power button multiple times and verify that AP doesn't boot. Charge better to 2% and press power button. Verify that AP boots. BRANCH=Samus Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Change-Id: Ib03c3f707f9d90d0a9cb07ada3738d00e2728c32 Reviewed-on: https://chromium-review.googlesource.com/239352 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org>
* samus: pd: reject power swap if not in dual-role modeAlec Berg2015-01-081-2/+6
| | | | | | | | | | | | | | | Samus should reject request for a power swap if it is not in a dual-role mode, for instance if in S3 or lower. BUG=chrome-os-partner:35141 BRANCH=samus TEST=load on two samus'. turn on samus off, then request a power swap from the samus that is on and see that it is rejected. Change-Id: Ifb23febac967c981251c3932856e1e942818694f Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/238963 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* pd: dingdong/hoho: Enable flash write-protectionVincent Palatin2015-01-086-13/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These USB type-C accessories don't have a write-protect GPIO. Add a configure flag (CONFIG_WP_ALWAYS) to force the flash write-protection on the dongles. Also set the read protection (by elevating RDP to level 1), so trying to unprotect the flash will trigger a full erase. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=samus BUG=chrome-os-partner:35088 TEST=boot Hoho, check the flash OBR and WRPR registers: "rw 0x4002201c" / "rw 0x40022020" and the option bytes write-protect bits: "rw 0x1FFFF808" dump the logical state with "flashinfo" command. > rw 0x4002201c read 0x40022020 = 0xffff0002 > rw 0x40022020 read 0x40022020 = 0xffff0000 > rw 0x1FFFF808 read 0x1ffff808 = 0xff00ff00 > flashinfo Physical: 128 KB Usable: 128 KB Write: 2 B (ideal 2 B) Erase: 2048 B (to 1-bits) Protect: 4096 B Flags: wp_gpio_asserted ro_at_boot ro_now Protected now: YYYYYYYY YYYYYYYY ........ ........ Change-Id: I45bbc0bce40ecc174b6b8a1ebacf4f53d2fd372d Reviewed-on: https://chromium-review.googlesource.com/238893 Trybot-Ready: Vincent Palatin <vpalatin@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Todd Broch <tbroch@chromium.org> Tested-by: Todd Broch <tbroch@chromium.org>
* Queue: Add methods that accept a memcpy routineAnton Staaf2015-01-084-13/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | These versions of the queue add and remove methods support using memcpy like routines to access regions of memory with specific requirements. In particular, this will allow for transfers between queues and USB packet RAM on the STM32 which has specific access requirements. This change also includes an update to the mem* util routines to make their prototypes compatible with C89 and POSIX standards. Signed-off-by: Anton Staaf <robotboy@chromium.org> BRANCH=None BUG=None TEST=make buildall -j Test USB Echo functionality on discovery-stm32f072 board to ensure that queues still function correctly. Change-Id: I557064d99abfc3e8cfc98099a1d94334a976550c Reviewed-on: https://chromium-review.googlesource.com/239217 Tested-by: Anton Staaf <robotboy@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Anton Staaf <robotboy@chromium.org> Trybot-Ready: Anton Staaf <robotboy@chromium.org>
* USB: Add memcpy_from_usbram and update existing memcpyAnton Staaf2015-01-084-16/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | Previously there was just a memcpy_usbram that copied to USB packet memory, and no routine to copy out. This adds the "from" version and renames and improves to "to" version. The improvement is that the new "to" version correctly handles unaligned beginning and endings of the region to be copied. These need to be read/modify/write accesses since the USB packet ram has to be manipulated in 16-bit chunks. Signed-off-by: Anton Staaf <robotboy@chromium.org> BRANCH=None BUG=None TEST=make buildall -j Verify that discovery-stm32f072 still enumerates and communicates correctly over USB. Change-Id: I94353e66ad0248d4e674abb29f9a88e979767655 Reviewed-on: https://chromium-review.googlesource.com/238764 Tested-by: Anton Staaf <robotboy@chromium.org> Reviewed-by: Vic Yang <victoryang@chromium.org> Commit-Queue: Anton Staaf <robotboy@chromium.org> Trybot-Ready: Anton Staaf <robotboy@chromium.org>
* lm4: Increase time to wake up from deep sleepShawn Nematbakhsh2015-01-081-2/+2
| | | | | | | | | | | | | | | | | | The recent change to decrease the time to wake up from deep sleep when not using LFIOSC was too agressive. Increase the time to wake up based upon the worst observed case. BUG=chrome-os-partner:35184 TEST=Manual on Samus. Go to deep sleep, verify that no "overslept by Xus" prints are seen. BRANCH=Samus Change-Id: Ib9fe2eba5e29a112e03fffaedbc5ae53d6d650ff Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/239242 Reviewed-by: Alec Berg <alecaberg@chromium.org> Commit-Queue: Alec Berg <alecaberg@chromium.org> Tested-by: Alec Berg <alecaberg@chromium.org>
* ryu: Re-enable low power idleVic Yang2015-01-081-0/+1
| | | | | | | | | | | | | | | | | Now that the problem with sysjump while the AP is running is fixed, let's re-enable low power idle. BRANCH=Ryu BUG=chrome-os-partner:34230 TEST=None Change-Id: I9b01330720f5cdd70741285cb4ab19699fbeb494 Signed-off-by: Vic Yang <victoryang@google.com> Reviewed-on: https://chromium-review.googlesource.com/238919 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org> Tested-by: Vic Yang <victoryang@chromium.org> Commit-Queue: Vic Yang <victoryang@chromium.org>
* tegra: Preserve sleep mask on sysjumpVic Yang2015-01-081-2/+5
| | | | | | | | | | | | | | | | | | | If we sysjump while the AP is running, the AP_RUN sleep mask should be preserved. Otherwise, the EC goes into low power idle while the AP is still up. BRANCH=Ryu BUG=chrome-os-partner:34230 TEST=Without this change, bit 0 becomes 0 after a sysjump. With this, it doesn't. Change-Id: I55cecff3275402f7974c6078a9c203bafce2a2f9 Signed-off-by: Vic Yang <victoryang@google.com> Reviewed-on: https://chromium-review.googlesource.com/238918 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org> Tested-by: Vic Yang <victoryang@chromium.org> Commit-Queue: Vic Yang <victoryang@chromium.org>
* nyan: Disable console command helpVic Yang2015-01-081-0/+1
| | | | | | | | | | | | | | | | | We're close to running out of flash space for Nyan. Disable console command help to free up some space. BRANCH=None (unless flash space is also running out on branchs) BUG=None TEST=Build and doesn't see error when linking. Change-Id: I24c9869f94a7c4741c1c88df795a1333562cbe9d Signed-off-by: Vic Yang <victoryang@google.com> Reviewed-on: https://chromium-review.googlesource.com/239235 Tested-by: Vic Yang <victoryang@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Vic Yang <victoryang@chromium.org>
* USB: Delete mass storage driverAnton Staaf2015-01-088-1299/+0
| | | | | | | | | | | | | | | | | | | | | | | This was an attempt at providing support for flashing a SPI flash device over USB, but it suffered from being rather complex and large. A simpler solution of bridging SPI over USB directly and writing a SPI over USB driver for flashrom is being used instead. Signed-off-by: Anton Staaf <robotboy@chromium.org> BRANCH=None BUG=None TEST=make buildall -j Change-Id: I0d1ef8f17f5d6a4de46003096a8bff4a33b41cb7 Reviewed-on: https://chromium-review.googlesource.com/238763 Tested-by: Anton Staaf <robotboy@chromium.org> Reviewed-by: David Schneider <dnschneid@chromium.org> Reviewed-by: Vic Yang <victoryang@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Commit-Queue: Anton Staaf <robotboy@chromium.org> Trybot-Ready: Anton Staaf <robotboy@chromium.org>
* Read ADC channels one by one for STM32FVic Yang2015-01-071-1/+15
| | | | | | | | | | | | | | | Currently, we are seeing problem with adc_read_all_channels() for STM32F, and thus 'adc' console command reports incorrect values. Before that's fixed, read ADC channels one by one to work around this problem. BRANCH=Ryu BUG=chrome-os-partner:33971 TEST='adc' on Ryu Signed-off-by: Vic Yang <victoryang@chromium.org> Change-Id: Iae92b82b24f6a843b9d46a8804da1e51d33ed7cb Reviewed-on: https://chromium-review.googlesource.com/231125 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* OutStream: Remove unused prototypesAnton Staaf2015-01-071-3/+0
| | | | | | | | | | | | | | | | | | | These prototypes are for functions that didn't make the final cut and should have been removed before this header was committed. Signed-off-by: Anton Staaf <robotboy@chromium.org> BRANCH=None BUG=None TEST=make buildall -j Change-Id: I46726d20c25898681890caa95ad71500272fb7f6 Reviewed-on: https://chromium-review.googlesource.com/238753 Tested-by: Anton Staaf <robotboy@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Anton Staaf <robotboy@chromium.org> Trybot-Ready: Anton Staaf <robotboy@chromium.org>
* pd: fix bug when forcing port to sinkAlec Berg2015-01-072-4/+19
| | | | | | | | | | | | | | When changing a port that is sourcing power to a force sink role, then make sure VBUS is turned off before going to SNK_DISCONNECTED. BUG=chrome-os-partner:34036 BRANCH=samus TEST=test on plankton with samus. verify can change from source to sink multiple times with no problems Change-Id: I781f6f4395845f949d00b322e4e87c150aeba187 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/233755
* pd: Show literal PD state name for 'ectool usbpd'Vic Yang2015-01-073-32/+64
| | | | | | | | | | | | | | | | | | | Currently, 'ectool usbpd' shows PD task state in numerical format. Every time we add/remove a state, the number changes, and this makes the command difficult to use. Modify the command to print the name of the PD task state. BRANCH=Samus,Ryu BUG=chrome-os-partner:34296 TEST=Run 'ectool usbpd 0' with different combination of new/old PD firmware and new/old ectool. Change-Id: Ic0daa03e9f7565c1322166713c2cce3b7cb93a30 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/237623 Reviewed-by: Alec Berg <alecaberg@chromium.org> Commit-Queue: Alec Berg <alecaberg@chromium.org> Tested-by: Alec Berg <alecaberg@chromium.org>
* charge_manager: Bug fixes for power_info host commandsShawn Nematbakhsh2015-01-072-3/+3
| | | | | | | | | | | | | | | | | | - Correctly identify certain source ports (ex. c-plug to empty a-receptacle) - Correct ectool power unit print (mV * mA != mW). BUG=chrome-os-partner:33248 TEST=Manual on Samus. Connect c-plug to empty a-receptacle, run "ectool --name usbpdpower", verify that port power role is identified as source. Also, verify that 5000 mV @ 500mA port correctly prints 2500mW total power. BRANCH=Samus Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Change-Id: Icf0850afc570a1056578df9f1a647079a00229b3 Reviewed-on: https://chromium-review.googlesource.com/238235 Reviewed-by: Alec Berg <alecaberg@chromium.org> Commit-Queue: Alec Berg <alecaberg@chromium.org>
* pd: Bugfix for pending VDM in disconnected state.Todd Broch2015-01-071-9/+7
| | | | | | | | | | | | | | | | | | | | | Commit f993fe3c refactored pd_vdm_send_state_machine to allow well timed PD disconnects to be acceptable. This violates specification as VDMs certainly shouldn't proceed without an explicit contract and mode entry. CL reverts the logic to make 'ready' VDM in shadow of disconnect an error. Signed-off-by: Todd Broch <tbroch@chromium.org> BRANCH=samus BUG=chrome-os-partner:33947 TEST=manual, compiles when disconnect occurs 'ready' VDM transistions to vdm_state VDM_STATE_ERR_BUSY instead of staying 'ready' Change-Id: Ic8e96506df365a72053713a806356c4afcfde26d Reviewed-on: https://chromium-review.googlesource.com/238292 Reviewed-by: Alec Berg <alecaberg@chromium.org> Tested-by: Todd Broch <tbroch@chromium.org> Commit-Queue: Todd Broch <tbroch@chromium.org>
* pd: Add timeout for HC flash commands.Todd Broch2015-01-073-17/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For flash commands add timeout so if VDM doesn't return properly host can receive error message. Note, for flash erase its performed by page at a cost of 20-40ms according to datasheet. For hoho/dingdong that leaves maximum erase time at 40ms * 32 =< 1280ms which is above the host command timeout. Increasing the host command delay (i2c bus pending) is not an option and since the erase will complete and subsequent erases will be much faster do to early out in physical_flash_erase this solution should be acceptable. Future CLs could alternatively push the burden of command latency to host altogether and return EC_RES_SUCCESS in similar fashion to reboot command. Signed-off-by: Todd Broch <tbroch@chromium.org> BRANCH=samus BUG=chrome-os-partner:33947 TEST=manual, if VDM doesn't return by timeout HC command is properly returned EC_RES_TIMEOUT error code. Change-Id: I33c515200c2999dd97fdd690a7e900c5548b2d47 Reviewed-on: https://chromium-review.googlesource.com/238290 Reviewed-by: Alec Berg <alecaberg@chromium.org> Tested-by: Todd Broch <tbroch@chromium.org> Commit-Queue: Todd Broch <tbroch@chromium.org>
* pd: vdm: Add VDM related timeouts and busy response handling.Todd Broch2015-01-073-5/+63
| | | | | | | | | | | | | | | | | | | | | | Initial VDM implementation had a very conservative 500msec timeout period. This CL adds the timeouts defined in the USB-PD specification for various commands. Additionally it adds a state to the vdm state machine to allow proper busy response handling. Signed-off-by: Todd Broch <tbroch@chromium.org> BRANCH=samus BUG=chrome-os-partner:30645 TEST=manual, Alternate mode and flashing still work. Creating a VDM responder which returns busy shows retries from initiator after at least 100msec. Change-Id: I79f5da557ca9faf63d2299bb77009f6d98a782bd Reviewed-on: https://chromium-review.googlesource.com/235682 Reviewed-by: Alec Berg <alecaberg@chromium.org> Tested-by: Todd Broch <tbroch@chromium.org> Commit-Queue: Todd Broch <tbroch@chromium.org>
* Stop building ryu_p1 board.Todd Broch2015-01-071-1/+1
| | | | | | | | | | | | | | Signed-off-by: Todd Broch <tbroch@chromium.org> BRANCH=none BUG=chrome-os-partner:35138 TEST='make buildall' no longer builds ryu_p1 Change-Id: I53b5b9a1967ac53faabbe2ee8268328d7a5c3ae7 Reviewed-on: https://chromium-review.googlesource.com/238810 Reviewed-by: Vic Yang <victoryang@chromium.org> Tested-by: Todd Broch <tbroch@chromium.org> Commit-Queue: Todd Broch <tbroch@chromium.org>
* pd: ryu_p1: Remove console 'typec' command.Todd Broch2015-01-071-0/+1
| | | | | | | | | | | | | | | BRANCH=none BUG=none TEST=builds, get ~500 bytes of flash back. Signed-off-by: Todd Broch <tbroch@chromium.org> Change-Id: I031a858e2c497927680e8b897c2582ac4d1bf21b Reviewed-on: https://chromium-review.googlesource.com/238772 Reviewed-by: Alec Berg <alecaberg@chromium.org> Tested-by: Todd Broch <tbroch@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Vic Yang <victoryang@chromium.org> Commit-Queue: Todd Broch <tbroch@chromium.org>
* pd: add flags to pd state console commandAlec Berg2015-01-071-7/+2
| | | | | | | | | | | | | Add PD flags to pd <port> state console command BUG=none BRANCH=samus TEST=load on samus and call pd <port> state. Change-Id: I490c7c5ae942a0f4e3f64c24e22ef3470edec641 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/238962 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* samus: change power supply transition delay to 80msAlec Berg2015-01-071-2/+6
| | | | | | | | | | | | | | | Change samus power supply transition delay for Raiden ports to 80ms since it may take that long to turn off the power supply when doing a power swap. BUG=chrome-os-partner:34525 BRANCH=samus TEST=load onto samus, connect samus to samus and do a power swap. Change-Id: I20c2cb78f17168a5b69780de4af5ff478f6d5f87 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/238961 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* samus: add hot keys alt+voldown+0|1|2 to set charging portstabilize-6662.BAlec Berg2015-01-072-0/+57
| | | | | | | | | | | | | | | | | | | | Add hot key detection for alt + volume down + 0|1|2 to set the charging port by sending the charge override command to PD MCU. This should be removed once hot-keys (or some other UI) is added to higher layers. BUG=chrome-os-partner:34850 BRANCH=samus TEST=load onto samus and connect to another samus. use hot keys and see that charge override command gets set appropriately on PD MCU. Change-Id: I7e72d597a02b7aca3326911796d20003f6697077 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/238226 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* samus: pd: on PD connection, if sink, ask for power swapAlec Berg2015-01-0713-62/+134
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For samus, on PD connection or on resume to S0, if we are a sink, and the other side supports PR_SWAP, then attempt a power swap. This adds callback functions into board policy file to check and issue power or data swaps if required by the product. BUG=chrome-os-partner:31195 BRANCH=samus TEST=connect samus to zinger and make sure zinger always ends up as SRC-UFP. connect samus to samus with both in S0 and see that they swap power roles once and not data roles. connect one samus in S0 to one samus in S5 and see that the one in S5 is sink. then when you boot the one in S5 it switches to a source. connect samus to samus with both in S0. do chgoverride 1 on one side to start charging from the other samus. then on the same side, turn off the machine (S5) and resume (S0), and see that it is still charging from the other samus (ie has not switched roles to source). Change-Id: Ifab2465fccef77448ac4771a3c2de1c867cbbec4 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/238302 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* pd: fix timeouts during power swap and send soft reset on no CRCAlec Berg2015-01-061-19/+60
| | | | | | | | | | | | | | | | | | Change behavior on timeouts during a power swap. If a power swap fails in the final stages, go to disconnected state instead of simply sending a hard reset. When we fail to receive goodCRC to power swap or data swap commands, send a soft reset instead of a hard reset. BUG=chrome-os-partner:34989, chrome-os-partner:34980 BRANCH=samus TEST=make -j buildall Change-Id: I3fa9f1475e42c2754fb7eb15a75bc0b67ed1e2c0 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/238301 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* pd: Add NoResponseTimer to disconnect after no responseAlec Berg2015-01-062-17/+49
| | | | | | | | | | | | | | | | | | | | | | Add NoResponseTimer to go to disconnected state after some number of hard resets with the port partner non-responsive. This only takes affect when the port partner is known to be PD capable, i.e. has sent us PD communications in the past. This is useful as a last resort to attempt to restore PD communications with a port partner. BUG=chrome-os-partner:34976 BRANCH=samus TEST=load onto two samus', connect with C to C cable, and let them form a PD contract, then on one side disable PD comms with "pd enable 0" and from the other side initiate some PD traffic, such as "pd 1 soft". See that the side with PD communications enabled sends two hard resets and then goes to disconnected state, then goes to discovery state and acts as if a non-PD capable device is attached. Change-Id: Id40ce7eb05b8b7ae6a4f70b9d08ce6cad0d471fe Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/238300 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
View Lorry Controller Status