For enhanced EC images, change the string telling the user that the
console is enabled. This is such that EC-3PO can distinguish between
non-enhanced ECs and enhanced ECs during EC boot.
BUG=chromium:588611
BRANCH=None
TEST=Build for chell with CONFIG_EXPERIMENTAL_CONSOLE and verify that
the new string is printed.
TEST=Repeat above test but without the config option and verify that the
old string is printed.
TEST=make -j buildall tests
Change-Id: Ic8ed0a028ecb701b999fa6c6a376704f375dbc62
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/329161
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When forcing a sink role (eg. on transition from S3->S5), make sure
we're not sourcing VBUS. Otherwise, if a power source is attached, we
will fail to charge from it, due to the inability to sink and source
VBUS simultaneously.
BUG=chrome-os-partner:49544 chrome-os-partner:50343
TEST=Boot chell, attach USB-C peripheral, then power down chell. Remove
USB-C peripheral, attach zinger, and verify PD negotiation + charging
succeeds.
BRANCH=glados
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I5fb9b0eb26e61daa93a167d6a3e9aaf4e4eeed39
Reviewed-on: https://chromium-review.googlesource.com/327727
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Divagar Mohandass <divagar.mohandass@intel.com>
Reviewed-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Now that the cr50 no longer uses this array to store its pinmux config
we can move it out of the header file, removing it from the public
interface for GPIO code. This allows us to start modifying this struct
more easily.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Change-Id: I9b4ca8b678b102bb9b63ccffe23bf2dc87aeb44a
Reviewed-on: https://chromium-review.googlesource.com/328824
Commit-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@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>
In case of no battery condition, current code sets the charger input
current to the charger maximum input current. To avoid damage to the
board, set the charger input current to the maximum current that the
board can support.
BUG=none
BRANCH=none
TEST=Manually tested on kunimitsu, removed the battery & then using EC
console command 'charger', verified that the current value is set
to 3000mA.
Change-Id: I94c40228a6362822c841a6e0c226bea0d3398b73
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/325522
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Li1 Feng <li1.feng@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
fmap_decode now checks the fmap name to determine if the fmap it is
decoding is the correct one. This change puts a comment in the ec fmap
header to note the use.
BUG=none
BRANCH=none
TEST=make buildall -j
CQ-DEPEND=CL:322262
Change-Id: Icdd56eef5474b51cb178b6ba37c530c2357341b2
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/326450
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This change use a simple counter to to prevent ec enter sleep if there's
any i2c port active. Once there's no i2c port active, we enable sleep bit of
i2c in i2c_lock() func. Please note FW disables interrupt during changing
counter to prevent preemptive conditions.
Modified sources:
1. common/i2c.c: Fix sleep mask for multi-port lock.
BUG=crbug.com/537759
TEST=make buildall -j; test on wheatley when CONFIG_LOW_POWER_S0 is deifned.
BRANCH=none
Change-Id: I17c226108fee0e5d656fa157808179898f9a8dbf
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/325256
Reviewed-by: Randall Spangler <rspangler@chromium.org>
- ec_response_thermal_get_threshold.value is unsigned, so it can not be
less than zero.
- make power_button_wait_for_release() take a signed int, to match its
existing usage.
BUG=None
TEST=`make buildall -j`
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ie5748df3d9904d1e417adc38fee18f8cb3ce9750
Reviewed-on: https://chromium-review.googlesource.com/325840
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This patch introduces HOST_CPPFLAGS to be used for all
objects being compiled with HOSTCC rather then the target
compiler.
Since glibc is not linked into the EC, no glibc include files
should be included in the EC code base. Hence, create local
definitions for clock_t and wchar_t that match what the glibc
include would have done, and remove some unneeded includes.
Due to very eager optimization, we have to give gcc a little
notch to not kick out memset.
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
BUG=chrome-os-partner:43025
BUG=chrome-os-partner:49517
BRANCH=none
TEST=compile tested
Change-Id: Idf3a2881fa8352756b0927b09c6a97473358f239
Reviewed-on: https://chromium-review.googlesource.com/322435
Commit-Ready: Patrick Georgi <pgeorgi@chromium.org>
Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Battery in cut-off mode wakes when voltage is applied to the PACK
and takes approximately 2 to 3 seconds to initialize before capable
of providing the power. Hence made the battery present status to
BP_NO in case of cut-off mode. Once the battery is ready new status
is updated as BP_YES.
When the battery status changes from BP_NO to BP_YES, charger input
current is set to board specific charger input current which is not
sufficient to boot the AP hence the system reboots. To avoid this
issue, added code to write charger manager negotiated current to
charger input current when the battery status changes from BP_NO to
BP_YES.
BRANCH=none
BUG=chrome-os-partner:49224
TEST=Manually tested on Kunimitsu.
Used console command 'cutoff' to put the battery in cut-off mode.
Inserted the adopter to wake the system, system doesn't reboot &
the battery charges.
Change-Id: Ia5a1457506b4bef0b3dd27993e4b60ae64c8f746
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/322430
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Resetting our state to default without also resetting the power role may
lead to a state / role mismatch.
BUG=chrome-os-partner:49563
TEST=Verify kunimitsu correctly detects charger at either polarity on
sysjump.
BRANCH=glados
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I239df9793773429e9b84a847e55d6753577fab32
Reviewed-on: https://chromium-review.googlesource.com/325385
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Adds a JEDEC SFDP v1.* compatible Serial NOR Flash driver to control
multiple Serial NOR Flash devices (NOR EEPROMs, etc.). The SFDP tables
are used to discover parts' page sizes and capacities.
This driver only supports parts with capacities under 4GiB. If the
parts are larger than 16MiB, then the 0xB7 4-Byte addressing mode
entry opcode and 0xE9 4-Byte addressing mode exit opcode are required.
This driver also assumes that a 4KiB erase opcode of 0x20 is always
available.
BRANCH=none
BUG=none
TEST=Tested on cr51 with multiple EEPROMs with various SFDP revs
Change-Id: I5c2b757267e23c4f22ac89c6d5048a54b04de0c3
Signed-off-by: Ewout van Bekkum <ewout@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/321922
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This adds a temporary secure storage interface for the EC to be able
to store small amounts of data from the host that is locked until the
chipset resets. This is used by pre-memory verified boot on x86 systems
where we need to know which RW slot to boot and what the hash is to
ensure that we can resume from S3 safely.
BUG=chrome-os-partner:46049
BRANCH=none
TEST=tested on glados and samus
Change-Id: I5fa91046437479bcae69a8fca4c989b0ef554bbf
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/315222
Commit-Ready: Aaron Durbin <adurbin@chromium.org>
Tested-by: Aaron Durbin <adurbin@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>
If we're asked to compute a hash of an image on a region of storage, we
may find that the region actually contains no image. In that case, we
need to compute a hash of zero bytes. Properly handle this case from
image size detection to hash computation to hash invalidation.
BUG=chrome-os-partner:49529
TEST=Manual on chell. `dd conv=notrunc if=/dev/zero of=ec.bin bs=131072
count=1`, then write ec.bin and verify SW sync occurs, RW hash is
computed correctly, and the system boots into dev mode.
BRANCH=glados, strago
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ie5a023d13d2521f9c224615666950aea8fbc22bb
Reviewed-on: https://chromium-review.googlesource.com/322750
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Previously there were only two uses of gpio_config_pins, one was
gpio_config_module, which passed in GPIO_CONFIG_ALL_PORTS (the only
place this is used), the other was the common I2C code when it needs to
return the SDA and SCL lines to their alternate function after unwedging
the bus.
These uses are so different that it doesn't make much sense to keep a
single API for them. This change adds a gpio_config_pin that is
simpler to use as it just takes a gpio_signal enum to select the GPIO
to configure and makes gpio_config_pins and GPIO_CONFIG_ALL_PORTS
internal to gpio.c
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Change-Id: I92bfb0b520b0aa2165655b2ff5076e428c88631f
Reviewed-on: https://chromium-review.googlesource.com/322437
Commit-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Use a static buffer rather than 256 bytes of stack when scanning for the
end of an image.
BUG=chrome-os-partner:49396
TEST=Verify "ectool echash abort; ectool echash start 0xfffffffe 100"
doesn't panic on glados.
BRANCH=glados
Change-Id: Ia864fe77134533bce079dab3b253142b14410ded
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/322283
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
For TCPMs with an off chip TCPC, PD MCU host event status can be handled
in a common way. When a status flag is updated (ex. from
charge_manager), notify the AP through the host event, and save the
status flag for later retrieval.
BUG=chrome-os-partner:49124
BRANCH=None
TEST=Verify `cat /sys/class/power_supply/CROS_USB_PD_CHARGER1/online` on
chell reflects the actual online status of the charger. Also verify UI
charge icon tracks the online status correctly.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I63bc70205627474590e38ffd282faedaea3bcc66
Reviewed-on: https://chromium-review.googlesource.com/320796
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
x86 systems will auto-power-on when power is applied to the EC. When
the battery level is critically low, power-on is prevented, except when
the system is unlocked. So, when unlocked, some systems will
auto-power-on regardless of battery level, overcurrent the charger /
battery, and then repeat forever.
Prevent this reboot loop by ignoring auto-power-up when the battery is
critically low, regardless of system unlocked status.
BUG=chrome-os-partner:48339
TEST=Verify power-up is prevented on no-battery chell w/ donette. Then,
run 'powerbtn' on EC console and verify system powers on (and
overcurrents).
BRANCH=None
Change-Id: Ia631b5a8c45b42ec805e4a0c3f827929a0efd236
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/319187
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
With the RO region being added to software sync, up to two hashes will
be requested during boot. Currently if vboot_hash has a valid hash when
the EC gets an EC_VBOOT_HASH_GET host command then it will return that
hash. When the EC gets a request for the RO hash after it has calculated
the RW hash it returns the RW hash in the response.
This change will add a check that the EC not only has a valid hash, but
that it is for the correct region.
BRANCH=none
BUG=none
TEST=Try to get the RO and RW hashes from depthcharge and make sure they
match the values gotten using ectool
Change-Id: I2449c8d79b4a74f4865dd1234fb253bcdac66a31
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/318861
Reviewed-by: Randall Spangler <rspangler@chromium.org>
After commit 98ab7484d331 ("keyboard: prevent races enabling/disabling
kb scanning") kbpress was totally broken, which wasn't so good for
FAFT. Fix it by making sure we go into polling mode for simulated
keyboard presses.
BUG=chrome-os-partner:48849
TEST=kbpress works
Change-Id: Icd663c2ee7a184e6af4438368595087b35724a4f
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/319586
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Add support for continuously writing ADC samples to a circular buffer.
CONFIG_ADC_PROFILE_FAST_CONTINUOUS should be defined and an
appropriate sized buffer must be passed to adc_read_all_channels().
BUG=chromium:569994
TEST=Manual on snoball. Verify 'adc' continues to function (single
mode). With pending commit, verify that continuous conversion interrupt
is called at appropriate frequency and values look consistent.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I025825d72a698f8f1f4f95a89477df791bd5e67e
Reviewed-on: https://chromium-review.googlesource.com/318505
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
keyboard_scan_enable() is called from several contexts. From a skim of
the code I found:
* keyboard_lid_change(), which is called from HOOK_LID_CHANGE
* enable_keyboard(), which is called from HOOK_CHIPSET_RESUME
* lidangle_keyscan_update(), which is called from motion_sense_task.
* check_for_power_off_event() which is called from power_handle_state()
which is called from chipset_task.
* power_button_interrupt(), which is an interrupt
* power_button_change_deferred(), which is a deferred function
So, ummm, it's probably not a good idea to do a read-modify-write of a
variable without any locking. ...and then to act on the resultant state
in various different contexts.
It's presumed that's just what happened to poor Julius. Julius found
himself in the unfortunate situation where he resumed his device (with
the power button, I believe) and that everything worked (including
reading the battery state and including the accelerometer) but the
keyboard didn't work. Now, it should be noted that Julius is a little
strange. Well, maybe he's not strange and maybe just the way he uses
his laptop is strange. He uses his veyron_minnie device as a smart
keyboard/trackpad. Said another way: it is in tablet mode but is docked
to an HDMI monitor, the screen is face flat on his table, and he uses
the builtin keyboard and trackpad. Nobody else that I know does this.
It's pretty darn cool, but I just don't think anyone else would think of
it. Anyway, that might have something to do with how he reproduced
this. ...or it might not. He does that a lot and hasn't seen the
problem before now.
Anyway, I managed to reproduce a number of problems similar to what poor
Julius saw by adding a 200ms sleep in keyboard_scan_enable() after we
read disable_scanning_mask but before we did anything to it (I skipped
the sleep if this happened to be one of those people who was calling
from interrupt).
Since there appears to be no spin_lock_irqsave() in the EC, let's just
have the EC use atomic operations to mess with its masks. Then we'll
leave all heavy lifting to the task.
This requires thinking through the task code a bit.
Conflicts:
common/keyboard_scan.c
...due to commit 6112f20679 ("common: keyboard_scan: Add items to
.bss.slow.") in ToT.
BRANCH=ToT
BUG=chrome-os-partner:48470
TEST=Poke a lot with power button and lid; NTF.
Change-Id: I61b906505100186b0ca2c48e7b1a7ffaaa8a7d3e
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/317896
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit 98ab7484d331a78fced870b58b4d82e79e2e0f4e)
Reviewed-on: https://chromium-review.googlesource.com/318292
Enabling of ALS is done during resume hook.
During EC sw sync, resume hook is not called
and hence ALS task wont run.
Adding init hook to wake up the ALS task.
BUG=chrome-os-partner:48418
BRANCH=none
TEST= On Kunimitsu board, ensure sw sync is enabled.
In OS, cat /sys/bus/iio/devices/iio:devicesx/in_illuminace_input
should output valid value and not zero.
Change-Id: Iba1a3ab2cf7bfc2d8aa36cf9bb9b762f398882c3
Signed-off-by: Jagadish Krishnamoorthy <jagadish.krishnamoorthy@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/317030
Commit-Ready: Freddy Paul <freddy.paul@intel.com>
Reviewed-by: Freddy Paul <freddy.paul@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
A typical EC image includes two similar in their functionality
subsections, RO and RW. CR50 has a small RO subsection, all it does -
detects a proper RW image to run and starts it up. To provide for
reliable firmware updates, the CR50 image needs to include two RW
sections, while the code is running from one RW subsection, the other
one can be upgraded.
This patch adds the ability to generate two identical RW sections,
mapped half flash size apart, and include them into the resulting EC
image.
To keep things simple the previously existing RW section's name is not
being changed, while the new (identical) RW section is named RW_B.
Two configuration options need to be defined to enable building of the
new image type: CONFIG_RW_B to enable the feature and
CONFIG_RW_B_MEM_OFF to define where RW_B should be mapped into the
flash.
A new rule added to Makefile.rules allows to generate a different lds
file from the same source (core/cortex-m/ec.lds.S) by defining a
compile time variable to pick a different base address for the
rewritable section, when RW_B is built.
BRANCH=none
BUG=chromium:43025
TEST=as follows:
- make buildall -j still succeeds
- verified that regular CR50 image starts successfully
- modified chip/g/loader/main.c to launch RW_B first, re-built and
re-run the image, observed on the console:
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
cr50 bootloader, 20151118_11218@80881, no USB, full crypto
Valid image found at 0x00084000, jumping
--- UART initialized after reboot ---
[Reset cause: power-on]
[Image: unknown, cr50_v1.1.4160-4c8a789-dirty 2015-12-07 18:54:27 vbendeb@eskimo.mtv.corp.google.com]
[0.001148 Inits done]
This FPGA image has no USB support
Console is enabled; type HELP for help.
> [0.002212 task 2 waiting for events...]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(note that the image base address is 0x840000, which is RW_B).
Change-Id: Ia2f90d5e5b7a9f252ea3ecf3ff5babfad8a97444
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/316703
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When AP is suspended, only predefined events could wakeup AP.
Check EC_MKBP_EVENT_KEY_MATRIX event when we use embedded keyboard to make AP
wakeup from S3 power state.
BRANCH=none
BUG=chrome-os-partner:47554
TEST=Enter "powerd_dbus_suspend" in AP console to make system
suspend and then press embedded keyboard to wakeup AP.
Change-Id: I79f91776c39554a4e488e50841d3537fe85fea13
Signed-off-by: YH Huang <yh.huang@mediatek.com>
Reviewed-on: https://chromium-review.googlesource.com/312156
Tested-by: Wei-Ning Huang <wnhuang@chromium.org>
Reviewed-by: Wei-Ning Huang <wnhuang@chromium.org>
Reviewed-by: Rong Chang <rongchang@chromium.org>
Add 2 bytes into the TX byte count register used in
TCPC interface.
BUG=chrome-os-partner:48256
BRANCH=none
TEST=load on glados and attach zinger, make sure
PD negotiation successful.
Change-Id: Ie57d79f20def861c22f6e2e023545a65825ab3b4
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/315879
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Rather than having various PWM module groups initialized from various
HOOK_INIT functions, group them all into a single module and initialize
them all from a common function in pwm.c.
BUG=chromium:563708
TEST=Manual on samus / samus_pd (with CONFIG_ADC enabled). Verify that
samus fan + KB backlight control is functional and samus_pd correctly
sets PWM output.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I9f9b09bfa544cd9bc6b7a867e77757dff0505941
Reviewed-on: https://chromium-review.googlesource.com/314882
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
If we're still in DISCONNECTED or DISCONNECTED_DEBOUNCE state, don't check
CC lines to detect a disconnect since CC polarity has not yet been
established.
BUG=chrome-os-partner:48220
BRANCH=None
TEST=Verify PD contact can be negotiated on Snoball with either polarity.
Change-Id: Iacde14446c0ff5d2170936b650f56668038f613e
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/315780
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
When none of temp sensors' temp/fan speed profile is not set(zero),
thermal control will set 0% duty over initial fan speed setting.
This patch allows fan under EC control at inital max speed
till host's DPTF sets proper fan speed.
BRANCH=master
BUG=none
TEST=1. check if fan is running at max speed until ChromeOS UI comes up.
2. check if fan is running when system is in recovery mode.
Change-Id: I1b3e69b003ba1045779e263b25ac35b103fe457e
Signed-off-by: Kyoung Kim <kyoung.il.kim@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/314363
Commit-Ready: Kyoung Il Kim <kyoung.il.kim@intel.com>
Tested-by: Kyoung Il Kim <kyoung.il.kim@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
cl/301134 has a bug. If the AP wants a forced sensor (i.e. light) at
100Hz but a sampling frequency at 1s, we would still wake it up every
.1s instead of 1s.
Take in account force mode only when calculating the sampling frequency
not the interrupt interval.
BRANCH=smaug
BUG=b:25425420
TEST=Check the device goes to suspend even with 40Hz light sampling
rate:
echo 0 > /sys/bus/iio/devices/iio:device0/frequency
echo 40000 > /sys/bus/iio/devices/iio:device3/frequency
echo mem >/sys/power/state
Before it would resume just after suspend/while suspending.
Change-Id: Ie4fe36268cb1b04bc8f01ec885af84fad9e8b282
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/314315
Reviewed-by: Alec Berg <alecaberg@chromium.org>
When sensor_shutdown() is called, the sensors may already been powered
off, or will be soon.
In that case, do not attempts to access them.
Check their state before setting range or disabling activities.
BRANCH=smaug
BUG=chromium:557966
TEST=compile
Change-Id: I60640b120a23f9aab393a93c4c67ef17222ced4e
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/314382
Reviewed-by: Alec Berg <alecaberg@chromium.org>
The EC-3PO console and interpreter could be used to talk to EC images
which do not have the necessary changes to support the new enhancements.
If this was the case, the interpreter would be very confused and the
user wouldn't be able to use the console. This commit adds
compatibility support for talking to both non-enhanced and enhanced EC
images.
When the console and interpreter are instantiated, they assume by
default that the EC image they are talking to is non-enhanced. When the
user presses the carriage return key, the console initiates an
interrogation with the EC image. The interrogation is a simple
EC_SYN(0xEC) and waits EC_INTERROGATION_TIMEOUT for the correct
EC_ACK(0xC0). Enhanced EC images will try to reply immediately to a
EC_SYN. Non-enhanced EC images will just ignore the EC_SYN as it's not a
printable character. Once the interrogation is complete, the console
will either simply pass everything forwards to the EC or provide the
console interface itself.
BUG=chrome-os-partner:46063
BRANCH=None
TEST=Enabled CONFIG_EXPERIMENTAL_CONSOLE on GLaDOS. Entered some
commands and verified console was working. Disabled
CONFIG_EXPERIMENTAL_CONSOLE on GLaDOS, reflashed, and verified console
was still working without restarting the EC-3PO console.
TEST=./util/ec3po/console_unittest.py -b
TEST=./util/ec3po/interpreter_unittest.py -b
TEST=cros lint --debug util/ec3po/console.py
TEST=cros lint --debug util/ec3po/console_unittest.py
TEST=cros lint --debug util/ec3po/interpreter.py
TEST=cros lint --debug util/ec3po/interpreter_unittest.py
Change-Id: I4f472afbdd7e898bee308c239b68ace0f4049842
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/313002
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Added new host command to support returning lid angle.
New output from ectool:
System with lid angle support:
------------------------------------------
localhost ~ # ectool motionsense lid_angle
Lid angle: 72
System without lid angle support:
------------------------------------------
localhost ~ # ectool motionsense lid_angle
EC result 3 (INVALID_PARAM)
BUG=none
BRANCH=none
TEST=run "ectool motionsense lid_angle"
verify the value matches the physical lid angle position
Change-Id: I4179172c778f643640561e819216f7adfee679d2
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/313345
Reviewed-by: Shawn N <shawnn@chromium.org>
If multiple TCPCs are present on a system then we may have multiple
alert signals, each of which alerts us to the status of a different
TCPC. Make boards with external non cros-ec TCPCs define
tcpc_get_alert_status, which returns alert status based upon any alert
GPIOs present, and then service only ports which are alerting.
BUG=chromium:551683,chrome-os-partner:47851
TEST=Verify snoball PDCMD task sleeps appropriately when no devices are
inserted, and verify ports go to PD_DISCOVERY state when we attach
samus. Also verify that glados / glados_pd can still negotiate PD.
BRANCH=None
Change-Id: Iae6c4e1ef4d6685cb5bf7feef713505925a07c8c
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/313209
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
This change includes hardware and software support for SHA1/256 on
CR50. When running in the RO image, only hardware sha256 support is
included. When running in the RW image, the code auto-selects between
the software and hardware implementation. Software implementation path
is taken if the hardware is currently in use by some other context.
Refactor the CR50 loader to use this abstraction.
The existing software implementation for SHA1 and SHA256 is used for
the software path.
CQ-DEPEND=CL:*239385
BRANCH=none
TEST=EC shell boots fine (implies that SHA256 works)
BUG=chrome-os-partner:43025
Change-Id: I7bcefc12fcef869dac2e48793bd0cb5ce8e80d5b
Signed-off-by: nagendra modadugu <ngm@google.com>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/313011
In case the actual ODR rate is way higher that the AP asked for,
we don't have to settle to a slower EC rate if
EC rate == AP requested ODR rate.
BRANCH=smaug
BUG=none
TEST=Run android.hardware.cts.SingleSensorTests
Change-Id: I437f47bd942a16694c7efcdbc00201352f0480a6
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/313641
Reviewed-by: Alec Berg <alecaberg@chromium.org>
AP could collect samples while motion task was still adding timestamp.
A data stream not ending with a timestamp can lead to timestamp error in
the kernel.
This is espcially true if the motion task interrupt the AP back to back,
when sensor ODR changes for instance.
BRANCH=smaug
BUG=b:24367625
TEST=Run android.hardware.cts.SingleSensorTests
Change-Id: I5820216a2cfc0a869db7dc5ef75d4be126a53b4f
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/313640
Reviewed-by: Alec Berg <alecaberg@chromium.org>
When task creating, input_current will be set as condition.
But there is no more handling for this value. so it will remain
even if condition is changed.
This will put input current decision int the loop so that we can
proper input current as battery existence.
BUG=chrome-os-partner:47546
TEST=make buildall, command 'charger' with/without battery.
and see it is changed dynamically
BRANCH=None
(cherry picked from commit d2ac89d58c34d7cc0a2a3fb591fcdcddbe2e9feb)
Change-Id: Ib72e20faf7c7f302a4e39d43b23176247e5176fa
Signed-off-by: Wonjoon Lee <woojoo.lee@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/312950
Commit-Ready: Shawn N <shawnn@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Throughout the code, there are comparison between frequency (in mHz) and
period (in us). To improve readability, append units (_mhz, _us) after
variable names.
BRANCH=smaug
BUG=none
TEST=compile.
Change-Id: Icc9c66d9f06c526fc3b74fd85ca9759b702ee416
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/313221
Reviewed-by: Alec Berg <alecaberg@chromium.org>
We need to wake up the main task, even if we disable a sensor. It will
force sending the sensors samples in the FIFO and put a timestamp behind
them.
Also, reduce the interrupt period by 10us to be sure we fire interrupt
to the AP even if there are some variation in the timing calculation.
BUG=b:24367625
BRANCH=smaug
TEST=Run ts.SingleSensorTests overnight.
Change-Id: I6d966d52b5cbb72ba5eb936bc2fad6c06c7d8605
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/312986
Reviewed-by: Alec Berg <alecaberg@chromium.org>
If EC sampling rate is close to sensor rate, decrease sampling frequency
by 5% to prevent samples by the EC without data.
It can happen when the clocks are slightly different and get
unsynchronized.
BRANCH=smaug
BUG=b:24367625
TEST=Ran cts.SingleSensorTests overnight without error.
Change-Id: Iab5e578763171411eb474e1e717167c8e1ef7ecf
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/312985
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Some SPI slave devices need a delay to digest write commands. (BMI160).
Add a 1ms delay in the write command.
BRANCH=smaug
BUG=none
TEST=Check on the logic analyzer that there is ~1.5ms delay between back
to back spixfer w ... commands.
Change-Id: I7cc6ed0da9ae39550e58457b9431eb01b5ab36d8
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/305379
Reviewed-by: Alec Berg <alecaberg@chromium.org>
To ease finer calculation of ec rate change units from
ms to us.
BRANCH=smaug
BUG=b:24367625
TEST=compile
Change-Id: I52057c8ca1b1180a64b58d1ba0af9ec53f40b026
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/312984
The receive buffer needs to be able to accommodate the largest
commands. Even though the spec sets the size limit at 4096, let's keep
it at 2K for now and see if this needs to be increased.
BRANCH=none
BUG=chrome-os-partner:43025
TEST=with the rest of the patches applied, the AES test vectors pass
through without a problem.
Change-Id: I1cd6979fdaa343f0ddfddb58c552368b3f54db95
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/312588
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
