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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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
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>
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>
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>
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>
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>
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
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>
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>
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>
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>
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>
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>
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
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>
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>
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>
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>
This adds an optional lb_power() function that the lightbar TAP sequence can
use to briefly power up the lightbar rails while the AP is shut down.
BUG=chrome-os-partner:29041
BRANCH=ToT
TEST=manual
Shut the AP down, then from the EC console run "lightbar seq tap". The
lightbar should light up and briefly indicate the current power levels. You
can manully force the battery status with "lightbar demo on", then use the
arrow keys to change the state.
Note that the Samus that I tested on had trouble recognizing when it was
charging or not. That's a separate bug.
Change-Id: Iad3f08506d9e049e89d0711af00da2f1aa2337e0
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/213664
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This CL ensures that temporary "one-shot" sequences such as KONAMI, TEST,
TAP, etc. will revert to the previous "normal" sequences even when
interrupted by other one-shot sequences.
This also adds a test for those cases.
BUG=chrome-os-partner:29873
BRANCH=ToT
TEST=manual
make runtests
Change-Id: Ie83908731acdf2f7c9108568a1ba047943175d26
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/213230
This adds a new lightbar sequence (TAP), which temporarily displays the
battery level. It pulses if the system is charging.
BUG=chrome-os-partner:29041
BRANCH=ToT
TEST=manual
From the EC console, run
lightbar seq tap
The lightbar should change temporarily.
Then run
lightbar demo on
and press the Up, Down, Left, and Right keys to fake the battery charge
level (up & down) and the AC present state (left & right). Run the
lightbar seq tap
command periodically to watch it change.
Change-Id: I84ff928d93060f7ef7d46d608732d37cf5185aff
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202964
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Our code base contains a lot of debug messages in this pattern:
CPRINTF("[%T xxx]\n") or ccprintf("[%T xxx]\n")
The strings are taking up spaces in the EC binaries, so let's refactor
this by adding cprints() and ccprints().
cprints() is just like cprintf(), except that it adds the brackets
and the timestamp. ccprints() is equivalent to cprints(CC_CONSOLE, ...)
This saves us hundreds of bytes in EC binaries.
BUG=chromium:374575
TEST=Build and check flash size
BRANCH=None
Change-Id: Ifafe8dc1b80e698b28ed42b70518c7917b49ee51
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200490
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This adds an "extra/" directory to hold various experiments and optional
programs. With this change, we add a tool that can simulate the lightbar
behavior on the build machine. That can be used to experment with variations
in the lightbar pattern code without needing to reflash a Pixel with a new
EC to see the effect.
There is no functional change to the EC code, just a couple of #ifdefs to
allow common/lightbar.c to be compiled separately from the EC.
BUG=none
BRANCH=ToT
TEST=make buildall -j
cd extra
make
./lightbar
You may need to install the libxcb1-dev package on your build machine.
Change-Id: I847ce7ea97cae792b1de1b91f488819e873b6555
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199883
This puts the code that talks to the lightbar hardware in one file, and the
code that implements the pretty patterns and behavior into another. This
will let us make improvements or changes to the patterns without requiring
detailed knowledge of the controller chips.
BUG=chrome-os-partner:28596
BRANCH=ToT
TEST=make buildall -j
Refactoring only. There is no new functionality.
Change-Id: I4e5fe8943385ddeab26bbd7e66c20e2dccd3dc43
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199882
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This adds three new lightbar subcommands to the EC_CMD_LIGHTBAR_CMD host
command, allowing the AP to read the current brightness level, the
current lightbar LED values, and the state of demo mode.
Because this is new, also update LIGHTBAR_IMPLEMENTATION_VERSION. All the
previous commands are unchanged, though.
BUG=chrome-os-partner:28596
BRANCH=ToT
TEST=manual
From the AP, run these commands to see the changes:
ectool version
ectool lightbar brightness
ectool lightbar 0
ectool lightbar 1
ectool lightbar 2
ectool lightbar 3
ectool lightbar demo
The version output is different, the other commands used to just emit
errors.
Change-Id: If32a5d2388217edc3ae7b9b091d66e9d2cf753be
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199881
Reviewed-by: Randall Spangler <rspangler@chromium.org>
There's already a host command, but no console command. We should add one.
BUG=none
BRANCH=ToT, Samus
TEST=manual
From the EC console, run
lightbar version
It should display the version number and flags value.
Change-Id: Ide3517c0a71b5d78c4c4d849a952ccc1d908ea23
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187679
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This make minor syntactic changes and renames some camel-cased symbols
to keep checkpatch from complaining. The goal is to reduce the
temptation to use 'repo upload --no-verify'.
This is a big furball of find/replace, but no functional changes.
BUG=chromium:322144
BRANCH=none
TEST=build all boards; pass unit tests
Change-Id: I0269b7dd95836ef9a6e33f88c003ab0f24f842a0
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180495
All macros are now uppercase.
BUG=chromium:322144
BRANCH=none
TEST=Build all boards. Also, "git grep 'BOARD_[a-z]'" should return no
results (similarly for CHIP, CORE, TEST, CHIP_FAMILY, CHIP_VARIANT.)
Change-Id: I04850e569b3950bb88f9dff107de06dfa49b04fc
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180430
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The samus lightbar uses different LEDs from Link. Adjust the per-color
current limits accordingly. Also swizzle the layout, since LEDs 0/1 and 2/3
are swapped.
BUG=chrome-os-partner:24405
BRANCH=samus
TEST=manual
The colors were ugly and weird. Now they should be pretty and Googley.
Change-Id: I19f317243ff46852628b8b28f2bf6f5e02c6e631
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179160
Reviewed-by: Randall Spangler <rspangler@chromium.org>
battery.h is the high-level interface. battery_smart.h is the
low-level interface. Most things don't need the low-level interface,
but were including smart_battery.h solely to get at battery.h. Fixed
this. Also merged battery_pack.h into battery.h, since it was odd to
split that data across multiple header files. Tidied the function
comments in battery.h as well.
No functional changes, just renaming files and adding comments.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all boards; pass unit tests
Change-Id: I5ef372f0a5f8f5f36e09a3a1ce24008685c1fd0d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/171967
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Most systems don't have a lightbar. Those that do need a way to detect that
one exists. That's easily done by just sending a EC_CMD_LIGHTBAR_CMD command
to the EC and checking the result. If the response is
EC_RES_INVALID_COMMAND, there isn't a lightbar.
But what .cmd value should we use in struct ec_params_lightbar? Future
lightbar implementations (if any), could remove existing functions or add
new ones, so there isn't a safe choice.
This change adds a LIGHTBAR_CMD_VERSION operation to determine if any new
implementation exists. Future systems should return some useful information
in response to this command. Existing systems will return
EC_RES_INVALID_PARAM, which is enough to distinguish them.
BUG=chromium:239205
BRANCH=none
TEST=manual
make BOARD=link
make BOARD=link runtests
There are no user-visible changes in functionality to anything.
Change-Id: Ibe37f74a4dcbf68dd6bfd1963530aec907e67534
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167549
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This unifies the PWM module interface for LM4 and STM32. Now PWM
channels are defined in board.h/board.c. Instead of calling functions
named pwm_set_fan_duty(x), one can now use pwm_set_duty(PWM_CH_FAN, x),
which prevents additional functions added when we have a new PWM
channel.
BUG=chrome-os-partner:18343
TEST=Limit input current on Spring.
TEST=Check power LED in S0/S3/S5 on Snow.
TEST=Check keyboard backlight functionality on Link.
TEST=Check fan speed control/detecting on Link.
BRANCH=None
Change-Id: Ibac4d79f72e65c94776d503558a7592f7db859dc
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/64450
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Sadly, the existence of fans may not always imply the existence of keyboard
backlights.
BUG=chrome-os-partner:18825
BRANCH=slippy
TEST=manual
Use the Link EC console to make sure that both functions still behave.
faninfo
fanset 4400
faninfo
fanset 9999
faninfo
autofan
faninfo
fanduty 50
faninfo
fanduty 100
faninfo
autofan
kblight 0
kblight 100
kblight 50
kbligth 100
Change-Id: I2e07cd46c21bce2d0d4162275a8ea6ae40135e96
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49355
