There are none cros_ec devices running EC codebase connected to
chromebook, which can be accessed by ectool with
`cros_ec --name=SOME_DEV ...`.
In the case when SOME_DEV is not found, do not fallback to other
communication methods such as LPC or I2C, since ectool will instead get
the reply of real cros_ec device.
BRANCH=none
BUG=b:64468324
TEST=on poppy, `ectool --name=cros_tp version` should show:
`Unable to establish host communication
Couldn't find EC`
Change-Id: I2ac232122e0f928703f7607da365d5c1dc6f7194
Signed-off-by: Wei-Ning Huang <wnhuang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/604977
Commit-Ready: Wei-Ning Huang <wnhuang@chromium.org>
Tested-by: Wei-Ning Huang <wnhuang@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
this adds CLI support for the new PD_CHIP_ON subcommand of
ec_pd_control_cmd.
TEST=rebuilt ectool to see if "ectool pdcontrol on" does something useful.
copied new build to electro:
ec> i2cxfer rlen 0 0x50 1 0x10
Unknown error
Usage: i2cxfer r/r16/rlen/w/w16 port addr offset [value | len]
ec>
ap$ /tmp/ectool pdcontrol on 0
ec> i2cxfer rlen 0 0x50 1 0x10
Data: aa2934ad000000000000010000050500
ec>
so, "pdcontrol on" had the desired effect of bringing the chip
out of sleep mode.
BRANCH=none
BUG=b:35586895
Change-Id: I5275254fe797dda921a352b72f1683e1967efe58
Signed-off-by: Caveh Jalali <caveh@google.com>
Reviewed-on: https://chromium-review.googlesource.com/599361
Reviewed-by: Shawn N <shawnn@chromium.org>
Allow host to request a higher-power S3 variant, "wakeable S3", in which
more wakeup sources will be enabled by the EC. The actual implementation
and list of wake sources is left up to the chipset power driver and/or
board code.
BUG=b:63037490
BRANCH=gru
TEST=With subsequent commit, compile on scarlet w/ power sequencing
version = 2.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I469f0cd969052f173cb176196bb6d05f6f76fdb5
Reviewed-on: https://chromium-review.googlesource.com/572210
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Philip Chen <philipchen@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>
Add touchpad related host commands:
1) EC_CMD_TP_SELF_TEST: run open short test.
2) EC_CMD_TP_FRAME_INFO: get number of frame and frame size.
3) EC_CMD_TP_FRAME_SNAPSHOT: make a snapshot of the frame.
4) EC_CMD_TP_FRAME_GET: get frame data.
BRANCH=none
BUG=b:62077098
TEST=`make BOARD=rose -j`
`ectool --name=cros_tp tpselftest` and
`ectool --name=cros_tp tpframeget` works
Change-Id: I43db82278e556b1e6f6301fe88233fe7c4a18a14
Signed-off-by: Wei-Ning Huang <wnhuang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/515282
Commit-Ready: Wei-Ning Huang <wnhuang@chromium.org>
Tested-by: Wei-Ning Huang <wnhuang@chromium.org>
Reviewed-by: Rong Chang <rongchang@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>
Add new host command EC_CMD_RWSIG_ACTION for controlling rwsig task.
This allow us to make firmware stay at RO without toggling reset pin.
flashrom can use this host command and removed the need to use any
out-of-band pin to toggle the reset pin (and make RWSIG stay in RO).
BRANCH=none
BUG=b:37584134
TEST=on eve, `ectool --name=cros_tp rwsigaction abort` should prevent EC
from jumpping to RW after RWSIG check.
Change-Id: Ia435e4e3ea8ed612a1250d3bf755ca50e5db9d37
Signed-off-by: Wei-Ning Huang <wnhuang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/497787
Commit-Ready: Wei-Ning Huang <wnhuang@chromium.org>
Tested-by: Wei-Ning Huang <wnhuang@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
1. Provide led_control API that can be used by different drivers to
control the state of LED (0=off, 1=on, 2=reset)
2. Add a new LED ID for recovery HW_REINIT indication.
BUG=b:37682514
BRANCH=None
TEST=make -j buildall
Change-Id: I27334bde2b879046746456a610208f3fc2dd68b4
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/487840
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add a new host command EC_CMD_RWSIG_CHECK_STATUS for getting rwsig
status and rw firmware hash. This command is used to check the RW
signature of newly updated RW image.
A new subcommand is also added to ectool.
BRANCH=none
BUG=b:37584134
TEST=on rose board `ectool rwsigstatus` works
Change-Id: I33d8709f5248d3a4b8bedb36ded84a93dc8c971f
Signed-off-by: Wei-Ning Huang <wnhuang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/485079
Commit-Ready: Wei-Ning Huang <wnhuang@chromium.org>
Tested-by: Wei-Ning Huang <wnhuang@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
When invoking ectool fan commands on older ECs not supporting
EC_CMD_GET_FEATURES, the tool is choking on the lack of the command at
the beginning of get_num_fans() and not going further.
The regression was introduced by
https://chromium-review.googlesource.com/c/359069/, let's go back to the old
behavior for machines without feature bits and skip the
EC_FEATURE_PWM_FAN check.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=b:35575890
TEST=on Buddy, run 'ectool pwmgetnumfans' and 'ectool pwmgetfanrpm all'
and get results.
Change-Id: Ie9255d4afc9fa95a55807c310e9593a28c2aadc1
Reviewed-on: https://chromium-review.googlesource.com/456598
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Some people love to address the EC device nodes by number with ectool,
add the special offset for the FP MCU (e.g. '--dev=8').
Addressing it by name already works (e.g. '--name=cros_fp').
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=b:35648259
TEST=on Eve, execute 'ectool --dev=8 version'
and see a similar result to 'ectool --name=cros_fp version'
e.g. "RO version: eve_fp_v1.1.6177-945b19f+ [...]"
Change-Id: Ic08e3b7a3ae31b7e1b73bccc8375badf3284b49c
Reviewed-on: https://chromium-review.googlesource.com/453179
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Add LED types for left and right so they can be addressed
properly with ectool.
BUG=b:36150361
BRANCH=none
TEST=manual testing of 'ectool led <left|right> <color>' behavior
Change-Id: Iea25cc69db2d35416e787dcb5a324d2e2cf5d3a6
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/453126
Reviewed-by: Scott Collyer <scollyer@chromium.org>
pdcontrol suspend command will be used to prevent tcpm from putting
the chip into sleep while firmware update is taking place. Currently
the command suspends or resumes port 0. This patch makes the command
apply to ports individually.
pd enable console command now takes a port number:
pd <port> enable/disable.
This patch also replaces CONFIG_USB_PD_COMM_ENABLED with _DISABLED.
When it's defined, PD communication is disabled at startup.
Plankton undefines CONFIG_USB_PD_COMM_ENABLED enable, intending to
disable PD communication at startup. Therefore, this patch defines
CONFIG_USB_PD_COMM_DISABLED in its board.h.
BUG=b:35586859
BRANCH=none
TEST=From AP console:
localhost # /tmp/ectool pdcontrol suspend 1
[600.188013 TCPC p1 suspended!]
> pd 1 state
Port C1 CC1, Dis - Role: SNK-UFP State: SUSPENDED, Flags: 0x0020
localhost # /tmp/ectool pdcontrol resume 1
[678.516613 TCPC p1 resumed!]
> pd 1 state
Port C1 CC1, Ena - Role: SNK-UFP State: DRP_AUTO_TOGGLE, Flags: 0x0020
From ec console:
> pd 1 disable
Port C1 disable
> pd 1 state
Port C1 CC1, Dis - Role: SNK-UFP State: DRP_AUTO_TOGGLE, Flags: 0x0020
> pd 1 enable
Port C1 enabled
> pd 1 state
Port C1 CC1, Ena - Role: SNK-UFP State: DRP_AUTO_TOGGLE, Flags: 0x0020
Change-Id: Ia0cc4904ac52adc4b89de20918968c8df78b9c80
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/447968
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
ROLLBACK region will be used to store rollback information, and
can be protected independently of RW (it can only be protected when
RO is protected, though).
This is only supported on stm32f0 currently.
BRANCH=none
BUG=chrome-os-partner:61671
TEST=on hammer (stm32f072)
flashinfo => RO+RW not protected
flashwp true; reboot => only RO protected
flashwp all; reboot => RO+RW+RB protected
flashwp noall; reboot => only RO protected
flashwp rw; reboot => only RO+RW protected
flashwp rb; reboot => RO+RW+RB protected
flashwp norb; reboot => RO+RW protected
flashwp all; reboot => RO+RW+RB protected
flashwp norw; reboot => RO+RB protected
TEST=on reef, rb/norb commands not available
Change-Id: I45ffc66d91cf3699ecff025e5114c59a73dc8274
Reviewed-on: https://chromium-review.googlesource.com/430519
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The idea of this flag is to be able to protect/unprotect only the
RW portion of the flash. In the (usual) case where ALL=RO+RW, with
no other region, this makes no difference compared to the existing
EC_FLASH_PROTECT_ALL_* flag, and this flag may not be supported.
This is necessary for futher work, where a ROLLBACK region is added,
so that RW/ROLLBACK can be protected/unprotected individually.
Only support for stm32f0 is added, as this is the target for hammer.
BRANCH=none
BUG=chrome-os-partner:61671
TEST=build and flash hammer (stm32f072)
flashinfo => RO+RW not protected
flashwp true; reboot => only RO protected
flashwp all; reboot => RO+RW protected
flashwp noall; reboot => only RO protected
flashwp rw/norw not available
TEST=enable CONFIG_FLASH_PROTECT_RW
build and flash hammer (stm32f072)
flashinfo => RO+RW not protected
flashwp true; reboot => only RO protected
flashwp all; reboot => RO+RW protected
flashwp noall; reboot => only RO protected
flashwp rw; reboot => RO+RW protected
flashwp norw; reboot => only RO protected
TEST=build and flash reef (npcx)
flashinfo => RO+RW not protected
flashwp true => RO protected
flashwp all; flashinfo => all_now displayed
reboot => RO protected
flashwp rw/norw not available
Change-Id: Ica6f499cf2e8a9345b08ef52c915655a983ffe3c
Reviewed-on: https://chromium-review.googlesource.com/442265
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Use the motion sensor to manage ALS as well.
The current interface (via memmap) is preserved, but
we can also access the sensor via cros ec sensor stack and
send the ALS information to ARC++.
BUG=chrome-os-partner:59423
BRANCH=reef
CQ-DEPEND=CL:424217
TEST=Check the sensor is working via ACPI sensor and
cros ec sensor. Check ARC++ sees the sensors.
Change-Id: Iaf608370454ad582691b72b471ea87b511863a78
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/424323
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
This change adds an option to pdchipinfo command to force ec to get
the version from the chip instead of the cache (if it's available).
This option will be used after firmware update, which makes the cache
value stale.
BUG=chrome-os-partner:62383
BRANCH=none
TEST=Run ectool as follows:
localhost ~ # /tmp/ectool pdchipinfo 0 on
vendor_id: 0xaaaa
product_id: 0x3429
device_id: 0xad
fw_version: 0x15
localhost ~ # /tmp/ectool pdchipinfo 1 on
EC result 2 (ERROR)
Change-Id: Icefe96d7fc1208b991a4caa13aaf4f04052edba7
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/441271
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The firmware version formats may vary chip to chip. fw_version field is
changed to a union of a 8 byte string and an 64-bit integer.
BUG=chrome-os-partner:62383
BRANCH=none
TEST=ectool pdchipinfo 0/1 on Electro
Change-Id: Id51e66c44338a09ed897ee61f54cd6a394400e63
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/441270
This patch adds a host command to get PD chip info.
For PS8751, tcpci_get_chip_info will fail if the chip is in
low power mode. It can be woken up by reading a random register
first then wait for 10ms.
This code doesn't have the wake-up read to avoid 10ms delay.
Instead, we call this function immediately after the chip is
initialized because it'll gurantee the chip is awake.
Once it's called, the chip info will be stored in cache, which
can be accessed by tcpc_get_chip_info without worrying about
chip states.
localhost ~ # ectool pdchipinfo 0
vendor_id: 0xaaaa
product_id: 0x3429
device_id: 0xad
fw_version: 0x15
localhost ~ # ectool pdchipinfo 1
vendor_id: 0x1da0
product_id: 0x8751
device_id: 0x1
fw_version: 0x37
BUG=chrome-os-partner:62383
BRANCH=none
TEST=ectool pdchipinfo 0/1. make buildall
Change-Id: I3f1667d00ce1826936d90882ada1df6ed6b0ea37
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/433166
This commit adds a "spoof" mode feature to the motionsense stack. It
allows the user to arbitrarily set the outputs of the sensor in order to
"spoof" the readings of the sensor. This can be useful in emulating
tablet mode or device rotations. A command is available from the EC
console named `accelspoof` and there is a corresponding motionsense
command in ectool called `spoof`.
The usage is as follows:
- EC console
> accelspoof [id] [on/off] [X Y Z]
- ectool
# ectool motionsense spoof -- [id] [0/1] [X Y Z]
If on or off(or 0/1) is not specified, the current spoof mode status of
the sensor is returned. If on is specified, but no components are
provided, the sensor will lock the current values and provide those as
the spoofed values. If the components are provided, those will be used
as the spoofed values.
BUG=chromium:675263
BRANCH=cyan,glados,gru,oak
TEST=Flash a DUT with accels. From AP console, run `ectool motionsense
lid_angle` in a loop, use 'accelspoof' EC console command to set spoofed
values. Verify that the angle is fixed regardless of the actual angle
of the DUT.
TEST=Flash a DUT with accels. From AP console, use `ectool motionsense
spoof` to spoof values and verify that `ectool motionsense` reflects the
spoofed values. Test with both provided component values and no
component values.
Change-Id: Ie30688d22f38054e7243b1af493a3092b2cdfb72
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/421280
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
BRANCH=none
util/ectool.c:1158 merror: taking address of packed member 'size' of class
or structure 'ec_params_usb_pd_fw_update' may result in an unaligned
pointer value [-Werror,-Waddress-of-packed-member]
For this case, the pointer is always aligned but clang complains.
Workaround using double pointer casts to char and uint.
uint32_t *data = &(p->size) + 1;
BUG=chromium:665240
TEST=Builds now
Change-Id: Ibccf0f6e409b9724fc9e5acf28dde570e9d341e3
Reviewed-on: https://chromium-review.googlesource.com/411384
Commit-Ready: Manoj Gupta <manojgupta@chromium.org>
Tested-by: Manoj Gupta <manojgupta@chromium.org>
Reviewed-by: Yunlian Jiang <yunlian@chromium.org>
Match ec_commands.h, adding new type and sensors.
BUG=none
BRANCH=reef
TEST=Check on Reef that barometer sensor info is displayed properly.
Change-Id: I257f5161e5f57be562a2b3a29442b49f47f3fc89
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/394749
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Due to an error in ms_command_sizes, fifo_info command
would fail when lost vectors are present:
packet too long (16 bytes, expected 10)
Reorder ms_command_sizes commands properly.
Get the number of sensors present before printing the number of lost
vectors per sensor.
BUG=none
BRANCH=none
TEST=On cave (with broken MKBP support), check fifo_info
is returning the lost vectors count.
Change-Id: Ic745eb762563705372d8a670ce34eab15e188bf9
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/391887
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Previously, there was no way to identify which flash chip was used by
the EC, for ECs using an external SPI flash. Now, 'ectool flashinfo'
will print more information about the SPI flash chip in these cases.
BUG=chrome-os-partner:56765
BRANCH=any EC with MEC1322 or NPCX still going through factory
TEST=define CONFIG_HOSTCMD_FLASH_SPI_INFO, then
'ectool flashspiinfo' on samus indicates no SPI flash info,
and prints additional info on chell and kevin. Without
the config defined, all platforms report no spi flash info.
CQ-DEPEND=CL:386368
Change-Id: I3c162f7ad12ed4b30ab951c03f24476683382114
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/385702
Reviewed-by: Shawn N <shawnn@chromium.org>
To be able to parse binary panicinfo from feedback reports, we need
a host tool:
- Move panicinfo generic parsing functions to a separate C file
- Create a new host utility to parse panicinfo
BRANCH=none
BUG=chromium:643062
TEST=base64 -d | ec_parse_panicinfo
Change-Id: Idd8560a2894f270d0ab3a9f654c333135759e57f
Reviewed-on: https://chromium-review.googlesource.com/379639
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Record what current limit we set when we act as a source
and when we are changing it.
The change should be backward-compatible as older EC will return 0 in
`current_max` when their role is PD_ROLE_SOURCE while newer firmware
will set the actual limit.
BRANCH=none
BUG=chrome-os-partner:56110
TEST=manual: on Kevin, plug and unplug various devices on the 2
ports, and dump the values with 'ectool usbpdpower'.
Change-Id: I8e78663f3196b1b81c2235ed8642da0638bed649
Reviewed-on: https://chromium-review.googlesource.com/375918
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Allow the host to self-report its sleep state through
EC_CMD_HOST_SLEEP_EVENT, which will typically be sent with SUSPEND
param when the host begins its sleep process. While the host has
self-reported that it is in SUSPEND, don't assert the interrupt
line, except for designated wake events.
BUG=chrome-os-partner:56156
BRANCH=None
TEST=On kevin, run 'ectool hostsleepstate suspend', verify that
interrupt assertion is skipped for battery host event. Run 'ectool
hostsleepstate resume' and verify interrupt is again asserted by the
battery host event.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I74288465587ccf7185cec717f7c1810602361b8c
Reviewed-on: https://chromium-review.googlesource.com/368391
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
If an HPD IRQ event is seen, make note of it and keep the status set
until informing the host.
BUG=chrome-os-partner:55925
BRANCH=None
TEST=Manual on kevin, trigger HPD event, verify that event bit is set in
reply to first host command and not subsequent host commands.
Change-Id: I0900a683dcb344d5d4d03a1fa6e3d8de913597b2
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/366990
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Chris Zhong <zyw@rock-chips.com>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
If the EC has CONFIG_HOSTCMD_RTC set to 'y', then export this via the
features host command. The kernel can then use this feature to expose
an RTC device under /dev/rtc*.
Signed-off-by: Stephen Barber <smbarber@chromium.org>
BRANCH=none
BUG=chrome-os-partner:54639
TEST=`ectool inventory` shows RTC on kevin
Change-Id: I644c8e61c4d9f691cc6ca94ef60bee4384c21660
Reviewed-on: https://chromium-review.googlesource.com/359414
Commit-Ready: Stephen Barber <smbarber@chromium.org>
Tested-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Currently, it is assumed the host will sooner or later retrieve the
events from the sensor ring: It is only used by Android and the sensor
HAL is enabling the ring buffer at boot.
But if nobody processes the ring, and the ring is almost full, the EC will
generate interrupt for every new events.
This can happen with ARC, where events generated for ChromeOS
will be in the ring but nobody will process them until Android is
started.
Add a command to allow sending ring MKBP events. It will be used when
the IIO ring buffer is enabled / disabled.
It also can be used for preventing raising interrupt when the device is
about to go to sleep.
BRANCH=ryu,cyan
BUG=b:25425420,b:27849483
TEST=Check with fiforead that no events are queued when IIO ring
buffer is disabled.
Check with ectool and androsensor that interrupt generation stops.
Change-Id: Ibc85eed2e0eae3a9ec07d191e692118bc2fd0dab
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/356689
For designs where the host SOC is responsible for setting the USB-C SS
mux, the EC must track the desired mux state and inform the host when
the desired state changes. Then, the host must ask the EC for the new
desired state and set the mux accordingly.
BUG=chrome-os-partner:52639
BRANCH=None
TEST=Manual on gru with subsequent commit.
Attach USB dongle in port 1 and DP dongle in port 0, then verify `ectool
usbpdmuxinfo` output:
Port 0: DP
Port 1: USB
Flip DP dongle and verify output changes:
Port 0: DP INV
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I6a99ce93a76c3197f9195cfaa25c5217d09aeb75
Reviewed-on: https://chromium-review.googlesource.com/355281
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Adding ability to get # seconds before rtc alarm
goes off.
BUG=chrome-os-partner:52218
BRANCH=None
TEST=ectool rtcgetalarm w/o setting returns
Alarm not set.
ectool rtcsetalarm 30; ectool rtcgetalarm
to make sure counting down to 0. After alarm
goes off, rtcgetalarm should return alarm not
set again.
rtcsetalarm 30; rtcgetalarm to check alarm is set.
rtcsetalarm 0; should disable alarm. Use
rtcgetalarm to ensure that alarm is disabled.
Change-Id: I176b12fe2dda08eedd23ea33dc64785f09f1d9ae
Signed-off-by: Shelley Chen <shchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/353331
Reviewed-by: Shawn N <shawnn@chromium.org>
This commands makes it possible to control the PD chip (or
the interaction between EC and PD), from the AP.
- PD_SUSPEND: Suspends the PD chip: EC needs to stop talking
to PD chip. Useful at beginning of PD FW update.
- PD_RESUME: Resumes the PD chip: EC can start talking to PD
chip again. Useful at end of PD FW update.
- PD_RESET: Resets the PD chip (called at the end of the update).
- PD_CONTROL_DISABLE: Prevents further calls to this command
(for security reason, we do not want the AP to be able to
call the other subcommands after the update has been performed).
BRANCH=none
BUG=chrome-os-partner:52433
TEST=ectool pdcontrol {suspend,resume,reset,disable}
Change-Id: I7a955dd27b65086c21d195a6504aa7392eb0406d
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/342584
Reviewed-by: Randall Spangler <rspangler@google.com>
Only way to set alarm previously was through
rtcalarm command on EC console. Implemented
interface through ectool so that the AP can set
it as well.
BUG=chrome-os-partner:52218
BRANCH=None
TEST=from AP console, run ectool rtcalarm <sec>
Should see [event set 0x02000000] from EC
console in approximately <sec> seconds.
Change-Id: I3202b826cb994dbca456b8b9c22bbca4dbe2766a
Signed-off-by: Shelley Chen <shchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/347493
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This allows the AP to protect a I2C passthru bus. A board-specific
function then defines what I2C commands are allowed, so that we
can white/black list some addresses (e.g. I2C address allowing
PD chip FW updating).
BRANCH=none
BUG=chrome-os-partner:52431
TEST=Book elm-rev1
Change-Id: Ib106924418b16388ea8ea53c7b6bda6ef92e1d09
Signed-off-by: Nicolas Boichat <drinkcat@google.com>
Reviewed-on: https://chromium-review.googlesource.com/345761
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@google.com>
Add generic PWM host commands for setting + getting duty cycle. PWMs can
be controlled through index (board-specific meaning) or by type
(currently KB backlight and display backlight are supported, more can be
added as needed).
BUG=chrome-os-partner:52002
BRANCH=None
TEST=Manual on chell.
`ectool pwmsetduty kb 100` - Verify KB backlight goes to 100%
`ectool pwmgetduty kb` - Prints 100
`ectool pwmgetduty 0` - Prints 100
`ectool pwmsetduty 0 0` - Verify KB backlight goes to 0%
`ectool pwmgetduty kb` - Prints 0
`ectool pwmgetduty disp` - Error res 3 (unsupported PWM type)
`ectool pwmsetduty 1` - Error res 3 (non-existent PWM index)
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I607c92a291e6c2e3af8238eaf22ad2bb81ffc805
Reviewed-on: https://chromium-review.googlesource.com/344012
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
This is keyboard test mechanism request for "multiple key press test",
we can thru the testing to scan out kso ksi pins shortting or keyboard has
multiple key pressing, below was the testing steps:
1. Turn off internal keyboard scan function.
2. Set all scan & sense pins to input and internal push up.
3. Set start one pin to output low.
4. check other pins status if any sense low level.
5. repeat step 3~4 for all keyboard KSO/KSI pins.
6. Turn on internal keyboard scan function.
BUG=chrome-os-partner:49235
BRANCH=ToT
TEST=manual
Short any KSO or KSI pins and excute "ectool kbfactorytest", it shows failed.
if no pins short together, it shows passed.
Change-Id: Id2c4310d45e892aebc6d2c0795db22eba5a30641
Signed-off-by: Devin Lu <Devin.Lu@quantatw.com>
Reviewed-on: https://chromium-review.googlesource.com/332322
Reviewed-by: Shawn N <shawnn@chromium.org>
