This adds include/dptf.h to define the DPTF interface functions.
As the first DPTF feature, it also adds a register to the EC's ACPI
interface block. Register 0x04 is used to get and set the fan's target duty
cycle, as a percentage value. Writing a 0 to this register will set the
target duty cycle to 0, writing a 100 (0x64) will set it to 100%. Writing
any other value will return the fan control to the EC, rather than driving
it manually from the host.
Likewise, reading from this register returns the current fan target duty
cycle, as a percentage. If the EC is controlling the fan automatically, the
returned value will be 0xFF.
BUG=chrome-os-partner:23972
BRANCH=none
TEST=manual
You can monitor the fan state from the EC console with the "faninfo"
command. From the host side, test this interface from a root shell.
Read fan duty:
iotools io_write8 0x66 0x80
iotools io_write8 0x62 4
iotools io_read8 0x62
Set fan duty to 100%:
iotools io_write8 0x66 0x81
iotools io_write8 0x62 4
iotools io_write8 0x62 100
Set fan duty to 50%:
iotools io_write8 0x66 0x81
iotools io_write8 0x62 4
iotools io_write8 0x62 50
Set fan duty to 0%:
iotools io_write8 0x66 0x81
iotools io_write8 0x62 4
iotools io_write8 0x62 0
Set fan control back to automatic:
iotools io_write8 0x66 0x81
iotools io_write8 0x62 4
iotools io_write8 0x62 -1
Change-Id: I91ec463095cfd17adf452f0967da3944b254d558
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/177423
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The struct lightbar_params used to communicate lightbar settings between the
AP and the EC uses just "int" for some of its fields. The AP currently uses
32-bit values for "int" in both 64-bit and 32-bit mode, but that's just luck
since C only requires that "int" be at least 16 bits.
This change makes the size explicit.
BUG=none
BRANCH=none
TEST=manual
There should be no visible change.
ectool lightbar params > /tmp/foo
ectool lightbar params /tmp/foo
Change-Id: I4d77c16b3c68e179292b824938d2d012e917ad13
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176364
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
This adds space for up to two ALS lux readings to be available to the AP
through the memory-mapped LPC region. If enabled, the values are updated
once a second.
The ALS will be reinitialized at every AP resume, since it's typically
unpowered otherwise. The reported value will be zero when the ALS is off.
BUG=chrome-os-partner:23380
BRANCH=samus
TEST=manual
Boot the AP, then from the EC console run "als" or just monitor the
memory-mapped region directly ("rw 0x40080780" on Samus), while pointing the
sensor at bright and dim areas. The value should change.
Change-Id: I705371fcd57345dc9adae1231ea30c7ff024aaf8
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176142
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Device-specific headers belong in driver/ or chip/. The include/
directory should be for common interfaces.
Code should not normally need to include driver-specific headers. If
it does, it should use the full relative path from the EC project root
(for example, drivers/charger/bq24715.h).
Change-Id: Id23db37a431e2d802a74ec601db6f69b613352ba
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173746
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Some of the comments no longer apply. Others needed more info.
No code changes; just comment changes.
BUG=none
BRANCH=none
TEST=build all platforms
Change-Id: I1d52aa9a98427a78c9d9a8cf44934fb04c3c00c8
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174084
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The fixme was just a feature request. I've moved it to a new bug.
Comment change only; no code changes.
BUG=chrome-os-partner:23457
BRANCH=none
TEST=build rambi
Change-Id: Ie3fc0482b6697c12040b868ba837073929cf5b82
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173921
Reviewed-by: Vic Yang <victoryang@chromium.org>
We've removed a few constants from the exported header file since the last
big sync. Just in case some of them are still in use (coredump, flashrom),
let's make it easy to redistribute the header unchanged. We can remove them
for real next time.
BUG=chromium:251441
BRANCH=none
TEST=manual
Compile, test, run, etc. This CL just adds back some unused (by the EC)
constants that were previously removed, so nothing should change.
Change-Id: Ia9889db89a90d56c8154fea1e8c8a483fdcae805
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170522
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Having a per-device enum list for use by the EC_CMD_GET_SET_VALUE command
won't work when the one-and-only ectool tries to talk to different devices.
Any particular enum may be missing or have a completely different meaning.
Instead, we can do the same thing that EC_CMD_HOST_EVENT_* does - use the
same structs for a bunch of different commands.
If/when we run out of command numbers (it's currently only 8 bits), we'll
just switch to using EC protocol v3 (see crosbug.com/p/20820), which
provides 16 bits for the command.
This CL renames EC_CMD_GET_SET_VALUE to EC_CMD_GSV_PAUSE_IN_S5 (since that's
the one-and-only use of it at present), and renames the params/response
structs as well. Since only the names are changing, the implementation
remains backwards-compatible (assuming the flags value usage is preserved by
ectool for the EC_CMD_GSV_PAUSE_IN_S5 command, which it is).
If I can cherry-pick this change into the one place where it's being used, I
will.
BUG=chromium:287969
BRANCH=ToT
TEST=manual
Although this is primarily an internal name change, it also means that the
commands to invoke the previous usage of this feature have changed. To test:
On Haswell systems only.
To enable the pause in S5 at shutdown, do either of these:
EC console: pause_in_s5 on
root shell: ectool pause_in_s5 on
Shut the AP down politely, and it should pause in S5 for 10 seconds before
continuing to G3. You can see this by watching the EC console.
To disable the pause in S5 at shutdown, do any of these:
EC console: pause_in_s5 off
root shell: ectool pause_in_s5 off
or
press Refresh + POWER
Boot the system, then politely shut down. This time it should go directly to
G3 without pausing in S5.
Change-Id: Ic614fed37ad89db794c2bbcca2b83d1603030ab2
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168816
This adds EC_CMD_GET_SET_VALUE to the list of host commands. We have a bunch
of single-value getter/setter commands, which is wasteful. This is a start
towards unifying them into a simpler command.
BUG=chromium:285358
BRANCH=ToT,falco
TEST=none
There's nothing to test just yet. This just adds the command and some basic
interfaces. A future commit will make use of it.
Change-Id: Iee986b9d273b422bb06f3a0c9b7af50617f03d7f
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168083
Reviewed-by: Randall Spangler <rspangler@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>
Problems with existing thermal control loop:
* Not multi-board friendly. thermal.c only supports Link and needs
refactoring. Temp thresholds and fan speeds are hard-coded.
* Only the PECI temp is used to determine the fan speed. Other temp sensors
are ignored.
* Has confusing data structures. Values in the CPU temp thresholds array mix
ACPI thresholds with fan step values.
With this change, the thermal task monitors all temp sensors in order to
perform two completely independent functions:
Function one: Determine if the host needs to be throttled by or informed of
any thermal events.
For thermal events, each temp sensor will have three threshold levels.
TEMP_HOST_WARN
* When any sensor goes above this level, host_throttle_cpu(1) will be called
to ask the CPU to slow itself down.
* When all sensors drop below this level, host_throttle_cpu(0) will be called.
* Exactly AT this level, nothing happens (this provides hysteresis).
TEMP_HOST_HIGH
* When any sensor goes above this level, chipset_throttle_cpu(1) will be
called to slow the CPU down whether it wants to or not.
* When all sensors drop below this level, chipset_throttle_cpu(0) will be
called.
* Exactly AT this level, nothing happens (this provides hysteresis).
TEMP_HOST_SHUTDOWN
* When any sensor is above this level, chipset_force_shutdown() will be
called to halt the CPU.
* Nothing turns the CPU back on again - the user just has to wait for things
to cool off. Pressing the power button too soon will just trigger shutdown
again as soon as the EC can read the host temp.
Function two: Determine the amount of fan cooling needed
For fan cooling, each temp sensor will have two levels.
TEMP_FAN_OFF
* At or below this temperature, no active cooling is needed.
TEMP_FAN_MAX
* At or above this temperature, active cooling should be running at maximum.
The highest level of all temp sensors will be used to request the amount of
active cooling needed. The function pwm_fan_percent_to_rpm() is invoked to
convert the amount of cooling to the target fan RPM.
The default pwm_fan_percent_to_rpm() function converts smoothly between the
configured CONFIG_PWM_FAN_RPM_MIN and CONFIG_PWM_FAN_RPM_MAX for percentages
between 1 and 100. 0% means "off".
The default function probably provide the smoothest and quietest behavior,
but individual boards can provide their own pwm_fan_percent_to_rpm() to
implement whatever curves, hysteresis, feedback, or other hackery they wish.
BUG=chrome-os-partner:20805
BRANCH=none
TEST=manual
Compile-time test with
make BOARD=falco runtests
On the EC console, the existing fan commands should work correctly:
faninfo - display the fan state
fanduty NUM - force the fan PWM to the specified percentage (0-100)
fanset RPM - force the fan to the specified RPM
fanset NUM% - force the fan to the specified percentage (0-100) between
its configured minimum and maximum speeds from board.h
(CONFIG_PWM_FAN_RPM_MIN and CONFIG_PWM_FAN_RPM_MAX)
fanauto - let the EC control the fan automatically
You can test the default pwm_fan_percent_to_rpm() with
fanset 1%
faninfo
The fan should be turning at CONFIG_PWM_FAN_RPM_MIN. Let the EC control it
automatically again with
fanauto
Also on the EC console, the thermal settings can be examined or changed:
> temps
PECI : 327 K = 54 C
ECInternal : 320 K = 47 C
G781Internal : 319 K = 46 C
G781External : 318 K = 45 C
>
> thermalget
sensor warn high shutdown fan_off fan_max name
0 373 387 383 333 363 PECI
1 0 0 0 0 0 ECInternal
2 0 0 0 0 0 G781Internal
3 0 0 0 0 0 G781External
>
> help thermalset
Usage: thermalset sensor warn [high [shutdown [fan_off [fan_max]]]]
set thermal parameters (-1 to skip)
>
> thermalset 2 -1 -1 999
sensor warn high shutdown fan_off fan_max name
0 373 387 383 333 363 PECI
1 0 0 0 0 0 ECInternal
2 0 0 999 0 0 G781Internal
3 0 0 0 0 0 G781External
>
From the host, ectool can be used to get and set these parameters with
nearly identical commands:
ectool thermalget
ectool thermalset 2 -1 -1 999
Change-Id: Idb27977278f766826045fb7d41929953ec6b1cca
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66688
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Glue between the existing ectool led command and the
led control logic.
BUG=chrome-os-partner:20776
BRANCH=peppy
TEST=Manual. Run "ectool led" commands:
Should pass:
ectool led power blue|yellow|off|auto|blue=1 yellow=1
ectool led battery blue|yellow|off|auto|blue=1 yellow=1
Should fail:
ectool led adapter <color>
ectool led power|battery red|green|white
Signed-off-by: Dave Parker <dparker@chromium.org>
Change-Id: I2540940baa553866760dd9ae62278b6b845793ef
Reviewed-on: https://gerrit.chromium.org/gerrit/64627
The old low-level SPI protocol provided no useful information to the
host about whether it was ready to receive or not. It also could get
stuck waiting to receive data without setting up receive DMA, if the
host did two transactions back-to-back.
Add a real state machine to the SPI module.
Add a range of byte codes the EC can return outside of a response
frame, to indicate its current state. If the AP receives one of these
codes, it can abort the transaction since it now knows the EC is
unable to determine when it can send a response frame.
This change is backwards-compatible with current AP firmware and
kernel drivers, since those only look for the framing byte and don't
care what other bytes are received in the meantime.
BUG=chrome-os-partner:20257
BRANCH=none
TEST=crosec test; passes at 70us.
Change-Id: Ia06109ead3fbc421848e01050f7baf753cbeb16c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64254
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Occasionally the EC wants to ask the AP to throttle itself. Currently, the
only thing that the EC can do (at least on x86) is to assert the PROCHOT#
signal, which is a fairly intrusive operation and one that Intel suggests we
save for emergencies.
This CL adds a new pair of host events to ask the BIOS to throttle the AP
politely, or stop doing so. The turbo charger code will send these events to
the AP if they become necessary.
BUG=chrome-os-partner:20739
BRANCH=falco,peppy
TEST=manual
Tests should still pass, everything else is unchanged.
make BOARD=${BOARD} runtests
Currently, there's nothing on the BIOS/OS side that would respond to these
events, so they're just ignored. You can test that, even without this CL, by
running
hostevent set 0x40000
hostevent set 0x80000
Change-Id: I4a7a1b6eb87e42df94ddd09f4c6abee6ebcbd485
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63379
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add an enum for the number of flash regions so we can keep track of all
the possible regions.
(This is used in U-Boot which wants to declare an array of all possible
regions.)
BUG=chromium:244019
BRANCH=none
TEST=manual
Build EC for pit.
Change-Id: I494d857f1388dcc5c64b1cd580cf0084bdef0212
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/62701
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Expands and renames ectool 'chargeforceidle' command to
'chargecontrol'. Board-specific calls are needed to enable and
disable the discharge while on AC power state.
BUG=chrome-os-partner:20506
BRANCH=falco,peppy
TEST=Run ectool chargecontrol command with each option (normal,
idle, discharge) on Falco and Peppy. Verifiy battery is discharging
in discharge mode via EC console 'battery' command.
Change-Id: I7ac2b18b4f143bf6abc1e0bb878ad21a99f52100
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60689
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This adds two new fields: the ideal write size for best EC flashing
performance (e.g., page mode instead of word mode), and a flags field
with a flag to indicate whether the EC erases its bits to 0 or 1.
The EC still supports the old version 0 command, since u-boot and
flashrom expect that to work.
BUG=chrome-os-partner:20973
BRANCH=(all haswell); this will speed up flashing and software sync
TEST=ectool flashinfo
1. old EC, new ectool -> only reports version 0 info
2. new EC, old ectool -> only reports version 0 info
3. new EC, new ectool -> reports new fields
Change-Id: I484327fe22a58d2b69d7f6ac767b2d3e81b3e0b7
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/62378
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Chipset control of wireless power uses the new API instead of overriding
the wireless power itself.
Refactor board-specific support for it to just a few config #defines
instead of board-specific functions. This makes some assumptions
about the polarity of the enable signals. Not making those
assumptions would require defining an array of structs or some other
heavier-weight board-specific info. Since the assumptions hold for
all current boards, let's make them now because this is a step in the
right direction, and reserve doing something more general until we
actually have a use case for it (so we build in just the flexibility
we need).
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all platforms; see that link wifi turns on at boot and off at
shutdown (verify via 'gpioget' from EC console)
Change-Id: Ic036e76158198d2d5e3dd244c3c7b9b1e8d62982
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61608
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
These constants are scattered around the various interface
implementations and should be in one place. This will also clean up
the u-boot side when ec_commands.h is copied there.
BUG=chrome-os-partner:20257
BRANCH=none
TEST=build link, spring, pit; test 'ectool hello'
Change-Id: Ib1425db00ec8220538d8c5c65107ac9548009516
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60810
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
This is necessary to support larger packet sizes for host protocol
ver.3. The host previously didn't have any way to know how big a
packet the EC could accept / respond with (except on LPC, where the
size is determined by the I/O window).
BUG=chrome-os-partner:20257
BRANCH=none
TEST='ectool protoinfo' returns good info; on link,
Protocol info:
protocol versions: 2 3
max request: 256 bytes
max response: 256 bytes
flags: 0x00000000
and on pit,
Protocol info:
protocol versions: 2 3
max request: 544 bytes
max response: 544 bytes
flags: 0x00000001
Change-Id: Ic1e3831d9b4a96ffbf365c0d09b6023472de39a9
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60703
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Version 1 of EC_CMD_FLASH_WRITE will use as big a write as possible given
the available command parameter space. Falls back to 64 byte writes on old
platforms.
BUG=chrome-os-partner:20571
BRANCH=none
TEST=Copy burn_my_ec onto a link and run it. Write size should be 64 bytes
for the first half of the update (since the old EC doesn't support ver.1
of the write command) and 240 bytes for the second half of the update.
Change-Id: I5900de3a5700d7c82a2e0c3cf9921b7ced1c0343
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60511
The maximum packet length for LPC is limited by the I/O space window
size. But that's not the case for SPI or LPC. Rename LPC constant
before adding a SPI constant.
BUG=chrome-os-partner:20257
BRANCH=none
TEST=build link
Change-Id: I088327a11eff18d401c773db953700a36f9c1bb4
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59959
This lets us force the EC to return various error codes, so that we can be
sure we're seeing them.
BUG=chromium:242706
BRANCH=none
TEST=none
Trigger various errors like so:
ectool test 0 14
ectool test 1 14
ectool test 5 14
ectool test 8 14
ectool test 0 33
Change-Id: Ia951cd7afacdcce6c8ec7d35d3bfb5b113dea694
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59327
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This will fix EC flash commands on pit, once the host side (u-boot and
cros_ec driver) are upgraded to match.
This change is backwards-compatible the EC still supports the existing
version 2 protocols for talking to existing AP/kernel/ectool.
Once the AP-side supports version 3 for SPI (and existing systems are
upgraded), we will remove older SPI support since we haven't shipped a
product which uses SPI.
BUG=chrome-os-partner:20257
BRANCH=none
TEST=disable cros_ec driver support in ectool; 'ectool hello' works on link
And with an old ectool which predates this CL, 'ectool hello' also works.
On pit, from u-boot prompt, 'crosec test' and 'crosec version' work, and
keyboard works.
Change-Id: I01f193e316e9aa442fe50d632dc8a4681723e282
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58908
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit-Queue: Doug Anderson <dianders@chromium.org>
This is preparation for the common userspace EC interface. If/when that
appears, this will be ready.
BUG=chromium:239197
BRANCH=all
TEST=manual
Build, install, run it. Shouldn't be any change.
Change-Id: I9fa78515ec5443ba659f10a66bbaadcb7f4802b0
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56131
This adds the option to specify which LED to control as well as the
ability to query the supported LED color on the board.
BUG=chrome-os-partner:19745
TEST=On Spring:
- ectool led 0 query -> See the max value for R, G, Y is 0x80.
- ectool led 1 query -> See error message.
- ectool led 0 yellow -> See LED turns yellow.
- ectool led 0 green=0x40 red=0x40 -> See green and red lit up.
- ectool led 0 auto -> See LED turns off (without charger.)
BRANCH=spring
Change-Id: Ibdde2f7450122f59383dad1030a0a2a985386f73
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56877
Haswell devices have EC control of the WWAN power rail.
Expose a new wireless switch enable flag for this under
the existing wirless enable command.
This change also abstracts the wireless enable function
to call a per-board handler so the different boards can
do the right thing based on their GPIO setup.
The haswell boards will switch WLAN radio and WWAN power
rails based on the switch inputs. These boards do not have
EC control of bluetooth radio/rail power.
WLAN (power and radio) still defaults to enabled. Disabling
with ectool will turn off the radio but keep the power enabled
in order to prevent the PCIe device from disappearing.
WWAN (power) still defaults to disabled. Disabling with
ectool will turn off the power rail.
BUG=chrome-os-partner:19871
BRANCH=none
TEST=manual: boot on slippy
DEFAULT:
> ectool gpioget pp3300_wlan_en
GPIO pp3300_wlan_en = 1
> ectool gpioget wlan_off_l
GPIO wlan_off_l = 1
> ectool gpioget pp3300_lte_en
GPIO pp3300_lte_en = 0
ENABLE WWAN:
> ectool wireless 0x7
Success.
> ectool gpioget pp3300_lte_en
GPIO pp3300_lte_en = 1
DISABLE WLAN (radio):
> ectool wireless 0x7
Success.
> ectool gpioget pp3300_wlan_en
GPIO pp3300_wlan_en = 1
> ectool gpioget wlan_off_l
GPIO wlan_off_l = 0
Change-Id: I6f760b8cf5ab47d8f7f0dd8cd4d3e6563464043e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57215
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This provides a way to control LED color with ectool. We can either set
the color or switch back to automatic control.
BUG=chrome-os-partner:19745
TEST=ectool led red -> LED turns red.
ectool led green -> LED turns green.
Unplug charger -> LED turns off.
ectool led green -> LED turns of and shows green.
ectool led auto -> LED back to normal.
BRANCH=spring
Change-Id: I0b455f34cea448660fe44a5fecaac1cb084f8144
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56721
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Nothing has used this since link EVT, so it's just dead code at this point.
BUG=chrome-os-partner:13213
BRANCH=none
TEST=manual
- Update ectool but leave old firmware
- ectool version -> works
- ectool flashread 0 0x10000 foo -> puts the first 64KB of EC flash into foo
- Update firmware
- ectool version -> works
- ectool flashread 0 0x10000 foo -> puts the first 64KB of EC flash into foo
- power+esc+refresh -> recovery mode
Change-Id: Ib25a705bcd8280d5295c8e7890969d796542b6c9
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47866
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This is useful for debugging and the factory.
BUG=chrome-os-partner:18530
TEST=On spring, check we can set PWM duty cycle and can go back to
automatic control.
BRANCH=spring
Change-Id: I3da75f0a356cc0f21d748bf135e3b95fbd9c465b
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47105
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This was left over from the way we reported keyboard recovery early in
link/snow, before we had host events. No shipping EC ever reported it.
Coreboot and u-boot look for this flag, so we can't repurpose it until
they ignore it too.
BUG=chrome-os-partner:18512
BRANCH=none
TEST=compile link,spring
Change-Id: I38fbf0fa7d958c3774c8b293d4be25faaecdadea
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47058
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Getting voltage and current can be handy when verifying hardware design.
Let's add host command to do this.
BUG=chrome-os-partner:17880
TEST=Manual on Spring
BRANCH=none
Change-Id: I4d4f6a42a9d0f917292d092e132ccd9ce3367fd6
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/43508
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Allow to send commands to the smart battery using EC commands when the
battery is connected to an I2C bus behind the EC.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:14314
TEST=on Spring, with a kernel including patch to use the pass-through
for the sbs-battery driver, run "power-supply-info" and see the correct
information.
Change-Id: Ie10f1c95afe4a33cf0b55d5a0de7640d5971ebb3
Reviewed-on: https://gerrit.chromium.org/gerrit/41289
Reviewed-by: Vic Yang <victoryang@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Allow to send commands to switch on/off the TPSchrome LDOs by using EC commands
when the TPSchrome chip is connected to an I2C bus behind the EC.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:14314
TEST=on Spring, with an updated bootloader, switch on screen FETs from
U-Boot instead of hardcoding them in the EC board code.
Change-Id: Ic6cebf04ba73a7c0ca2c54f532f8cf4c953ac0c1
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/41288
Reviewed-by: Vic Yang <victoryang@chromium.org>
To make test and bring-up easier, adds a host command for USB mux
switching.
BUG=chrome-os-partner:17111
TEST=manual
BRANCH=none
Change-Id: I9da43fe934881ce24f326275ef312c4e6a474f11
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/40586
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add an interface to allow the CPU to cap the maximum battery charging
current.
The maximum is removed every time the machine goes to S3 or S5.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=link
BUG=chrome-os-partner:16041
TEST=on Link, plug AC to charge the battery,
then run "ectool chargecurrentlimit 1200" and see
the charging current in "power-supply-info" decreasing to 1.2 A.
Change-Id: I10900e1c264d2db67809638ec0dcb836d721fa75
Reviewed-on: https://gerrit.chromium.org/gerrit/37532
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Reviewed-by: Rong Chang <rongchang@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
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>
Add EC commands for managing a list of keyscan events which the EC
should replay instead of its normal key scanning operation.
There are two commands: one adds to the list of events. The other
allows the list to be cleared, the sequence to be started, and the
resulting information to be collected.
BUG=chrome-os-partner:12179
BRANCH=none
TEST=manual for now:
On snow:
./ectool keyscan 10000 key_sequence.txt
See that the test passes.
Signed-off-by: Simon Glass <sjg@chromium.org>
Change-Id: Ie4c3e4d0f5c1dbf642185fec99b9201d47532ae1
Reviewed-on: https://gerrit.chromium.org/gerrit/35117
Commit-Ready: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@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>
BUG=chrome-os-partner:15174
BRANCH=link
TEST=manual, from root shell
- ectool temps all -> prints all temps
- ectool tmp006cal 1 0 0 0 0
- ectool temps all -> sensor 3 not calibrated
Change-Id: I16ee818c948fe90ac7c18b230c5d9f9a0ec83ded
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35288
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
At present the keyboard scan parameters are hard-coded, so changing them
requires a new EC image. This can be problematic if we want to adjust
the behavior of keyboard scanning since we must send an EC update.
Define the keyboard scan parameters and commands to get/set these
parameters.
Signed-off-by: Simon Glass <sjg@chromium.org>
BUG=chrome-os-partner:12179
BRANCH=snow,link
TEST=manual
Build for all boards
Change-Id: I715755cb5357503723b27ae33053dba1452e48e0
Reviewed-on: https://gerrit.chromium.org/gerrit/34656
Commit-Ready: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
This enables the OS to request the EC drop into its lowest-power
shutdown state. Targeted at end of factory flow, where the
at-shutdown variant is the desired variant because it allows the main
processor to shut down cleanly first.
BUG=chrome-os-partner:14838
BRANCH=link
TEST=from root shell,
ectool reboot_ec hibernate at-shutdown
shutdown -h now
System should shut down, and EC console should be unresponsive (since
it's hibernating). Press power button, and system should power back on.
ectool reboot_ec hibernate
System should shut down immediately. Press power button, and system
should power back on.
Change-Id: I8084a3a1bca6b7c201e090552b193fe1568708a2
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34569
Reviewed-by: Vic Yang <victoryang@chromium.org>
