If the power button is pressed for a shorter period than the debounce
timeout, then the debounced state never changes. This was causing the
power button state machine to disable scanning (in the interrupt
handler) but never re-enable it (in the deferred handler).
Easy fix; just re-enable based on whether the current state is
released, not whether the debounced state is transitioning to
released.
BUG=chrome-os-partner:21772
BRANCH=all (falco, pit, etc.)
TEST=type on console. briefly flick power button. type more; should work.
Change-Id: I9723a6aa10f122fcee62702b85ce7981b1c8103a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/65238
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This fixes a confusing indication in flashinfo, where the all_now flag
is set but banks aren't shown as protected now.
BUG=chrome-os-partner:20277
BRANCH=pit
TEST=See bug for full test procedure. In short:
1) Enable physical write protect
2) flashwp enable
3) flashwp now
4) flashinfo shows all banks protected now
Change-Id: I489e80f63a33c182629d3a04fd0a9dadfb3914ab
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64980
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Rather than have every board check for tasks before declaring their
config macros, have config.h know what configs are invalid without
their corresponding tasks.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all platforms and pass unit tests
Change-Id: Iecf6eb44782e15565eaaf6d69c6288ee8d2e4c4c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/65010
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Daisy systems are few and far between, and not actively used for
development now that we have pit. Remove the I2C port detection which
was used for early systems, and just hard-code the port value to the
one on my daisy.
BUG=chrome-os-partner:10622
BRANCH=none
TEST=boot daisy
Change-Id: I981a51448899f75437f35dc2aa84a0556c0018eb
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64958
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Saving + restoring the channel print mask previously involved running
the 'chan' command with no parameters, then parsing the output. This
parsing is unreliable if other tasks are also writing to the console.
Add commands to save / backup the current channel mask, and later
restoring it. Typical method to limit channel mask will now be:
chan save
chan <mask>
...
chan restore
BUG=chromium:269758.
TEST=Run 'chan save' / 'chan 0' / 'chan restore' on EC console, verify
print mask is restored.
BRANCH=Peppy/Falco.
Change-Id: I725c7fb5e3ac7e55ed5f435446f8fc5c54af165f
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/65208
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This just replaces all the "X - 273", "Y + 273" stuff with a macro.
BUG=none
BRANCH=falco,peppy
TEST=manual
Run the EC console command "temps". It should print human-readable things.
Change-Id: Icc4284c89fdbc0cd3b206a0faacf121973652a63
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/65005
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When running certain ectool commands, our ioctl may succeed, yet our
command may not be successful for a variety of reasons (see ec_status
enum). In this case, we should return a non-success exit code so that we
can easily detect such failures in scripts.
BUG=chrome-os-partner:21171.
TEST=Pass FAFT suite on Peppy. Pass factory tests on Peppy.
BRANCH=None.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ia33b8285fb048b256f0668b709573e86c15f1162
Reviewed-on: https://gerrit.chromium.org/gerrit/64686
Reviewed-by: Vincent Palatin <vpalatin@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
GPIO alternate functions used to be configured throughout the code,
which made it hard to tell which ones you needed to configure yourself
in board.c. It also sometimes (chip/lm4/i2c.c) led to GPIOs being
configured as alternate functions even if they weren't used on a given
board.
With this change, every board has a table in board.c which lists ALL
GPIOs which have alternate functions. This is now the only place
where alternate functions are configured. Each module then calls
gpio_init_module() to set up its GPIOs.
This also fixes a bug where gpio_set_flags() ignored most of the flags
passed to it (only direction and level were actually used).
On stm32f, gpio_set_alternate() does not exist, and pins are
configured via direct register writes from board.c. Rather than
attempt to change that in the same CL, I've stubbed out
gpio_set_alternate() for stm32f, and will fix the register writes in a
follow-up CL.
BUG=chrome-os-partner:21618
BRANCH=peppy (fixes I2C1 being initialized even though those pins are used
for other things)
TEST=boot link, falco, pit, spring
Change-Id: I40f47025d8f767e0723c6b40c80413af9ba8deba
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64400
It looks like a line of code was accidentally left in during
refactoring gpio_set_flags(). That line is equivalent to
gpio_set_level(signal, 0).
It's so far been harmless, because it's immediately followed by
gpio_set_level(signal, 1) - but it does mean the signal may glitch for
a few clocks at this point.
BUG=chrome-os-partner:21678
BRANCH=none (or Spring, but it seems to work fine even with this line)
TEST=boot Spring
Change-Id: Id7a48e2c9bd543f2aa6a0b710faa5dd2b482fd84
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64719
This includes:
- Kirby doesn't use TPS65090. Removing TPS65090 config flag.
- TIM3 is used by charging LED. Move timer to TIM2.
BUG=chrome-os-partner:21607
TEST=Build kirby.
BRANCH=None
Change-Id: I226660cf53371e03730ca41d08f0da2ad5c8ebf7
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64811
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Jeremy Thorpe <jeremyt@chromium.org>
The power button LED is on PA2, not PB3. Remove a line of code
accidentally left in from copy-paste at the start of pit bringup.
BUG=chrome-os-partner:21676
BRANCH=pit
TEST=boot pit
Change-Id: Id991b16d69bca0a411efa72211c5dc407923240d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64714
Reviewed-by: Vic Yang <victoryang@chromium.org>
We started SPI development on the Snow platform, but then repurposed
some of the GPIOs to use for I2C arbitration. Now that we have Pit,
we'll never go back and finish SPI on Snow, so this code can be removed.
Remove the remaining dead code from Snow. This makes it easier to do the
GPIO alternate function refactoring.
BUG=chrome-os-partner:21618
BRANCH=none
TEST=build snow
Change-Id: I1cebf5097ecfd1dc6b3f55f2bbc47cb6c95cb937
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64712
Reviewed-by: Vic Yang <victoryang@chromium.org>
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>
GPIO mappings are according to current schematic. Charging and power
sequence code need to be fixed. Charging is disabled now, and some power
sequence code is #ifdef'd out for kirby to compile.
BUG=chrome-os-partner:21607
TEST=Build all boards (including Kirby.)
BRANCH=None
Change-Id: I3a48a7779dab8aad0d086c41e0be19223cd7d6c9
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64364
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This moves per-test config flags from test_config.mk to test_config.h,
where one can define/undefine config flags for individual test.
BUG=chrome-os-partner:19235
TEST=Pass all tests
BRANCH=None
Change-Id: I096aded2007881433d3b6414d37f8bfdc6a2c45c
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64367
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
No functional changes; just moving file
BUG=chrome-os-partner:21612
BRANCH=none
TEST=onewire red / onewire green / onewire yellow all set the adapter LED
(tested on link, since I don't have a bolt, but the EC chip and adapter
are identical)
Change-Id: I005abf871caafa39e82e88875b515c842a12d591
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64376
Reviewed-by: Vic Yang <victoryang@chromium.org>
This is cleaner than having the charge state machine explicitly know
about the power button task.
BUG=chrome-os-partner:21610
BRANCH=none
TEST=reboot EC; see that power button task does not leave init-on state until
just after the charge state initializes:
[0.022646 Charge state init -> idle0 after 0.005908 sec]
[0.022956 PB task 8 = init-on]
[0.023147 PB PCH pwrbtn=LOW]
[0.023303 PB task 6 = released, wait 199996]
Change-Id: I11d70103e3ee545512efe621f53d999680a7ad56
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64366
Reviewed-by: Vic Yang <victoryang@chromium.org>
There's no need for it to directly access the GPIO registers. That
was only necessary at the beginning of link, when gpio_set_flags()
didn't exist.
BUG=chrome-os-partner:21612
BRANCH=none
TEST=onewire red / onewire green / onewire yellow all set the adapter LED
(tested on link, since I don't have a bolt, but the EC chip and adapter
are identical)
Change-Id: I2386962ff039bb2251be38eaadcaeae8ffd1ea7b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64375
Reviewed-by: Vic Yang <victoryang@chromium.org>
Previously, processing of arrow keys and control characters was done
in the interrupt handler itself. This increased the impact of UART
input on other interrupts and high-priority tasks. It also makes it
harder to implement DMA-based UART input on STM32L (in an imminent
CL), since the processing affected the circular UART input buffer
in-place.
This change turns uart_buffering.c back into a dumb I/O buffering
module, and puts all the command line editing and history support into
console.c.
Console history is done via a simple array of input lines instead of a
packed circular buffer of characters. This is a little less
RAM-efficient, but is easier to implement and read. History depth is
controlled via CONFIG_CONSOLE_HISTORY, and is 3 for STM32F and 8 for
other platforms. If we really need a greater history depth, we can
look into implementing a packed circular buffer again, but this time
at task time in console.c. Also added a 'history' command to print
the current console history.
BUG=chrome-os-partner:20485
BRANCH=none
TEST=console_edit unit test passes; 'history' command prints the last commands
Change-Id: I142a0be0d67718c58341e4569f4e2908f191d8b0
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64363
Reviewed-by: Vic Yang <victoryang@chromium.org>
The registers.h file should only be included by code in the chip/ and
board/ directories. Code outside those directories should not access
chip-specific registers.
(This change doesn't completely fix that, because
common/extpower_usb.c uses STM32-specific regs, but we'll fix that in
a separate CL.)
BUG=chrome-os-partner:18343
BRANCH=none
TEST=compile all platforms
Change-Id: Ic499f56690c38663083423b0593800161a68e6e9
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64382
Reviewed-by: Vic Yang <victoryang@chromium.org>
Remove support for allowing host command handlers to set the response
pointer. This is just one more thing that can break (and did, on SPI
protocol V2). No commands other than the trivial read-memory-map
command in host_command.c and flash read made use of this capability,
and the savings in performance was negligible.
BUG=chrome-os-partner:21576
BRANCH=none
TEST=boot pit; still boots
Change-Id: I0a9bcf57dbea7155318fc389d7b47d3742a1a00a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64236
BUG=chrome-os-partner:20145
BRANCH=falco
TEST=Hack it. Add (uint64_t)599 * MINUTE to ctx->curr.ts.val
in the timeout comparison. This makes the 10 hour timeout only
take 1 minute. Testing this directly is tricky as a healthy battery
will charge quickly. If you force it to trickle charge it will
give up before 10 hours pass.
Change-Id: I69094a07e58c2d65e322ddc6a1b2ced828da0e26
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64309
BUG=chromium:267146
BRANCH=falco,peppy
TEST=Manual. Observe charge state messages on the ec console.
Change-Id: I25f04db56bf62394b5bb2e0d56edbda3a0bb5e25
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64280
This would allow us to do something like:
util/make_all.sh -j32
util/make_all.sh V=1
BUG=None
TEST=util/make_all.sh -j
TEST=util/make_all.sh V=1
BRANCH=None
Change-Id: Ifed0baf6c94fbe8b0296cbdc70ba84f92f04b75b
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64268
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
They're now called from a deferred function call, which is done in the
hook task and not the chipset task.
No code changes.
BUG=none
BRANCH=none
TEST=compile code
Change-Id: I115b6b254bd2b0ddd9688df603621e7ce0c12e1e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64258
Reviewed-by: Vic Yang <victoryang@chromium.org>
It takes ~250ms for TSU6721 to recognize a CDP charger. Let's shorten
the redetecting delay from 4 seconds to 600ms so that:
1. A CDP charger is recognized faster
2. We can properly detect overcurrent for CDP charger
BUG=chrome-os-partner:21388
TEST=Plug in a CDP charger and see it recognized after 600ms.
BRANCH=Spring
Change-Id: Id5020132686f8cfabb126e2fb57e7e75e3868775
Original-Change-Id: Iafbc677fbcdd4eb9e6cf276cc0219b965eb35ef5
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63814
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64277
With this, we are able to boot with a super dead battery even with a bad
charger. This however breaks support for chargers that cannot even
supply 100mA, but that's very unlikely to happen.
BUG=chrome-os-partner:21107
TEST=Charge a dead battery with a bad charger and a super long cable.
BRANCH=Spring
Change-Id: I3c532523456185223420a4381f56365ad3afb2ec
Original-Change-Id: I6b7b0df0ae7bdf863420755ea92e09d87f6866c3
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63804
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64276
To prevent the EC browning out when the battery is too low, let's always
pull 500mA before we can determine the charger type. The correct current
limit can then be set after we know the charger type.
Also, even if the battery is not present, keep the PWM tweaking loop
going.
BUG=chrome-os-partner:21107
TEST=Plug in charger to a device with a dead battery and see it charge.
BRANCH=Spring
Change-Id: Iad5599b60d20fb405d78d30b2be74bcc98958dd5
Original-Change-Id: Iec2ec96e3c2c341f14888aa50bd84f72af75c073
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63626
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64275
Even if the charge state machine is in idle mode, we should still show
yellow LED if the battery is not fully charged. This prevents the case
where the LED is green when the battery just comes back from cut-off
mode.
BUG=None
TEST=Cut off the battery. Plug in the charger and doesn't see green LED.
BRANCH=Spring
Change-Id: I079bcc19fcfff98a498cd9e3d2f99f0566b15fe4
Original-Change-Id: I14e6b3d32e04992bd8291da4b8b95e8e23a3acf0
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63459
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64274
With this, we can more precisely distinguish a video dongle and an USB
host. The downside is that old boards with ID_OUT connected instead of
CABLE_DET will lose the ability to use a video dongle.
BUG=chrome-os-partner:21310
TEST=Plug in USB host in S5 and see it's detected correctly.
BRANCH=Spring
Change-Id: I26856593a9fc1ef99c60b27aef3a53538e96f482
Original-Change-Id: I1116ac447bbc0b491f88fa38c16ff57501fe0288
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63297
Reviewed-by: Jeremy Thorpe <jeremyt@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64273
This reverts commit 154c73f32d.
The kernel driver to control TPS65090 FETs is now submitted in our tree,
and turning on the FET3 connected the 3G modem by default.
So let's remove the hardcoded to allow better power management policy on
the CPU side.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=spring
BUG=chrome-os-partner:17790
TEST=on Spring, boot and dump the TPS65090 configuration from the EC
command line by using "pmu" command.
See 0x1f in the register 0x11 for FET3.
Change-Id: Ie699fef0348138a7483f0e8e7bcaebc37810eba8
Original-Change-Id: I9de0f92a561397ceb81a67b8291d1e8bf04ade38
Reviewed-on: https://gerrit.chromium.org/gerrit/57978
Reviewed-by: Vic Yang <victoryang@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64271
Tested-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vic Yang <victoryang@chromium.org>
This fixes unaligned access exceptions when totally-unrelated code
changes happen to move around host_command.c's global variables.
BUG=chrome-os-partner:21578
BRANCH=none
TEST=add a ccprintf() call to host_command.c; no longer causes an exception
Change-Id: I5407e5631a08ea647dc40e5bd9c7bd101868ced0
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64233
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The following signals were not being initialized properly in the
forcing G3 path:
- GPIO_SYS_PWROK
- GPIO_PP3300_DSW_GATED_EN
This lead to the EC RW sysjump, but the boards wouldn't reboot
on the x86 side. Sadly, without this change, the board I have
works. However, those signals need to be driven low.
BUG=chrome-os-partner:20372
BRANCH=None
TEST=Willis tested on boards that previously didn't work.
Change-Id: I1771881485bc5be73ed2b08da91fddff9ab09167
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63845
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This wraps the EC_HOST_EVENT_THROTTLE_START/STOP host events in a new
function called host_throttle_cpu(), similar to chipset_throttle_cpu().
That function requests the AP to throttle itself, which is less drastic than
just smacking it down from the EC.
BUG=chrome-os-partner:20805
BRANCH=falco,peppy
TEST=manual
This is a refactoring change only. All boards should still build, all tests
should still pass.
Change-Id: I871cce8f0e13230cb52eeb5e16955266f8461374
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63909
Reviewed-by: Randall Spangler <rspangler@chromium.org>
We've been declaring a bunch of statically-sized arrays:
extern struct foo_t foo[FOO_COUNT];
And then initializing them like so:
struct foo_t foo[FOO_COUNT] = {
/* blah */
};
That only catches cases where we initialize with too many entries. It
doesn't catch cases where we haven't initialized enough. This change tests
for both cases like so:
extern struct foo_t foo[];
struct foo_t foo[] = {
/* blah */
};
BUILD_ASSERT(ARRAY_SIZE(foo) == FOO_COUNT);
The affected arrays are:
adc_channels[ADC_CH_COUNT]
gpio_list[GPIO_COUNT]
temp_sensors[TEMP_SENSOR_COUNT]
x86_signal_list[X86_SIGNAL_COUNT]
i2c_ports[I2C_PORTS_USED]
BUG=chrome-os-partner:18343
BRANCH=falco,peppy
TEST=build all platforms
All platforms should still build, all tests should still pass.
Change-Id: Ibb16dc3201f32df7cdc875648e89ba4ffb09f733
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63833
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This got dropped during some of the recent clean up.
BUG=None
BRANCH=slippy
TEST=Manual. Check that the LED on slippy is working.
Change-Id: I80505c5df72410c9f25521d0c116fc59da5cb1db
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63886
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Before this change, powerinfo host command supports only one target
with USB charging. This change adds a common powerinfo host command
and console command for TPSChrome based targets.
BRANCH=None
BUG=chrome-os-partner:20326
TEST=manual
build and flash pit target, check console command 'powerinfo'.
check ectool powerinfo with and without AC adapter.
Change-Id: I2cfd8dfa011e23f819c6bae19cf22b4a7343f044
Signed-off-by: Rong Chang <rongchang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63350
Reviewed-by: Vic Yang <victoryang@chromium.org>
There are a few issues with console output:
1. The EC was returning more bytes than the message's insize. The
reason stems from a refacotring that the set the global
ec_max_insize variables to 'EC_PROTO2_MAX_PARAM_SIZE - 8'.
It really should be EC_PROTO2_MAX_PARAM_SIZE to cover the
maximum packet size returned from the EC.
2. A change was made to handle EAGAIN returning from the EC kernel
driver's ioctl() interface. That change prevented 0 bytes received
from being returned properly.
The first issue occurs because the EC console is always larger than
what the original ec_max_insize was set to. This caused no console
messages to be displayed. The second issue causes the console command
to potentially loop forever because the drain of the EC console is
never indicated because 0 could never be returned.
BUG=chrome-os-partner:21165
BRANCH=falco,peppy
TEST=Built and can now read 'ectool console' output as well
as not including gargabe.
Change-Id: I3114594f0020a5198532aa78ce126f4da6caf09a
Reviewed-on: https://gerrit.chromium.org/gerrit/63445
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Tested-by: Aaron Durbin <adurbin@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>
The Silego chip has a 50k pulldown which will leak power if we leave
EC_ENTERING_RW high. We don't need to leave it high, because once the
latch in the Silego gets set it ignores this signal. This is ~100uA,
so it only really matters in S5 on pit (since x86 boards and spring
both hibernate in S5).
BUG=chrome-os-partner:20757
BRANCH=none
TEST=probe ec_in_rw signal before/after sysjump
Change-Id: Ib6b09cfc7718b35e4e93c952c3098c08d53572e2
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/62133
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Some chargers can run in a "turbo" mode, which lets it draw from the battery
to provide extra power to the AP in short bursts. In order for this to work
properly, the EC has to watch the current closely to make sure specific
limits are observed. It also has to recognize specific adapters, since those
limits vary depending on the rated power that the adapter can provide.
This adds the basic functionality, plus a test for it.
BUG=chrome-os-partner:20739
BRANCH=falco,peppy
TEST=manual
make BOARD=${BOARD} runtests
On Falco, you can also use the "adapter" EC command to see what's going on.
Try replacing the adapters and running that command to be sure they're
correctly identified, too:
> adapter
Adapter 65W (590mv), turbo 1, AP_throttled 0
>
We currently support 45W, 65W, and 90W adapters. Unknown adapters are
treated as 65W, but don't enable turbo mode.
Change-Id: I7e5407db825ce7e596cb495fb8cb4d1dd1ff639c
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63372
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
We can't change CONFIG_ options from the gcc commandline, because
include/configs.h explicitly undefs them again. So for some tests, we add a
-DFOO to the command line and then put this in the source:
This change just uses TEST_FOO instead of FOO, so it's more obvious what's
happening.
BUG=chrome-os-partner:20739
BRANCH=falco,peppy
TEST=manual
No functional change, just renaming. Run
make BOARD=${BOARD} runtests
Everything should still pass.
Change-Id: I17e10180f8d779dff0961cf411f5b61cfc70c316
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63371
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Rename onewire_led to led_driver_ds2413, since we may have other LED
drivers hanging off a one-wire bus in the future.
No functional changes, just renaming config options.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all platforms
Change-Id: I1d70b1c5778da94bda4ebef3b57f7c39bfba2322
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63273
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
