fusb302 determines attach / no-attach (and Rd / Ra) by comparing CC
voltage against an MDAC output (42 mV steps). The previous 'floor'
calculation was particularly bad for 3.0A Rp (2600 / 42 = 61, 61 * 42 =
2562 mV - 21 = 2551 mV actual threshold, ignoring other error sources).
Reduce the chance of error by rounding our thresholds, which also
matches the suggested thresholds in the datasheet.
BUG=chromium:758608
BRANCH=gru
TEST=Attach problematic dingdong, verify we don't enter an attach /
detach loop.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I9211782da0fdad8339246e272952ba1930b69851
Reviewed-on: https://chromium-review.googlesource.com/633276
Reviewed-by: Joe Bauman <joe.bauman@fairchildsemi.com>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
(cherry picked from commit 311b3e4e15fd37ea2ab151edb8b8a468e93355fd)
Reviewed-on: https://chromium-review.googlesource.com/638694
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Zero ITERM_SET to keep the charger out of topoff mode, since it has
undesirable side-effects related to dead / low battery charging.
BUG=b:35575421
BRANCH=reef
TEST=Previous testing on kevin with same register setting.
Change-Id: Ic1dd280e1069d410895498c0f72989654a6b8c63
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/636152
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
fetching the chip firmware version toward the end of the chip
anx74xx_tcpm_init() sequence is a good place to do this. we need this
info in any case and this is a safe place to access device registers
and cache the values. subsequent chip firmware queries typically
return the cached value. also, tcpci_tcpm_init() is already
structured this way.
TEST=verified with follow-up CL that firmware update succeeds and new
version is reported
BRANCH=none
BUG=b:35586895
Change-Id: Ic3fd07bbf8a220bfd506d59d8a1f3ea25b14e94c
Signed-off-by: Caveh Jalali <caveh@google.com>
Reviewed-on: https://chromium-review.googlesource.com/634513
Reviewed-by: Shawn N <shawnn@chromium.org>
TEST="make buildall" succeeds, "make runtests" passes for reef.
returning SUCCESS instead of UNIMPLEMENTED from .release() means the
pd_task() is allowed to reinitialize the TCPC when coming out of
PD_STATE_SUSPENDED or similar scenario.
TEST=verified anx3429 firmware update succeeds, USB port still usable
for charging after update.
BRANCH=none
BUG=b:35586895
Change-Id: I1a624ccf25dfa6468de72f8564f936bc0a35edb1
Signed-off-by: Caveh Jalali <caveh@google.com>
Reviewed-on: https://chromium-review.googlesource.com/596797
Reviewed-by: Shawn N <shawnn@chromium.org>
On max17055, current/temperature register values are in 2's
complement format.
Therefore we need to consider the case of negative values before
doing bitwise operation.
BUG=b:63870414
BRANCH=none
TEST=run 'battery' command and confirm the reported discharge
current looks reasonable.
Change-Id: Iea0c554aecf2b410fc27b547e01ee7a583a0dd00
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/617654
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
When booting scarlet rev1, the initialization of rt9466
is not finished because CHIP REV < 0x05.
Actually, we shouldn't keep the latest CHIP REV in rt946x.h
because it's hard to maintain. And we should try to finish
rt946x_init() no matter what CHIP REV it is.
Also, let's clean up the logging message in rt946x_init()
a bit to make it clear that it's from RT946X.
BUG=chromium:736821, b:63739819
BRANCH=none
TEST=boot scarlet rev1 and confirm the
initialization of rt946x is finished
Change-Id: Ic0b1f837b801cc18744a1222794a055dfe8aa54c
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/612585
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
the ps8xxx family of TCPCs (ps8751, ps8805) have historically used the
generic tcpci_tcpm_drv functions, but we need to override some of
these entry points because the parade parts need to be woken up before
accessing registers.
in most cases, this doesn't matter because we access the chip in quick
succession where we can "safely" assume the chip is awake -- and the
code is structured to implicitly keep the chip awake. the new case we
need to address here is where we need to suspend the pd_task and TCPC
at an arbitrary point in time. the driver's .release method is called
to shut down the chip, and that involves first waking up the chip to
be able to access its regs to mask off interrupts, etc.
BUG=b:35586896
BRANCH=none
TEST=tested from depthcharge - we no longer get errors in the EC
console logs about TCPC "release" failed.
Change-Id: Ic2a90b71050b3f68c697b1cef48d736ed88b3f41
Signed-off-by: Caveh Jalali <caveh@google.com>
Reviewed-on: https://chromium-review.googlesource.com/616460
Reviewed-by: Shawn N <shawnn@chromium.org>
We use the unofficial, Windows 8, Relative Scan time HID usage
(Digitizer page, 0x56) to add timestamps to our HID touchpad
events.
The timestamps is a rolling, unsigned, 16-bit integer, with a
resolution of 100us (so it wraps around every 6.5s).
The host will be able to synchronize to that timestamp, resetting
an offset every time the touchpad is quiet a certain amount of
time (e.g. 1 second).
BRANCH=none
BUG=b:63685117
TEST=Flash hammer, timestamps are reported in HID descriptor.
Change-Id: Ie5d56a9df14e464d2cdcd559f550d6e3cc81961f
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/603041
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The variable is_high_power was only used if a board was using charge
ramping. However, we can get rid of the variable entirely.
Additionally some of the intermediate gpio_signal variables can be
removed as well.
BUG=none
BRANCH=none
TEST=Build a board that uses the bq24392 but does not charge ramp.
Verify that there are no compliation errors.
Change-Id: I7edaa74f5029c08662d8c4a15c973beae9729fdf
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/601533
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
In the function bd9995x_battery_charging_profile_settings, the current
values for trickle, precharge, and fastcharge were being set. Fastcharge
current level was being set via
charger_set_current(PD_MAX_CURRENT_MA). By calling this function with
a non-zero parameter, charging will always be enabled. In addition,
PD_MAX_CURRENT_MA is an input current limit and doesn't neceassrily
apply to the fastcharge current level which would be read from the
fuel gauge. The other side effect is that by enabling charging, VSYS
is being set to battery->voltage_min which reverts VSYS being set to
battery->voltage_max in the init routine.
Per Rohm, all charging profile registers should be set prior to
enabling charging. On Coral, enabling charging at this point was
leading to VSYS collapse when no battery was connected or a fully
depleted battery case. I also believe that enabling charging here
exacerbates other issues we've been running into with low battery
startup cases.
BUG=b:64388515
BRANCH=eve
TEST=On Coral tested both no battery a fully depleted battery
cases. Verified that without the call to charger_set_current() that
VSYS consistently collapses and that after removing this call, the
start up was stable and the battery begins charging.
Change-Id: Ice20ed5d8147fe9ad8faa754286a2ec8a784f8d8
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/602493
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
We'd like to know touchpad vendor/product id, as well as currently
running FW version. This CL does that by adding a new
UPDATE_EXTRA_CMD_TOUCHPAD_INFO command.
We also make the interface more generic by adding a CONFIG_TOUCHPAD
configuration option, even though we only support Elan touchpads
currently.
BRANCH=none
BUG=b:63418037
TEST=Flash hammer, ./usb_updater -t
Change-Id: Icce3c785eb3235bcc50b2ae7c0227ce11cbc9f2b
Signed-off-by: Nicolas Boichat <drinkcat@google.com>
Reviewed-on: https://chromium-review.googlesource.com/593000
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Chun-ta Lin <itspeter@chromium.org>
The primary purpose of the Pericom PI3USB9281 is for BC1.2 detection.
Therefore, move the driver to the bc12/ directory.
Additonally, rename the config option to match.
CONFIG_USB_SWITCH_PI3USB9281 => CONFIG_BC12_DETECT_PI3USB9281
BUG=None
BRANCH=None
TEST=`make -j buildall`
Change-Id: I02f17064c0625e62d6779f895e69899c24898f74
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/594710
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
The BQ24932 is a dual single-pole single-throw USB 2.0 high-speed
isolation switch with charger detection capabilities. The device's
charger detection circuitry can support USB Battery Charging
Specification version 1.2 (BC1.2), Apple, TomTom, and other non-standard
chargers.
BUG=None
BRANCH=None
TEST=`make -j buildall`
TEST=Enable support for the BQ24392 on a board. Verify that it
complies.
Change-Id: I82f426f1eedabdbb6b951a6ce0252135de3368db
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/592133
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
id only really needs 4 bits (16 touch events should be more than
enough), so we can steal 2 bits from that field.
We also reorder the fields to make sure that width/x are aligned
on 8-bit boundary.
BRANCH=none
BUG=b:63936194
TEST=Flash hammer, touchpad works, ABS_PRESSURE > 255 is reported
when a palm is pressed on the touchpad.
Change-Id: I1abf1bf53cc9dd998082cea5dc7cd3be17f99ec6
Reviewed-on: https://chromium-review.googlesource.com/583297
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Chun-ta Lin <itspeter@chromium.org>
Reviewed-by: KT Liao <kt.liao@emc.com.tw>
BUG=chromium:736603
BRANCH=none
TEST=Follow the steps below
1) add MAX17055 config to Scarlet and build the code
2) hook up max17055 eval board and a single cell battery
3) battery command from ec console shows reasonable numbers
for temperature, voltage, and charge percentage
Change-Id: I3f838ff92c591665e9f1d0a7ba636ff83d9b7612
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/578300
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Reduce maximum frequency of BMM150 compass to 80Hz, 800Hz is a typo.
Reduce SI1141 maximum frequency to 50Hz: 100Hz is too high when polling
mode is used.
Fix up of CL:482703
BRANCH=eve, glados
BUG=chromium:615059
TEST=On eve, check CTS test
android.hardware.cts.SensorBatchingTests#testMagneticField_fastest_flush
passes. Observed that dumpsys sensorservice returns compass maxRate at
80Hz instead of 200Hz.
Change-Id: If4e688ab59aa53c402d34714b6bb33ccd4a4ab96
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/570482
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
This commit adds support for the PS8805, another Parade Tech TCPC with
integrated superspeed muxes. This also creates a generic Parade Tech
TCPC driver which supports the PS8xxx series.
The current supported TCPCs are:
- PS8751
- PS8805
BUG=b:63508740
BRANCH=None
TEST=`make -j buildall`
Change-Id: I78383af414996e0e8d6220985d286f95267136f8
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/564799
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Use existed macro instead of creating new one.
BRANCH=none
BUG=none
TEST=plug USB-C power adapter and USB-C to hdmi adapter, both work.
Change-Id: I133142232ac6abfa7f285c289eb03c4d65e84d5f
Signed-off-by: Dino Li <Dino.Li@ite.com.tw>
Reviewed-on: https://chromium-review.googlesource.com/554655
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
similar to the USB_PD_TCPC case, add release/init operations when the
pd_task enters/leaves the PD_STATE_SUSPENDED state. one use case for
PD_SUSPEND is to get exlusive access to the TCPC for things like
firmware update, so the release/init operation is needed to get the
TCPC and driver into a good state.
updated all tcpm_drv style drivers. for backward compatibility, "old"
drivers that may not handle init/release properly simply return
EC_ERROR_UNIMPLEMENTED for tcpm_release(). pd_task() uses this as a
signal that it should not try to re-init() the driver.
TEST=tested in combination with follow-on CLs to do TCPC firmware
update on electro. also built for kevin, eve, sand which are
some of the other boards using these drivers.
"make buildall -j" passes.
BRANCH=none
BUG=b:35586896
Change-Id: I3d2964a79e710428f7a6e7004d68ab424af85be8
Signed-off-by: Caveh Jalali <caveh@google.com>
Reviewed-on: https://chromium-review.googlesource.com/544660
Reviewed-by: Shawn N <shawnn@chromium.org>
The initial value for input current limit is set to
CONFIG_CHARGER_INPUT_CURRENT which is typically 512 mA. In deeply
discharged battery cases (Vbat < 5.8V), the 512 mA input current limit
can cause VSYS to collapse which in turn causes the EC to
reset. Depending on how discharged the battery is, the EC may remain
off until the external charger is disconnected and reconnected again,
or it may undergo a number of reset cycles, each time charging the
battery just a little, until Vbat becomes > ~5.8V and the charger is
able to stabilize. When the charger type is determined, either from
BCD detection, or Type C/USB PD, the input current limit is set to the
appropriate level.
In order to avoid the issue described above, this CL sets a bit in the
VIN_CTRL_SET register which will disable the input current limit in cases
Where the VBAT is less than the VSYSREG_SET value.
BUG=b:35648317
BRANCH=none
TEST=Manually tested on Electro.
a. With Zinger attached DUT boots without the battery after
plugging in AC
b. DUT boots from cut-off battery
c. With Zinger attached DUT boots from cold-reset without the
battery
d. With no battery & DCP charger, anti-collapse occurs,
input current is limited to 512mA & the DUT is
power-up inhibited.
Tested also on Eve with signal wires attached to both PPVAR_VSYS,
PP3300_DSW, and Vbat. Verified that on certain boards (some board to
board variation) that PPVAT_VSYS would collapse when the input current
limit was set to CONFIG_CHARGER_INPUT_CURRENT. Then after adding this
CL, verifed on the scope that the collapse of PPVAR_VSYS no longer
occurred.
Change-Id: Ief9960550f988e69ab4637db85450e91c70d3b51
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/456049
Commit-Ready: Vijay Hiremath <vijay.p.hiremath@intel.corp-partner.google.com>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Vijay Hiremath <vijay.p.hiremath@intel.corp-partner.google.com>
The line to convert the desired double tap window time to its
register value was using the incorrect macro. Have corrected this to
use the intended one.
BUG=b:62202895
BRANCH=none
TEST=On Eve verified that double tap events are properly detected.
Change-Id: I70d810c93a8e27a3f61f3175e1ea95d0e59554ac
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/518522
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
In order to ensure we are always meeting the deadlines for the IRQ_HPD
pulse, increase the priority of the processing by moving the rising edge
from the low-priority HOOK task (in a deferred function) to the caller
task (which is the high-priority PD task).
The downside is we are now sleeping in the PD task blocking the
processing of the PD messages during this time.
Changed HPD_DSTREAM_DEBOUNCE_IRQ to 500us instead of 750us. According
to DP spec, the IRQ_HPD pulse width is between 500us and 1000us.
Ensure there is a minimum of 2ms delay in between each IRQ_HPD as specified
by the DP spec, by sleeping before sending the next pulse if needed.
(in practice, this should not wait if we are not too off processing the
messages)
BUG=chromium:711334
BRANCH=glados strago reef oak
TEST=manual, on SKL platform with kernel 3.18 and MST, verify display is
functional on USB-C dock.
Change-Id: Ib2e9dd608c5f1c671cc5a0fd979a5742101375ff
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/508629
Reviewed-by: Todd Broch <tbroch@chromium.org>
The trimmed value of CC parameter setting registers
(port0: ff3760h ~ ff3763h, port1: ff3860h ~ ff3863h)
will be reset to default after a soft reset (system_reset()).
BRANCH=none
BUG=none
TEST=Console command 'reboot' and checking if the value of
cc parameter setting registers are correct (trimmed).
Change-Id: Ibf9c72e8aeef36701d72bcb64529735295295cdf
Signed-off-by: Dino Li <Dino.Li@ite.com.tw>
Reviewed-on: https://chromium-review.googlesource.com/513744
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Allow to configure the sensor to detect autonomously finger touch event
similar to what is done in the suspend() routine of the kernel fpc1020
driver.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=b:35648259
TEST=make BOARD=eve_fp
Change-Id: I8b78bd6bdeecd8658850383417c950d9025fdf40
Reviewed-on: https://chromium-review.googlesource.com/491072
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Move the existing fingerprint host command in the driver and
add more of them to prepare the new fingerprint architecture.
The commands are mostly stubbed for now.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
CQ-DEPEND=*364728
BRANCH=none
BUG=b:35648259
TEST=make BOARD=eve_fp (with and without a private repository)
do a fingerprint image capture with 'fptest'.
Change-Id: Ie17a5fde2d6470c6272e8059bddc845cea07aff2
Reviewed-on: https://chromium-review.googlesource.com/491071
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Adds min_frequency and max_frequency to struct motion_sensor_t.
New attributes min_frequency and max_frequency are now returned in
ectool's MOTIONSENSE_CMD_INFO response.
Incremented ectool's MOTIONSENSE_CMD_INFO version to version 3.
Add constants for MIN_FREQUENCY and MAX_FREQUENCY to each sensor's
header file.
BRANCH=none
BUG=chromium:615059
TEST=build/boot and verify MOTIONSENSE_CMD_INFO response on kevin,
make buildall -j passes.
Change-Id: I66db9715c122ef6bb4665ad5d086a9ecc9c7c93a
Signed-off-by: Nick Vaccaro <nvaccaro@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/482703
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
At init time, read resolution/dpi from trackpad, and check that
logical/physical dimensions match the expected values, provided
at build-time.
BRANCH=none
BUG=b:38277869
TEST=Flash staff, no error message at boot time. Flash hammer image
onto staff, a warning is shown at boot time.
Change-Id: I5ef7d25b6e6525c2bd6fc023f58f3a242134d962
Reviewed-on: https://chromium-review.googlesource.com/505857
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
With the change, compiler won't use 64-bit division for
bd9995x_psys_charger_adc() function.
BRANCH=none
BUG=none
TEST=To replace "reg" variable and checking the return value
if it is expected for both "bd9995x_psys_charger_adc()" and
"bd9995x_amon_bmon_chg_adc()" functions.
Change-Id: Ifc461e5a54ce583ff59281ad13421c640ec9e21e
Signed-off-by: Dino Li <Dino.Li@ite.com.tw>
Reviewed-on: https://chromium-review.googlesource.com/485083
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The function bc12_detect was using a msleep(312) to allow for enough
time for the bd9995 to determine the charger type. Putting the USB_CHG
task to sleep for this period of time means that the USB_CHG task is
not able to process interrupts from the bd9995 during that time. This
is a particular problem when Try.SRC is enabled and a charger is
connected. VBUS will only remain present for ~40-50 msec, and
when it goes away, the discharge circuit should be engaged. However,
the USB_CHG task is still in the 312 mSec sleep from when VBUS was
detected. The result is that discharge circuit is not engaged. It was
observed that processing of charger interrupts could be delayed
upwards of 500 msec.
On Eve with the EVT charger, VBUS was not discharging without the
discharge circuit being enabled. This resulted in excessive connect
time as the Try.SRC cycle repeated many times until a case where the
discharge circuit was not disabled when VBUS detect occurred and this
finally allowed the charger to attach.
This CL modifies the USB_CHG task main loop so that a wait timer is
used when bc12_type needs to be read from the charger. There is a wait
timer mark per port. If the mark value is 0, then a wait timer is not
required and the task is put to sleep with -1. Each time the task is
woken, either from the interrupt or wait event timer, the current time
is checked against the timer mark for each port. The function that
reads the bc12_type will return a 1 if the type is still not available
and will return 0 if either VBUS is no longer present, or the
bc12_type was successfully determined.
With this change in place the discharge circuit is reliably
enabled/disabled within ~5-10 mSec of VBUS changes.
BUG=b:37292010
BRANCH=reef,gru
TEST=Manual
Added signal probe wires to VBUS, discharge control, and charger
interrupt signals. Connected eve EVT charger and verified that the
discharge circuit is consitently enabled when VBUS is removed
following the initial attach in Try.SRC. Verifed that the EVT charger
always connects on the first attempt.
Also tested with various different chargers on both Eve and Reef
platforms. In addition, temporarily changed the initial deferred time
to 100 mSec and validated the path where vbus_provided is not true and
that additional deferred calls were initiated until bc12_type is valid.
Change-Id: Idd066b5461ec4cbb77bb023519fed90c9e9f71db
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/487028
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
We can get the correct chip info after the change was made.
BRANCH=none
BUG=none
TEST=console message:
[0.013915 TCPC p1 VID:0x48d PID:0x8320 DID:0x1 FWV:0xec]
[0.018054 TCPC p0 VID:0x48d PID:0x8320 DID:0x1 FWV:0xec]
Change-Id: I4eb94967acb351559e745ed1c4e34a4c58f41e14
Signed-off-by: Dino Li <Dino.Li@ite.com.tw>
Reviewed-on: https://chromium-review.googlesource.com/487767
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If charging current is set to 0mA during charging, reference of
charge current feedback amp (VREF_CHG) is set to 0V. Hence the DCDC
stops switching (because of the EA offset). To eliminate this issue,
disable/enable charger depending on the charging current is zero
or non-zero respectively.
BUG=b:37413065
BRANCH=reef
TEST=test 'ectool chargecontrol normal/idle/discharge' are working
Change-Id: Id31876afe365a476fb906e059ab519b7a0c9a7c6
Signed-off-by: james_chao <james_chao@asus.com>
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/486101
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
(cherry picked from commit 6da9ed8786e90ee91b39934180fe84e01ac30260)
Reviewed-on: https://chromium-review.googlesource.com/489812
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
RO does not need touchpad/keyboard driver or I2C passthru, RW does
not need RW verification, let's shrink both images by only including
required config options.
BRANCH=none
BUG=b:35582031
TEST=Build and flash hammer: still functional.
build/hammer/RO/ec.RO.flat shrank by 10144 bytes: (45868 to 35724)
build/hammer/RW/ec.RW.flat shrank by 2764 bytes: (45332 to 42568)
Change-Id: Iff0feb4e8446cc9f2e32103cd383fddae3234fec
Reviewed-on: https://chromium-review.googlesource.com/479492
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
These are options for features can be implemented if they are required.
BRANCH=none
BUG=none
TEST=build 'it83xx_evb' board with pd modules.
Change-Id: I1afb7d9c2d764728a375563a6739544032394c54
Signed-off-by: Dino Li <Dino.Li@ite.com.tw>
Reviewed-on: https://chromium-review.googlesource.com/483319
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Before entering standby mode, bit 7 (cable_det) or analog_ctrl_0 is
cleared. This allows a new cable detect event to trigger the EC to
put the ANX4329 into normal mode. However, in some cases such as when
in S3/S5/G3 chipset power states a port will be in sink only mode and
therefore won't attach when a sink only adapter is connected to the
port. This results in the an indefinite toggle of standby<->normal
mode transitions. This constant toggle floods the EC console and more
importantly prevents the ANX4329 from remaining in standby mode and
the power consumption remains at ~9.5 mW instead of ~1.2 mW when no
adapter is connected.
This CL adds logic around clearing the cable_det bit so that it's only
cleared if both CC lines are open or if an Emark cable is
attached. Emark cable is determined from the presence of Ra on one CC
line and no Rd on the other CC line. The special consideration for an
Emark cable is reqiured because when an Emark cable is connected, the
USB PD auto toggle state may require some number of iterations until
the attach event is recognized.
In order to support handle cases where the drp mode is changed via
either the EC console command or host command, added a call to
tcpm_set_drp_toggle whenever the drp state is updated. Since the drp
mode is updated upon chipset resume events, the chipset resume hook in
board.c for anx74xx_cable_det_handler() became redundant and hence it
was removed.
BUG=b:35775019,b:35586188
BRANCH=reef
TEST=Tested the following cases:
- Sink, source adapters in chipset S0. Verified that adapters
connected as expected. Also, used Emark cable to connect to both USB
PD chargers (source) and Pixel phone (sink).
- Run 'lidclose' on EC console then connect Type C -> A adatper
[3490.370125 TCPC p0 reset!]
[3490.389588 TCPC p0 Low Power Mode]
It no longer toggles indefintely and after running 'lidopen' verified
that port 0 is now in SRC_DISCOVERY.
- In S3/G3 connected USB PD charger with regular and Emark typeC
cable. Verified that port 0 is in SNK_READY state.
- use 'pd dualrole sink' and test with Type C -> A adatper. Verified
that tcpc wakes up, but goes into standby mode until entering 'pd
dualrole on'.
- When sink only adapter is connected in S3/G3, measure power level
~1.2 mW as opposed to ~10 mW in S0.
- Repeated similar tests on port 1 (parade tcpc) to verify that
adapters connected as expected.
Change-Id: Ib8de666f72723934186fee7869f9dda01381c7a8
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/463991
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: S Wang <swang@analogix.corp-partner.google.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
The cable_det signal is used to signal to the EC that the tcpc has
detected a cable being connected when low power mode is
configured. The driver then needs to take the tcpc out of suspend
state by setting PWR_EN and RESET_N high. Then bit 7 of analog_ctrl_0
needs to be set properly.
The code that is handling this transition was attempting to access the
tcpc via I2C before putting the chip in normal mode when
transitioning from suspend to normal. In addition there are issues
with calling the driver function directly from the hook task (in the
delayed ISR handler) and from the USB PD task.
This CL changes the delay ISR handler to only set the TCPC_RESET
indication so that the call to put the ANX3429 into normal from
standby to normal mode only happens in the USB PD task. The TCPC_RESET
event is only set if cable_det is high, but reset_n (to the ANX3429)
is low which indicates that the ANX3429 is currently in standby mode.
BUG=b:35775019
BRANCH=reef
TEST=Manual
Tested with various adapters in both S0 and S3/G3 chipset
states. Verified that adapters connected as expected. When in S3/G3
connecting a sink only adapter still causes an indefinite toggle, but
all calls into the driver are executed from within the USB PD 0 task
and all ANX3429 I2C accesses work as expected.
Change-Id: I6e4843e43f59afbf5ca3251feb68981b815c1c78
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/457103
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
This patch disables IADP immediately after the EC boots. We
observed noise on IADP/RESET pin causing SEL_ILIM_VAL to
randomly change. This seems the cause of b:35648317.
We enabled IADP to fix b:35647661 initially and also followed
the vendor's recommendation. However, the issue is only
reproducible on the particular board which was used for power
measurement and we did not see the issue on other boards with
IADP disabled.
Also the vendor assumed our EC doesn't control IBUS_LIM_SET
and ICC_LIM_SET. (I think they assumed like other thier customers
our EC controls ILIM by DAC connected to IADP/RESET pin.) If ILIM
is not set by EC and IADP is disabled, the system would brownout
because ILIM stays at 128mA. Therefore, it was (mistakenly)
recommended that our EC should keep IADP enabled.
Cros EC configures IBUS_LIM_SET and ICC_LIM_SET dynamically thus
the above concern does not apply.
We also found that we have too much noise on IADP/RESET pin. The
noise is not big enough to cause the chip to reset but it's big
enough to cause ILIM to fall in 128mA zone. We think this is why
the boards fail to boot from battery cutoff or no battery.
(Contrary to the vendor's explanation, it seems IADP/RESET pin
continusouly affects ILIM not only in the early chip power-up
period.)
BUG=b:35648317
BRANCH=none
TEST=Booted two Electro and two Snappy from 1) dead battery 2) no
battery 3) battery cutoff.
Change-Id: Ic675f1354b9ef222ceec8ce112b19713812d2752
Reviewed-on: https://chromium-review.googlesource.com/458676
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
