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
CONFIG_ macros should be set directly. Expanding the task names in the same
way made it difficult to tell what was a configuration choice and what was
due to changes in ec.tasklist
BUG=chrome-os-partner:18343
TEST=build all, run link
BRANCH=none
Change-Id: Ib82e34f974238ee2dd216f33b701b6f4c6a4f1f1
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49098
Reviewed-by: Randall Spangler <rspangler@chromium.org>
There is a 4% difference between the kernel's view of battery level and the
actual battery level, to give userspace a chance to shut down cleanly. The
EC should turn the lightbar red when the battery drops below 10%, so this
change makes that happen when the kernel says it's 10%, instead of the real
10%.
Note: We don't have to cherry-pick this to the Link branch. Although it
affects the EC, we already patch the EC lightbar parameters at boot and
that's done in userspace.
BUG=chromium:225500
BRANCH=none
TEST=manual
Unplug Link, let the battery run down. The lightbar should pulse red when
the battery level reported by the UI drops to 9% (there may be a little
delay due to rounding). Note that it's only red when on battery.
Change-Id: If3d335c54ceb37c86da59e4a66f8ecd46ce15664
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48904
Reviewed-by: Randall Spangler <rspangler@chromium.org>
We have yet another tweak for the lightbar, but we don't want to update the
EC. This CL adds an init script that runs on the AP at every boot and pokes
the EC to modify the lightbar settings. We have to run it at every boot
because the EC will hibernate after the AP has been off (not suspended) for
an hour on battery power and will lose its settings.
There's a corresponding CL for the ec-utils ebuild that installs the
userspace scripts into the rootfs.
BUG=chrome-os-partner:16827
BRANCH=link
TEST=manual
Build the image for Link, install, reboot.
Run "ectool lightbar params". The output should match what's in
/usr/share/ec/lightbar_params.txt
Change-Id: If50ac2ef2432f7d60cdaf4c222b68dbdee80b2ec
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/39979
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Richard Barnette <jrbarnette@chromium.org>
We'd defined them in a number of different files. This moves
definitions to timer.h, and uses them everywhere we have large delays
(since 10*SECOND is less typo-prone than 10000000).
Also add msleep() and sleep() inline functions. No need for mdelay()
or delay(), since any delays that long should use sleep funcs instead
of spin-waiting.
BUG=chrome-os-partner:15579
BRANCH=none
TEST=boot system; taskinfo displays similar numbers to before
Change-Id: I2a92a9f10f46b6b7b6571759b1f8ab4ecfbf8259
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36726
Since POWERSTATE is confusing whether it refers to battery power or
system power.
BUG=chrome-os-partner:15579
BRANCH=none
TEST=taskinfo; see CHARGER task
Change-Id: I5a237b1329cace4ce48ae39d8954c08a9912ed4b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36707
Previously, all hook functions returned EC_SUCCESS, which was
meaningless because nothing ever looked at the return value. Changing
the return value to void saves ~100 bytes of code size and an equal
amount of source code size.
BUG=none
BRANCH=none
TEST=code still builds; link still boots
Change-Id: I2a636339894e5a804831244967a9c9d134df7d13
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36372
This makes the timing for the S3 low-power indicator adjustable without
reflashing.
BUG=chrome-os-partner:8039
BRANCH=Link
TEST=manual
Boot, log in, run this to put the lightbar into demo mode:
ectool lightbar demo 1
ectool lightbar seq s3s0
The lightbar should act as though the system is asleep.
Then press the left arrow a couple of times and the down-arrow four or five
times. You should see the red light pulse every 5 seconds or so.
Now run
ectool lightbar params > /tmp/w
Edit /tmp/w to change the timing lines to this:
100 # .s3_ramp_up
100 # .s3_ramp_down
Then run
ectool lightbar params /tmp/w
After a cycle or two, you should see the lightbar flash instead of pulse.
Change-Id: If815ff2fb9a158c0e1f4dbb6a269ad07e122d84c
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35839
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This is hopefully the finally final tweak to the lightbar behavior. It does
this:
* When booting or awakening from sleep, Google colors pulse briefly.
* When the chromebook is fully on, lightbar is dim blue. Every 3-5 seconds,
a pulse of brighter blue sweeps across.
* On battery, the lightbar is not quite as bright, and the sweep goes in the
other direction and is slightly slower. If the battery charge drops below
10%, the lightbar changes from blue to red (but only on battery, not AC).
* When going to sleep (close lid while logged in), lightbar fades to black,
then pulses Google colors, then off.
* While asleep, lightbar does nothing, UNLESS on battery and battery charge
is under 10%. Then it pulses red every 5-8 seconds.
* When shutting off, it just goes black with no special effects.
Other than the slight dimming on battery power, there is no ambient light or
dynamic brightness control.
BUG=chrome-os-partner:8039
BRANCH=Link
TEST=manual
Turn it on, watch the blinky lights. Log in, close the lid, open the lid.
Connect/disconnect AC. The lights should change as described above. Ta Da.
Change-Id: Id174a452639decc4b5eefb9e21b28cf3643529f5
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35742
Reviewed-by: Randall Spangler <rspangler@chromium.org>
I introduced a glitch in the parameterization CL. This fixes it, and makes
the choice between the gentle throbbing and occasional pulse something that
can be selected as a parameter. Default is the new pulsey style.
BUG=chrome-os-partner:8039
BRANCH=Link
TEST=manual
Using the ectool that's part of this change, run these commands to flip
between suspend and active displays:
ectool lightbar seq s3s0
ectool lightbar seq s0s3
Change the "new_s0" value (0/1) and reload the params with
ectool lightbar params | tee /tmp/w
vi /tmp/w
ectool lightbar params /tmp/w
In each case you'll see some pretty patterns. Pass/Fail is an artistic
decision. No QA required.
Change-Id: I8de0b1b3cc77f65879befe95e110bbbce18846d9
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35620
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This change replaces most of the hard-coded lightbar constants with values
that can be updated at run-time, so that if we change our minds about colors
and timing we can tweak some of the values without requiring an EC/BIOS
update.
It also adds the "ectool lightbar params" command to get and set those
values from the host. You can see the values from the EC console ("lightbar
params"), but there's no way to set them.
BUG=chrome-os-partner:8039
BRANCH=Link
TEST=manual
From the EC console, run
lightbar params
It should display the current values that can be changed.
Log in to the host and run this to see the same values:
ectool lightbar params
Or edit and change them with this:
ectool lightbar params > /tmp/vals.txt
vi /tmp/vals.txt
ectool lightbar params /tmp/vals.txt
The updated parameters are persistent across EC jumps (RO->RW), but are lost
when/if the EC reboots (as it will after the AP is off for 24 hours, for
example).
Change-Id: Ic2a3fd6f8062673432b48904933e0c7239b8658b
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35289
Reviewed-by: Randall Spangler <rspangler@chromium.org>
An earlier commit made the lightbar test sequence run much too quickly. This
puts it back. I'm not sure if the factory still looks at this, but I think
they did at one time, so we might as well keep it working. It's helpful for
debugging anyway.
BUG=chrome-os-partner:8039
BRANCH=link
TEST=manual
Log in, run "ectool lightbar seq test". You should see the lightbar colors
pulse in various colors, then go back to whatever they were doing before.
Change-Id: I11c24a448bf40f0c0c82456fcf6e0415a0392c28
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35190
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Latest tweaks after working with the UI folks. This changes the S3 and S0
sequences and the transitions between them, using Google colors, smooth
fades, and persistent state across EC resets.
In S3, we only pulse when the battery is low and is discharging.
BUG=chrome-os-partner:8039
BRANCH=Link
TEST=none
Artistic criticism only, please.
Change-Id: Id75b8c2c96e2e9dc9ff27af0bfe126cfad5d490e
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34465
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Yet another set of tweaks to the lightbar patterns:
At Startup or wake from sleep, Google colors cycle in.
While running, > 25% power level in the battery:
All blue, in a breathing effect (cycle up and down 30%).
While running, <= 25% power level in battery:
Same as above, but with red
Shutting down, or going into sleep:
Cycle out the Google colors (Note: the effect is only visible for S0->S3,
because shutting down kills power to the lightbar before we can react).
While sleeping:
Similar to now, but only using Blue and red for battery indication as above.
The EC doesn't have access to the ALS, so we use the keyboard backlight to
control the lightbar brightness instead:
If keyboard backlight is OFF (which it is when ambient is bright), use max
brightness for lightbar.
If keyboard backlight is ON, use keyboard backlight brightness.
BUG=chrome-os-partner:13870
BRANCH=Link
TEST=none
This is an aesthetic change. Nothing to test, only artisitic criticism.
Change-Id: Ib0b98eef18984945a83e988588c225025c4e8e52
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/33824
Reviewed-by: Randall Spangler <rspangler@chromium.org>
We recently changed the way host messages are passed to the EC to make it
work nicer across I2C. When we did, we updated all the internal structs
except those used for lightbar commands. This CL updates the lightbar
commands too.
BUG=chrome-os-partner:11277
BRANCH=all
TEST=manual
This shouldn't change anything, but you can ensure that by poking at the
lightbar manually. On Link, run this from a root shell:
ectool lightbar seq stop
ectool lightbar 4 ff 00 ff
ectool lightbar seq run
With the first command, the lightbar pattern should freeze.
With the second command, it should turn magenta.
With the third command, it should resume pulsing as before.
Change-Id: Ic5dc4c827b3b4459288d7d9bd7d06af8a5176b3c
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/33798
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Previously this was in lightbar.h. ec_commands.h should not require
other header files.
Also make brightness local variable static, so it won't leak outside
lightbar module.
This is simply code cleanup; values themselves have not changed.
BUG=none
TEST=if it builds, it's fine
BRANCH=none (not required in link branch since it's just cleanup)
Change-Id: I5722fb677fcec99e0826e3dfc0b22033781b576f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32815
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Yung-Chieh Lo <yjlou@chromium.org>
The response size was wrong. It should be right.
BUG=none
BRANCH=link
TEST=none
Build the lbplay tool, copy it to the DUT.
cd src/platform/ec
make BOARD=link
scp build/link/util/lbplay root@LINKIPADDR:/tmp/
Run /tmp/lbplay on DUT. It used to print a warning message. Now it doesn't.
The lightbar will glow green, then red (that's what lbplay does).
Change-Id: Iee02a026f08b6f761e5f28f20b79bcb9f4704a43
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31403
Reviewed-by: Randall Spangler <rspangler@chromium.org>
I keep getting asked to build an EC image to manually control the lightbar
patterns so that the Powers That Be can look at it. This change just makes
it possible to turn that mode on and off for yourself. You'll need a root
shell or the EC console to do it, though.
BUG=chrome-os-partner:8039
BRANCH=link
TEST=manual
From the EC console, type
lightbar demo 1
OR from the root shell run
ectool lightbar demo 1
After that, these keys should change the lightbar appearance (transitions
may be slow and subtle - that's intended):
UP = battery is more fully charged
DOWN = battery is less fully charged
RIGHT = battery is charging
LEFT = battery is discharging
BRIGHT = increase lightbar brightness
DIM = decrase lightbar brightness
Note that this does not interfere with the normal function of any keys. It
only adds some additional EC behavior.
Change-Id: Ia1a9855188244d74b670f9dbfdf60e3ac0343460
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/30899
This removes a bunch of unnecessary typecasts, since you can assign
to/from void * without them. This also uncovered a few cases where
const was being cast away for the input params; now fixed.
BUG=none
TEST=mkbp hash from u-boot console, and/or system boots ok
Change-Id: Ic314b9d2ca06226ea8a09703ef5c1a912eb7146d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28500
BUG=chrome-os-partner:8039
TEST=manual
Boot the system, look at the lightbar. It should pulse colors slowly on
battery, faster on AC.
Change-Id: I0184973d11eda51db87d652aa2c92995f5a25588
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27810
Make sure that a negative 'num' param won't be accepted if passed by a
malicious caller.
BUG=chrome-os-partner:11048
TEST=manual
No visible changes, everything should continue to work.
Change-Id: I8128d24adc99e5ff954a6b8065e1bfa8bf20630e
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27386
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Make sure it doesn't run off the end of the I2C device list.
BUG=chrome-os-partner:11051
TEST=manual
No visible changes. Everything should continue to work.
Change-Id: I43182361cda6be578e57acef01afb27260cea80a
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27390
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Added version mask field to DECLARE_HOST_COMMAND() because it's
convenient to do so when I'm touching all host command
implementations, but all commands simply declare version 0 and nothing
checks it yet. Will add version support in a followup CL.
This change is internal to the EC; it does not change the data sent
over the host interface.
BUG=chrome-os-partner:11275
TEST=manual
ectool version && ectool echash; should get sane data from both
ectool flashread 0x80 0x40 /tmp/foo && od -tx1 /tmp/foo
should match data from offset 0x80 of ec.bin (od -j128 -n64 -tx1 ec.bin)
Change-Id: I5699f72b8d5e1ac23929353c9a34158d76c44206
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27172
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
At this point, EC code requires EVT. If you still have a proto1,
here's what'll break:
1) Keyboard recovery mode checks refresh key, and may read unreliably due
to proto1 silego reset circuit.
2) Lightbar may not start in the correct state.
3) EC 'hibernate' command will not work.
4) Board version may read incorrectly.
BUG=chrome-os-partner:9661
TEST=manual
1) powerbtn -> system powers on, lightbar displays proper sequence
2) version -> board version 1 (EVT)
3) power+refresh+esc -> system boots into recovery mode
4) power+refresh, then power button -> system reboots, then boots normally
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Change-Id: I699946e365d15ae38622b69da1a0241e72d05f61
Reviewed-on: https://gerrit.chromium.org/gerrit/26053
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Additional help messages and usage are gated by
CONFIG_CONSOLE_CMDHELP, so we can turn it on if there's space (adds
about 3KB to image size) and turn it off when there isn't.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=none
TEST=manual
1) help
2) help list
3) help gpioset
4) gpioset -> wrong number of params
5) gpioset fred 0 -> param1 bad
6) gpioset cpu_prochot fred -> param2 bad
Change-Id: Ibe99f37212020f763ebe65a068e6aa83a809a370
Since the events are requests for new patterns, we only want to do the
latest one. This does that.
BUG=chrome-os-partner:9349
TEST=none
No test: multiple events are rare. I had to fake them to see the problem.
Change-Id: I7e7de94655576e16c442a97097a7303e422a551a
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
BUG=chrome-os-partner:9850
TEST=manual
Open the lid. The lightbar should turn on.
Change-Id: I14d1316e6b0cac7a7e2f5b08b7d14b6bbdfa5830
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Preparatory work to use common host command code between ARM and x86.
Just rename constants, do not change the binary API.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:9614
TEST=make BOARD=link
Change-Id: I534d427c9b50103273835a6f32a0ddb622c762b3
Preparatory work to use common host command code between ARM and x86.
Every command sends back explicitly the size of the response payload.
The size of the response defaults to 0 ond can be updated.
Add a protocol version number returned as command 0x00 to help with
backward compatibility.
move a couple of function from lpc specific header to host commands to
be able to implement them for the I2C link.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:9614
TEST=make BOARD=link
Change-Id: I6a28edf02996ddf6b7f32a3831d07d5f0271848f
Open drain cleanup minimizes leakage and signal glitching on shared
reset/signal lines, and is tidier than explicitly switching the
signals between inputs/outputs.
Touchscreen and lightbar are powered by +5VALW so their signals need
to be dropped when +5VALW is off to avoid leakage, and so they see a
clean reset signal when they're powered up.
Moved +5VALW power-on to S5-S3 transition, to minimize power draw in
S5. This also ensures that 5VALW-powered devices get reset when the
device bounces through S5. (No effect on proto1, where 5VALW is not
under EC control.)
Signed-off-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:9172
TEST=boot and shutdown system; still works.
Change-Id: Ia4bf0703292a189c324ce283d1e79a33776ee40f
