| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the policy of the board is to select lowest voltage providing
enough power, the current algorithm ignores the fact that the board
input current limit might be lower than the charger maximum current for
a particular voltage level leading to the possibility of selected a
voltage with a lower available power.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=set a Ryu board with the following configuration :
PD_PREFER_LOW_VOLTAGE
PD_MAX_POWER_MW 24000
PD_MAX_CURRENT_MA 1000
PD_MAX_VOLTAGE_MV 20000
connect it a Zinger (offering 3A @ 20V, 3A @ 12V and 3A @ 5V),
see it selecting 20V rather 12V before the patch.
Change-Id: I8c0589bb5e5705c4d8a6035120d1cdfaacaa14df
Reviewed-on: https://chromium-review.googlesource.com/269262
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new charger has a different input voltage range and has now a 5V
boost providing 1.5A when sourcing VBUS (along with an updated 1.5A Rp),
update the PD descriptors and voltage thresholds accordingly.
Overall, there is no functional change.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:38603
TEST=build and verify 5V and 12V charging is still working
Change-Id: Ie3d54956c940781d06039fccd52966f37d7d48e4
Reviewed-on: https://chromium-review.googlesource.com/269261
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add explicit setting of USB D+/D- switch when setting the type-C
muxes. This fixes a bug in which we would open D+/D- switch when
entering DP mode and lose USB2.0 connection.
BUG=chrome-os-partner:39766
BRANCH=samus
TEST=add printf to board_set_usb_switches() on samus and make sure
we don't open the D+/D- switch when entering DP mode.
Change-Id: I2b5bb2185298794ddb4cc457f3695ce6adabd9f8
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/268993
Reviewed-by: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Scott Collyer <scollyer@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On P5, the lid detection interrupt has been hijacked to workaround the
power sequencing issue. So the lid state is sometimes inconsistent, so
we need to ignore the current lid state when the power button is
pressed, else we sometimes ignore the power-request by wrongly thinking
that the lid is closed.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:38689
TEST=on Ryu P5, switch on the system by pressing the power button either
on the servo board or the casing and see the system turning on.
Change-Id: I88b2e1f06ed8b4a155a42dac640f8b946db214ea
Reviewed-on: https://chromium-review.googlesource.com/269132
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- use the TI BQ25892 instead of the BQ24773 as the battery charger,
update the board configuration accordingly.
=> this change is NOT backward compatible with previous boards
- upate GPIOs configuration
- Use the BQ25892 5V boost to source VBUS.
- on the type-C port, Rp has been set to 1.5A, update the USB PD source
limit accordingly and set the boost limit to 1.65A.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:38603 chrome-os-partner:39202
TEST=make buildall
run on a P4 modified board with BQ25890 and see the battery charging and
the system running on AC and battery. Plug on C-to-A receptacle adapter
and see 5V.
Change-Id: Id28c9dbd155fe5aedc328bf5ab4da4420495e1f5
Reviewed-on: https://chromium-review.googlesource.com/266021
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove all Ryu Proto 4 specific support to make space for Proto 6
configuration : support for both D12 and B8 as PMIC_THERM_L GPIO,
old SuperSpeed mux config.
People with P4/P5 boards can use the ryu_p4p5 board support instead.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:38333
TEST=make buildall
Change-Id: I0c5ab5e098d0e4828bee8f576461cd75bbb7b422
Reviewed-on: https://chromium-review.googlesource.com/266020
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In preparation for Proto 6 board support which won't be backward
compatible, fork the EC for Proto 4 and Proto 5 for people who need to
support older boards.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:39202
TEST=make buildall
Change-Id: I520bbf146cc1c1dc04e55283be57807ec19ebaa1
Reviewed-on: https://chromium-review.googlesource.com/266064
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds an optional extra parameter to the 'rw' command. When the
first argument is .b or .s, the access size becomes 8 pr 16 bits
respectively.
BRANCH=none
BUG=none
TEST=on the EC console:
> rw 0x10000
read 0x10000 = 0x00000000
> rw .b 0x10000 0x55
write 0x10000 = 0x55
> rw 0x10000
read 0x10000 = 0x00000055
> rw .b 0x10000
read 0x10000 = 0x55
> rw .s 0x10002
read 0x10002 = 0x0000
> rw .s 0x10002 0x1234
write 0x10002 = 0x1234
> rw 0x10000
read 0x10000 = 0x12340055
> rw .b 0x10000
read 0x10000 = 0x55
> rw .b 0x10001
read 0x10001 = 0x00
> rw .b 0x10002
read 0x10002 = 0x34
> rw .b 0x10003
read 0x10003 = 0x12
> rw .s 0x10000
read 0x10000 = 0x0055
> rw .s 0x10002
read 0x10002 = 0x1234
> rw . 0x10002
Parameter 1 invalid
Usage: rw addr [.{b|s}] [value]
>
Change-Id: Iad1a4b3e297253ffdbf13afeede8ade9451eb11a
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/268897
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix flaky charge_ramp test. The test often delays CHARGE_DETECT_DELAY
after a new charger has been plugged in. But, that is the same delay
the charge_ramp module uses before starting to ramp. This creates a
race condition where sometimes the test resumes before the ramp up
starts and sometimes the test resumes after the ramp up starts. This
change fixes the problem by modifying the test to delay by 100ms
less than the charge_ramp module.
BUG=chromium:483543
BRANCH=none
TEST=run charge_ramp test 10 times w/o this CL and see failure 4
times. run test 20 times with this CL and observe 0 failures.
Change-Id: I5f7a6a05f9293d3dd7db5517a9df7caec95c58ea
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/268798
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Our goal is to use include/config.h as the canonical list of all
CONFIG_ options. Several CONFIG_ options are in use in various
places in the code, but aren't mentioned in the header.
This CL adds these options:
CONFIG_ACCELGYRO_LSM6DS0
CONFIG_BATTERY_BQ27621
CONFIG_BATTERY_RYU
CONFIG_BATTERY_SAMUS
CONFIG_USB_RAM_ACCESS_SIZE
CONFIG_USB_RAM_ACCESS_TYPE
CONFIG_USB_RAM_BASE
CONFIG_USB_RAM_SIZE
And it changes this misspelled one:
CONIFG_USB_PD_CHECK_MAX_REQUEST_ALLOWED
to this:
CONFIG_USB_PD_CHECK_MAX_REQUEST_ALLOWED
BUG=none
BRANCH=none
TEST=make buildall
Change-Id: I1b4d7ca65efb356f6450a9bc94bb03c1923d933b
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/268778
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These CONFIG_ options in include/config.h are not used or
referenced anywhere else in the code:
CONFIG_ADC_CLOCK
CONFIG_USB_PD_IDENTITY_HW_ID
CONFIG_USB_PD_IDENTITY_SW_ID
The first one is real, but the other two are just the wrong names.
They should be:
CONFIG_USB_PD_IDENTITY_HW_VERS
CONFIG_USB_PD_IDENTITY_SW_VERS
This CL removes the unused option and fixes the names of the
others.
BUG=none
BRANCH=none
TEST=make buildall
Change-Id: I0f6279f362a7aa214ff9b17a2b24b776588a210e
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/268791
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This renames some motion sensor options to start with more
consistent prefixes.
For gesture (tap) detection:
CONFIG_GESTURE_DETECTION:
CONFIG_SENSOR_BATTERY_TAP => CONFIG_GESTURE_SENSOR_BATTERY_TAP
For detecting lid angle:
CONFIG_LID_ANGLE:
CONFIG_SENSOR_BASE => CONFIG_LID_ANGLE_SENSOR_BASE
CONFIG_SENSOR_LID => CONFIG_LID_ANGLE_SENSOR_LID
BUG=none
BRANCH=none
TEST=make buildall
Change-Id: Ib8f645902a5585346e1d8d2cbf73d825c896a521
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/268777
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change the EC_CMD_USB_PD_POWER_INFO host command to report the input
current limit and the max current theoretically possible given the
charger. The input current limit field is useful for logging purposes
and the max current field is useful to give to powerd to determine
if we have a low power charger connected.
The max current is determined by checking if the charge supplier is
allowed to ramp. If the charge supplier is allowed to ramp and has
not completed ramping yet, then max current is the max current that
we are allowed to ramp up to. Once the ramp has completed, then max
current is the stable charging current. If the charge supplier is not
allowed to ramp, then max current is simply the max current as
registered with charge_manager. The point here is to keep the max as
high as possible until we know for sure it is lower to avoid showing
the user the low power notification until we know for sure.
This CL also adds a new charger type, USB_CHG_TYPE_UNKNOWN. For a short
period after a charger is plugged in, the supplier type may change and
PD negotiation is still in process, and therefore we tell the host we
have an unknown charger type. This allows powerd to show the charging
icon, but delay determining if this is a low power charger until we
know for sure.
BUG=chrome-os-partner:38548
BRANCH=samus
TEST=tested with zinger, a DCP, an SDP, and a proprietary charger.
tested that low power notification never pops up with zinger, even
if you purposely wedge charge circuit with "charger voltage 7000" on
EC console. tested that the other chargers all pop up low power
notification once the supplier changes from UNKNOWN to the real
supplier. used "ectool --name=cros_pd usbpdpower" to check current
values.
Change-Id: If8a9a1799504cc2a13238f4e6ec917d25d972b22
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/265066
Reviewed-by: Sameer Nanda <snanda@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Added config option CONFIG_USBC_SS_MUX_DFP_ONLY
- If this options is enabled, then the mux is set to
TYPEC_USB_MUX only is data role is DFP.
- If this option is not enabled, the mux is set for
both UFP and DFP (i.e. RYU)
BUG=chrome-os-partner:39059
TEST=Manual samus to plankton, switching between source and sink modes.
Forced data role swap via ec console command.
BRANCH=Samus
Change-Id: Ibc2fb0ad42d0fe415d3338d38da94ad4b041513b
Signed-off-by: Scott Collyer <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/266916
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Intel DP sees HPD pulse as 2msec < x < 100msec. While DP spec
mentions pulse widths >250usec as acceptable they aren't recognized by
i915 driver.
CL increases the HPD_IRQ pulse width to 2msec minimum.
BRANCH=samus
BUG=chrome-os-partner:39717
TEST=manual samus + apple hdmi multiport dongle drivers external
screen.
Change-Id: I32c33f938ba1aa7a3927a0f75a1269b1278e82de
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/268653
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we are switching from DP mode to USB mode, reset the USB hub to make
sure the hub recognizes USB connection properly. Note that we only reset
the hub when making the switch by pressing the button on the board. This
is to prevent disrupting BFT test flow, during which we don't want to
reset the hub so as to maintain the USB link between the test host and
Plankton MCU.
BRANCH=None
BUG=chrome-os-partner:34296
TEST=Press the button to toggle between DP and USB mode. Measure USB hub
reset signal with a scope.
Change-Id: I69bdee292fe414abbe0a4778b8f5e8041e4534c1
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/237606
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a DP cable is attached, if we toggle the USB/DP mux to USB mode,
the DP data link is broken. In this case, we should send a HPD event to
notify the host. Similarily, when we switch back to DP mode when a cable
is attached, we should send a HPD attachment event and then a HPD IRQ to
notify the host that the DP link is ready.
BRANCH=None
BUG=chrome-os-partner:34296
TEST=Connect Plankton to Samus. Perform the following tests:
1. Attach a cable, and switch between USB and DP mode.
2. Attach a cable in DP mode, switch to USB mode, unplug the
cable, and then switch back to DP mode.
3. Similar to 2 but start without the cable.
Change-Id: I5db0c036ce45850b2f4ca142957f4a235673df6f
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/237604
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sometimes default buffer size in not enough to collect debug
information generated before console is initialized.
This helps when debugging, allowing to enable fairly large amount of
data printed before console is available, could be reduced if memory
becomes tight.
BRANCH=none
BUG=none
TEST=early debug information previously truncated is printed fully
now.
Change-Id: I647c6064a44f7558414f72f399280b5780a4b1ec
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/268640
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
HPD needs to be transported over USB PD as both SBU lines are consumed
for differential AUX signalling.
This CL does the following:
1. Enables GPIO DPSRC_HPD as interrupt.
2. Sends debounced HPD across CC via the SVDM DP status message.
3. Adds polling for GPIO_DBG_20V_TO_DUT_L as it shares the same
interrupt as DPSRC_HPD.
4. Configures DP redriver in presence of HPD high.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=none
BUG=chrome-os-partner:33132,chrome-os-partner:33761
TEST=manual,
1. Connect samus -> plankton via type-C
2. Connect plankton -> DP monitor via displayport
See initial SVDM discovery on samus console
See EDID information
See SVDM status message correct when plug/unplug DP cable from plankton
3. Press 'CHARGING_20V_TO_DUT_L' button and see below on plankton console.
Button 8 = 0
Change-Id: Id95567a3bfa073ffa2c699335be8c5bf0327675f
Reviewed-on: https://chromium-review.googlesource.com/229429
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit, '0016de8 - plankton: Initialize re-driver', didn't account for
the state of the redriver at the time it was being initialized in
manual training mode. This led to inconsitencies of manual training
configuration.
This CL resets the SN75DP130 via software to guarantee configuration
regardless of cold versus warm boot.
Additionally I learned that manual training requires setting of both
the link_bw_set (5.4gbps) and lane_count_set (4) in order make the
back side of the redriver happy. This can ONLY be done however in the
presence of HPD high. Future CL will incorporate this DPCD init into
HDP interrupt handler as well.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=none
BUG=chrome-os-partner:35153
TEST=manual,
samus + plankton successfully drives Samsung U28D590 from cold or warm
boot of either plankton or samus in both polarities. Note DisplayPort
cable must be connected to external monitor prior to power on or reset.
macbook (2015 type-C) + plankton also works.
Change-Id: I8b34341d10f64abfa55c18f70c842a4446f36fa8
Reviewed-on: https://chromium-review.googlesource.com/266526
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A purely cosmetic change making it easier to convert numbers into
enums when analyzing debug printouts.
BRANCH=none
BUG=none
TEST='make buildall -j' still succeeds.
Change-Id: I078a1d253fe928a1390cbed9baf7786a239fa01d
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/268402
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously samus_pd just picked pin mode E without regard to what the
UFP was requesting. This change surveys the UFP's DP pin capabilities
and then requests the appropriate pin config.
Additionally if the UFP supports multi-function and has preferred it
during the initial DP status message, samus will configure its
type-c mux in 'dock' mode.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:38728
TEST=manual,
1. hoho + samus, pin mode = 'C'
2. dingdong + samus, pin mode = 'E'.
3. apple type-C HDMI multiport + samus, pin mode = 'D' and USB device
enumerates as SuperSpeed.
4. plankton + samus w/ patch asserting alternate mode with
multi-function preferred sets config to 'F' now and only drives DP
out on 2 lanes w/ other two allowing USB key to be seen.
Change-Id: Ie4764c33f108e8a88f0052b64ddb96cb92e5a78b
Reviewed-on: https://chromium-review.googlesource.com/267796
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Attempts to use ccprinf() before both uart and usb consoles have been
initialized cause the device lock up. Luckily both console channels
are buffered (and usb console buffering is about to be greatly
improved), all what needs to be done is to hold on to the attempts to
start transmit interrupts until hardware has been initialized.
BRANCH=none
BUG=none
TEST=attempts to print something on the console early in the process
do not cause the device to lock up any more, and the printouts
show up where expected.
Change-Id: I16cd1fab79bceaf7c2334a955fdb6046d21ed550
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/268379
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Sheng-liang Song <ssl@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:38728
TEST=make buildall -j
Change-Id: I6be4e59daf7d79f643a6e4fa6400d6f13f521ea4
Reviewed-on: https://chromium-review.googlesource.com/267795
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Samus does NOT provide any sink capabilities for DisplayPort or USB
device mode so it should NOT request UFP_U select any pin assignments
for DFP_D.
Additionally even if this functionality was provided by the DFP the
specification states, 'and one pin assignment for either the DFP_D or
UFP_D'.
This did NOT cause any functional issues but strictly speaking is a
compliance bug.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:38728
TEST=manual, hoho still successfully drives external monitor.
Change-Id: Iea3441989924dcee69fdb83299ef7e817df55683
Reviewed-on: https://chromium-review.googlesource.com/267794
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Cleanup PD receive error enum by including RX in name since
we will have a different enum for TX errors.
BUG=none
BRANCH=none
TEST=make -j buildall
Change-Id: I355092e0e73a022acb4a92736374cd2289d324bf
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/267670
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current power sequencing would shutdown the system
when suspend command or reboot was initiated from the kernal.
Proper transitions from S0-S3 and S3-S0 are handled.
BUG=None
BRANCH=None
TEST=Tested on Braswell reference design. Issued
commands from kernel:For shutdown - "shutdown -P now" and
suspend - "powerd_dbus_suspend"
Change-Id: I7cc734f29c0dca89f7d9564f175895467b405df0
Signed-off-by: Divya Jyothi <divya.jyothi@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/265091
Reviewed-by: Shawn N <shawnn@chromium.org>
Commit-Queue: Eric Caruso <ejcaruso@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=none
TEST=Verified with a SMBus analyzer that only the expected device
address is detected on the bus.
BRANCH=none
Change-Id: Ib8c8589544b9ec11127619a1120eb21f211fd690
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/267472
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Commit-Queue: Divya Jyothi <divya.jyothi@intel.com>
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=chrome-os-partner:39400
BRANCH=None
TEST=make -j buildall
Change-Id: Iba2ce1395e1f8e662db4888e3cec79d5e4bbce82
Signed-off-by: Divya Jyothi <divya.jyothi@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/267470
Reviewed-by: Shawn N <shawnn@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sometimes the chipset task is slow enough that we might get messages from
the AP before chipset_in_state(CHIPSET_STATE_ON) is true. This causes us
to leave the spi off after our usual reset after every transaction
(see chrome-os-partner:31390). This would put an end to any EC communications.
Instead of relying on CHIPSET_STATE_ON we could just save the value of
"enabled" before we turn it off, then use that as a condition instead.
There shouldn't be a race condition on "enabled" because the only other place
it gets modified is in the hooks, which can't preempt spi_init
(which usually happens in the host command task).
The only problem is that in case of a sysjump enabled will be 0,
so CHIPSET_STATE_ON was left as a backup to handle that case.
This fixup was squashed from Ied3788f83fef548dff3b01bec93d0e40101ba0f7
TEST=Resume minnie from "echo mem>/sys/power/state" a few times, note ec still works
BUG=chrome-os-partner:39564, chrome-os-partner:39576
BRANCH=veyron
Change-Id: I7c33243faebfd74dc33451024c1d75080babee03
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/267593
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=none
TEST=Verified als reading changed on Strago.
BRANCH=none
Change-Id: I4c29234121f19ed35ac3a5ff7cf6fe51996c5bfb
Signed-off-by: li feng <li1.feng@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/267273
Reviewed-by: Divya Jyothi <divya.jyothi@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Commit-Queue: Kevin K Wong <kevin.k.wong@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With mec1322's EMI set to decode IO 0x800, it does not have any other
interfaces to support POST code via IO 0x80.
This change is to enable Port80 POST code support via polling method.
Limitation:
- POST Code 0xFF will be ignored.
- POST Code frequency is greater than 1 msec.
BUG=chrome-os-partner:39386
TEST=Verified Port80 POST code is captured in EC console.
Verified "port80 task" console command will disable/enable Port80 task.
Verified "port80 poll" will get the last Port80 POST code.
BRANCH=none
Change-Id: I27e53e84b5be1fd98464a44407dd58b93d8c798d
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/266783
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
i2c levels were not reporting correct value as programming the
controller to switch to Bit Bang mode was not enabled.
BUG=chrome-os-partner:39400
BRANCH=None
TEST=Wedge condition was simulated and unwedge was validated using
Oscilloscope
1. SDA was grounded, ran i2cxfer console command,
SCL line creates pulses when SDA gets wedged.
2.SCL was grounded to create cloack stretching, ran i2cxfer console
command and unwedge was confirmed.
Change-Id: Id96d8460820b7d19961ed94d1262112ebd146636
Signed-off-by: Divya Jyothi <divya.jyothi@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/267137
Reviewed-by: Shawn N <shawnn@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add Apple VGA charge-through adapter PID to dual-role charging
white list so that we automatically charge through it.
BUG=chrome-os-partner:38785
BRANCH=samus
TEST=make -j buildall
Change-Id: I5de757a9e97824a2b488a45497c73ab53cc1899c
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/267300
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As a source, when we detect Open/Ra (active cable with no UFP)
then do not transition to debounce CC line, instead continue
dual-role toggling as if nothing is connected.
BUG=chrome-os-partner:35652, chrome-os-partner:39486
BRANCH=samus
TEST=test with samus and twinkie. on twinkie, simulate Open/Ra
with: "tw res ra nc" and verify that we continue dual-role toggling.
Then plug in zinger and verify we negotiate and start charging.
Also, tested case where we initially detect Open/Rd and start
debouncing, but then it turns into Open/Ra:
echo "tw res rd nc" > /dev/ttyUSB0; sleep 0.05; echo "tw res ra nc" > /dev/ttyUSB0
In this case, samus transitions to SRC_DEBOUNCE briefly, then goes
back to disconnected state and continues dual-role toggling.
Change-Id: Idabac60b9e2f54639d7a6305d96e9984b0600519
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/267087
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a slight mistake where we were enabling the wrong
interrupt (EP1 instead of EP2).
I'm not sure that this is necessary, since we don't actually do
anything about these interrupts except clear them.
BUG=none
BRANCH=none
TEST=manual
To test, I instrumented the hid_tx() interrupt handler. Before
this CL, it never fired. Now it does.
Change-Id: Iaa5816ec78f70ef101d4663c08842678ddc7d2f9
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/267089
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=none
TEST=Verified system is able to boot to kernel.
BRANCH=none
Change-Id: I7fa4a45bf2209098b5c3794f197d4010c05c356e
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/266835
Reviewed-by: Shawn N <shawnn@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds the support of STM32F09X with 256KB flash.
BUG=none
Test=manual
Check stm32mon ChipID output:
ChipID 0x442 : STM32F09x
Bootloader v3.1, commands : 00 01 02 11 21 31 44 63 73 82 92
Flash read unprotected.
Waiting for the monitor startup ...Done.
Flash write unprotected.
Waiting for the monitor startup ...Done.
Flash erased.
Writing 262144 bytes at 0x08000000
Change-Id: Ied967716750820a335011f244aae5885c507360a
Signed-off-by: Rong Chang <rongchang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/266972
Reviewed-by: Alec Berg <alecaberg@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Identify and ignore cable reset PD command
BUG=chrome-os-partner:39464
BRANCH=samus
TEST=connect two samus'. on one samus add code to send a cable
reset like such:
int send_cable_reset(int port)
{
int off;
CPRINTF("C%d Send cable reset\n", port);
/* 64-bit preamble */
off = pd_write_preamble(port);
/* Hard-Reset: 3x RST-1 + 1x RST-2 */
off = pd_write_sym(port, off, BMC(PD_RST1));
off = pd_write_sym(port, off, BMC(PD_SYNC1));
off = pd_write_sym(port, off, BMC(PD_RST1));
off = pd_write_sym(port, off, BMC(PD_SYNC3));
/* Ensure that we have a final edge */
off = pd_write_last_edge(port, off);
/* Transmit the packet */
if (pd_start_tx(port, pd[port].polarity, off) < 0) {
pd[port].send_error = -5;
return -5;
}
pd_tx_done(port, pd[port].polarity);
/* Keep RX monitoring on */
pd_rx_enable_monitoring(port);
return 0;
}
Without this CL, the receiving samus times out and ends
up causing equivalent of hard reset. With this CL, we receive
cable reset and drop it.
Also used twinkie to measure goodCRC delay. No measureable
change in delay on samus and zinger. Samus delay is ~70us and
zinger delay is ~65us.
Change-Id: Ic0e871c8cf96502b861f430e05ee145881fb55fa
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/266981
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mec1322 only has 96KB program memory, vs 256KB
flash space on lm4.We no longer have enough program
memory to load both RO and RW at boot. We'll want to
implement a small loader program that will load either
RO or RW from flash, and then jump to the loaded image.
CONFIG_FW_INCLUDE_RO is enabled to include RO image into
the build.
pack.py script is altered to load the (lfw + R)O on boot.
Software sync is not added.Distinguish between
RO/RW is yet to be added.
flash_ec is altered to support padding 0xFFs to 256k ec.bin
to match the size of the SPI flash of the board.
BUG=chromium:37510
BRANCH=None
TEST=Make -j buildall,Verified ec.bin to be 256k.
Verified RW image at offset 0h and (lfw + RO) at offset 2000h.
On boot sysjump to lfw. lfw checks in shared SRAM (currently RO)
and jumps to RO image.
Change-Id: Ib9b114e2f24a615d5e5bd8b3803be621d1e5bd17
Signed-off-by: Divya Jyothi <divya.jyothi@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/265807
Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Icarus W Sparry <icarus.w.sparry@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=none
TEST=Verified the pin is toggling along with ACPI Event.
BRANCH=none
Change-Id: If401768fc03925f972adfce1c52f08efb3ffc40c
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/265507
Reviewed-by: Shawn N <shawnn@chromium.org>
Commit-Queue: Divya Jyothi <divya.jyothi@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
lfw is a customized boot loader with max targeted code size of 4k
and data size of 2k.It supports minimal functionalities required to
support chromebooks RO/RW architecture.It is placed in the
write porected section with RO image .
Capabilities include SPI,DMA,UART with minimal debugging support.
Currently sysjump support is missing and exception handling is very basic.
BUG=chromium:37510
TEST=make buildall -j, flashing and booting on strago
BRANCH=None
Change-Id: I803998d489297dfe0745dcccbb54412035d73f78
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Signed-off-by: Divya Jyothi <divya.jyothi@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/265904
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mec1322 bootloader looks for a CRC TAG at the xFF00 boundary of the
flash before it loads the ec onto SRAM for execution. Code for EC will
be packed to occupy the last 256k of Flash. That way the binay generation
is independent of the flash size. The last 20000h is RO + lfw followed by
20000h space for RW.
BUG=chromium:37510
TEST=make -j buildall
BRANCH=None
Change-Id: Ie75bd8a40826d630b3022b5b3ecb2d6ad3aa2471
Signed-off-by: Divya Jyothi <divya.jyothi@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/265885
Reviewed-by: Shawn N <shawnn@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
func < 0 should assign the pin as a GPIO.
BUG=chrome-os-partner:39400
TEST=None
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I231c65a9d660127caf06ff8b235f26563926804d
Reviewed-on: https://chromium-review.googlesource.com/266779
Reviewed-by: Alec Berg <alecaberg@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mec1322 I2C controller 0 has two attached ports. Modify the I2C driver so
that both ports are usable.
BUG=chrome-os-partner:38335,chrome-os-partner:38945
TEST=Manual on strago. Verify that i2cscan is functional.
BRANCH=None
Change-Id: I18d9d516984d041a38c86fd4ec1b0bfa4e885c9f
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/265951
Reviewed-by: Divya Jyothi <divya.jyothi@intel.com>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We allow reading the EC console via case-closed debugging on locked
systems, so we should also allow reading it via host command. The
original reason for denying this (EC printing keystrokes) no longer
exists; we don't print keyboard matrix changes by default anymore.
BUG=chromium:479223
BRANCH=none (well, could apply this anywhere...)
TEST=on a system with both hard and soft WP enabled in the EC,
'ectool console' works instead of failing with access denied.
Change-Id: Ie111bc130dd3f17cd4b658718d00d299786e3434
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/266701
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Update the BQ2589x charger driver to configure properly the boost
used as a VBUS 5V source.
Define the bits used for I2C registers configuration.
Return success in unused charger callbacks to avoid blocking the
charge state machine.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:38603
TEST=On Ryu P4 reworked with BQ25892, plug a C-A receptacle adapter and
see the 5V VBUS coming up, un-plug it and see VBUS going away,
try several PD/type-C charger and check the selected current limit.
Change-Id: I24b832b6d130ff6dfda1ce47f5e445d65279fa7d
Reviewed-on: https://chromium-review.googlesource.com/266063
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This uses the variable 'usage' in an error message to fix a clang
warning.
BUG=chromium:475960
TEST=CC=x86_64-cros-linux-gnu-clang emerge-falco ec-devutils
BRANCH=none
Signed-off-by: yunlian@chromium.org
Change-Id: Ic5703636040805661c7b81b83fc182e127ceab8c
Reviewed-on: https://chromium-review.googlesource.com/266404
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Yunlian Jiang <yunlian@chromium.org>
Commit-Queue: Yunlian Jiang <yunlian@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For the driver functions get_range and get_data_rate, each call would
end up executing an i2c transaction even if the value had not
changed. Therefore, I modified the lsm6ds0 driver to cache the output
data rate as well as the range. This prevents unecessary i2c
transactions from occuring.
BUG=chromium:476226
TEST=Flashed EC on samus and verified that the accelrange and accelrate
commands still worked and that the sensors were functional.
TEST=Verified Double Tap still worked.
TEST=make -j buildall tests
BRANCH=none
Change-Id: Ie432979266dc4e4892978005de5d1df62cc0654f
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/265933
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move "-fno-delete-null-pointer-checks -fconserve-stack" to the
target-only portion of the CFLAGS as they are no needed for host tools
(and not supported by clang).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chromium:475960
TEST=make utils-host V=1
make BOARD=samus_pd V=1
and manually check the compilation flags
Change-Id: I001359621d60b5ad4e020f41fe2e97d4b7edec2a
Reviewed-on: https://chromium-review.googlesource.com/266212
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
|