Add command to read the sensors events FIFO from the AP:
FIFO_INFO: get information on the FIFO state
FIFO_READ: read and update the consumer pointer
FIFO_FLUSH: insert a flush meta event and force a interrupt.
A new MKBP event is added to tell the host the FIFO needs processing.
BRANCH=smaug
TEST=Test on ryu
BUG=chrome-os-partner:39900
Change-Id: I11c0cf8cdc3087eb9e323f7d6780e6cf3a16257f
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/276264
Reviewed-by: Randall Spangler <rspangler@chromium.org>
MOTIONSENSE_CMD_DATA return the value of a sinlge sensor.
BRANCH=none
BUG=chrome-os-partner:39900
TEST=On Smaug, using the new cros-ec-sensors driver,
check sensors data using iio sysfs interface.
Change-Id: I618ff050e0c7b4247ac56cfb0ca25e351270e1d6
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/274824
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Add command that list supported features by the firmware.
Also let the firmware indicates if more features are expected in the RW
version.
This will help the cros_ec framework load the right driver(s) for
exposing information via sysfs.
BUG=chromium:428364
BRANCH=none
TEST=Test on samus on both ec and pd:
localhost ~ # ectool inventory
EC supported features:
1 : Flash support
2 : Direct Fan power management support
3 : Keyboard backlight support
4 : Lightbar support
6 : Motion Sensors support
7 : Keyboard support
9 : BIOS Port 80h access support
10 : Thermal management support
11 : Switch backlight on/off support
12 : Switch wifi on/off support
13 : Host event support
14 : GPIO support
15 : I2C master support
16 : Charger support
17 : Simple Battery support
18 : Smart Battery support
21 : Control downstream MCU support
localhost ~ # ectool --name cros_pd inventory
EC supported features:
1 : Flash support
14 : GPIO support
15 : I2C master support
22 : USB Cros Power Delievery support
Change-Id: Ib6eaac91fda86835e754c5316ecf81fbc27786e5
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/263463
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Sameer Nanda <snanda@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>
Export what the PD protocol stack thinks about the port connection
state. This simplifies getting a meaningful data role/power role from the
host (eg we are not really a UFP if we are simply dual-role toggling but
not connected).
Do not increment the command version as this is mostly
backward-compatible and currently no client actually uses that field.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=none
TEST=ectool --name=cros_pd usbpd 0
plug and unplug various accessories on the port and check the result.
Change-Id: Ief3e0d47b6a288bcfc5b8fbb8156f29fd09dd336
Reviewed-on: https://chromium-review.googlesource.com/266120
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Rather than hardcode a specific mips toolchain, do a build-time test to
see if the target is x86 based.
BUG=chromium:443783
TEST=link still includes comm-lpc
TEST=arm64 omits comm-lpc
BRANCH=none
Change-Id: I0253df6cbe89bee231ec643dd6bb3498eb040708
Reviewed-on: https://chromium-review.googlesource.com/265793
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Commit-Queue: Mike Frysinger <vapier@chromium.org>
Tested-by: Mike Frysinger <vapier@chromium.org>
The 'lightbar params' v1 command has a parameter list that exceeds 120 bytes,
which will not work over i2c. Therefore, I created a params v2 command which
breaks up the existing parameters into logical groups which are less than 120
bytes.
TEST=Tested new lightbar params2 command and ran get/sets on all groups for
samus. Repeated test on ryu as well.
BUG=chromium:467716
BRANCH=none
Change-Id: If0fa92e9a2f373b20257f8ce7eb66b7836d9ac60
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/263106
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Add a new supplier type for VBUS chargers (USB chargers which supply VBUS
but are not identified as another charger type).
BUG=chrome-os-partner:37168
TEST=Manual on Samus with subsequent kernel commit. Modify code to
reject all non-VBUS suppliers, charge with SDP port, and verify charge
icon appears in OS.
BRANCH=Samus
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I5fbdb1cb57bd0224b01aaf5a763f93b678b6d204
Reviewed-on: https://chromium-review.googlesource.com/254346
Reviewed-by: Alec Berg <alecaberg@chromium.org>
When we find that charging is in a wedged state, we may wish to write a
PD log entry, but the PD MCU cannot detect such a state on its own.
Therefore, add a new command to ask the PD MCU to write a log of a given
type, and add a new board-specific custom log event.
BUG=chrome-os-partner:36668
TEST=Manual on samus:
./ectool --dev=1 pdwritelog charge 0
./ectool --dev=1 pdwritelog charge 1
./ectool --dev=1 pdwritelog 1 0
./ectool --dev=1 pdwritelog 2 0
./ectool --dev=1 pdlog
Verify log output matches expectation:
2015-02-12 11:12:49.290 P0 SRC
2015-02-12 11:12:49.296 P1 SNK Charger PD 20286mV max 20000mV / 3000mA
2015-02-12 11:12:49.303 P0 New connection
2015-02-12 11:12:49.310 P0 Board-custom event
--- END OF LOG --
Also, verify kernel logging of wedged event:
[ 181.378420] PDLOG 2015/02/12 19:13:44.019 P0 Event 02 (0000) []
Also, trigger wedged state on Samus and verify log entry is written.
BRANCH=Samus
Change-Id: I55c7c839cf8300fcd3931dccdaaf16c1065e31a8
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/248981
Reviewed-by: Alec Berg <alecaberg@chromium.org>
mcdp_info is a logging payload, so related structures need to be moved
to the public include file.
BUG=chrome-os-partner:35935
TEST=make buildall -j
BRANCH=Samus
Change-Id: Idb939db884821fa85faafbfe643e713f5bcdbc59
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/244780
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Current simplified implementation allows single mode entry. Specification
allows multiple mode entry and its advantageous for things like flashing RW
while staying in DisplayPort mode on video dongles.
CL adds capability on DFP to track as many alternate modes as supported by the
DFP. Initial mode entered is still the default supported mode ( 1st entry, 1st
opos). Policy manager can then use host command, EC_CMD_USB_PD_SET_AMODE, to
enter additional supported modes.
On the UFP (hoho, dingdong) a small modification to track multiple svid mode
entries was made.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:33946
TEST=manual, On hoho
1. Still successfully enter default mode DP
2. Using ectool's pdsetmode can successfully enter/exit multiple modes.
For example,
# port:1 svid:18d1 opos:1 cmd:1==enter
ectool --name cros_pd pdsetmode 1 0x18d1 1 1
Checking with pdgetmode shows both modes entered.
3. Works across hard & soft resets
4. Can flash via ectool --name cros_pd flashpd 4 <port> <RW image>
5. Still drives external display. With bootarg drm.debug=0x6 and following
command: 'tail -f /var/log/messages | grep "Received HPD" &'
I see HPD assert & deassert when switching between GFU and DP mode.
If both modes entered screen stays lit (after reboot) during write.
Change-Id: I7a21ebea377402eb1b0a0cf1d29df59694e301b1
Reviewed-on: https://chromium-review.googlesource.com/241790
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Renaming this to 'opos' for consistency with USP-PD specifications
'object position' in VDM header.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:35495
TEST=manual, On hoho
1. Still successfully enter default mode DP
2. Using ectool's pdgetmode pdsetmode can successfully enter/exit
other modes
3. Works across hard & soft resets
Change-Id: I08cb8e003ced4de481adcb503bcba3437ebb1ab7
Reviewed-on: https://chromium-review.googlesource.com/241718
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Use one line per entry and display the real time for the events.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:33248
TEST=ectool --name=cros_pd pdlog
and see a nice log like:
2015-01-20 15:14:02.974 P0 Disconnected
2015-01-20 15:14:05.676 P0 SNK Charger Type-C 4958mV max 5000mV / 500mA
2015-01-20 15:14:11.810 P1 SRC
2015-01-20 15:14:14.460 P0 Disconnected
2015-01-20 15:14:17.277 P0 SNK Charger Type-C 5185mV max 5000mV / 3000mA
2015-01-20 15:14:17.287 P0 SNK Charger PD 5015mV max 20000mV / 3000mA
2015-01-20 15:14:17.383 P0 SNK Charger PD 20198mV max 20000mV / 3000mA
--- END OF LOG ---
Change-Id: Ibf189cdb9e5d9ba74cb1fb241a2945439dfb50f7
Reviewed-on: https://chromium-review.googlesource.com/242082
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
For dual-role USB ports (host/device), let the AP know whether we are
currently DFP (USB host) or UFP (USB device) by exporting the data role
in addition to the power role in the EC_CMD_USB_PD_CONTROL response.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=none
TEST=ectool --name=cros_pd usbpd 0
plug various accessories on the port and see properly "SRC DFP" for the
USB key, "SNK DFP" for the power supply and "SNK UFP" for a regular
C-to-A charging cable.
Change-Id: I292da15fa8cf3566109dd05995ef1d00bed6f92d
Reviewed-on: https://chromium-review.googlesource.com/242012
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Flashing PD devices works through ectool but only when device has
already entered GFU alternate mode. This CL adds ability to force
that entry for devices with default policy engine does not already do
that.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:33947
TEST=manual,
1. On hoho flash RW successfully
ectool --name cros_pd flashpd 4 1 hoho.ec.RW.bin
Change-Id: Idd320cf91644f0c1bff87767ab20049d86aa86c6
Reviewed-on: https://chromium-review.googlesource.com/236959
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Add the charging events to the PD event log FIFO
and add an ectool to retrieve/decode them.
BUG=chrome-os-partner:33248
TEST=Manual on Samus. Run `ectool --name cros_pd pdlog`, verify that
all log entries are dumped and the content matches expectation.
BRANCH=Samus
Change-Id: I65dd5696cc0487856ab42aff24134bcdfa1a8219
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/238093
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
MIPS host CPU does not access IO registers using a separate address space.
Remove for support of LPC for this host architecture.
Confine x86 function to Intel Architecture only.
BRANCH=none
TEST=Compile: Test on ARM, MIPS and X86: using emerge... ec-utils.
BUG=chromium:443783
Change-Id: I9d4276ec3588037adfcff96e596bbe8be74f22fd
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/236687
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If the EC controls the lightbar and sets the sequence when
it notices the chipset transitioning between states, we can't
make exceptions for cases where we don't want to activate the
lightbar, such as in dark resume. Instead, let's make it a
separate command that we expect from the kernel.
BUG=chrome-os-partner:32181
TEST=build on samus, verify lightbar does correct thing with
manual control set
BRANCH=ToT
Signed-off-by: Eric Caruso <ejcaruso@chromium.org>
Change-Id: I5dc619cbbf2498e2ef03ce622831b33e14c7c495
Reviewed-on: https://chromium-review.googlesource.com/239215
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
With CL:
5ef45ad pd: Add timeout for HC flash commands.
I thought I'd licked the timeout related issues with flashing dingdong
& hoho.
With further testing however I found I was occassionally hitting the
failure where I couldn't return from 'flash erase' on PD peripheral
prior to the 1 second limit for host command timeout.
That could be remedied by retrying the erase on the host side which
then succeeds quickly. That solution seems non-optimal however.
Additionally, even when erase does succeed in <1sec we have the shared
i2c bus pending. That too is non-optimal.
For those reasons I've decide to return immediately from flash erase
command and instead put the burden of waiting the necessary time on
the host which at least does have some wider perspective on what the
system is attached to and doing.
CL also adds following related changes:
1. corresponding ectool edit to delay 3sec after RW erase.
2. fixup to error returns from hc_remote_flash for timeouts.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:33947
TEST=flashing dingdong/hoho via ectool works reliably.
Change-Id: I8fbfb592f760273b26bcb16b67210d569454eee2
Reviewed-on: https://chromium-review.googlesource.com/239253
Trybot-Ready: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Currently, 'ectool usbpd' shows PD task state in numerical format. Every
time we add/remove a state, the number changes, and this makes the
command difficult to use. Modify the command to print the name of the PD
task state.
BRANCH=Samus,Ryu
BUG=chrome-os-partner:34296
TEST=Run 'ectool usbpd 0' with different combination of new/old PD
firmware and new/old ectool.
Change-Id: Ic0daa03e9f7565c1322166713c2cce3b7cb93a30
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/237623
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
Tested-by: Alec Berg <alecaberg@chromium.org>
- Correctly identify certain source ports (ex. c-plug to empty a-receptacle)
- Correct ectool power unit print (mV * mA != mW).
BUG=chrome-os-partner:33248
TEST=Manual on Samus. Connect c-plug to empty a-receptacle, run
"ectool --name usbpdpower", verify that port power role is identified
as source. Also, verify that 5000 mV @ 500mA port correctly prints
2500mW total power.
BRANCH=Samus
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Icf0850afc570a1056578df9f1a647079a00229b3
Reviewed-on: https://chromium-review.googlesource.com/238235
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
This addition allows the AP to query whether the PD device is currently
running from RO or RW FW.
BUG=chrome-os-partner:34599
TEST=Manual on Samus. Run 'ectool --name cros_pd infopddev 0' and verify
that correct RO/RW status of Zinger is printed. Verify that the output
matches the index printed by "pd 1 hash" on samus_pd console.
BRANCH=Samus
Change-Id: I4266cae931f5c7855ca0531717c4a18b138b2d62
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/236771
Reviewed-by: Alec Berg <alecaberg@chromium.org>
CL adds sleep to USB-PD flashing loop in ectool. Real problem is
likely busy waiting within the host command master in the EC which
causes it to starve other lower priority tasks there.
Additionally,
1. Sleep 100ms after reboot to attempt to avoid colliding with other
USB-PD traffic communication that happens when accessories boot.
2. Sleep 100ms after last flash write prior to reboot as there's some
race between finalizing flash write.
Workaround should be removed once we've identified root cause.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:33905
TEST=manual,
1. attach zinger to port 1 of samus
2. create ec.RW.bin for zinger and copy to samus
3. update RW fw on zinger via:
ectool --name cros_pd flash_pd 1 1 ec.RW.bin
Result:
- No longer see watchdog fire on samus EC
- See successful update of RW fw on zinger. Takes ~15secs.
Change-Id: If617cbf1c25ee92de94bdb312ec822af2a688640
Reviewed-on: https://chromium-review.googlesource.com/230845
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Add host command to set charge port override.
BUG=chrome-os-partner:32003
BRANCH=Samus
TEST=Manual on Samus. Insert PD charger in port1 and BC1.2 charger in
port0.
./ectool --name=cros_pd chargeoverride 0 --> Charges from port 0
./ectool --name=cros_pd chargeoverride off --> Charges from port 1
./ectool --name=cros_pd chargeoverride dontcharge --> No charge port
./ectool --name=cros_pd chargeoverride 1 --> Charges from port 1
./ectool --name=cros_pd chargeoverride 2 --> Correctly returns error
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ib35f797a4a24e96fd2e3c008ace3fd6291b89d25
Reviewed-on: https://chromium-review.googlesource.com/230910
Reviewed-by: Alec Berg <alecaberg@chromium.org>
MOTIONSENSE_CMD_DUMP is deprecated, replaced with MOTIONSENSE_CMD_GET_DATA
Also use vector_3_t instead of x,y,z
ectool motionsense commands only work with newer firmware, to
handle a dynamic number of sensors.
- The host sends the number of sensor it has allocated space for.
- If 0, the EC just sends the number of sensors available
- Otherwise returns sensor information up to the limit imposed by the host.
Remove MOTIONSENSE_GET_STATUS: not needed. It is only useful for LPC,
to guarantee atomicity of the data.
Remove MOTIONSENSE_GET_DATA: not needed since we increase the version
number of MOTIONSENSE command.
BUG=chrome-os-partner:31071,chromium:430792
BRANCH=ToT
TEST=Compile. On a firmware that support the new command:
/usr/sbin/ectool --name=cros_sh motionsense
Motion sensing active
Sensor 0: 92 15 1030
Sensor 1: -94 -63 718
/usr/sbin/ectool --name=cros_sh motionsense active
0
On a machine with older firmware (samus), check these
functions are not working anymore.
Change-Id: I64b62afff96670fb93457760d43d4e64e26e029f
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226880
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Factory test process need lid switch no function or keep lid opened
BUG=chrome-os-partner:33304
BRANCH=paine,yuna
TEST=Run command "ectool forcelidopen 1" and "reboot". Then lid close
quickly, the system boot as lid opened.
Deault value or run command "ectool forcelidopen 0" make the device normal.
Change-Id: I94527b7ef7f9efe779c6b86f3eab651f99af6000
Signed-off-by: Henry Hsu <Henry.Hsu@quantatw.com>
Reviewed-on: https://chromium-review.googlesource.com/230180
Reviewed-by: Mohammed Habibulla <moch@chromium.org>
Reviewed-by: Bowgo Tsai <bowgotsai@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
During the discovery identity phase of type-C devices that support it
there is some info that could be useful to kernel & userland for
policy decisions. CL starts by passing up the vid, pid & product type
(ptype) of the discover identity VDO.
BRANCH=samus
BUG=chrome-os-partner:32650
TEST=manual,
From host, w/ hoho in port 1
ectool --name=cros_pd infopddev 1
Port:1 Device:4 Hash: 0x57b1e4e0 0x7204075f 0x65c0fa72 0xdcca15ed 0xf3231237
Port:1 ptype:6 vid:0x18d1 pid:0x5010
Change-Id: Ie05d191149ada0ec860b713d780b0345eab3a647
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226899
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Add flag for whether or not device plugged into a given port is a
dual-role PD device. For now, the dual-role flag is always 0, but
need to add the flag to the host command now for compatibility
in the future.
BUG=chrome-os-partner:32650
BRANCH=samus
TEST=load onto samus, run ectool --name=cros_pd usbpdpower and
verify that for anything plugged in it says "dedicated charger"
Change-Id: I2d3c8c149802492f27a87a47aaa68fbf505ee7a9
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/226820
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Get type-c port power info including power role, charger type,
and charging info. Also added host command to get number of type-c
ports.
Also adds new charging suppliers for pericom identified chargers
including DCP, CDP, SDP, proprietary, and other chargers. Priority
of these for charging is set in samus board file.
BUG=chrome-os-partner:32650
BRANCH=samus
TEST=run 'ectool --name=cros_pd usbpdpower' and verify correct
status with minimuffin, zinger, and type-C to type-A adapter.
Change-Id: I1dabbe7de4185a23df5684a5ea9a2d944f1f6ff5
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223523
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This implements a new API for EC modules to define MKBP event sources
and send MKBP event to the AP. Also, a new host command
EC_CMD_GET_NEXT_EVENT is added for the AP to query the pending MKBP
events. Each event type may have custom event data sent along with the
event.
BRANCH=None
BUG=chrome-os-partner:33194
TEST=Enable MKBP event on Ryu. Set a host event from EC console, run
'ectool nextevent', and see MKBP event 0x01 (HOST_EVENT) and the set
host event.
Signed-off-by: Vic Yang <victoryang@chromium.org>
Change-Id: I28a1b7e826bcc102bbe39016c9bb3e37d125664c
Reviewed-on: https://chromium-review.googlesource.com/224905
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The original algorithm is given in the TMP006 User's Guide
(SBOU107.pdf). The algorithm we previously implemented is that,
plus some additional and completely undocumented massaging of the
Tdie and Vobj registers. The original meaning of that hack is now
lost in the mists of time, thanks to our email retention policy.
This CL introduces a new algorithm variant, but at least this
time the details are in the bug report. It's essentially the same
as the User's Guide algorithm, except that we apply one-stage FIR
filters to the Tdie input and the Tobj output.
There are five new parameters: d0, d1, ds, e0, e1. Refer to
tmp006_read_object_temp_k() in ec/driver/temp_sensor/tmp006.c to
see how these new parameters are applied.
CAUTION: The tmp006 sensor algorithm is mostly math and magic
numbers. The spreadsheet attached to the bug report has six
sheets with wildly varying values for those parameters. Since the
correct parameter values haven't yet been determined for Samus,
all I can be sure of with this CL is that it seems to work and
isn't any worse than the old one.
Oh, and note that the EC's 't6cal' console command has been
disabled until/unless we add support for floating point IO. Use
ectool from the host to get and set the params instead.
BUG=chrome-os-partner:32260
BRANCH=ToT,Samus
TEST=manual
After booting, look at the sensor values using ectool:
localhost ~ # ectool temps all
0: 312
1: 314
2: 313
Sensor 3 not calibrated
4: 311
Sensor 5 not calibrated
6: 305
Sensor 7 not calibrated
8: 306
Sensor 9 not calibrated
10: 307
Sensor 11 not calibrated
12: 312
Sensor 13 not calibrated
localhost ~ #
localhost ~ # ectool tempsinfo all
0: 0 PECI
1: 1 ECInternal
2: 1 I2C-Charger-Die
3: 2 I2C-Charger-Object
4: 1 I2C-CPU-Die
5: 2 I2C-CPU-Object
6: 1 I2C-Left C-Die
7: 2 I2C-Left C-Object
8: 1 I2C-Right C-Die
9: 2 I2C-Right C-Object
10: 1 I2C-Right D-Die
11: 2 I2C-Right D-Object
12: 1 I2C-Left D-Die
13: 2 I2C-Left D-Object
EC result 2 (ERROR)
...
localhost ~ #
There are six tmp006 object temps that need calibrating. The
index used for the calibration is for the tmp006 objects, not the
3,5,7,.. numbers reported for all temp sensors. See the current
values with tmp006cal:
localhost ~ # /tmp/ectool tmp006cal 5
algorithm: 1
params:
s0 0.000000e+00
a1 1.750000e-03
a2 -1.678000e-05
b0 -2.940000e-05
b1 -5.700000e-07
b2 4.630000e-09
c2 1.340000e+01
d0 2.000000e-01
d1 8.000000e-01
ds 1.480000e-04
e0 1.000000e-01
e1 9.000000e-01
localhost ~ #
If the s0 param is zero, this sensor is uncalibrated. The params
are entered in the order in which they're displayed You can
change any or all of the parameters. Skip the ones you don't want
to update by specifying '-' for its position. (Note: throw in an
extra '--' first so that ectool doesn't think that negative
numbers are command options).
For example, to change s0 and b0:
localhost ~ # ectool -- tmp006cal 5 1.0 - - -3.0
localhost ~ #
localhost ~ # ectool tmp006cal 5
algorithm: 1
params:
s0 1.000000e+00
a1 1.750000e-03
a2 -1.678000e-05
b0 -3.000000e+00
b1 -5.700000e-07
b2 4.630000e-09
c2 1.340000e+01
d0 2.000000e-01
d1 8.000000e-01
ds 1.480000e-04
e0 1.000000e-01
e1 9.000000e-01
localhost ~ #
Now sensor 13 (tmp006 object index 5) is calibrated:
localhost ~ # ectool temps all
0: 310
1: 315
2: 313
Sensor 3 not calibrated
4: 310
Sensor 5 not calibrated
6: 305
Sensor 7 not calibrated
8: 307
Sensor 9 not calibrated
10: 307
Sensor 11 not calibrated
12: 312
13: 313
Change-Id: I61b5da486f5e053a028c533ca9e00b9a82a91615
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224409
Reviewed-by: Randall Spangler <rspangler@chromium.org>
With only four LED segments, it's confusing to indicate a power
percentage by dimming the top segment unless you can see the
indicator smoothly ramping up from all-off. This does that.
Kind of pretty, if I say so myself.
BUG=chrome-os-partner:29041
BRANCH=ToT, Samus
TEST=make buildall
Run "ectool lightbar demo on", then press the T key to invoke the
pattern and the arrow keys to fake the charge state.
Change-Id: Ib6a56aea56078b8c1fc9edddda469d7f41735ff7
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223300
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reboot the PD device after a successful flash so that it will boot into
the new RW. This syncs the ectool PD update to the implementation in
flash_pd.py.
BUG=chrome-os-partner:31361
TEST="./ectool --name=cros_pd flashpd 0 1 ec.RW.bin", verify flashing
succeeds and PD is rebooted after flash.
BRANCH=samus
Change-Id: I14e7dffe59fcc7ca678c76890dbc825df5b19862
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223062
Reviewed-by: Alec Berg <alecaberg@chromium.org>
This prepends EC_ a macro exposed in ec_commands.h, moves a
macro into lbcc that is not used elsewhere, and changes lb_program
structs to lightbar_program.
BUG=None
BRANCH=ToT
TEST=make buildall -j
Change-Id: I481562da72d91f846c64cf9af40338027641462c
Signed-off-by: Eric Caruso <ejcaruso@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222406
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The PD protocol no longer uses a SHA1 RW hash. Instead, it uses the
first 20 bytes of the SHA-256 hash. Update constants and comments
accordingly.
BUG=chrome-os-partner:31361
TEST='make buildall -j'
BRANCH=samus
Change-Id: Ice74b841dbd1d81205c1ef0079a5e18fca2153b6
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222446
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
ectool autofanctrl 1 - set auto fan control for fan 1
BUG=chrome-os-partner:23803
TEST=Tested the above EC command on Auron
BRANCH=none
Change-Id: Idcd3690ad98d7965420f26f7cc445207fe73704d
Signed-off-by: Mohammed Habibulla <moch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221816
Reviewed-by: Randall Spangler <rspangler@chromium.org>
