This patch introduces board_system_is_idle callback function. It's
called when system is in G3. A board can customize its action taken
when system is idle in G3 using battery thresholds, expiration timer,
etc. determined at runtime.
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
BUG=none
BRANCH=nami,strago,coral
TEST=Verify Vayne cut off battery on G3 idle expiration while other
Nami's hibernate.
Change-Id: I6118a074ac7d844b99d9c0f3eb638b72d5894008
Reviewed-on: https://chromium-review.googlesource.com/1512623
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
ANX PD has two way to get VBUS present info, 1:ADC, 2:Comparator
the ADC has been reset at chip reset stage, the comparator(0x1e:bit2)
is analog part, it is not been reset by chip reset.
there is a corner case which EC TCPM detect VBUS present info at
chip reset stage(at system rebooting stage, EC TCPM issue TEST_R
signal, this will trigger chip hardware reset).
the original VBUS present function checks the VBUS from ADC, the
ADC register value became to 0 while at chip reset stage, so at this
moment, EC TCPM need check 0x1e:bit2 to get real VBUS present info.
BRANCH=None
BUG=b:129092057
TEST=Tested on Phaser, reboot stress test.
Change-Id: I1e847c88b22684bc9b17243628179bad534801b2
Signed-off-by: Xin Ji <xji@analogixsemi.com>
Reviewed-on: https://chromium-review.googlesource.com/1535085
Commit-Ready: Justin TerAvest <teravest@chromium.org>
Tested-by: Justin TerAvest <teravest@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
Reviewed-by: Diana Z <dzigterman@chromium.org>
Currently, one sampling rate is set for all channels.
This patch allows a board to select a different sampling rate per
channel.
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
BUG=none
BRANCH=none
TEST=Verify intended sampling rate is used for USBC_THERM on Flapjack.
Change-Id: I9f791f2865ef6f479ec02dbf1440cd744e280c7b
Reviewed-on: https://chromium-review.googlesource.com/1535116
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Add optional third argument - inhibit_charge into help message of
usbchargemode.
BRANCH=none
BUG=None
TEST=Check help message by executing new generated ectool binary.
Change-Id: Ie6dca334c3eec00e00fa2e3083f57c45bed3c745
Signed-off-by: Marco Chen <marcochen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1485031
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Marco Chen <marcochen@chromium.org>
Reviewed-by: Zhuohao Lee <zhuohao@chromium.org>
Sometimes messages with the same ID are retransmitted at the physical
layer. Under such scenario do not handle the repeat messages.
BUG=b:129337537
BRANCH=None
TEST=make -j buildall; Ensure that the DUT boots to ChromeOS. Ensure
that the servo_v4 boots fine. Ensure that the DUT boots fine in
normal mode and recovery mode with and without battery. Ensure that the
repeat request messages triggered aritificially are dropped without any
side-effects. Ensure that the DUT is detected in CCD with
pass-through connected after multiple EC reboots, servo_v4 reboots and
USB-C unplug/replug procedure.
Change-Id: I850cd3536ff5e62c34f9dabcc0f8f53bb196ce4c
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1513033
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Karthikeyan Ramasubramanian <kramasub@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
Reviewed-by: Diana Z <dzigterman@chromium.org>
Currently, unlocked systems can maintain a contract over a reset or
sysjump by referencing BBRAM flags for the data and power state. An
additional flag is needed to track Vconn state though, particularly in
scenarios with hubs which prefer to swap Vconn when they source power.
Otherwise, both port partners have a different perspective of which one
is sourcing Vconn and this can lead to hard resets when the hub attempts
another Vconn swap.
BUG=None
BRANCH=None
TEST=Ran EC resets on unlocked octopus board with a hub which prefers to
not source Vconn, ensured that there were no strange Vconn_swap
sequences after reset
Change-Id: I4ccae72bef1a2df8cda4b32fb6e0a15c0cf176b1
Signed-off-by: Diana Z <dzigterman@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1536078
Reviewed-by: Jett Rink <jettrink@chromium.org>
BUG=None
BRANCH=None
TEST=build and verify the existence of the blob
Change-Id: Idf5132edec8c8b6a62c407387ab65d3893f93f18
Signed-off-by: YH Lin <yueherngl@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1440082
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Nick Sanders <nsanders@chromium.org>
This patch does not allow for I2C transfers to reserved address
ranges for the I2C module. Also does not allow transactions to
non-existent ports.
Returns an error if writing to a non-reserved, invalid
address range
Reference: DW_apb_i2c.pdf, pg. 74
BUG=b:123357842
BRANCH=none
TEST=i2cxfer commands in ISH console for invalid/valid ports and
addresses on atlas_ish board
Change-Id: Ieeec14b1c9b82e88d8e7658c0c56b10e3735936f
Signed-off-by: Daniel Gonzalez <daniel.d.gonzalez@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/1541941
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Li1 Feng <li1.feng@intel.com>
Reviewed-by: Jett Rink <jettrink@chromium.org>
Reviewed-by: Kyoung Il Kim <kyoung.il.kim@intel.com>
DP pin mode is needed to configure the Intel virtual muxes hence,
added a board level function that returns the current DP pin mode.
Also added a variable to return the DP pin mode in USB_PD_CONTROL
host command.
BUG=b:112311321
BRANCH=None
TEST=Verified on Dragonegg, able to get correct pin mode
USB:0x0 (No DP)
DP cable:0x4 (Mode:C)
USBC dock:0x8 (Mode:D)
Change-Id: I997de80d0963e8ac45e97e5da0064694d5572942
Signed-off-by: Ayushee <ayushee.shah@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/1512134
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Jett Rink <jettrink@chromium.org>
SBU orientation was detected in a one-shot check, that didn't
ensure that the line was idle.
Change to detect SBU orientation independently of PD state, and only while
it's disconnected from the host.
Delete keepalive and ccd_enable as they aren't meaningful for the new
mechanism.
BUG=b:128646723, chromium:942130
BRANCH=servo
TEST=unplug a lot of times, orientation always correct.
Signed-off-by: Nick Sanders <nsanders@chromium.org>
Change-Id: I16c770b9d8d7a0c2d90aa214cb8cdec4c36a7303
Reviewed-on: https://chromium-review.googlesource.com/1529724
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Seen some logs where due to the regex cutting out too soon, the
servo_updater assumes an update might be needed whereas the version on
the v4/micro is actually already up to date.
This change tightens the regex used to query the version by requiring it
to match some sort of newline character after the version string as
well.
BRANCH=None
BUG=chromium:933978
TEST=manual testing
sudo servod_updater
[observe it working well]
Change-Id: I0b3139a120087d49d6f4bd52267d191716d3b541
Signed-off-by: Ruben Rodriguez Buchillon <coconutruben@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1481770
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Matthew Blecker <matthewb@chromium.org>
The new command line option accepts a single optional parameter, the
timestamp. If the parameter is not given, the entire log is retrieved
one entry at a time. If the parameter is given, only entries newer
than the passed in timestamp are retrieved.
BRANCH=none
BUG=b:63760920
TEST=tried retrieving log entries from an H1 running the updated Cr50
code.
Change-Id: I317a659dfc7ebe24cf6f1d957bf0b6d29fb94518
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1525149
Reviewed-by: Namyoon Woo <namyoon@chromium.org>
We want to be able to retrieve flash log contents using the vendor
command channel.
The input parameter of the command is the timestamp of the last
retrieved log event, or zero of the AP wants to start over.
The response is the next entry after the one requested by the AP, or
an empty message if there are no newer log messages.
BRANCH=cr50, cr50-mp
BUG=b:63760920
TEST=with the upcoming gsctools changes observed the ability to
retrieve flash log messages.
Change-Id: I7a5438daab780c80f77cc7ebda5b719814b46489
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1525146
Reviewed-by: Namyoon Woo <namyoon@chromium.org>
With upcoming Cr50 changes which might trigger occasional reboots, it
is better to keep the Cr50 log in the newly introduced flash log space
as opposed to the circular log in SRAM.
There is no need to log TPM resent events, as this is not something
worth tracking in a flash log.
Enabling flash log facility adds 624 bytes to the prod Cr50 image and
1420 bytes to the DBG Cr50 image.
BRANCH=cr50, cr50-mp
BUG=b:63760920
TEST=with modified code observed saving of FE_TPM_I2C_ERROR event.
Change-Id: Id6779de887dac20ce6c1091c8b1571ae900623fd
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1525145
Reviewed-by: Namyoon Woo <namyoon@chromium.org>
Cr50 flash layout does not use space in the top of RO_B section, this
is a good location for the flash log, as it can not be easily used for
the code or RO data of the main Cr50 application.
BRANCH=cr50, cr50-mp
BUG=b:63760920
TEST=with the rest of the stack of patches applied was able to add and
retrieve flash log messages on Cr50.
Change-Id: I8639ad437c5b90eb2d182453bd8bbdda610bdb15
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1525144
Reviewed-by: Namyoon Woo <namyoon@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
Now that we unconditionally include all enum values, which makes the
code easier to read, we still want to add compile-time errors for code
that uses an unsupported PD state based on the board's configuration.
BRANCH=none
BUG=none
TEST=through manually adding incorrect code that uses the wrong state,
that a compiler error is generated in the following form:
common/usb_pd_protocol.c:2669:18: error:
'UNSUPPORTED_PD_STATE_VCONN_SWAP_SEND' undeclared (first use in this
function); did you mean 'PD_STATE_VCONN_SWAP_SEND'?
set_state(port, PD_STATE_VCONN_SWAP_SEND);
Change-Id: Ibf3c05826b32739afaa93cf9563aac61f10441ff
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1526317
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Currently, kukui_scp's memory layout interleaves with RO and RW
sections. This complicates the MPU region configuration, and it
even unconfigurable.
This CL propose to simplify the layout and configuration by introducing
an IROM region, and re-layout the memory.
New layout would be:
---------------------------- 0x0
RO| .stepping_stone
| .text .rodata .data LMA
---------------------------- 0x100000
RW| .bss .data stack
| ipi shared buffer
---------------------------- 0x7C0000
BRANCH=None
BUG=b:123269246
TEST=1. w/o this CL: make buildall -j; mv build build.old
2. w/ this CL: make buildall -j;
3. compare smap by: ls build/*/*/ec.*.smap | \
sed -e 's|build/||' | \
xargs -I{} diff build/{} build.old/{}
and sees that only kukui_scp's smap changed.
Change-Id: I875a28c6b325ba66afe0387d3ea244190ddccde8
Signed-off-by: Yilun Lin <yllin@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1530263
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Yilun Lin <yllin@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
BUG=none
BRANCH=none
TEST=manually ran flash_ec on coral, scarlet, and ampton.
The test log is at gpaste/6202232963858432.
$ ./util/flash_ec --board=coral --read ${IMG}
$ ./util/flash_ec --board=scarlet --read ${IMG} --bitbang_rate=57600
$ ./util/flash_ec --board=ampton --read ${IMG}
Tested with a EXPECT_TO_FAIL case with a line, dut_control_get xxxx
$ ./util/flash_ec --board=scarlet --read ${IMG} --verbose
Problem with ['xxxx'] :: No control named "xxxx"
ERROR: dut_control_get failed: dut-control --port=9999 xxxx
Tested with a board name in stm32_dfu, and checked dut_command_get
is not called.
$ ./util/flash_ec --board dingdong --image ${IMG} --verbose
INFO: Using a dedicated debug cable
INFO: Using toad.
INFO: Using ec image : /tmp/ec.read.bin
INFO: Flashing chip stm32_dfu.
INFO: Using dfu flasher : dfu-util
...
Change-Id: Ib936cf450c3d12f0784ff1aaf3c33e9d18069606
Signed-off-by: Namyoon Woo <namyoon@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1524670
Reviewed-by: Matthew Blecker <matthewb@chromium.org>
This patch adds implementation and test for a generic logger saving
log entries in the flash.
The entries payload are limited to 64 bytes in size, each entry starts
with a header, which includes
- 8 bit type type to allow to interpret the payload
- 6 bit size field (two top bits of the byte are left for user flags,
not yet used)
- 32 bit timestamp to allow to identify newer log entries (presently
this is just a monotonically increasing number)
- 8 bit crc field protecting the entire entry
The entries are padded to make sure that they are ending on the flash
write boundary.
The location of the log is defined by the platform using it. There is
a provision for allowing the platform to register a callback which is
needed to be called to allow write access to the log (as is the case
on H1).
While the device is running, the log is growing until the allotted
flash space is 90% full. If there is an attempt save another entry
after that the log is compacted, namely the last 25% worth of flash
space is preserved, the log space is erased and the saved contents
written back.
On restarts the log is compacted if its size exceeds 75% of the
allotted flash space.
An API is provided to add entries to the log and to retrieve an entry
newer than a certain timestamp value. Thus starting with timestamp
zero will result in reading the very first log entry. To read the next
entry, the read function needs to be called with the timestamp value
of the current entry. This allows to browse the entire log, one entry
at a time.
A CLI command compiled in when CONFIG_CMD_FLASH_LOG is defined, allows
to add log and retrieve log entries.
BUG=b:63760920
BRANCH=cr50, cr50-mp
TEST=the included test case can be invoked by
make run-flash_log
and it passes. More tests are done when the rest of the patch stack
is added.
Change-Id: I3dcdf2704a1e08fd3101183e434ac4a4e4cf1b9a
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1525143
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
A lot of places check if cr50 is forcing the wp state. Add a function
for that.
BUG=none
BRANCH=cr50
TEST=none
Change-Id: Ie00841bd805f987817ab1dcaab740b97af770eb4
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1539008
Reviewed-by: Namyoon Woo <namyoon@chromium.org>
Use code from ash/wm/tablet_mode/tablet_mode_controller.cc, in
particular TabletModeController::HandleHingeRotation()
to calculate lid angle.
Add unit tests based on
ash/wm/tablet_mode/tablet_mode_controller_unittest.cc and the data file
accelerometer_test_data_literals.cc.
BUG=b:120346412
BRANCH=none
TEST=Check unit tests pass, check it compile on FPU based EC, EC without
FPU and no 64 bit support (ampton).
Check lid calculation is correct on eve:
- with "while true ; do ectool motionsense lid_angle ; sleep 1 ; done"
Check when hinge is almost vertical lid angle is close to constant or
marked are unrieliable.
Check when shaking device, lid angle is also unreliable
Check with evtest SW_TABLET_MODE event is trigger when lid angle is
available and cross 180 region.
Change-Id: I545f7333ed9b53accedb75f238f747f66bae1f5d
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1388844
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Jett Rink <jettrink@chromium.org>
USB TX FIFO should be checked for readiyness before trying to
moving data from uart consumer queue to usb producer queue.
BUG=b:126909037
BRANCH=cr50
TEST=manually ran the script below.
i=0
while true; do
dut-control power_state:off && dut-control power_state:rec && \
dut-control lid_open
i=$((i+1))
echo $i
done
Change-Id: I56316165c2ce420029fdc9d594bf1c5274a002d1
Signed-off-by: Namyoon Woo <namyoon@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1515816
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-by: Karthikeyan Ramasubramanian <kramasub@chromium.org>
This adds support for the watchdog timer (WDT) available on Intel Sensor
Hub (ISH). The ISH will reset after T1 expires; see the comments at the
top of watchdog.c for further information on this design decision.
Originally, we had planned to implement a counter that would disable the
WDT after N failures. This was abandoned, since the register used to
store the counter was not able to maintain a value across reset on a
reliable basis (see b:128679825).
BUG=b:127980538,b:128679825
BRANCH=none
TEST=Used waitms command on arcada to verify WDT triggered a warning
IRQ after T1 and reset the system.
Change-Id: I4bd16c253110d60c57eb24cda2abc0facee20748
Signed-off-by: Jack Rosenthal <jrosenth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1526316
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Jett Rink <jettrink@chromium.org>
To flash ITE in ccd mode, I2C ccd capability should be set always.
This CL makes flash_ec check this condition before it attempts to
ask CR50 to send a special waveform which triggers ITE EC DBGR mode.
CQ-DEPEND=CL:1524439
BUG=b:123901082
BRANCH=none
TEST=manually ran flash_ec on ampton in CCD mode.
// Expected to fail , case 1
$ ./util/flash_ec --board=ampton --read /tmp/ec.ampton.read.bin --verbose
...
ERROR: CCD I2C capability is not set as 'Always' : IfOpened
...
// Expected to fail , case 2
$ ./util/flash_ec --board=ampton --read /tmp/ec.ampton.read.bin --verbose
...
ERROR: CCD I2C capability is not set as 'Always' : UnlessLocked
...
// Expected to fail , case 3
$ ./util/flash_ec --board=ampton --read /tmp/ec.ampton.read.bin --verbose
...
ERROR: CCD I2C capability is not set as 'Always' : Default
...
// Expected to success
$ ./util/flash_ec --board=ampton --read /tmp/ec.ampton.read.bin --verbose
...
524288 bytes read.
INFO: Flashing done.
...
Change-Id: I394ea9b6c6e41f0a926f4af5d3767ebba7037f37
Signed-off-by: Namyoon Woo <namyoon@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1524669
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Matthew Blecker <matthewb@chromium.org>
Some boards (Hatch) do not control the PWREN via a GPIO, instead the
power is always on. In that case, do not try to handle that non-existent
GPIO.
BRANCH=None
BUG=b:124405913
BUG=b:126455006
TEST=flash_fp_mcu on Hatch doesn't error out
TEST=flash_fp_mcu on Nocturne still works
Change-Id: I959024693b8af614e930f03991e11b0f44573a49
Signed-off-by: Nicolas Norvez <norvez@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1532344
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Tom Hughes <tomhughes@chromium.org>
Fix the stepping stone code stack_end definition to match the one
in vecttable.c (else LTO complains).
Add __keep to SECTION_KEEP to prevent LTO from dropping the stepping
stone.
BRANCH=none
BUG=b:129111699
TEST=kukui_scp boots, kernel recognizes it
TEST=Saves ~1.5kb of RAM. Before/after:
*** 459968 bytes in RAM still available on kukui_scp ****
*** 461528 bytes in RAM still available on kukui_scp ****
Change-Id: I07e9d9ac003bdc5fce2617aa3aad072b51f89b6b
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1535089
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Yilun Lin <yllin@chromium.org>
For non-gpio-based mkbp event delivery, we do not want to temporarily
disable interrupts as the code to send the mkbp events may use mutexes or
task scheduling to perform the more complicated mkbp event delivery.
For simple GPIO-based implementations, pausing interrupts gives the
mkbp_last_event_time marker the best chance at matching the actual time
the gpio was toggled on the EC. For other implementation, we are already
at the mercy of bus delays and timing for delivery so it wasn't as
reliable in that case to beginning with.
BRANCH=none
BUG=b:128862307
TEST=Ran AIDA64 sensor tab for a long time without seeing ISH
communication issue.
Change-Id: Id6e63a7f7b494559bd38b4659a580fa57666ecf1
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1531773
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Mathew King <mathewk@chromium.org>
Rammus boards do not have a dedicated GPIO for MKBP events
between EC and AP. On boards without this hardware support, the
tight timestamps feature cannot be reliably supported due to
issues with the performance of the ACPI SCI chain, compared to
a dedicated interrupt.
Disabling tight_timestamps restores legacy behavior that is known
to fare better with sensors events over SCI.
BUG=b:123700100
BRANCH=rammus
TEST=tight_timestamps is 0, ran CtsSensorTestCases
Change-Id: I459f2673abad7ff75ba9e8a844b7702dee1ef8c0
Signed-off-by: Enrico Granata <egranata@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1524667
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Alexandru M Stan <amstan@chromium.org>
CONFIG_ACCEL_FIFO was being used both to control the size of the
sensor FIFO, and the notion of tight timestamps. The latter is
related to the format the EC uses to send sensor event timestamps
and not to the size of the FIFO.
Split this latter portion into its own configuration flag,
CONFIG_SENSOR_TIGHT_TIMESTAMPS.
This defaults to enabled, and should be turned on for all new
boards. It will be selectively disabled on a few boards where
the AP-side filtering this enables does not perform optimally
due to jitter issues.
BUG=b:123700100
BRANCH=rammus
TEST=observe tight_timestamps on the sensor_ring device in kernel
be enabled/disabled depending on whether CONFIG_SENSOR_TIGHT_TIMESTAMPS
is #undef'ed or not
Change-Id: I806ba6bb45a0007512afec9151c57c60d30fd604
Signed-off-by: Enrico Granata <egranata@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1524666
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Alexandru M Stan <amstan@chromium.org>
Currently HOOK_PRIO_INIT_ADC is defined as a macro in adc.h. This patch
moves the definition to enum hook_priority for better visibility and
consistency.
There will be no functional change.
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
BUG=none
BRANCH=none
TEST=buildall
Change-Id: I1be65d034993652740d78adc901521621d23b118
Reviewed-on: https://chromium-review.googlesource.com/1520949
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Mechanical replacement of bit operation where operand is a constant.
More bit operation exist, but prone to errors.
Reveal a bug in npcx:
chip/npcx/system-npcx7.c:114:54: error: conversion from 'long unsigned int' to 'uint8_t' {aka 'volatile unsigned char'} changes value from '16777215' to '255' [-Werror=overflow]
BUG=None
BRANCH=None
TEST=None
Change-Id: I006614026143fa180702ac0d1cc2ceb1b3c6eeb0
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1518660
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Requested for linux integration, use BIT instead of 1 <<
First step replace bit operation with operand containing only digits.
Fix an error in motion_lid try to set bit 31 of a signed integer.
BUG=None
BRANCH=None
TEST=compile
Change-Id: Ie843611f2f68e241f0f40d4067f7ade726951d29
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1518659
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Include compile_time_macros.h to files that will use BIT macro.
BUG=None
BRANCH=None
TEST=unit tests.
Change-Id: I9d44f4b588620f6770f8d522d422f5dd0d237903
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1525156
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
As requested for integration in kernel mfd subsystem, use BIT(...)
instead of (1 << ... ).
Add the macros, apply just to ec_commands.h for now.
BUG=None
BRANCH=None
TEST=Compile
Change-Id: I8509f1e8dc966799c3c4f0269b15f1ccc4138c07
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1518658
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Per the VESA DisplayPort Alt Mode on USB Type-C spec, IRQ_HPD indicates
that a high to low followed by a low to high transition was detected.
Therefore, we should be checking when IRQ is high and HPD is low is
received as that is an error. This commit fixes that bug where were
comparing our level to the GPU instead of what was shown in the PDO.
BUG=chromium:920877
BRANCH=grunt
TEST=DP still works with dock and DP-only dongles.
Change-Id: If23bcc94951ca8c40efc35098e05ed2b5f3371d2
Signed-off-by: Edward Hill <ecgh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1530129
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
When we are configuring a Type-C port for DisplayPort alternate mode, we
should check to see that the selected pin config supports multi-function
mode or not. This commit fixes a bug where we were setting the
SuperSpeed muxes based solely upon the Multi-function Preferred bit in
the DPStatus VDO. Some Type-C video adapters are buggy and set the MF
preferred bit without actually supporting an MF pin configuration.
Therefore, we trust the reported supported pin configurations in the
DiscMode VDO.
BUG=chromium:919756
BRANCH=grunt
TEST=DP still works with dock and DP-only dongles.
Change-Id: I3df2b67f29aaf2c725bba30a45bb902bdc44fcf4
Signed-off-by: Edward Hill <ecgh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1530128
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
When we are configuring a Type-C port for DisplayPort alternate mode, we
should check to see that the selected pin config supports multi-function
mode or not. This commit fixes a bug where we were setting the
SuperSpeed muxes based solely upon the Multi-function Preferred bit in
the DPStatus VDO. Some Type-C video adapters are buggy and set the MF
preferred bit without actually supporting an MF pin configuration.
Therefore, we trust the reported supported pin configurations in the
DiscMode VDO.
BUG=chromium:919756
BRANCH=firmware-nocturne-10984.B
TEST=Flash nocturne, plug in Insignia NS-PU369CH-WH USB-C to HDMI
adapter, verify that 4k60 display is shown.
TEST=Plug in Belkin dock which supports SuperSpeed ports, verify that
SuperSpeed ports work and display is shown at 4k30.
Change-Id: I9febb007edc5392a6172e4709482981dbcbdc8b7
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/1404136
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Commit-Queue: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1530127
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Edward Hill <ecgh@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
The TI SN5S330 has VCONN overcurrent protection and will automatically
latch off VCONN if a port overcurrents it. Keeping VCONN latched off is
allowed per the USB Type-C spec. This commit simply logs a message on
the EC console such that it will be easier to tell when it happens.
BUG=none
BRANCH=firmware-nocturne-10984.B
TEST=flash nocturne, plug in a Type-C adapter which overcurrents VCONN,
verify that a console message indicating the overcurrent event is shown.
Change-Id: I22da6e8d43ac7739dc213d5a1f049b98d7ee829d
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/1328321
Reviewed-by: Jett Rink <jettrink@chromium.org>
Commit-Queue: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1330162
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Edward Hill <ecgh@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
The SBU FET control should be tied to entering/exiting DP Alt Mode and
not the USB MUX position as the previous commit had. However, the SBU
lines are also used for CCD and the older boards don't have the
necessary hardware.
BUG=b:114340064
BRANCH=firmware-nocturne-10984.B
TEST=Flash nocturne; verify that external display works after a reboot.
Verify that cr50 is enumerated using SuzyQable.
TEST=Repeat above test on board rev 1.
Change-Id: I5ab9123816fa6ef946dde95b421c5b89bd9719a4
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1250028
Commit-Queue: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1405611
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Edward Hill <ecgh@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
The SBU lines aren't used for the superspeed mux at all so remove the
logic here.
BUG=b:114340064
BRANCH=firmware-nocturne-10984.B
TEST=Make sure that SBU FETs aren't touched by USB MUX settings.
Change-Id: I67074d37ba1960694ad8cfbd09ea63015cedd066
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1250027
Commit-Queue: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1530126
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Edward Hill <ecgh@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
The SN5S330 has FETs for the SBU lines which need to be controlled by
the TCPM. This commit adds a function to control the SBU FETs and
enables them when configuring the USB mux.
This commit also fixes a bug with the external VBUS current limit
setting by setting it appropriately to a min of ~3A.
BUG=b:114340064
BRANCH=firmware-nocturne-10984.B
TEST=Flash nocturne; plug in hoho; verify that external display is
shown. Bounce thru S5, verify that external display still works.
TEST=Repeat above with superspeed hub instead.
Change-Id: I931f7a47d4eb28e8d9e3cb188601ce0889a44f8d
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1244382
Commit-Queue: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1530125
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Edward Hill <ecgh@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
fork ec.tasklist from kukui to add wireless charger task.
BRANCH=none
BUG=none
TEST=BOOTBLOCK=... make BOARD=flapjack -j flash_ec; and see AP boots.
Change-Id: I1d3c82245f94b7cdc1c16fcb753c21325a905fe4
Reviewed-on: https://chromium-review.googlesource.com/1527908
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Tony Zou <zoutao@huaqin.corp-partner.google.com>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
This commit fixes two issues with the LSM6DSM driver:
- it fixes a race condition in load_fifo() which could lead
to samples being labeled at the wrong timestamp if the FIFO
was cleared, and a new interrupt occurred, between reading the
last sample, and pushing it to the motion sense queue
- it drops samples even when the ODR is changed to the same final
normalized rate, since the sensor is turned off/on regardless
of this condition; additionally, it adds one more sample to the
number of samples to be discarded, since I was experimentally
seeing occasional spurious data in the first sample after a rate
change.
BUG=b:124085261
TEST=on Meep with magnetometer stuffed, and CL:1470775
enabled, run CTS sensor test cases
Change-Id: I9701d90fa4e86488840b776e2c7afe4dd89570e7
Signed-off-by: Enrico Granata <egranata@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1509718
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Diana Z <dzigterman@chromium.org>
It was observed that the security verification is the bottleneck for the
EC boot time. In this CL, we reduce this bottleneck by accelerating the
CPU clock during the computation and set it back to normal after.
BRANCH=none
BUG=b:77608104
TEST=pass "make buildall"
TEST =on npcx7_evb, with related CL, we got ~4x improvement of
security verification time.
Change-Id: I679ca10639aa2978b048e1f23285130f6653649b
Signed-off-by: CHLin <CHLIN56@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/1475098
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: CH Lin <chlin56@nuvoton.com>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
This defines PROTOBUF_MIN_PROTOC_VERSION so protobuf headers don't fail
with -Wundef and sets -Wno-unreachable-code to allow for maps to be used
in protocol buffers.
BRANCH=None
BUG=chromium:937442
TEST=make -j buildall
Change-Id: Id595825c224e34df1034c26d49bb4f6263358470
Signed-off-by: Allen Webb <allenwebb@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1531336
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Daisuke Nojiri