summaryrefslogtreecommitdiff
path: root/common/lightbar.c
Commit message (Collapse)AuthorAgeFilesLines
* LICENSE: remove unnecessary (c) after CopyrightTom Hughes2019-06-191-1/+1
| | | | | | | | | | | | | | | | Ran the following command: git grep -l 'Copyright (c)' | \ xargs sed -i 's/Copyright (c)/Copyright/g' BRANCH=none BUG=none TEST=make buildall -j Change-Id: I6cc4a0f7e8b30d5b5f97d53c031c299f3e164ca7 Signed-off-by: Tom Hughes <tomhughes@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1663262 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* tasks: convert TASK_EVENT_CUSTOM macro to bitJett Rink2019-04-241-1/+1
| | | | | | | | | | | | | | | | | | | | | We should ensure that all custom task definition are non-zero and fit with the globally defined events. Add compile time check and change semantics to specify bit number (instead of making all callers use the BIT macro). This also fixes an error with TASK_EVENT_PHY_TX_DONE for ITE being 0. The bug that made that happen hasn't landed on any firmware branches that use it though. BRANCH=none BUG=none TEST=builds Cq-Depend:chrome-internal:1178968,chrome-internal:1178952 Change-Id: I5e1d1312382d200280c548e9128e53f4eddd3e61 Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1570607 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
* cleanup: update TASK_EVENT_CUSTOM usageJett Rink2019-04-231-11/+10
| | | | | | | | | | | | | | | | | | The lightbar.c uses the TASK_EVENT_CUSTOM macro in a non-standard way comparing it to the rest of the code base. Update the style in preparation for changing the TASK_EVENT_CUSTOM macro to be a BUILD_CHECK_INLINE macro. Without this cleanup CL, this code breaks. BRANCH=none BUG=none TEST=builds Change-Id: I4fdbb35a2aeeb1f8718b22c017607aee5fa1730a Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1570606 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Diana Z <dzigterman@chromium.org>
* common: bit change 1 << constants with BIT(constants)Gwendal Grignou2019-03-261-2/+2
| | | | | | | | | | | | | | | | | Mechanical replacement of bit operation where operand is a constant. More bit operation exist, but prone to errors. Reveal a bug in npcx: chip/npcx/system-npcx7.c:114:54: error: conversion from 'long unsigned int' to 'uint8_t' {aka 'volatile unsigned char'} changes value from '16777215' to '255' [-Werror=overflow] BUG=None BRANCH=None TEST=None Change-Id: I006614026143fa180702ac0d1cc2ceb1b3c6eeb0 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1518660 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* ec: Make it possible to build tests using clangNicolas Boichat2018-06-281-15/+8
| | | | | | | | | | | | | | | | | | We might want to try out address sanitizer/fuzzer on some host tests: make it possible to build host tests using clang. Board builds are broken, and there is no intention to fix them, at least for now. BRANCH=none BUG=chromium:854924 TEST=make buildall -j TEST=make CC=clang runtests -j Change-Id: Id49a1b8537bc403d53437a2245f4fab6ceae89ac Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1107522 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* cleanup: DECLARE_CONSOLE_COMMAND only needs 4 argsBill Richardson2016-08-241-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Since pretty much always, we've declared console commands to take a "longhelp" argument with detailed explanations of what the command does. But since almost as long, we've never actually used that argument for anything - we just silently throw it away in the macro. There's only one command (usbchargemode) that even thinks it defines that argument. We're never going to use this, let's just get rid of it. BUG=none BRANCH=none CQ-DEPEND=CL:*279060 CQ-DEPEND=CL:*279158 CQ-DEPEND=CL:*279037 TEST=make buildall; tested on Cr50 hardware Everything builds. Since we never used this arg anyway, there had better not be any difference in the result. Change-Id: Id3f71a53d02e3dc625cfcc12aa71ecb50e35eb9f Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/374163 Reviewed-by: Myles Watson <mylesgw@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* charger: Change unlocked battery level ignore conditionsShawn Nematbakhsh2016-01-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | x86 systems will auto-power-on when power is applied to the EC. When the battery level is critically low, power-on is prevented, except when the system is unlocked. So, when unlocked, some systems will auto-power-on regardless of battery level, overcurrent the charger / battery, and then repeat forever. Prevent this reboot loop by ignoring auto-power-up when the battery is critically low, regardless of system unlocked status. BUG=chrome-os-partner:48339 TEST=Verify power-up is prevented on no-battery chell w/ donette. Then, run 'powerbtn' on EC console and verify system powers on (and overcurrents). BRANCH=None Change-Id: Ia631b5a8c45b42ec805e4a0c3f827929a0efd236 Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/319187 Commit-Ready: Shawn N <shawnn@chromium.org> Tested-by: Shawn N <shawnn@chromium.org> Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
* common: lightbar: update leds when neededGwendal Grignou2015-11-131-23/+32
| | | | | | | | | | | | | | | | In S0 state, update leds only when needed: add a variable in get_battery_level to indicate the colors need to be changed. BRANCH=smaug BUG=b:25510300 TEST=Check the traffic on the i2c bus notice less traffic coming from lightbar task in S0. Change-Id: I22dce35edd794424f6fbb607a0dbb495eb308897 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/311756 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* common: lightbar: Add histeresis to prevent flickeringGwendal Grignou2015-10-231-16/+29
| | | | | | | | | | | | | | | | | | | | | | | When ALS is enabled, if light is around one threshold (say 40 lux), the lightbar will flicker between readings. Add a histeresis to prevent the flickering. The current setting is: setting ^ (dim) 2 | ------+---->---+ 1 | +----<---+--->---+ (bright) 0 | +---<---+--------- +-------+--------+-------+--------> lux 20 40 60 BRANCH=smaug BUG=chrome-os-partner:44400 TEST=check in a dark room (30~40 lux) there is no flickering. Add unit test. Change-Id: I4018e2c2ed764abf9c9ed28e2d50a3e94a7d5f75 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/308205
* common: Add lightbar dimming based on outside light.Gwendal Grignou2015-10-201-7/+35
| | | | | | | | | | | | | | | | Unless the lid is closed, the ALS is used for lightbar dimming. Change the google colors depending on the light sensor result. BUG=chrome-os-partner:44400 BRANCH=smaug TEST=Check all 3 levels of brightness of the lightbar. Check value using "adb shell ectool lightbar" Check double tap color are not affected and is using full brightness. Change-Id: I7b5e2890c3557f1dd3ae719f5f82ffb5fe7b24fb Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/301216 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* lightbar: define primary colorsGwendal Grignou2015-10-201-9/+18
| | | | | | | | | | | | | Use defines for color entries 4 - 7. BRANCH=smaug BUG=none TEST=compile Change-Id: I2fe9b286adbb4e2cc471320ccd3d0437b451a7cc Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/306787 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* lightbar: on tap sequence, only get battery percentage onceAlec Berg2015-10-061-11/+11
| | | | | | | | | | | | | | | Change tap sequence so that it only gets the battery percentage once. This means we won't dynamically change color and level if the battery percentage changes mid sequence, but that's ok. BUG=chrome-os-partner:45878 BRANCH=none TEST=run tap sequence Change-Id: I2183343b69d01f4835302e291a2e1a0a2c658b1e Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/302685 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* lightbar: fix battery level hysteresis bugAlec Berg2015-10-061-5/+3
| | | | | | | | | | | | | | | | | | | | | Fix bug in get_battery_level() where we attempt to apply hysteresis to the battery percentage when it jumps between levels. The problem is if the battery jumps up multiple levels, then it won't always update the battery level. For example, using level thresholds of {14, 40, 99}, if you jump from 0% to 99%, it won't update the battery level because it compares the new percentage, 99%, with the battery threshold for the new level + 1 (100%). BUG=chrome-os-partner:45878 BRANCH=smaug TEST=use the battfake console command to jump from 5% to 99% and verify that the lightbar goes from all red to google colors. note: without this CL, the lightbar stays all red. Change-Id: I5ae658c8c92469ebc7f516a04bda7b7fbcd32146 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/302684 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* lightbar: clear all segments before starting tap for batteryAlec Berg2015-09-251-0/+3
| | | | | | | | | | | | | | | | | | | | | | | This makes sure to clear all segments before turning on lightbar for tap for battery. Without this, the previous colors are stored and flash briefly before starting the tap for battery pattern. BUG=chrome-os-partner:45835 BRANCH=smaug TEST=tested on ryu. go to s5, type 'lightbar seq tap' and see that the tap sequence starts without first blinking google colors. note that this doesn't affect samus because for samus in s5, the lightbar is not powered, so when we do tap for battery, we first power the lightbar and the registers are cleared. Change-Id: Ic7ae8c580005e786ba35656d8feeedac56e35cfd Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/302147 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org> (cherry picked from commit 962d0b2595b1dbb5ef162b7e6b4db7ce8a65e6c5) Reviewed-on: https://chromium-review.googlesource.com/302447
* ryu: fix max lightbar brightnessAlec Berg2015-09-251-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix max brightness for Ryu. The max brightness must be less than 0x80 because the top bit in the lightbar current registers is reserved. Writing the top bit seems to have undefined behavior. This fixes the hiccups in the tap for battery sequence which was ramping brightness to above 0x80 and producing weird results. BUG=chrome-os-partner:45835, chrome-os-partner:44029 BRANCH=smaug TEST=test tap for battery looks smooth. test that the google colors match the desired current levels: > lightbar ... 15 0f 06 16 0f 20 17 16 08 18 06 21 19 26 11 1a 1d 0b Change-Id: Iecf1c770f986064b9b4d2d3d54fab0ea1242af01 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/302146 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org> (cherry picked from commit 133dab0c36160d0e54820cce9e97071df34340f8) Reviewed-on: https://chromium-review.googlesource.com/302446
* common: lightbar: put multiple commands under i2c_lockGwendal Grignou2015-09-191-8/+6
| | | | | | | | | | | | | | | | | | If other i2c traffic happens around the time the light bar is initialized, the i2c bus is wedged. Instead of waiting 500ms in the motion task loop for the tap sequence to complete, set under i2c lock the lp power and init sequence. BRANCH=smaug, samus BUG=chrome-os-partner:45223 TEST=With msleep(500) removed and With lb_power + lb_init + 100ms, I don't see the wedge at TAP sequence. Change-Id: I931eb25bcc5e3237b6c569f2330f72f9fc415964 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/299543 Reviewed-by: Bill Richardson <wfrichar@google.com>
* ryu: re-calibrate lightbar colors for device.Todd Broch2015-08-211-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Todd Broch <tbroch@chromium.org> BRANCH=smaug BUG=chrome-os-partner:44029 TEST=manual, 1. Boot device into S0 2. From EC console lightbar ... 15 0f 06 16 0f 20 17 16 08 18 06 21 19 26 11 1a 1d 0b These values match requested values. Change-Id: Ib65044510ac24bd41d63586534685f995fcb131d Reviewed-on: https://chromium-review.googlesource.com/294840 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Tested-by: Todd Broch <tbroch@chromium.org> Commit-Queue: Todd Broch <tbroch@chromium.org>
* ec: Created lightbar params v2Aseda Aboagye2015-03-311-1/+100
| | | | | | | | | | | | | | | | | | | | The 'lightbar params' v1 command has a parameter list that exceeds 120 bytes, which will not work over i2c. Therefore, I created a params v2 command which breaks up the existing parameters into logical groups which are less than 120 bytes. TEST=Tested new lightbar params2 command and ran get/sets on all groups for samus. Repeated test on ryu as well. BUG=chromium:467716 BRANCH=none Change-Id: If0fa92e9a2f373b20257f8ce7eb66b7836d9ac60 Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/263106 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Commit-Queue: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* lightbar: clear all segments first before starting konami seqAlec Berg2015-03-061-0/+3
| | | | | | | | | | | | | | | | | | | Clear all lightbar segments first before starting konami sequence. If currently displaying Google colors, we need this so the start of the sequence shows up correctly. BUG=chrome-os-partner:37469 BRANCH=samus TEST=from S0 with google colors on lightbar, run "lightbar seq konami" from EC console and make sure 1st and 4th segments are cleared before starting konami sequence. Change-Id: I92ba8f29414c279895658167f8d5958fe49ea034 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/256192 Reviewed-by: David Schneider <dnschneid@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* samus: change tap for battery to not show dimmed last segmentAlec Berg2015-03-061-1/+13
| | | | | | | | | | | | | | | Change tap for battery lightbar sequence to not show the last segment dimmed as a percentage of your battery. BUG=chrome-os-partner:37335 BRANCH=samus TEST=use battfake console command to test out every increment of 10% and use "lightbar seq tap" to show tap. Change-Id: I4f38d26a8cfbecfa6efc86fcc8751ca8cb34879b Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/256191 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* lightbar: make tap red threshold match low battery thresholdAlec Berg2015-02-251-2/+3
| | | | | | | | | | | | | | | | | Make tap for battery red threshold match the low battery red threshold. BUG=chrome-os-partner:36811 BRANCH=samus TEST=use a fake battery console command to change battery percentage on samus and make sure that the same level at which lightbar turns red in S0 is the same level at which tap for battery shows red. Change-Id: I084c8412beac4f5b311eb30f46f4f3273e9f2456 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/252351 Reviewed-by: Shawn N <shawnn@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* samus: fix lightbar tap sequence doesn't always show on AC eventAlec Berg2015-02-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Fix bug on samus that the battery status doesn't always show on lightbar when AC is plugged/unplugged. It doesn't show when the battery is full is S3 or S5 because in these states we turn off CHARGE_EN so that ACOK to the EC never toggles. Instead, what we want to do is display battery status whenever the active charge port changes. This will happen when AC is plugged or unplugged OR if a user has AC on both ports and toggles between them using the charge override hot-keys. BUG=chrome-os-partner:36317 BRANCH=samus TEST=test plugging and unplugging AC on both sides when battery is full and unit is in S0, and when unit is in S5. also tested lightbar flashes battery percentage when two zingers are plugged in and you switch between them using Ctrl+Search+0|1|2. Change-Id: I5cd7fff4f466adf857f1e63f07f3b0c7ae8422c7 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/245922 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* samus: lightbar: Set tap for battery red threshold to match kernelAlec Berg2015-01-211-1/+1
| | | | | | | | | | | | | | | | | | | | Set the battery threshold for tap for battery to show red to match the kernel percentage at which the battery icon turns red. This threshold is 14% real battery percentage which is equivalent to 10% battery for what the user is shown. Note: due to rounding we may still be off, but this closes the window at which these will differ. BUG=chrome-os-partner:35664 BRANCH=samus TEST=make buildall. compare to CL:48904 where we made a similar change for the lightbar color to turn red when running. Change-Id: I31d3c4544c57bc11967d0ba7a54d26e543f6bf5b Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/242255 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* lightbar: Don't let EC control suspend/resume sequenceEric Caruso2015-01-101-2/+19
| | | | | | | | | | | | | | | | | | | 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>
* lightbar: Pulse lightbar in S5 if power-up is inhibitedShawn Nematbakhsh2015-01-061-4/+74
| | | | | | | | | | | | | | | | Add a lightbar indicator if a charger is attached and we refuse to power-up the AP due to battery level. BUG=chrome-os-partner:31127 TEST=Manual on Samus. Attach charger with depleted battery, verify that lightbar pulses red. Remove charger and verify that lightbar stops pulsing. Also verify the same with missing battery. BRANCH=Samus Change-Id: Icddd543dc34e36ac04957ea07bde0e2d5709f74b Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/236023 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* samus: when battery is full, and not in S0, stop chargingAlec Berg2015-01-031-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When battery is full and system is not in S0, then stop charging and allow battery to power the system. Once battery is no longer full and requests current, allow charging again. This is to work around power consumption issues in our AC input path. The charge override port is stored upon entering S3 and restored going back to S0 so that the charge override port is not affected by this. This also fixes lightbar so lightbar checks if battery is full instead of checking raw percentage. The lightbar is also changed to use the last tap direction if no charger is plugged in. And the lightbar tap for battery threshold for turning green is lowered to 95%. This also moves some samus_pd board code out of interrupt handlers and in to deferred functions to minimize time in interrupts. BUG=chrome-os-partner:34640, chrome-os-partner:34847 BRANCH=samus TEST=load onto samus. use battfake command from pd console to set battery percentage. when system is in G3, see that batt = 100% stops charging, and when batt < 100% it starts charging again. tested that we receive host command from EC with battery information every time battery changes SOC. Change-Id: Ia8e0721508e34ee3630f5e5b0c2f431a00329caf Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/236411 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* lightbar: ask the PD MCU for the charge directionBill Richardson2014-12-111-5/+15
| | | | | | | | | | | | | | | This exposes the pd_exchange_status() function and lets it return the charge port that the PD reports, so that the lightbar TAP sequence can decide which direction to display. BUG=chrome-os-partner:32227 BRANCH=ToT, samus TEST=make buildall -j Change-Id: I78b57fbeaaf38fee15c86eca4d90abce77e2f722 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/232092 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* lightbar: tap sequence can go in either directionBill Richardson2014-11-261-4/+22
| | | | | | | | | | | | | | | | | | | | | We still need to decide which direction to use. Refer to the bug for details & discussion. BUG=chrome-os-partner:32227 BRANCH=ToT,samus TEST=make buildall -j From the EC console, use lightbar seq tap 0 lightbar seq tap 1 If you don't give the third arg, it just uses the previous direction. Change-Id: I3a6566e8ba18d392f8d9d3419745a5377d22db25 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/231893 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Clean up lightbar sequencing a bitBill Richardson2014-11-261-20/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When other tasks call lightbar_sequence() to indicate power state changes, a single-bit event is delivered to the lightbar task and the requested sequence is saved in a variable. This is intentional, because we want the lightbar to run only the most recently requested sequence. Of course this means there's a small race condition, which caused occasional problems. This change reduces the window for problems, by making a copy of the requested sequence immediately after the event is delivered (rather than after printing a bunch of stuff), and then having the current sequence function return that new sequence back to the lightbar_task() main loop. While we're at it, the transitional sequences (S5S3, etc.) can just return their next sequence directly instead of letting that decision be made in the lightbar_task() loop. BUG=chrome-os-partner:33401 BRANCH=ToT,samus TEST=make buildall -j Power on/off, reboot, open & close the lid, double-tap, etc. Watch the lightbar the whole time. It should do the right thing. Change-Id: Icbe96194e523ef4d85d2643ec14675cf5c893dc0 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/231881 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Improve EC console messages for lightbar stuffBill Richardson2014-11-211-12/+14
| | | | | | | | | | | | | | I need more information to find the source of some problems. This just adds a little more context to the lightbar console messages. BUG=chrome-os-partner:33401 BRANCH=ToT,samus TEST=make buildall -j Signed-off-by: Bill Richardson <wfrichar@chromium.org> Change-Id: I97a210754833c9384eae517f9df2e97d3a9ea6b4 Reviewed-on: https://chromium-review.googlesource.com/231136 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Re-Calibrated lightbar values for Samus & RyuBill Richardson2014-11-061-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | New values from lab testing with slightly higher intensity. BUG=chrome-os-partner:33017 BRANCH=ToT,samus,ryu TEST=manual ectool lightbar brightness ff ectool lightbar seq s3s0 ectool lightbar Resulting current levels: 15 00 2d 16 2a 0a 17 26 13 18 10 0b 19 10 26 1a 1b 0d Change-Id: I118bf2fda3dee67b27c5d6a5825b7a9a96dc66dd Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/227515 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Calibrated lightbar values for Samus & RyuBill Richardson2014-10-221-4/+11
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* lightbar: interpreter additions to encode other patternsEric Caruso2014-10-151-42/+158
| | | | | | | | | | | | | | | | | | | | Makes a significant encoding change to existing opcodes and adds several opcodes to allow for encoding the more complicated patterns that we have on the lightbar (S0, etc.) as well as condense the ones we technically could encode but couldn't fit in the 192-byte footprint allotted to us (KONAMI). We need this to remove sequences from the EC code. BUG=chrome-os-partner:32203 BRANCH=ToT TEST=run test programs on hardware and lightbar simulator Signed-off-by: Eric Caruso <ejcaruso@chromium.org> Change-Id: I12fe908d3a43a924aa39f24ad66adbe53f7f38e1 Reviewed-on: https://chromium-review.googlesource.com/222949 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* lightbar: bring the TAP sequence in graduallyBill Richardson2014-10-151-2/+16
| | | | | | | | | | | | | | | | | | | With only four LED segments, it's confusing to indicate a power percentage by dimming the top segment unless you can see the indicator smoothly ramping up from all-off. This does that. Kind of pretty, if I say so myself. BUG=chrome-os-partner:29041 BRANCH=ToT, Samus TEST=make buildall Run "ectool lightbar demo on", then press the T key to invoke the pattern and the arrow keys to fake the charge state. Change-Id: Ib6a56aea56078b8c1fc9edddda469d7f41735ff7 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/223300 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* lightbar: Rename structs and macros for kernel cros_ec_commandsEric Caruso2014-10-091-4/+6
| | | | | | | | | | | | | | | This prepends EC_ a macro exposed in ec_commands.h, moves a macro into lbcc that is not used elsewhere, and changes lb_program structs to lightbar_program. BUG=None BRANCH=ToT TEST=make buildall -j Change-Id: I481562da72d91f846c64cf9af40338027641462c Signed-off-by: Eric Caruso <ejcaruso@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/222406 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Remove PULSE and TEST sequences from lightbar moduleVic Yang2014-10-081-70/+0
| | | | | | | | | | | | | | | PULSE and TEST sequences are not used anywhere. Remove them to save flash space. Also, fix msleep(MSEC) calls in the unit test; it's essentially usleep(SECOND) written in an incorrect way. BUG=chrome-os-partner:32203 TEST=make buildall BRANCH=None Change-Id: I61ba897df632538eb89364a4c913d5fee87f3864 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/220711 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* lightbar: refactoring RAMP_ONCE and CYCLE_ONCEEric Caruso2014-10-041-40/+31
| | | | | | | | | | | | | | | | These opcodes basically do the same thing, but with minor changes. We can factor this out to avoid code duplication. Saves 90 bytes. BUG=None BRANCH=ToT TEST=Inspected programs that use RAMP_ONCE and CYCLE_ONCE with both nonzero and zero ramp delay. Change-Id: I0105dbd4fc0af86beea993dbef85a0e0f01a0a90 Signed-off-by: Eric Caruso <ejcaruso@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/220604 Reviewed-by: Vic Yang <victoryang@chromium.org>
* Remove 'param' option in lightbar console commandVic Yang2014-10-021-69/+0
| | | | | | | | | | | | | | We can use ectool to set/get lightbar parameters and don't need a huge console command option for this. Let's get rid of it to save flash space. BUG=chrome-os-partner:32203 TEST=make buildall BRANCH=None Change-Id: Ifbc122c887a36accaf3f8dce43f091d7d1333550 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/220710
* lightbar: hide program command over consoleEric Caruso2014-10-011-5/+4
| | | | | | | | | | | | | | | | This doesn't make any sense to expose to the console, so we can save some logic and string literals by only compiling it for the simulator. BUG=chrome-os-partner:32203 BRANCH=ToT TEST=Checked console does not support command. ectool still works and the lightbar simulator still has the command. Change-Id: Ib216c7c11fd3d0d2d444ef7fc0dda4e451103219 Signed-off-by: Eric Caruso <ejcaruso@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/220834 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* lightbar: Removing unused space in ramp tableEric Caruso2014-10-011-1/+1
| | | | | | | | | | | | | | | We don't need the upper two bytes of any elements in the ramp table, since none of them are big enough to flow into them. This saves us another 60-70 bytes. BUG=None BRANCH=ToT TEST=Manual, visual inspection Change-Id: Id9d03b8f63e61172c5cc6b36b010582957c7bb22 Signed-off-by: Eric Caruso <ejcaruso@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/220595 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* lightbar: simplify JUMP, SET_DELAY_TIME opcode executionEric Caruso2014-10-011-12/+2
| | | | | | | | | | | | | | | | We do some unnecessary work here. All we are trying to do is decode, and decode already does all the error checking we want. Saves 20 bytes. BUG=None BRANCH=ToT TEST=Run programs with JUMP and SET_DELAY_TIME opcodes in simulator and on hardware. Change-Id: Ia55f9010da50fe748bda565e069359162cc92b4f Signed-off-by: Eric Caruso <ejcaruso@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/220630 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* lightbar: treat HALT like a normal opcodeEric Caruso2014-10-011-7/+11
| | | | | | | | | | | | | | | | This removes the special casing around HALT. It saves us a string literal and some logic. In total, we gain about 50 bytes and a little cleanup for this. BUG=None BRANCH=ToT TEST=Tried a program that uses HALT (i.e. red-green-blink) in simulator and on hardware. Change-Id: Iffee1b559983fd1ecd385cc6b8967f72a6b968a0 Signed-off-by: Eric Caruso <ejcaruso@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/220589 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* lightbar: remove erroneous multiplications by FP_SCALEEric Caruso2014-09-301-2/+2
| | | | | | | | | | | | | | Not sure why these were around. They were making RAMP_ONCE and CYCLE_ONCE do obviously incorrect things. BUG=None BRANCH=ToT TEST=Manual, visual inspection Change-Id: I618078e8bef8824f5449d5b5453924beb36d50e1 Signed-off-by: Eric Caruso <ejcaruso@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/220463 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* lightbar: shrink size of sine table for rampingEric Caruso2014-09-301-28/+19
| | | | | | | | | | | | | | | cycle_010 now uses a table one-fourth the size and does a small bit of linear interpolation in order to save space. This change saves around 350 bytes. BUG=None BRANCH=ToT TEST=manual; inspection that ramping still looks smooth Change-Id: Ib5900630ba4a471a6284660377134724070babdc Signed-off-by: Eric Caruso <ejcaruso@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/220430 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Add compiler/decompiler for lightbar bytecode programs.Bill Richardson2014-09-301-28/+6
| | | | | | | | | | | | | | | | | BUG=none BRANCH=ToT TEST=manual make BOARD=samus for i in extra/lightbar/programs/[g-z]*.bin; do ./build/samus/util/lbcc -d $i /tmp/x.lbs ./build/samus/util/lbcc /tmp/x.lbs /tmp/x.bin cmp $i /tmp/x.bin done Change-Id: I86c014c425e917ecafadd1c6845fcf2e5b4edbb7 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/220244
* Fix floating point usage in lightbar moduleVic Yang2014-09-271-4/+4
| | | | | | | | | | | | | | | | | This patch fixes stary floating point usage in lightbar module. They should be scaled by FP_SCALE and of type 'int'. BUG=None TEST=Compile and make sure the compiler is not using floating point related instructions. BRANCH=None Change-Id: I8d598af1014160b83bc44ef3e88e2cc4bf304e5e Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/220121 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Eric Caruso <ejcaruso@chromium.org>
* Add demo_tap() function for lightbar demo modeBill Richardson2014-09-261-2/+10
| | | | | | | | | | | | | | | | | | | BUG=chrome-os-partner:29041 BRANCH=ToT TEST=manual From the host run ectool lightbar demo on Then press the 'T' key. The lightbar should change to indicate the charge state. Fiddle with the arrows to change the pretend battery level and AC presence. Change-Id: I398a829e2e5de5e1a186500aa2ed72c61e71deaa Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/220024 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* lightbar: add seq type PROGRAM for user-programmable sequencesEric Caruso2014-09-251-0/+374
| | | | | | | | | | | | | | | | | | | | | | | | This diff allows the user to send small programs to the EC and gain control of the lightbar. Right now, this is only exposed through ectool, and sysfs support will come later. To send a program to the EC, use $ ectool lightbar program /path/to/program.bin and then start running the program with $ ectool lightbar seq program BUG=None BRANCH=ToT TEST=Using the above steps with hand-assembled programs. Checked that infinite bytecode loops do not hang the EC. Checked that bad opcodes exit with an error. Stress tested pushing programs and changing sequences. Signed-off-by: Eric Caruso <ejcaruso@chromium.org> Change-Id: I635fb041a5dc5c403f7c26fb9a41b5563be9b6b7 Reviewed-on: https://chromium-review.googlesource.com/219558 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* lightbar: show google colors in S0 (red for low battery)Bill Richardson2014-09-251-0/+54
| | | | | | | | | | | | | This removes the pulsing blue colors in S0. BUG=chrome-os-partner:31546 BRANCH=ToT TEST=manual Change-Id: Ib756b93bb51cb7b618958e5b1d270ba9cd1eef22 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/219417 Reviewed-by: Vic Yang <victoryang@chromium.org>
* Remove floating point usage in lightbar codeVic Yang2014-09-231-84/+96
| | | | | | | | | | | | | | | Not every chip that we use has FPU. To make it easier to enable lightbar on chips other than LM4, let's remove floating point usage in lightbar code. Instead, scale those numbers by a factor of 10000. BUG=chrome-os-partner:32203 TEST=Run on Samus. Visually check lightbar. BRANCH=None Change-Id: I88b12bb66b5c586f2e14135069bd97d6b56832a1 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/219246 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
View Lorry Controller Status