The TCPCI specification defines ane optional register
18h 'CONFIG_STANDARD_OUTPUT' providing a standardized way
of steering the high-speed muxes.
Implement the feature as a usb_mux_driver, under the conditional flag
CONFIG_USB_PD_TCPM_MUX.
The USB PD port index should be set in the port_addr field of the
'usb_mux' structure.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:49605
TEST=run pdeval-stm32f072 connected to a Parade PS8751 board and test USB/DP
muxing.
Change-Id: I7e5f0b8ec70b1910b2cff9d106514baca8c899e5
Reviewed-on: https://chromium-review.googlesource.com/322956
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Shawn N <shawnn@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>
Currently the EC waits until it reads a battery status with the flag
STATUS_INITIALIZED set, but the EC does not use this flag for charging
or any other battery operation. If this flag is not set, it does not
mean that the battery is unusable, it just means that its values may not
be trustworthy.
This change will remove the check for STATUS_INITIALIZED and just check
that the battery responds. The battery response shows that the battery
is connected and can be used by the EC.
BRANCH=none
BUG=chromium:564893
TEST=see that device without STATUS_INITIALIZED set will exit
battery_wait_for_stable() without timing out.
Change-Id: I07778e8570b6d9400b61beec6b2e222984a40692
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/315200
Reviewed-by: Randall Spangler <rspangler@chromium.org>
It is possible for the ALS state machine and the chip to not
agree: The EC thinks the device is busy making a measurement,
while the chip is waiting for the IRQ status register to be written.
It is not clear how it happened, an IRQ must have been lost.
Reinitiliazed the chip is stuck for 10s.
BRANCH=smaug
BUG=chrome-os-partner:45627
TEST=With an extra patch that force the IRQ handler to not do anything
every 100th, check the device recovers.
Use andro sensor to monitor light/proximity outputs.
Change-Id: I80d50bf92af127f85f82dc5c0ae318d4cfe06812
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/313668
If proximity overflow (daylight), we would still assume the data was valid
and consider there is an object very very close.
That would prevent the light to be measured. (cl/312982)
Leave the value as max range for the HAL to handle.
BRANCH=smaug
BUG=b:25573958
TEST=Check in daylight that light is still measured
Change-Id: I684e6f4a9aecd3fd6b338a9939f7ede26752ecb8
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/314921
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Depending on timing, additional important messages may reside on our RX
FIFO at the time we process GoodCRC. Therefore, rather than flushing the
RX FIFO, simply read and discard the GoodCRC message.
BUG=chrome-os-partner:314492
BRANCH=None
TEST=Manual on Snoball with subsequent PWM changes. Verify PD contact
can be established with samus.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I4f4fab1bc318d1bce1effffad9a792c5b4a43761
Reviewed-on: https://chromium-review.googlesource.com/314871
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
This adds a new function that can be use to apply USB EQ settings
to the mux. It currently only exposes the Tx and Rx channel
loss compensation.
BUG=chrome-os-partner:47074
BRANCH=none
TEST=build and boot on chell
Change-Id: I1ec83cdcbb17da8e7289e6633509b64f01b14348
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/313747
Reviewed-by: Shawn N <shawnn@chromium.org>
This adds a callback for board specific initialization that is called
after the driver init function. This will allow a board to apply
port-specific tuning (such as USB EQ settings) to the mux chip.
BUG=chrome-os-partner:47074
BRANCH=none
TEST=build and boot on chell
Change-Id: Ib162f9a2c5239678c46b80e5517823b336f6b66c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/313746
Reviewed-by: Shawn N <shawnn@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>
If the proximity sensor indicates there is an object very close
(<= 5cm), ignore light sensor readings.
Otherwise, when someone put their finger on the sensor, the light
sensor would most likely report dark condition and the screen brightness
will be lowered unexpectedly.
BUG=b:25573958
BRANCH=smaug
TEST=check light report does not change when proximity sensor reports
< 5cm, using androsensor apps.
Change-Id: I16db40766a71a7925e28372ebb54ae43f60a4989
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/312982
Always initialize TCPC when TCPM boots. This guarantees
that our TCPM driver is synced up with the TCPC reg values.
BUG=chrome-os-partner:47608
BRANCH=none
TEST=test on glados. reboot EC and PD MCUs independently
with and without external power.
Change-Id: I2d989e8a85ba8a72fe1a8edaef8da9c51651d240
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/312951
Reviewed-by: Shawn N <shawnn@chromium.org>
Add HW charge ramping option and enable on glados.
Modify charge_manager to enable/disable HW charge ramping
when option is defined.
Unfortunately, the isl9237 doesn't have a way to determine
what the input current limit has settled on, so the EC will
always report the max input current for that supplier.
BUG=chrome-os-partner:47335
BRANCH=none
TEST=plug in CDP, SDP, DCP, type-C, and PD charger. Make sure
we ramp to a reasonable value for the correct suppliers.
Make sure we don't ramp for type-C and PD chargers.
Change-Id: Ib541fa0be48d8f4d261c71b853b0ee72b2adbf6b
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/311301
Reviewed-by: Shawn N <shawnn@chromium.org>
Add a new configuration struct tcpc_config_t that initially defines the
i2c host port and i2c slave address of all TCPCs present on the board.
This will allow us to create boards with multiple TCPCs on different i2c
ports, with arbitrary i2c slave addresses.
BUG=chromium:551078
TEST=Manual on glados. Verify PD communication / charging is still
functional on both PD ports.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I9b2bde85d7f1642e8727c052e064371be7967619
Reviewed-on: https://chromium-review.googlesource.com/311000
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Make oak_pd a sym link to glados_pd. A few small changes
necessary to make this possible:
- glados_pd now sets the VBUS present power status bit as oak_pd
does and as is appropriate for TCPCI spec.
- oak_pd now has watchdog enabled (not sure why it was
previously disabled).
- add a flag in gpio.inc to define EC_INT pin on B5 for oak_pd
and A14 for glaods_pd (and all other boards pointing to
glados_pd). Note: this breaks oak board rev 1, where EC_INT was
on A14.
BUG=none
BRANCH=none
TEST=make -j buildall
Load on glados and make sure zinger works.
Change-Id: I28f4ee106e44e2819919f1826508fc1fc05bb2a1
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/310193
Call shutdown() entry point at init() and remove duplicate code.
shutdown would init the sensor so they would be ready if needed.
Set S5 flag to include G3 (hard off) state, not only S5 (soft off).
BUG=chrome-os-partner:45722
BRANCH=smaug
TEST=When doing a RO->RW transition while AP is in G3, check the sensors
are initialized properly. This issue was found while testng the magic
sequence code.
Change-Id: I647f83580240bf5ba0c340fca3184220abe4c12e
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/308561
Reviewed-by: Alec Berg <alecaberg@chromium.org>
If init of the light sensor fails (for instance, the chip is not present
on the i2c bus), we need to fail the init of the proximity sensor.
Otherwise, the EC will report an unexistent sensor to the AP.
BRANCH=smaug
BUG=chrome-os-partner:46638
TEST=check the proximity sensor is not reported if sensor is disconnected from the
main board.
Change-Id: Ie6b1d74eaac4d6c38d52641626966b5d3ce63bd3
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/308560
Reviewed-by: Alec Berg <alecaberg@chromium.org>
If init() is interrupted while we are setting the link to the compass,
the BMI160 may be in paging mode and will only answer to registers 7Eh
and 7Fh. Other registers access will return 00h.
To get out of this state, run the sequence to move back from the paging
mode in the error handler. If successful, a subsequent call to init()
will work.
BRANCH=smaug
BUG=chrome-os-partner:45722
TEST=use a special firmware that exists in the middle of the compass
init sequence. Check that the FIFO and all other registers return 0.
Issue 'accelinit 1' (to reset the Gyro): the command succeeds and the
accelerometer is operational again (double tap works).
Check the sequence can be issued after sysjump to RW/RO.
Change-Id: I3455a8cbdcf1c88699ae90f7c09e4438e1268d47
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/308184
Reviewed-by: Alec Berg <alecaberg@chromium.org>
ARM systems currently use SBS kernel driver which talks to the battery
through I2C passthu in the EC. Instead when asking for battery
information try getting it from the charge state machine first, and
then try the battery if charge state does not have the information.
This reduces latency by cutting out the battery response time.
BUG=chromium:484841
BRANCH=none
TEST=check that power_supply_info works properly on Jerry
Change-Id: If4da15ccabe412adc31fc94b189089ebb3e9265c
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/307905
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
On TCPC startup, set an alert to notify TCPM that we have been
reset. When TCPM gets this notification, it should re-send
initial TCPC parameters. If we were in a stable contract as
a sink, make sure we don't reset connection. If not, then
reset PD protocol state machine to the default state.
This fixes a bug where if the TCPC reboots while the TCPM is
still running, then the TCPC would not get re-initialized and
therefore no PD communication would not work. This also fixes
it such that if we are in a stable contract as a sink and the
TCPC reboots, then we don't lose power.
BUG=chrome-os-partner:46676
BRANCH=none
TEST=tested on glados. reboot PD MCU with and without a charger
plugged in and verify that PD communication works after the
reboot. verify that with a charger, we don't lose power.
also tested with a hoho plugged in during reboot.
Change-Id: I84fec4577b0daf5891bd8461d3f3d925014a5ecf
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/307187
Reviewed-by: Shawn N <shawnn@chromium.org>
With a new PS8740 chip revision 0xb the explicit check for 0xa
is failing. Change this to allow revisions >= 0xa to pass.
BUG=chrome-os-partner:46728
BRANCH=none
TEST=boot on chell and confirm lack of mux init errors
Change-Id: I0847bb9953920569922183ed4c83da2370ef40e4
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/307932
Reviewed-by: Shawn N <shawnn@chromium.org>
Declare optional parameters are const structure.
These parameters, when used, are just read by the sensor driver.
BRANCH=smaug
BUG=None
TEST=compile
Change-Id: I8f2a9291e1908922831fb5e2a524bb6edd0e0f65
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/306696
Reviewed-by: Alec Berg <alecaberg@chromium.org>
When the sensor is defined to be used in forced mode, ec rate was not
calculated properly: if the AP rate was rounded up, ec_rate requested by
the AP would always be 0. If the EC rate is 0, the sensor may potientally
never be queried.
Also, when the sensor was disable for a long time, the last timestamp of
collection may appear to be in the future, so collection was not
initiated. (long time more than 35 minutes, less than 71 minutes).
We still see instance where the sensor seems locked up.
accelinit would not help because the state machine was not reseted, fix
that.
BRANCH=smaug
BUG=chrome-os-partner:45627
TEST=With accelerate 3/4, check the value is now correct.
Check proximity sensor is not stuck 45 minutes after last collection.
Change-Id: Ia6805b75f67b048cb0b42c0f91a73dfaf94a254f
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/305823
Reviewed-by: Alec Berg <alecaberg@chromium.org>
To minimize noise, instead of using recommend preset from the
documentation, use specific repetition value.
BRANCH=smaug
BUG=chrome-os-partner:45436
TEST=Check the noise is somewhat reduced, still not great.
Change-Id: I0ed3409dd907fa1e393d1eb77b6f23ff03763e53
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/305588
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Code for hard iron calibration: Every seconds (or faster if enough
samples), find a sphere that fit the compass data.
Based on Android code.
BRANCH=smaug
BUG=chrome-os-partner:39900
TEST=Check hard-iron bias is removed. Works better outside.
Change-Id: Iab479d5113b6560b4f01b0fd87373d2eecdb9b54
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/299583
Reviewed-by: Anton Staaf <robotboy@chromium.org>
This moves battfake console command to the battery driver.
This fixes a race condition with using the 'battfake' command
where charge_state_v2 could return the real battery percentage
even when a faked percentage is specified, if a higher priority
task uses the battery state of charge in between when the
battery is read, and when the fake state of charge overwrites
the battery parameter.
BUG=chrome-os-partner:45878
BRANCH=none
TEST=use tap for battery with a faked state of charge. the tap
for battery queries the battery percentage a lot, so without
this CL, the tap sequence often temporarily jumps to different
percentages and colors. with this CL, the tap sequence works
great.
Change-Id: I3ae0866d1ff7bb8d0c51355cd6b958310766f19e
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/302711
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Added code to enable the system power monitoring functionality to get the
details of the system power consumption.
And also added EC console command "psys" to get the system power consumption.
BUG=none
TEST=Manually tested on Kunimitsu.
Power = Voltage * Current, reading is equal to the power readings
from the psys command.
BRANCH=none
Change-Id: I62519ac96800363b67cab23cd9eb0dcac229cb47
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/302472
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Increase the change of false positive, but make double feels like Samus:
- increase time beetwen tap to 500ms
- decrease tap threshold to 100mg (actually 62.5mg)
- increase ODR during TAP.
BRANCH=smaug
BUG=b:24440423
TEST=check Ryu and Samus side by side, their tap behavior is more
similar.
run cts -c android.hardware.cts.SingleSensorTests
Change-Id: I260ad95136cb2be71ef4d71efc4bee0b28afa8e0
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/302627
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Code has been added to not send data to AP ring when the
AP does not want data, but we should still enable the BMI160 FIFO if the
EC wants the data.
BRANCH=smaug
BUG=chromium:513458
TEST=Disable sensor at AP (sysfs frequency) enable in EC (accelrate).
Check with accelinfo we are collecting sensor info.
Change-Id: I962fecad0e8cea899e4d788d25982e8bc7e7fb88
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/301795
Reviewed-by: Alec Berg <alecaberg@chromium.org>
- Add interrupt latching: notice that interrupt register
was cleared before entering the task irq handler.
Add a 5ms latching time address the issue.
Check it was not a problem for regular operation.
- Fix FIFO interrupt setting: interrupt when FIFO was full was
missing from one register
- Really disable FIFO when AP does not want data from sensors.
BRANCH=smaug
BUG=b:23570481
TEST=check that significant motion and double tap are reliable in S3.
Change-Id: Iec3681da00462b1aa392056eecea4ee6862d42ee
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/298689
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
In S0, allow the host to enable/disable double tap.
Set S0 accel frequency to 100Hz to track double tap event.
BRANCH=smaug
BUG=chrome-os-partner:44754
TEST=check CTS results are identical to previous runs.
Check we can enable/disable double tap from the host.
Change-Id: Ic36bdd77005a1152fd413fb3869c8a77ef680117
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/298685
Rereading the spec, the repetition registers are massaged by the chip
to produce the repetition value: for XY: 1 + 2 * REPxy, Z axis: 1 + REPz
BRANCH=smaug
BUG=chrome-os-partner:39900
TEST=check the registers matches the spec.
Change-Id: Ic8618d70c18b4f408e3c95acdbe7fcdf6d95e39e
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/299582
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
When IRQ handler is not processing any event raised,
return NOT_HANDLED.
Without this change, any event would set the light sensor
process timestamp and, if the light sensor frequency was lower
than BM160 fifo interrupt frequency, we would never read from
the light sensor.
BRANCH=smaug
BUG=chrome-os-partner:43800
TEST=Compile. Check that light sensor data get updated.
Change-Id: I302f80c5cd9b4f3c926362fdafdc8b5074cabb60
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/298686
This commit adds the base accelerometer as well as the gyroscope to the
list of motion sensors on the board. They are currently wrapped behind an
ifdef for HAS_TASK_MOTIONSENSE due to space constraints.
BUG=chrome-os-partner:43494
BRANCH=None
TEST=Build GLaDOS EC with driver enabled and verify that we can calcuate
a valid lid angle.
TEST=Verify that signs of accelerometer conform to those shown in the
Chrome/Android/HTML5 doc/spec. See description in accelerometer_types.h
TEST=Verify that signs of gyroscope conform to those shown in the
"Sysfs interface to EC accelerometers" document.
TEST=make buildall tests
CQ-DEPEND=CL:299504
CQ-DEPEND=CL:300510
Change-Id: I34026813431f0df6211f9c781ab5b8c7b4dd8403
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/299886
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Add an interface with the host to set up gesture recognition.
Today, only significant motion is supported.
Add a virtual sensor for concentrating gesture support from host.
BRANCH=smaug
BUG=b:23570481
TEST=On ryu, enable significant motion from host.
Change-Id: I906fa2d2d7b4ca2771ea2f58b91de8d97bf4e2e3
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/296213
