Store our image size (known at build time) in our version struct (now
renamed to image_data). This will allow us to more efficiently determine
the size of an image in a follow-up CL.
Note that compatibility is broken for old ROs that do not include this
CL.
BUG=chromium:577915
TEST=Verify on kevin + lars + lars_pd that stored image size matches
output of system_get_image_used() for both RO and RW images.
BRANCH=None
Change-Id: I7b8dc3ac8cf2df3184d0701a0e0ec8032de8d81b
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/450858
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Currently if an interrupt is pending before it is enabled the interrupt
will fire immediately. In most cases this is fine, but if we want to
use the interrupt to trigger something like waking the AP it should be
sure that it won't immediately fire once enabled.
For example: on the Eve board we have the trackpad interrupt run to the
AP and the EC in order to support wake from Deep S3 (magic AP state that
only the EC can wake it from). This interrupt is used in S0 by the AP
while ignored by the EC, and then enabled on the transition to S3 in
order to be able to wake. Since it has been active the interrupt may
be pending in the EC (depending on the chip), which can result in the
interrupt firing immediately and waking the AP.
BUG=chrome-os-partner:62224
BRANCH=none
TEST=This has been functionally tested on npcx only as that is what I
have a use case and system for, the others compile and look right but
have not been directly tested.
Change-Id: I9e0877d99e7f09f4c30bf9861fbad81c12c059ad
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/446962
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Our previous idea to cut Rd for many reset cases cannot work if cr50
consistently resets the EC by asserting the reset pin shortly after
power-on. Therefore, make a decision based upon whether battery-backed
memory indicates we previously negotiated a PD power contract as a sink.
If we previously did not negotiate a contract, or if power was removed
from the device (causing battery-backed memory to wipe) then we can
assume that we don't have an active power contract.
BUG=chrome-os-partner:62952
BRANCH=reef
TEST=On reef, run "cutoff" on the console, reattach AC, and verify
device successfully wakes. Also verify Rp is dropped on console 'reboot'
and F3 + power from RW.
Change-Id: Ie300b9589cac6be7a69b77678bea6b1b6b25578c
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/443356
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add generic routines to read or write a byte to battery-backed RAM, and
implement vbnvcontext get/set using these routines.
BUG=chrome-os-partner:62952
BRANCH=reef
TEST=On reef, with subsequent commit, run "cutoff" on the console,
reattach AC, and verify device successfully wakes. Also verify Rp is
dropped on console 'reboot' and F3 + power from RW.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I14691923f2e5198e901b6b5199e92c58c68cd18d
Reviewed-on: https://chromium-review.googlesource.com/444444
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
In preparation for adding the rollback protection block, pass
EC_FLASH_PROTECT_RO/ALL_AT_BOOT to flash_[physical_]protect_at_boot,
instead of an enumeration no protection/RO/ALL.
This will later allow us to protect/unprotect the rollback region only,
by adding a EC_FLASH_PROTECT_ROLLBACK_AT_BOOT flag.
BRANCH=none
BUG=chrome-os-partner:61671
TEST=Build hammer with CONFIG_CMD_FLASH command, so that write protection
can be checked with flasherase/flashwrite.
TEST=On hammer (stm32f072):
flashinfo => RO+RW not protected
flashwp true; reboot => only RO protected
flashwp rw; reboot => RO+RW protected
flashwp norw; reboot => only RO protected
TEST=On reef (npcx):
deassert WP, flashwp false; flashinfo => RO+RW not protected
flashwp true => only RO protected
reboot => only RO protected
flashwp rw => RO+RW protected
reboot => only RO protected
Change-Id: Iec96a7377baabc9100fc59de0a31505095a3499f
Reviewed-on: https://chromium-review.googlesource.com/430518
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Store our image size (known at build time) in our version struct (now
renamed to image_data). This will allow us to more efficiently determine
the size of an image in a follow-up CL.
Note that compatibility is broken for old ROs that do not include this
CL.
BUG=chromium:577915
TEST=Verify on kevin + lars + lars_pd that stored image size matches
output of system_get_image_used() for both RO and RW images.
BRANCH=None
Change-Id: I49ea5fc27a7f11f66daba485a87d0dfe7d0c770f
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/427408
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The 'cycles' register will be clobbered by our macro, so it must be
specified as an output operand that may also be used as input.
BUG=chrome-os-partner:60000
BRANCH=gru,strago,glados
TEST=Build + burn wheatley, verify alignment exception is not
encountered on boot. Also verify produced assembly is still correct:
100a89a6: 2303 movs r3, #3
100a89a8: 3b01 subs r3, #1
100a89aa: d1fd bne.n 100a89a8
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I1be03a006967aed6970dbac5d98a19a31e0b7d49
Reviewed-on: https://chromium-review.googlesource.com/412441
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Mulin Chao <mlchao@nuvoton.com>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The `idlestats` command was not behind the CONFIG_CMD_IDLE_STATS option;
this commit fixes that.
BUG=None
BRANCH=glados
TEST=build a board that uses mec1322. Undef CONFIG_CMD_IDLE_STATS;
verify that the command isn't present in the build.
Change-Id: Id17c8377f812ee2a63dc4507766c1c557704dcb1
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/411518
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reset-on-hibernate wake performs a soft-reset, which re-initializes GPIO
states to ROM POR values. Therefore, it is necessary to re-init GPIO
states once again based on board-level GPIO settings.
BUG=chrome-os-partner:58077
BRANCH=gru
TEST=Run `hibernate` on gru, wake, then run `bd99955_dump`. Verify
actual register values are printed rather than zeros.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ib3eb1dd6aa264d00d42d8e386bfd1ef7f6cf7717
Reviewed-on: https://chromium-review.googlesource.com/395426
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
The application may need to read/write/erase the flash memory,
but we not want console users to do so. This CL adds
CONFIG_FLASH_PHYSICAL, which allows the higher-level CONFIG_FLASH
to be undefined while still providing the chip-specific
flash_physical_* accessor functions.
There aren't many board.h files that needed changes, since
CONFIG_FLASH_PHYSICAL is enabled by default, just like CONFIG_FLASH.
BUG=chrome-os-partner:57408
BRANCH=none
TEST=make buildall; try on Gru with and without CR50_DEV=1
See that it still boots, updates, wipes, restores, etc. without
linking common/flash.o in the production image; and that the
flash commands are still there in the dev build.
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: I7eb1bbcb414b1c70ee427c4fcb5cea899dbb9e93
Reviewed-on: https://chromium-review.googlesource.com/391188
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Since pretty much always, we've declared console commands to take
a "longhelp" argument with detailed explanations of what the
command does. But since almost as long, we've never actually used
that argument for anything - we just silently throw it away in
the macro. There's only one command (usbchargemode) that even
thinks it defines that argument.
We're never going to use this, let's just get rid of it.
BUG=none
BRANCH=none
CQ-DEPEND=CL:*279060
CQ-DEPEND=CL:*279158
CQ-DEPEND=CL:*279037
TEST=make buildall; tested on Cr50 hardware
Everything builds. Since we never used this arg anyway, there had
better not be any difference in the result.
Change-Id: Id3f71a53d02e3dc625cfcc12aa71ecb50e35eb9f
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/374163
Reviewed-by: Myles Watson <mylesgw@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The console adc command prints adc values in the
order they appear in hardware, however they are lableled
in the order they are enumerated in board.h, which is not
necessarily the same.
This prints the correct name and value pairs, and removes
the adc_read_all_channels function which is not otherwise
used.
BUG=chromium:571476
BRANCH=None
TEST="adc" command associates correct values with names now.
Change-Id: I688641953d20082224b4120eaefe0d634ad4c74c
Signed-off-by: Nick Sanders <nsanders@google.com>
Reviewed-on: https://chromium-review.googlesource.com/340892
Commit-Ready: Nick Sanders <nsanders@chromium.org>
Tested-by: Nick Sanders <nsanders@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Using HOOK_PRIO_DEFAULT for peripheral initialization necessitates using
HOOK_PRIO_DEFAULT+1 for board-level code. Instead, use a
higher-than-default relative priority for peripheral initialization
outside of board.
BUG=None
TEST=Verify PWM and ADC are functional on kevin.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ia8e90a7a866bdb0a661099dd458e3dfcaaa3f6bb
Reviewed-on: https://chromium-review.googlesource.com/342171
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Add PWM_CONFIG_DSLEEP PWM config flag, which can be set to keep a
channel active during low-power idle / deep sleep. Currently it's
supported by npcx and mec1322.
BUG=chrome-os-partner:52783
BRANCH=glados
TEST=Manual on chell w/ subsequent commit + CONFIG_LOW_POWER_S0. Verify
KB backlight does not flicker during idle.
Change-Id: Ib9df5879aaa7dfa5764de1583496de84d40d2bb5
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/341002
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Previously the maximum number of deferred routines was specified by the
the default maximum number of deferred routines you had to override
this, and if you wanted fewer, you still payed the price of having the
defer_until array statically allocated to be the maximum size.
This change removes that define and instead creates the RAM state of
the deferred routine (the time to wait until to call the deferred) when
the deferred is declared.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
manually test on discovery-stm32f072
Change-Id: Id3db84ee1795226b7818c57f68c1f637567831dc
Reviewed-on: https://chromium-review.googlesource.com/335597
Commit-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Previously calls to hook_call_deferred were passed the function to call,
which was then looked up in the .rodata.deferred section with a linear
search. This linear search can be replaced with a subtract by passing
the pointer to the deferred_data object created when DECLARE_DEFERRED
was invoked.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
CQ-DEPEND=CL:*255812
TEST=make buildall -j
Change-Id: I951dd1541302875b102dd086154cf05591694440
Reviewed-on: https://chromium-review.googlesource.com/334315
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This is keyboard test mechanism request for "multiple key press test",
we can thru the testing to scan out kso ksi pins shortting or keyboard has
multiple key pressing, below was the testing steps:
1. Turn off internal keyboard scan function.
2. Set all scan & sense pins to input and internal push up.
3. Set start one pin to output low.
4. check other pins status if any sense low level.
5. repeat step 3~4 for all keyboard KSO/KSI pins.
6. Turn on internal keyboard scan function.
BUG=chrome-os-partner:49235
BRANCH=ToT
TEST=manual
Short any KSO or KSI pins and excute "ectool kbfactorytest", it shows failed.
if no pins short together, it shows passed.
Change-Id: Id2c4310d45e892aebc6d2c0795db22eba5a30641
Signed-off-by: Devin Lu <Devin.Lu@quantatw.com>
Reviewed-on: https://chromium-review.googlesource.com/332322
Reviewed-by: Shawn N <shawnn@chromium.org>
During the resume sequence of S0ix EC can receive host commands early
in the resume path when LPC is still disabled in EC. Host messages
will be lost if the LPC interface with the kernel is down.
Clock control was programed to 2 which means ring oscillator is
shut down after completion of everty LPC transaction.To restart
the oscillator EC should enable a wake interrupt on LPC LFRAME number
and this mode can cause an increase in the time to
respond to the LPC transactions.
Keeping LPC always on shows minimal power impact as per datasheet
Pg.390. The impact is < 0.45mW.
BUG=chrome-os-partner:50627
TEST=Enter into S0ix and exit reliably.
BRANCH=firmware-glados-7820.B
Change-Id: I670b9b45c3a85c9bca249312a73a25dca52b313a
Signed-off-by: Divya Jyothi <divya.jyothi@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/332333
Reviewed-by: Shobhit Srivastava <shobhit.srivastava@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
(cherry picked from commit c03fd6e0eaa6ecd3205214f901facb9896a798b4)
Reviewed-on: https://chromium-review.googlesource.com/332791
port80 activity usually comes in bursts during AP boot and then goes
quiet. For power savings, turn off the port80 interrupt and timer after
no activity is seen for 30 seconds.
BUG=chrome-os-partner:50175
TEST=Boot chell, verify port80 prints are seen. Verify timer +
interrupts are disabled ~30 seconds later. Power down, power up, and
verify port80 prints are seen once again.
BRANCH=glados
Change-Id: Iea091d73aa0c6e9cfb36240d68e31a20425cea45
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/327256
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Icarus W Sparry <icarus.w.sparry@intel.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
EC clears the SCI/SMI/Wake masks in the resume sequence for S3
and S0ix. This works in the S3 case because Coreboot reprograms
the masks after EC. But in S0ix, these masks stay cleared forever.
This means that no further events are sent to the host.
This patch conditionally clears the masks only in the S3 transition.
BRANCH=glados
BUG=chrome-os-partner:48834
TEST=hostevent in EC console before and after S0ix to ensure SCI masks
are preserved
Change-Id: I23751680788ee7a239e321309a1334d37adc4f43
Signed-off-by: Archana Patni <archana.patni@intel.com>
Signed-off-by: Subramony Sesha <subramony.sesha@intel.com>
Signed-off-by: Jenny TC <jenny.tc@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/320191
Commit-Ready: Jenny Tc <jenny.tc@intel.com>
Tested-by: Jenny Tc <jenny.tc@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
board_hibernate() may take alternate actions to place the chip into
hibernate, so inform the PD MCU that we're going to hibernate before
calling the function.
BUG=None
TEST=Run 'hibernate' on chell, verify that PD MCU goes to hibernate and
wakes when AC is attached.
BRANCH=glados
Change-Id: I71c12dcb416d54c79ac7d40e9bf430e268071fb2
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/327613
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
In the S0 <-> S3 transition, Coreboot sends EC messages to set/clear the
wake masks when the SMI is invoked. For S0ix, EC sets and clears the
wake mask via this patch.
These functions are directly invoked from the state machine transition states.
During S0ix entry, the wake mask for lid open is enabled. During S0ix exit,
the wake mask for lid open is cleared. All pending events are also cleared
BRANCH=none
BUG=chrome-os-partner:48834
TEST=test lidopen in S0ix
Signed-off-by: Archana Patni <archana.patni@intel.com>
Signed-off-by: Subramony Sesha <subramony.sesha@intel.com>
Change-Id: I52a15f502ef637f7b7e4b559820deecb831d818f
Reviewed-on: https://chromium-review.googlesource.com/320190
Commit-Ready: Divya Jyothi <divya.jyothi@intel.com>
Tested-by: Divya Jyothi <divya.jyothi@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
In normal operation the 16 bit timer number 1 is set up to count every
microsecond, and every 1000 counts (i.e. every millisecond) to assert an
IRQ (Interrupt Request). After a microsecond the IRQ is deasserted.when
the count is again not at its limit.
The IRQ handler ignores the IRQ from the timer itself.
If the clock is stopped or the autoreload of the counter is disabled
then the value of the count is left unchanged. If this count is the
limit then the IRQ will remain asserted. For stopping the clock this is
approximatly a 1 in 1000 chance, or is certain if the autoreload is
disabled.
If the IRQ from the timer continues to be asserted, then the NVIC will
continue to generate a fresh call to the IRQ handler as each previous
exception completes.
The fix is to do what almost every IRQ handler does for almost every
processor, and clear the request in the peripheral that is causing the
interrupt, rather than hoping that the timer will clear it itself. This
agrees with how the event timer is used. There may be a lurking bug in
the system timer handler as well as it also expects the timer to clear
its own IRQ.
BUG=chrome-os-partner:48499
TEST=Pass 2000s of continuous calls to port_80_interrupt_disable() /
port_80_interrupt_enable() without WDT being triggered. Stop the
autoreload and see it doesn't watchdog.
BRANCH=glados
Change-Id: I4726854b7784e2e4a39b8cb74c350206d71f90df
Signed-off-by: Icarus Sparry <icarus.w.sparry@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/326781
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Referring to i2c ports as i2c0 thru i2c4 is confusing, due to the
special naming of controller 0 ports, so use their actual names from the
datasheet.
BUG=None
TEST=Trigger failure on i2c0_1, verify that "i2c0_1 bad status .." is
seen on console.
BRANCH=glados, strago
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ibd0d638e5af1c0a64e6f4b1a709b790b6b10d5e6
Reviewed-on: https://chromium-review.googlesource.com/325822
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
EC boot / hash computing can be a bottleneck for system boot time.
Reduce this bottleneck by running our processor at 48 MHz through boot,
until vboot hashing of RW completes.
BUG=chrome-os-partner:49583
TEST=Boot chell, verify vboot hash completes within 1 sec of EC boot and
'cbmem' delta between 'vboot select&load kernel' and 'finished EC
verification' is reduced to ~250 ms (which includes sysjump time).
BRANCH=glados
Change-Id: I18d87e685b89decef761e51517bfcfc43dcf8ef0
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/326792
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Allow boards to take action (such as entering a custom low-power
hibernate-like state) before putting the chip into hibernate state.
BUG=chrome-os-partner:48835
BRANCH=glados
TEST=Manual with subsequent commit on chell. Verify board-level
hibernate callback is called when "hibernate" is run on EC console.
Change-Id: Ie1da044037a74ff8bce5c822f28ce837c62ceec0
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/324086
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The new gpio_reset function simplifies the pattern used in this code,
that of returning a GPIO to its original configured state. It also
removes a few instances of using port/mask pairs.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Change-Id: I6e411aaf2f0fbc18aca0ed8742c400a0efe5690d
Reviewed-on: https://chromium-review.googlesource.com/324059
Commit-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
There are hooks for chipset power sequencing but not one to indicate
that the system has reset at runtime. Add a hook for this and
implement for lm4 and mec1322. The hook is notified on any platform
reset, including those that happen on the way into S3/S5 state.
There is a new config variable added because the hook is notified in
the interrupt handler and needs a deferrable function that needs to
be added to every board.
BUG=chrome-os-partner:46049
BRANCH=none
TEST=tested on glados and samus
Change-Id: I3be639414e18586344e0ec84632a50dfc1df586b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/315221
Commit-Ready: Aaron Durbin <adurbin@chromium.org>
Tested-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Configuring all GPIOs to INPUT / PULL_UP in hibernate is not a good
idea:
- INPUT / PULL_UP is not necessarially the lowest-power state (for
example, if there is an onboard pull-down).
- Most GPIOs should already be in lowest-power state when we're in S5.
- For the few GPIOs that need to be in a different state for hibernate,
we can use a board-level callback.
In addition, remove mec1322 code related to restoring from hibernate
state, since we always reset coming out of hibernate.
BUG=chrome-os-partner:49608
BRANCH=glados, strago
TEST=`hibernate` on chell console when in S5 and AC removed. Verify that
EC power is roughly equivalent to low-power idle power. Attach Zinger,
verify that device wakes and boots, and charges from charger.
Change-Id: Ib00ef035bec32cea3847eb38d743f5c0cec896ca
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/322937
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
When a sysjump host command is received, there is a (usually) small
period of time when the EC has sent a reply packet back to the host, but
interrupts are still enabled. If the host sends a new host command,
STATUS_PROCESSING will be set by the EC ISR, but the host command will
never be handled due to pending sysjump. In this case, STATUS_PROCESSING
will still be set, so we need to clear it on LPC post-sysjump re-init.
BUG=chrome-os-partner:49318
TEST=Add 200ms msleep before call to interrupt_disable() in
jump_to_image(), boot to software sync, and verify host commands are
handled successfully post-sysjump and system continues to boot.
BRANCH=glados, cyan
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Id0878df738541f7d5d158821a68988a8e6dc6759
Reviewed-on: https://chromium-review.googlesource.com/322431
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
If we haven't sent a stop condition, make note of that, and send a
repeated start next time.
BUG=chrome-os-partner:48294
BRANCH=None
TEST=Verify "ectool i2cxfer 1 0x25 1 2" succeeds on glados. Also verify
`i2cscan` on EC console succeeds.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Id45bfc6540dc1cc3a3d1e9f6916a238bce5ae33f
Reviewed-on: https://chromium-review.googlesource.com/316022
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
When Link Time Optimization is turned on, functions that set
task_waiting multiple times have one of the sets removed
by the linker leading to undesired results.
Marking task_waiting volatile alleviates this issue.
BUG=chrome-os-partner:46063
TEST=Manually tested on Kunimitsu.
Console command adc shows correct value of approx
20000 mV for VBUS.
BRANCH=none
Change-Id: I85a6e5c9688ae72c45d90fb58296f94b74a301aa
Signed-off-by: Shamile Khan <shamile.khan@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/314233
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
If we're doing a read transaction without a write and asked to send a
start condition, assume that the slave has already been addressed and
make a repeated start.
BUG=chromium:561143
TEST=Verify "ectool i2cxfer 1 0x25 1 2" succeeds on glados
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ic60a5c0f0fa32d5541b3cc6dce48cac28f26cd06
Reviewed-on: https://chromium-review.googlesource.com/314313
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Add a hard timeout to wait_for_interrupt() so that we won't wait
forever, even if we get into a state where interrupts fire yet our
status is not as expected.
BUG=chromium:561143
TEST=Verify "ectool i2cxfer 1 0x25 1 2" doesn't watchdog on glados
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I39773370bb7e45a8f0c0cdb4a463904643f72587
Reviewed-on: https://chromium-review.googlesource.com/314253
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
In handle_interrupt(), "|= 1 << 29" will clears all status bits, not
just bit 29. Fix this to make it only clear specified status bit and
keep R/W bits intact.
BUG=None
BRANCH=None
TEST=Verified on Kunimitus system
1. In configure_controller() write R/W bits in completion register
2. In handle_interrupt() print the value of completion register and
status bits is cleared, R/W bits are kept.
Change-Id: I6a9cc17b3dfc1e163af5e56a80600afb8ac23247
Signed-off-by: li feng <li1.feng@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/312701
Commit-Ready: Divya Jyothi <divya.jyothi@intel.com>
Tested-by: Divya Jyothi <divya.jyothi@intel.com>
Tested-by: Li1 Feng <li1.feng@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
The PWM clock on some chips can be configured to use different
sources, which will have a dramatic effect on the actual PWM
frequency. In order to support a variety of devices attached
to PWM outputs add an option to select an alternate source.
This is then implemented on the mec1322 chip to use the 100kHz
clock source for PWM which will allow it to drive a keyboard
backlight at appropriate frequencies.
BUG=chrome-os-partner:47435
BRANCH=none
TEST=verify that kblight brightness can be changed on chell
Change-Id: Ibe93a8e029baae5a2d5f520d590b0cc4ab9a7f93
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/312509
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
