summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* ec_uartd: bugfix for buffer pointer on partial write to FD.stabilize-swanky-5841.55.Bstabilize-gnawty-5841.84.Bstabilize-5841.83.Bstabilize-5841.76.Brelease-R36-5841.BTodd Broch2014-05-091-1/+13
| | | | | | | | | | | | | | | | | | | | | Previously I neglected to increment the buffer pointer which would allow double writing of same data and exclude tail if write didn't complete in one call. Also fixing bug with EAGAIN/EWOULDBLOCK to retry in those cases. Previously we'd just have just failed for those errno values. Signed-off-by: Todd Broch <tbroch@chromium.org> BRANCH=none BUG=chromium:371147 TEST=still compiles Change-Id: I30dbe56b2a4c735c487464349786a9db430130a8 Reviewed-on: https://chromium-review.googlesource.com/199052 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Commit-Queue: Todd Broch <tbroch@chromium.org> Tested-by: Todd Broch <tbroch@chromium.org>
* tegra: don't set auto_power_on if SYSJUMPLouis Yung-Chieh Lo2014-05-091-2/+4
| | | | | | | | | | | | | | | | | | | The auto_power_on is set 1 unexpectedly while EC jumps. This has a side effect that would turn on the AP unexpectedly after "power off". See comment 43 of issue 28249 BUG=chrome-os-partner:28249 BRANCH=tot,nyan TEST=on nyan: > reboot > sysinfo // If EC is in RO, "sysjump RW" > power off // The AP keeps off. Change-Id: I3c06e99383c06af7cd6c17dd65040e20f06d8e73 Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/198941
* tegra: waits for battery stable before booting AP.Louis Yung-Chieh Lo2014-05-091-0/+7
| | | | | | | | | | | | | | | | | This is a follow-up for CL 197990 and 197991. See issue tracker for more details. BUG=chrome-os-partner:28289 BRANCH=tot,nyan TEST=Copy from https://chromium-review.googlesource.com/#/c/197990 Going battery shipmode and plug-in AC, See booting and expect EC log: "[... battery initialized]" Disconnect battery, and plug-in and see booting and expect EC log: "[... battery not responding]" Change-Id: Ic218414c21057a971b478ec60e406f1eb69dd379 Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/198412
* tegra: reorder the "AP running" and "XPSHOLD seen".Louis Yung-Chieh Lo2014-05-091-1/+2
| | | | | | | | | | | | | FAFT expects the "AP running" shows first, then "XPSHOLD seen". BUG=chrome-os-partner:28316 BRANCH=tot,nyan TEST=build only Change-Id: Ic3e9d68b7727d62d3ccc2c037e7547f0276c2eae Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/198766 Reviewed-by: David Hendricks <dhendrix@chromium.org>
* tegra: fixed a corner case that AP_OFF flag is not cleared.Louis Yung-Chieh Lo2014-05-091-3/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | If we follow the TEST steps below, the power state machine in AP and EC were out of sync -- due to the un-clear bit and wrong initial power state. BUG=chrome-os-partner:24835 BRANCH=tot,nyan TEST=on big. > reboot > power off // De-assert XPSHOLD > reboot ap-off > sysinfo // This reset flags does NOT contain "ap-off". > power on % ectool reboot_ec RW // The following message is NOT observed. // "system is on, but RESET_FLAG_AP_OFF is on". > power // This should show the AP is "on". // ensure everything still works. > reboot ap-off // AP keeps off. > reboot // AP is on. Change-Id: I51afed7201d16ebcd889ad12a7af90026591cc2d Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/198587 Reviewed-by: David Hendricks <dhendrix@chromium.org>
* stm32: Re-enable spi transfers after a sysjumpRandall Spangler2014-05-091-20/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | If we sysjump to EC-RW, that sets enabled=0. enabled is only set back to 1 when the chipset resumes. But on an AP-requested sysjump, the chipset is already on, and so the resume hook never gets called. So, in spi init, check if the AP is already on. If it is, enable spi transfers right away. This probably also affects Pit/Pi. That may need an additional fix in power/gaia.c, if it returns an incorrect chipset state after a sysjump (I didn't test that.) BUG=chrome-os-partner:28249 BRANCH=nyan,pit TEST=Power+Refresh boot system with RONormal disabled, so that the AP tells the EC to jump to EC-RW. Confirm EC communication still works after that. Change-Id: I588ef6d841040cf05d5527f645f122d5708b16ad Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/198869 Reviewed-by: Yung-chieh Lo <yjlou@chromium.org> Reviewed-by: David Hendricks <dhendrix@chromium.org> Commit-Queue: Yung-chieh Lo <yjlou@chromium.org> Tested-by: Yung-chieh Lo <yjlou@chromium.org> Tested-by: Gabe Black <gabeblack@chromium.org>
* tegra: fix bug that apshutdown cannot shut down the AP.Louis Yung-Chieh Lo2014-05-091-3/+16
| | | | | | | | | | | | | | | | | | | | The power_request variable is not clear in apshutdown case. Thus, the AP comes up again by the "power up" request. Clear this variable only when apshutdown command to avoid affecting the regular power states. BUG=chrome-os-partner:28621 BRANCH=tot,nyan TEST=see below > reboot // or other methods to turn on the AP. > power on > apshutdown // The AP should remain off. Change-Id: Icfc8a50db95aba656168f5b10dabd9443d75338d Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/198770 Reviewed-by: David Hendricks <dhendrix@chromium.org>
* Wait for battery boot-upWonjoon Lee2014-05-081-0/+2
| | | | | | | | | | | | | | | | | | | Some battery uses clock stretching feature, and this could disturb PMU communication before battery going stable. AP does not know and will attempt PMU setting, and could get fail For various battery indicates usually 1s for stable (even if it is much less in real world 200ms~700ms) Let's checking 'battery is ready' when first pump-up power. BUG=chrome-os-partner:28289 TEST=Going battery shipmode and plug-in AC, See booting and EC log Disconnect battery, and plug-in and see booting and EC log Change-Id: I9b62266132d5322366265afe03adbe0db1f9ae75 Signed-off-by: Wonjoon Lee <woojoo.lee@samsung.com> Reviewed-on: https://chromium-review.googlesource.com/197991 Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Doug Anderson <dianders@chromium.org>
* Adding waiting function when battery boot-upWonjoon Lee2014-05-072-0/+49
| | | | | | | | | | | | | | | | | | | | | Some battery uses clock stretching feature, and this could disturb PMU communication before battery going stable. AP does not know and will attempt PMU setting, and could get fail For various battery indicates usually 1s for stable (even if it is much less in real world 200ms~700ms) Let's checking 'battery is ready' when first pump-up power. BRANCH=ToT BUG=chrome-os-partner:28289 TEST=Going battery shipmode and plug-in AC, See booting and EC log Disconnect battery, and plug-in and see booting and EC log Change-Id: Idd8ae2ab4ec164b11fe67413bbf647cad18bc481 Signed-off-by: Wonjoon Lee <woojoo.lee@samsung.com> Reviewed-on: https://chromium-review.googlesource.com/197990 Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Doug Anderson <dianders@chromium.org> Tested-by: Doug Anderson <dianders@chromium.org>
* CHROMIUM: ec: Add Port 80 history access from ectoolsWenkai Du2014-05-073-2/+170
| | | | | | | | | | | | | | | | | | | | | | While debugging reboot issue, it was difficult to get POST code from failing boards. Currently POST code is only accessible from EC console. Not all boards are fitted with servo board. This patch adds Port 80 history access from ectool. Reuse command code 0x48, EC_CMD_PORT80_LAST_BOOT with version 1. Signed-off-by: Wenkai Du <wenkai.du@intel.com> BUG=chrome-os-partner:28514 BRANCH=rambi TEST=manually test on rambi to confirm port 80 history match EC console Change-Id: If204d8fb457d8d8d18055f8282a406a35c03305e Reviewed-on: https://chromium-review.googlesource.com/198012 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Wenkai Du <wenkai.du@intel.com> Commit-Queue: Wenkai Du <wenkai.du@intel.com> Tested-by: Wenkai Du <wenkai.du@intel.com>
* cleanup: add square brackets to make test parser easierLouis Yung-Chieh Lo2014-05-0715-41/+46
| | | | | | | | | | | | | | | | This may not contain all. I filtered out possible code by the following command: find . -name "*.h*" -o -name "*.c*" | xargs grep -n CPRINTF | \ grep -v "\[" | grep -v define | less BUG=none BRANCH=none TEST=make buildall tuntests Change-Id: I674f84f5966b34aeb8d4321d22629b450627a120 Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/197997
* zinger: invert output controlVincent Palatin2014-05-072-9/+9
| | | | | | | | | | | | | | | | | | | | The electrical design has changed : the output enable GPIO (PF0) has switched from being the LM5050 shutdown pin to controlling directly the FET enabling. We need to invert the control logic and use it in push-pull mode rather than open-drain. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=chrome-os-partner:28332 TEST=plug a reworked Zinger to a firefly and check the firefly LED is displaying a solid ON (meaning the voltage is right). Change-Id: Iee79b07f49eade1fee7cac1986bc38ba21e04b25 Reviewed-on: https://chromium-review.googlesource.com/198240 Reviewed-by: Alec Berg <alecaberg@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org>
* fruitpie: handle dead batteryVincent Palatin2014-05-073-4/+4
| | | | | | | | | | | | | | | | | | | | ensure that the board will get power from VBUS by default, so it can start-up if it's own battery is fully drained. Also increase the console stack as the battery code footprint is growing over time. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=chrome-os-partner:28311 TEST=plug a Fruitpie without battery to a Zinger. Change-Id: I971040da9bedb7bf46363787a13220c39a78100d Reviewed-on: https://chromium-review.googlesource.com/198557 Reviewed-by: Alec Berg <alecaberg@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org>
* i2c: stm32l: Increase timeout from 10ms to 30msstabilize-5828.0.BDoug Anderson2014-05-062-2/+10
| | | | | | | | | | | | | | | | | We found some cases where the battery can flip out and get confused and hold the i2c lines. Since the battery is actually smbus it will give up after 25ms. Increase our timeout to 30ms so that the next trasaction will work OK. BRANCH=ToT BUG=chrome-os-partner:28425 TEST=Revert (1cd618e Wait for battery boot-up) and use a problematic battery; see boot works OK. Change-Id: Ife051220cbbbd49d7bc9c8607ba177cd9582fe58 Signed-off-by: Doug Anderson <dianders@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/198212 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* nyan: fix the power in_signals out of sync bug.Louis Yung-Chieh Lo2014-05-061-0/+6
| | | | | | | | | | | | | | | | | | | | See issue tracker for details. BUG=chrome-os-partner:28518 BRANCH=tot,nyan TEST=on big % reboot ap-off % powerbtn [6.100943 power on 4] Was power on 1 before fix. % reboot [0.098134 power on 2] Was power on 1 before fix. Change-Id: I7b2fd95234d16467edca041b1c12d63ca4b5112b Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/198070 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* zinger: implement fault protectionVincent Palatin2014-05-055-12/+120
| | | | | | | | | | | | | | | | | | | | | | Detect over-current and over-voltage and trigger a fault. The over-current threshold is 10% over 3A (3.3A). Only currently implement the slow protection, the fast interrupt-based one will be done later. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=chrome-os-partner:28331 TEST=with Zinger connected to an electronic load, adjust the current to 3.35A and see the output voltage cut. Change-Id: I0e848192392fd73f0839d4bcb806528b2a6b9122 Reviewed-on: https://chromium-review.googlesource.com/197947 Commit-Queue: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org>
* tegra: keeps AP in off state for "reboot ap-off"Louis Yung-Chieh Lo2014-05-031-3/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | XPSHOLD is not always removed after chipset_force_shutdown(). This is different to the GAIA design. So, check the RESET_FLAG_AP_OFF flag again while check_for_power_on_event(). BUG=chrome-os-partner:28371 BRANCH=tot,nyan TEST=verify on big. re-flash ec: power on 2, AP is up. AP is on, reboot@EC: power on 1, AP is up. AP is off, reboot@EC: power on 2, AP is up. AP is on, reboot ap-off@EC: AP keeps off (see FLAG_AP_OFF flag) AP is off, reboot ap-off@EC: AP keeps off (see FLAG_AP_OFF flag) reboot ap-off@EC, then 'powerbtn': AP is off at boot, then power on 4 reboot@EC: power on 2, AP is up. re-plug AC (remove battery): power on 2 re-plug battery (without AC): power on 2 (but my battery is dead) power off (S5), power on: power off 4, power on 5 power off (G3), power on: power off 4, power on 5 lid close / power off (S5)/ lid open: power on 3 lid close / power off (G3)/ lid open: power on 3 press power button and release: nothing happens after 15s. AP keeps in S5. button off (S5)/ on: power off 3, power on 4 button off (G3)/ on: power off 3, power on 4 power off (S5)/ button on: power off 4, power on 4 power off (G3)/ button on: power off 4, power on 4 button off (S5)/ power on: power off 3, power on 5 button off (G3)/ power on: power off 3, power on 4 button off (S5)/ lid open: power off 3, power on 3 button off (G3)/ lid open: power off 3, power on 3 is off, long press button (60s): power on 4, too long, shutdown, stay off is on, long press button (60s): power off 3, stay off AP is on, apreset cold: entered to S5, power off 3, power on 5 AP is on, apreset warm: power state is not changed, but reboots to BIOS Change-Id: I9ccd13ab4b5f38be1ad8d6c9a04724b56bc5b166 Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/197604 Reviewed-by: David Hendricks <dhendrix@chromium.org>
* blaze: remove from ToT.Louis Yung-Chieh Lo2014-05-037-735/+1
| | | | | | | | | | | | | | Since we already created the firmware-nyan-5771.B branch, we can remove this from ToT now. But for sure we are still able to cherry-pick changes back to ToT or from ToT. BUG=none BRANCH=tot TEST=make buildall Change-Id: I637d27b9f8672c5d17b60e210a5211ab8e19b54a Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/197165
* pd: more robust receptionVincent Palatin2014-05-023-5/+15
| | | | | | | | | | | | | | | | | | Ensure that we finish reception if and only if we started it whatever other events happened. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=chrome-os-partner:28332 TEST=Connect Zinger to Firefly, request higher voltage and ensure that Firefly was still getting the Pings after several hours. Change-Id: Ie99984aeb4c565be39d349457dbd2813203b3f5b Reviewed-on: https://chromium-review.googlesource.com/197946 Reviewed-by: Alec Berg <alecaberg@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org>
* pd: better sink transitionsVincent Palatin2014-05-021-13/+42
| | | | | | | | | | | | | | | | | | Ensure that the power sink as expected by the standard or times out if nothing happens. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=chrome-os-partner:28332 TEST=connect Firefly to Zinger and transition between voltages using Firefly buttons. Change-Id: I99e482982e4788a52bc2c1a57d672c3d71ff22e2 Reviewed-on: https://chromium-review.googlesource.com/197052 Reviewed-by: Alec Berg <alecaberg@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org>
* cortex-m0: fix hard-faults during software interrupt calls part 2Alec Berg2014-05-021-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is another patch to fix the bug which causes a HardFault exception at the "svc" instruction in __wait_evt(). The HardFault is due to a priority escalation problem in which "svc" is called when the PRIMASK is high, meaning interrupts are disabled. The issue was that an interrupt can occur just before the "svc" instruction, and when an interrupt fires that performs a context switch, the IRQ handler disables interrupts setting the PRIMASK reg high. The arm v6 reference manual specifies that "PRIMASK unchanged on exception exit". So, therefore, we must clear PRIMASK by running "cpsie" before exiting IRQ handler. BRANCH=none BUG=chrome-os-partner:28296 TEST= Reproduce the problem on a fruitpie by inserting dummy for loop in __wait_evt() before "svc" call: asm volatile("isb"); for (i = 0; i < 250; i++) ; __schedule(1, resched); Then, when running pd dev, the system gets the HardFault exception within a few minutes because there is more time for an interrupt to occur and disable interrupts right before call to "svc". After applying this patch, the code has run for > 3 hours without a HardFault. Change-Id: Ic50252b09c40c7d76975ff7f16d799c9eae2bde6 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/197839 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* test: build target test only when the full runtime is availableVincent Palatin2014-05-021-0/+2
| | | | | | | | | | | | | | | | | | | For targets not using the common runtime functions, the current test content does not make much sense and fails to build properly : de-activate the tests build in that case. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=chrome-os-partner:28480 TEST=USE=usbpd emerge-samus chromeos-ec Change-Id: Ic6477861b5a86916f29a9f6bb70ed0def3661886 Reviewed-on: https://chromium-review.googlesource.com/197883 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Vic Yang <victoryang@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org>
* Increase some task stack sizes to handle more FP regs.Bill Richardson2014-05-013-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With change b610695b61db3b3784e2a516c91f429139616100, we fixed a problem with the number of FP regs that were being saved on the stack. That change decreased the required stack size for non-FP tasks by 64 bytes, but increased the size needed for FP tasks (such as the lightbar). The lightbar task was previously using within 64 bytes of its alloted stack, so handling the task switching correctly meant that it now overflowed. The hooks task had the same problem, but was hidden by the lightbar task. This CL bumps the LARGER_TASK_STACK_SIZE up a bit, and switches the lightbar task to use it instead of the default size. BUG=chrome-os-partner:27971, chrome-os-partner:28407 BRANCH=ToT TEST=Try it on both Link and Samus. Before this change, the Samus lightbar was overflowing its stack every time the AP booted (causing the lightbar to do things). With this change, it doesn't. Here are typical stack sizes after this CL: Task Ready Name Events Time (s) StkUsed 0 R << idle >> 00000000 28.394913 328/512 1 HOOKS 00000000 0.534085 640/768 2 R LIGHTBAR 10000000 5.359356 520/768 3 CHARGER 00000000 0.094674 384/512 4 CHIPSET 00000000 0.003353 320/512 5 KEYPROTO 00000000 0.002814 312/512 6 HOSTCMD 00000000 0.002942 244/512 7 R CONSOLE 00000000 0.193776 340/768 8 POWERBTN 00000000 0.000392 248/512 9 KEYSCAN 00000000 0.409337 332/512 Change-Id: Ica93608c8adb225410a62ec3a0a27944c479270a Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/197733 Reviewed-by: Alec Berg <alecaberg@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Keyborg: Fix column orderingVic (Chun-Ju) Yang2014-04-301-10/+10
| | | | | | | | | | | | | | Column 0 is on the slave side. Fix this. BUG=None TEST=Press a finger at the center of the panel. See a single shape in touch data. BRANCH=None Change-Id: Ic3a9a4fafc6e7ee39a1c3422905cf3b1758f335a Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/197641 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* baytrail: Workaround for stuck boot processRandall Spangler2014-04-305-13/+116
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In some cases, the system will boot to S0 from the point of view of the EC, but PLTRST# will never deassert. Work around this by waiting 50 ms for PLTRST# to deassert. If it doesn't, force the chipset all the way down by deasserting RSMRST#, then pulse the power button to turn it back on. Also add a powerfail debug command to simulate this failure event, so that the recovery process can be tested. Add API to the LPC module to get the state of PLTRST#, and to the power button state machine to force it released when we shut down the chipset and and force another power button pulse as we reset the chipset. BUG=chrome-os-partner:28422 BRANCH=baytrail TEST=1. Boot system. Should boot normally. Shut system down. 2. powerfail 3. Boot system. On the EC console, should see the system come up, go back down through G3S5, then come back up. From the user's point of view, it just boots. 1. Boot system. Should boot normally. (That is, powerfail is not sticky) Change-Id: Ia57f196606f79b9f2fce7d9cd109ab932c3571aa Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/197523 Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* Keyborg: Disable SWD portsVic (Chun-Ju) Yang2014-04-302-4/+7
| | | | | | | | | | | | | | | | | Most of the time we don't need to use a debugger during runtime. Let's disable SWD ports so that we can use the two pins for touch scan. We can still re-flash the chips as long as we hold the reset pin when entering SWD mode. BUG=None TEST=Check we can still re-flash the chips BRANCH=None Change-Id: Ieb34406f4bc6d6a753ec840b3072f363c7b17c08 Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/197196 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* Keyborg: Refine master slave identificationVic (Chun-Ju) Yang2014-04-302-8/+29
| | | | | | | | | | | | | | | | | | | | The current identification method uses SPI_NSS as master/slave indication. However, if the other chip is not reset at the same time, it would drive SPI_NSS and fails the identification. Since the master chip is equipped with USB connection, we can identify the chips with USB pull up pin, which doesn't suffer from this problem. Also updates the comments on pin usage. BUG=None TEST=Reset the chips repeatedly. BRANCH=None Change-Id: Iccd7e73fca85abfa554f90dcb7e354cc4cc04626 Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/197194 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* Keyborg: implement matrix scanningVic (Chun-Ju) Yang2014-04-308-3/+479
| | | | | | | | | | | | | | This implements dual chip matrix scanning. Now the scan result is only dumped to debug output. BUG=None TEST=Put a finger on the panel and see its shape. BRANCH=None Change-Id: I015c901b42e24fe4a6249c12c37bc5bfcb308c9f Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/196468 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* stm32mon: fix STM32F03x flash sizeVincent Palatin2014-04-301-1/+1
| | | | | | | | | | | | | | | | | The current SKU has 32kB. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=none TEST=read-back the flash content from a Zinger power brick using "stm32mon -r". Change-Id: Id74e585f4b49b9ef5fecdec8182f3710eb0b4960 Reviewed-on: https://chromium-review.googlesource.com/196690 Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
* Add support for the Firefly boardVincent Palatin2014-04-307-1/+539
| | | | | | | | | | | | | | | | | | | Firefly is the test/burn-in board for Zinger production. It's acting a Power Delivery sink. The plug polarity is not managed correctly yet. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=none TEST=none Change-Id: I57f525ad04c519f2fa458635a1c6cc45a503e5ac Reviewed-on: https://chromium-review.googlesource.com/195586 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
* pd: handle plug polarityVincent Palatin2014-04-306-25/+54
| | | | | | | | | | | | | | | | | | | | Use the plug polarity detected by the ADCs to do the PD communication on the right CCx line. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=chrome-os-partner:28339 TEST=make buildall on Firefly, plug Zinger connector in both direction and see it can control it either way. on Fruitpie, use CC1 or CC2 and see it can communicate on both. Change-Id: I81cb00f164cb8194fba73b383014e81c37d975e2 Reviewed-on: https://chromium-review.googlesource.com/197520 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
* pd: update policy, timeout and board callbacksVincent Palatin2014-04-306-28/+49
| | | | | | | | | | | | | | | | | | | | | | | Slightly modify interfaces for better sink-only devices implementation (eg Firefly) update the host mode management and the voltage selection and add a hook for board checks. Simplify the reception timeout and fix other timeout detections. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=none TEST=make buildall and use with the follow-up firefly board configuration CL. Change-Id: I0240295764c8605793dc80a2fc21357af1740744 Reviewed-on: https://chromium-review.googlesource.com/195585 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
* Added v1 version of ectool gpioget supporting more functionsstabilize-5807.0.BMohammed Habibulla2014-04-293-20/+166
| | | | | | | | | | | | | | | | | ectool gpioget - returns all GPIOs (with flag info) ectool gpioget <GPIO_NAME> - get value of <GPIO_NAME> ectool gpioget count - returns number of GPIOs ectool gpioget all - returns all GPIOs (with flag info) BUG=chromium:344969 TEST="ectool gpioget [<subcmd> <GPIO_NAME>]" returns correct information on squawks BRANCH=none Change-Id: Ib6f0d8135a76501f08b084bfd7eb1f2689d5d6e0 Signed-off-by: Mohammed Habibulla <moch@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/196680 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* stm32: pd: add config option to use SPI master for USB PD trasmitAlec Berg2014-04-295-20/+99
| | | | | | | | | | | | | | | | | | | | | | | Added config option CONFIG_USB_PD_TX_USES_SPI_MASTER which switches to use SPI master for PD transmit. The advantage of SPI master mode is at the end of the tranmission, we don't have to send any dummy 0 bits. When the option is set, the CPU_CLOCK must be set to 38.4MHz, so that the SPI master can generate the correct clock frequency. BUG=chrome-os-partner:28309 BRANCH=none TEST=Tested by connecting two fruitpies together across CC1. One fruitpie has been modified such that the MISO and MOSI lines are swapped and is running PD TX in SPI master mode with 38.4MHz clock, while the other is running PD TX in SPI slave mode. On EC console ran pd charger on one board and pd dev on other board. Verified that communication works with no errors. Ran for 10 minutes in each configuration. Change-Id: Ib24030d34d95d59f4ac6c2dae98bf7adda1ada01 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/197215 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* Rename battery_vendor_params() to battery_override_params()Dave Parker2014-04-298-25/+28
| | | | | | | | | | | | | | | | | | | | Charger V1 only. This is a clearer name for the intent of the function to override the charging parameters requested by the battery. This also disabmiguates this function with a new host command to get and set arbitrary vendor parameters in the battery. BUG=chrome-os-partner:25145 BRANCH=ToT TEST=`make buildall -j`. Change-Id: I1e8762d359c0e91c5b2a539553d22c12c9850c03 Signed-off-by: Dave Parker <dparker@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/195823 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/197164 Reviewed-by: Yung-chieh Lo <yjlou@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Add host command to set battery vendor parametersDave Parker2014-04-295-0/+179
| | | | | | | | | | | | | | | | | | | | Also adds 'battparam' console command. BUG=chrome-os-partner:25145 BRANCH=ToT TEST=Run 'ectool batteryparam set 0 0x1234' 'ectool batteryparam get 0' and on the console: 'battparam 0' 'battparam 0 0x1234' on a board that implements parameter 0. Change-Id: I9cc54d001631f53dd39ae64cfdeececaa1747181 Original-Change-Id: Ib2812f57f2484309d613b23dab12ad43e0417bd2 Signed-off-by: Dave Parker <dparker@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/195824 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/197162
* zinger: remove race condition in event handlingVincent Palatin2014-04-291-0/+3
| | | | | | | | | | | | | | | | | | In the micro runtime for Zinger, wait for events with interrupt disabled to avoid race conditions where the event interrupt happens just after we tested it and before going to sleep. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=none TEST=make BOARD=zinger, test Zinger PD communication from Firefly. Change-Id: I10b919450a61fac7ea50e84dd73bcc568150e179 Reviewed-on: https://chromium-review.googlesource.com/197051 Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Vic Yang <victoryang@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
* util: fix support for dedicated debug dongle in flash_ecVincent Palatin2014-04-291-2/+7
| | | | | | | | | | | | | | | | | | | | | | When using a "non-servo" debug dongle or integrated FTDI chip to flash a STM32 microcontroller, add the option to toggle the reset of the microcontroller if the control exists. This was not done for the original Toad version because it cannot control the reset line, but now Firefly, Zinger, Fruitpie debug interfaces can do it. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=none TEST=./util/flash_ec --board=zinger Change-Id: Ia21e3b3403e56b4c0797582659d9a3a0c26bb8bb Reviewed-on: https://chromium-review.googlesource.com/197050 Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Todd Broch <tbroch@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
* stm32: fix GPIO EXTINT maskingVincent Palatin2014-04-263-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | The external interrupts above 15 are not used for GPIO IRQ handling, but for special purpose interrupts from internal peripherals (e.g. RTC, comparator, wake-up ...). When processing the GPIO interrupts, we should explicitly skip those interrupts, else if a GPIO interrupt happens first followed by another EXTINT, the loop in gpio_interrupt() will try to process it and do an out-of-bound read of the exti_events array. This will retrieve a garbage handler triggering a memory fault. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=chrome-os-partner:28296 TEST=on Firefly, press the buttons to trigger GPIO interrupts while there are a bunch of comparator interrupt on EXTIN21 (due to on-going USB PD communication). I no longer see HardFaults. Change-Id: Id90fab30215b0f7f8060c19de63a7ca8418b7b3c Reviewed-on: https://chromium-review.googlesource.com/197019 Commit-Queue: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Vic Yang <victoryang@chromium.org>
* cortex-m0: fix hard-faults during software interrupt callsVincent Palatin2014-04-251-2/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | From time to time (usually under heavy interrupt load), the runtime on Cortex-M0 was panic'ing at the "svc" instruction with a HardFault exception (inside the wait_event() function). The issue was probably the following : the wait_event() code is doing an atomic_read_clear() whose critical section disables interrupts and re-enables them using "cpsie i", then do __schedule() call which is essentially a "svc" instruction. According to ARMv6-m reference manual : "If execution of a CPS instruction: increases the execution priority, the CPS execution serializes that change to the instruction stream. decreases the execution priority, the architecture guarantees only that the new priority is visible to instructions executed after either executing an ISB instruction, or performing an exception entry or exception return." So, when we are executing the "svc", PRIMASK.PM can still be seen as 1 (while it was set to 0 by "cpsie i") and in that case the software interrupt is replaced by a HardFault. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=chrome-os-partner:28296 TEST=run Firefly board under load for extended periods of time. Change-Id: Ie355c36f06e6fe2fee5cca8998a469fa096badad Reviewed-on: https://chromium-review.googlesource.com/196659 Commit-Queue: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org>
* battery: don't talk to battery after cut-offLouis Yung-Chieh Lo2014-04-255-7/+86
| | | | | | | | | | | | | | | | | | | | | Add a shortcut in smart battery driver and i2c passthru. Once the battery cut-off order is submitted (in the factory line), the EC will no longer talk to battery. BUG=chrome-os-partner:28248 BRANCH=tot,nyan TEST=See below > remove AC, cutoff: expect system is off. > cutoff, then remove AC: expect system is off. > cutoff, wait for 1 min, then remove AC: expect system is off. Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org> Change-Id: Ied963c19d17d581ce99e4543469cf2fa165f0439 Reviewed-on: https://chromium-review.googlesource.com/196657 Tested-by: Yung-chieh Lo <yjlou@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org> Commit-Queue: Yung-chieh Lo <yjlou@chromium.org>
* charger v2: only configure charger when AC is on.Louis Yung-Chieh Lo2014-04-241-10/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The CL fcf26a4 enabled periodically charge_request(). However, that could fail and generates lots of error message in the EC console if the AC is not on and charger refuses the request (even it is 0v/0mA). BUG=none BRANCH=tot,nyan TEST=make runtests. Tested on big. Expect NO below annoying error message [1.353104 charge_request(0mV, 0mA)] [1.453170 charge_request(0mV, 0mA)] [1.553281 charge_request(0mV, 0mA)] [1.653317 charge_request(0mV, 0mA)] in the follwing cases: AC on, battery attached, power on, then remove/plug in AC. AC on, battery attached, power on, then remove/plug in battery. AC on, battery removed, power on, then plug in and remove battery. AC off, battery attached, power on, then plug in and remove AC. 'chgstate' also shows good state. At final, charge for 10 mins. Change-Id: Icc729c52246df1ecfb7f289b5078dbc122b20a74 Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/196678 Reviewed-by: Lin Cloud <cloud_lin@compal.com> Tested-by: Lin Cloud <cloud_lin@compal.com> Reviewed-by: Devin Lu <Devin.Lu@quantatw.com> Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Keyborg: increase UART baud rate to 38400Vic (Chun-Ju) Yang2014-04-241-3/+3
| | | | | | | | | | | | | | | | We are running a minimal runtime with less overhead. This allows us to run UART at 38400 bps. Let's update the config for easier debugging. Also fix a potential underflow bug. BUG=None TEST=See debug output at 38400 bps BRANCH=None Change-Id: Ic9e4f9d545f5dbc4a0816a843b0f01a4cf219666 Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/196190 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* Keyborg: chip-to-chip SPI communicationVic (Chun-Ju) Yang2014-04-246-12/+585
| | | | | | | | | | | | | | | | | | This implements a simple SPI driver for the two chips to exchange packets. There are both sync interface and async interface. Sync interface is easier to use, and async interface frees the CPU while the DMA takes care of the communication. BUG=None TEST=Hello test passed BRANCH=None Change-Id: I9823bad5cae6d1fa8f3658d17af4b998d3735a3e Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/195533 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* Keyborg: Implement master/slave identificationVic (Chun-Ju) Yang2014-04-245-3/+170
| | | | | | | | | | | | | | | The two chips work together, so let's teach them how to tell master from slave. After identification, the two chips shake hands through the two sync signals. BUG=None TEST=Disable handshake on master. See slave fail. Vice versa. BRANCH=None Change-Id: Idb6a56128f608dd2ee5c453f75abea475fe1779f Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/195395 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* Big: Correct the charger IC drivercloud_lin2014-04-244-1/+242
| | | | | | | | | | | | | | Add bq24735 driver and move to here for further developing BRANCH=big BUG=None TEST=test basic charing/discharging function Change-Id: I66c22a29cf94383cec86c5cf53db82494504fa77 Reviewed-on: https://chromium-review.googlesource.com/196541 Reviewed-by: Yung-chieh Lo <yjlou@chromium.org> Tested-by: Lin Cloud <cloud_lin@compal.com> Commit-Queue: Lin Cloud <cloud_lin@compal.com>
* battery: move cut-off commands to common/battery.cstabilize-5791.0.BLouis Yung-Chieh Lo2014-04-239-26/+58
| | | | | | | | | | | | | | | So that host and EC commands will be defined in common/battery.c. The board-specific battery.c can focus on the proprietary method. BUG=chrome-os-partner:28248 BRANCH=tot,nyan TEST=make buildall runtest Tested "cutoff" in EC console on big. Change-Id: I213c0d601d0241c8dea309d6ac60c72452d2d100 Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/196621 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* charger v2: supports charger watchdogLouis Yung-Chieh Lo2014-04-232-23/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Some chargers support a timeout mechanism that it would stop charging if no voltage/current setting comes from battery or EC. This is designed for safety. In charger v1, it always updates charger periodically. But in v2, old code only updates charger when needed. New code updates the charger periodically. Also keep the ability for debugging. A manual mode is introduced so that any requested volt/curr from host and force idle mode request would trigger this mode. To leave this mode, just disable the force idle mode. BUG=chrome-os-partner:28201,chrome-os-partner:28208 BRANCH=nyan TEST=See below. Plug AC and battery. Wait for 10 mins and the battery is charged normally. 'chgstate idle on': the charger doesn't charge the battery. 'chgstate idle off': charge again. Plug in AC and remove battery: No annoying repeated message and works fine. Plug in battery and remove AC: No annoying repeated message and works fine. Power up machine with battery only: No annoying repeated message and works fine. Power up machine with AC only: No annoying repeated message and works fine. Change-Id: I00d62f8afa2fe2627ea9259f11679ced02af897a Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/196385
* accel: add accel driver for lsm6ds0Alec Berg2014-04-234-223/+492
| | | | | | | | | | | | | | | | | | | | This adds the basics for the accelerometer potion only of the ST lsm6ds0 accel/gyro. Still need to add the acceleration interrupt functionality, and all of the gyro portion of the chip. BUG=none BRANCH=none TEST=Tested on a samus prototype hacked up to have the lsm6ds0 connected to the EC i2c bus. Added motion sense task to the samus tasklist, added accelerometer information to the samus board file, and tested console functions interacting with accelerometer. The data seems reasonable, and can successfully change data rate and range. Change-Id: I7949d9c20642a40ede82dc291b2c80f01b0a7d8b Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/196426 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* nyan: add info_precharge for drained batteryLouis Yung-Chieh Lo2014-04-224-15/+107
| | | | | | | | | | | | | | | | | | Charger v2 assumes the battery_get_info() always returns non-NULL even if the battery is not detected, for example, in the over-drained situation. Thus, add a new struct so that we know what the conservative setting is to pre-charge the unknown battery. BUG=chrome-os-partner:28112 BRANCH=nyan,big,blaze TEST=See issue tracker for the test procedure. Change-Id: Ica4fe75d154e2f195eb1da19ba045346da383b6c Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/195596 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Devin Lu <Devin.Lu@quantatw.com> Tested-by: Devin Lu <Devin.Lu@quantatw.com>
View Lorry Controller Status