| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Certain SKUs of certain boards have lesser number of USB PD ports than
defined by CONFIG_USB_PD_PORT_COUNT. Hence rename
CONFIG_USB_PD_PORT_COUNT as CONFIG_USB_PD_PORT_MAX_COUNT.
BUG=b:140816510, b:143196487
BRANCH=octopus
TEST=make -j buildall; Boot to ChromeOS
Change-Id: I7c33b27150730a1a3b5813b7b4a72fd24ab73c6a
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1879337
Tested-by: Karthikeyan Ramasubramanian <kramasub@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
Commit-Queue: Jett Rink <jettrink@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DCI mode is auto-enabled by default. we don't actually support DCI
(intel specific SoC debug path), so we can explicitly disable DCI
mode. doing so, saves about 40mW on the 3.3v rail when USB2 devices
or USB-C to USB-A dongles are left plugged in. this is particulary
relevant in sleep mode as this accounts for a significant portion
of the system power consumption.
BUG=b:119875949
BRANCH=none
TEST=verified power consumption drops using sweetberry, USB devices
still functional across suspend/resume.
Change-Id: Id13630425c78965d2ac4f2e97715374ae0640d23
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1732231
Reviewed-by: Edward Hill <ecgh@chromium.org>
Commit-Queue: Caveh Jalali <caveh@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the ps8751 really does not behave well with explicit low power mode
commands - it enters low power mode on its own in about 2 seconds, so
there's really no need to command it into low power mode.
when the ps8751 is awake, it will take the low power command, but also
generate an alert. when we try to read the alert register, it fails
because the chip is in low power mode, so we go through the normal
process of waking it up, including re-initializing the chip. we then
process the alert and power down the chip again.
but this time around the i2c transaction for the power down command
fails (we don't check this status). the reason the i2c transaction
failed is very likely because the chip processed the I2CIDLE command
and didn't complete the i2c transaction.
BRANCH=none
BUG=b:137622553
TEST=verified chip still goes to sleep on its own
Change-Id: I01b864791ae27a81a4512ddb752329e59be6a8c6
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1733860
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
Commit-Queue: Caveh Jalali <caveh@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The extentions were added to make the compiler perform most
of the verification that the conversion was being done correctly
to remove 8bit addressing as the standard I2C/SPI address type.
Now that the compiler has verified the code, the extra
extentions are being removed
BUG=chromium:971296
BRANCH=none
TEST=make buildall -j
TEST=verify sensor functionality on arcada_ish
Change-Id: I36894f8bb9daefb5b31b5e91577708f6f9af2a4f
Signed-off-by: Denis Brockus <dbrockus@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1704792
Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the requester does not expect the chip information from the live
target, return the hardcoded vendor and product id.
BUG=b:128820536,b:119046668
BRANCH=None
TEST=Boot to ChromeOS
Change-Id: I74affb00951411a3483258a8db165038e7eb683f
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1617894
Tested-by: Karthikeyan Ramasubramanian <kramasub@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Diana Z <dzigterman@chromium.org>
Commit-Queue: Karthikeyan Ramasubramanian <kramasub@chromium.org>
Auto-Submit: Karthikeyan Ramasubramanian <kramasub@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Semantics of renew field in EC_CMD_USB_PD_CHIP_INFO is changing as
follows:
0 -> Return hard-coded info for Vendor ID/Product ID and cached info for
the Firmware Version
1 -> Return the live chip info for Vendor ID/Product ID/Firmware Version
Also rename the 'renew' field to 'live' to match the new semantics.
BUG=b:128820536,b:119046668
BRANCH=None
TEST=make -j buildall; Boot to ChromeOS.
Change-Id: Ie3dd022336b0be5c9728bb0ebabef32b7a6b5d57
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1617893
Tested-by: Karthikeyan Ramasubramanian <kramasub@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Diana Z <dzigterman@chromium.org>
Commit-Queue: Karthikeyan Ramasubramanian <kramasub@chromium.org>
Auto-Submit: Karthikeyan Ramasubramanian <kramasub@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Opt for 7bit slave addresses in EC code. If 8bit is
expected by a driver, make it local and show this in
the naming.
Use __7b, __7bf and __8b as name extensions for i2c/spi
addresses used in the EC codebase. __7b indicates a
7bit address by itself. __7bf indicates a 7bit address
with optional flags attached. __8b indicates a 8bit
address by itself.
Allow space for 10bit addresses, even though this is
not currently being used by any of our attached
devices.
These extensions are for verification purposes only and
will be removed in the last pass of this ticket. I want
to make sure the variable names reflect the type to help
eliminate future 7/8/7-flags confusion.
BUG=chromium:971296
BRANCH=none
TEST=make buildall -j
Change-Id: I2fc3d1b52ce76184492b2aaff3060f486ca45f45
Signed-off-by: Denis Brockus <dbrockus@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1699893
Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=b:123607435
BRANCH=octopus
TEST=check the external monitor can work
Change-Id: Ibe334576b907774df62865817af6ba5eb3e9d96f
Reviewed-on: https://chromium-review.googlesource.com/1445137
Commit-Ready: James Chao <james_chao@asus.corp-partner.google.com>
Tested-by: James Chao <james_chao@asus.corp-partner.google.com>
Reviewed-by: Jett Rink <jettrink@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=b:113830171
BRANCH=octopus
TEST=check the power consumption is lower
Change-Id: I527cdc5d1e4dd5de137ab0927e66c171696758ce
Signed-off-by: James_Chao <james_chao@asus.corp-partner.google.com>
Reviewed-on: https://chromium-review.googlesource.com/1426306
Commit-Ready: James Chao <james_chao@asus.corp-partner.google.com>
Tested-by: James Chao <james_chao@asus.corp-partner.google.com>
Reviewed-by: Jett Rink <jettrink@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All chip info for the anx74xx and ps8xxx chips should be cached
after the first read, so that the info can be accessed in the
future without worrying about chip state. Now that we check the
version registers for these two chips, we need to cache that
information as well.
BRANCH=none
BUG=b:117301622
TEST=on warm reboot with GBB flags cleared, cbmem -t shows
the EC verification stage taking ~30ms instead of ~65ms.
Change-Id: I6077438b58e64b66a23db2992ba025ae3a864c19
Signed-off-by: Paul Moy <pmoy@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1291794
Commit-Ready: Martin Roth <martinroth@chromium.org>
Reviewed-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We know that the PS8751 TCPC needs to have firmware version 0x39 or
higher to support properly detecting Vbus presence.
BRANCH=none
BUG=b:116068318
TEST=min version for ps8751 is reported correctly
Change-Id: I83c7587c5b9792659ecb876039e6c460f242d432
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1246265
Reviewed-by: Justin TerAvest <teravest@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a new field to the pdchipinfo host command that exposes the minimum
required firmware version that we know about. This will allow factory
tests or automated test to compare this version to the current version
and fail.
BRANCH=none
BUG=b:116068318
TEST=with corresponding ectool change, min value is reported correctly
Change-Id: Idf338795c3fd6f9f95e51471d0f6a7a422901d52
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1240457
Reviewed-by: Justin TerAvest <teravest@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The alert line for TCPC will stay asserted as long as there are RX
messages for the TCPM (i.e. EC) to pull from the TCPC. We should clear
all of the RX messages we know about during a single alert handling
session.
This CL can stand on its own, but it is a part of a CL stack that will
tighten the critical section of time between received messages from the
TCPC and sending follow up message out through the TCPC.
See go/usb-pd-slow-response-time for more details.
BRANCH=none
BUG=b:112088135,b:112344286,b:111909282,b:112848644,b:113124761
BUG=b:113057273,b:112825261
TEST=Reduces reset issue in most cases for phaser, bobba. Does not seem to
adversely affect state machine negotiation. Full CL stack consistently
sends a REQUEST at 18ms after a SRC_CAP GoodCRC, which is well below the
24 ms threshold we need to be under for USB PD spec compliance.
Also testing pd_suspend scenario manually and EC was responsive after
port 1 suspend because of "bad behavior"
Change-Id: I1654b46400e9881f2927a5f6d6ace589edd182de
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1185727
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This converts the compile time option of
CONFIG_USB_PD_TCPM_TCPCI_MUX_ONLY into a runtime option to better
support draggon egg designs and reduce CONFIG complexity in general.
Introduce new mux_read/write to read from tcpc_config_t or mux driver
depending on new flag setting.
Audited all mux drivers for any use of tcpc_read/write and updated to
mux_read/write.
BRANCH=none
BUG=b:110937880
TEST=On Bip with CL stack:
Verified by connecting DP monitor at boot;
Verified plug / unplug of DP cable works;
Change-Id: I968893b886ff0ccc4074beae5ec42973814ae77c
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1200062
Commit-Ready: Gaggery Tsai <gaggery.tsai@intel.corp-partner.google.com>
Reviewed-by: Scott Collyer <scollyer@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All of the boards that are using the PS8751 with the
CONFIG_USB_PD_VBUS_DETECT_TCPC have upgraded their TCPC firmware version
past 0x38. We can now use the standard VBus present caching mechanism.
BRANCH=none
BUG=b:77639399,b:110022315
TEST=phaser can negotiated Vbus on C1 still.
Change-Id: I1ee69a67fc78560dde86b2affc288de0f329f53f
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1165856
Reviewed-by: Justin TerAvest <teravest@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We need to keep track of the low-power mode hardware state for each TCPC
so we can put a TCPC back into low power mode when it exits low power
mode before the software TCPM state machine wants it out of low power
mode.
This change also breaks the low power mode entry out of the drp_toggle
method into its own method: enter_low_power_mode.
BRANCH=none
BUG=b:77544959
TEST=Verified Analogix does not get into low-power mode loop. Tested
other SRC/SNK capabilities as well. Tested the device will go back into
low power mode if the AP access the TCPC via the 'ectool usbpdmuxinfo'
command.
Change-Id: I2fdefeda2bf13c2b79d988f0017629115438d313
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1119255
Reviewed-by: Scott Collyer <scollyer@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PS8751 supports the TCPCI spec for controlling the power source and sink
path, which is done through GPIO0 and GPIO1, respectively, by default.
BRANCH=none
BUG=b:78896495,b:78021059
TEST=verified TCPC drives PPC via reworked yorp board.
Change-Id: Ie1de67495947b787ad9cd5aee0db3ca21bec5a10
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1047796
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Once the PS8751 has new firmware, it will be able to detect VBus
at the appropriate time. After that, we can go back to using the
cached version of Vbus detection.
BRANCH=none
BUG=b:77639399
TEST=none
Change-Id: I691919f3bd2479a131aa58763c7906cb4f6919ff
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1024531
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This effectibly reverts CL:993394 except for the parade driver
BRANCH=none
BUG=b:77458917
TEST=yorp p1 still works
Change-Id: I04a57cfcbd19e9f8fdf8165c228a24089c0e1b67
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1005403
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Nasher, sending TCPC_TX_BIST_MODE_2 to register 0x50 on the
PS8751 TCPC does not generate BIST Carrier Mode 2.
BUG=b:68337231
BRANCH=None
TEST=`make -j buildall`
Generated an eye diagram for Nasher on the GRL USB-PD test station
Signed-off-by: Sam Hurst <shurst@chromium.org>
Change-Id: Ia6e5df54a183c989a68d12be3a46896e3daea738
Reviewed-on: https://chromium-review.googlesource.com/741090
Commit-Ready: Sam Hurst <shurst@google.com>
Tested-by: Sam Hurst <shurst@google.com>
Reviewed-by: Vincent Palatin <vpalatin@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>
|
|
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>
|