In the gpio_info struct, we had a irq_handler pointer defined even
though a majority of the GPIOs did not have irq handlers associated. By
removing the irq_handler pointer out of the struct, we can save some
space with some targets saving more than others. (For example, ~260
bytes for samus_pd).
This change also brings about a new define:
GPIO_INT(name, port, pin, flags, signal)
And the existing GPIO macro has had the signal parameter removed since
they were just NULL.
GPIO(name, port, pin, flags)
In each of the gpio.inc files, all the GPIOs with irq handlers must be
defined at the top of the file. This is because their enum values from
gpio_signal are used as the index to the gpio_irq_handlers table.
BUG=chromium:471331
BRANCH=none
TEST=Flashed ec to samus and samus_pd, verified lightbar tap, lid, power
button, keyboard, charging, all still working.
TEST=Moved a GPIO_INT declaration after a GPIO declaration and watched the build
fail.
TEST=make -j BOARD=peppy tests
TEST=make -j BOARD=auron tests
TEST=make -j BOARD=link tests
Change-Id: Id6e261b0a3cd63223ca92f2e96a80c95e85cdefb
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/263973
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Commit-Queue: Aseda Aboagye <aaboagye@chromium.org>
Trybot-Ready: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
The mec1322 LPC / EMI comm driver is no longer functional due to recent
EC changes. Rather than re-implementing a working driver across user
space tools, the plan of action is to use the kernel device driver
(through comm-dev) for all access.
BUG=chrome-os-partner:38103
TEST=Manual on glower with pending kernel cros_ec_lpc changes. Verify
"ectool version" and "ectool gpioget" succeed.
BRANCH=None
Change-Id: I770cb06ca534a7c31794e6b37c226e952361ee32
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/265031
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This turns on hardware controlled update of bit 5 (AUXOBF) in Keyboard
Status Read Register. Previously, this bit was in user-defined mode and
not reliable.
BUG=None
TEST=Tested that keyboard becomes functional on Braswell Ref Design.
BRANCH=None
Change-Id: I192383ebebb25a027d58da9fc1ef7f3bb3e8da66
Signed-off-by: Shamile Khan <shamile.khan@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/263948
Reviewed-by: Shawn N <shawnn@chromium.org>
Commit-Queue: Kevin K Wong <kevin.k.wong@intel.com>
MEC1322 KSO00~03 pin has an alternate JTAG function. For board that needs JTAG
function, this #define allows hardware to use a different set of KSO pins.
For example - Uses KSO04~16 instead of KSO00~KSO12.
BUG=none
TEST=Verified keyboard is functional with all keys detected
BRANCH=none
Change-Id: I1e3c1c2b6a4420cb6296b6bc921affa8c0ed5800
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/264610
Reviewed-by: Shawn N <shawnn@chromium.org>
- Changed TX BIST mode so that it transmits for 50 msec instead
of transmitting forever.
- Added console command to initiate TX BIST mode.
- Fixed an issue with circular DMA mode which was causing watchdog.
- Modified RX BIST to account for shorter TX BIST duration.
BUG=chrome-os-partner:36335
TEST=Manual on Samus to Samus, manual on Zinger to Samus
BRANCH=Samus
Signed-off-by: Scott Collyer <scollyer@chromium.org>
Change-Id: I666347de47c81b5b7a1e82c2b99345ff3ebbb7d4
Reviewed-on: https://chromium-review.googlesource.com/256194
Tested-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Trybot-Ready: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
Modify usbpdpower HC return args by adding a new current limit
field, and adding a new charger type (UNKNOWN). Note this
doesn't change the size of the return struct.
BUG=chrome-os-partner:38548
BRANCH=samus
TEST=make -j buildall
Change-Id: I51bb062a7e4fcd9ae6aea15204adb83b19882ac9
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/264641
Reviewed-by: Sameer Nanda <snanda@chromium.org>
This replaces a special-purpose python script with futility, to
sign the firmware for those boards that require a signed RW image
instead of using software sync.
Currently, the only boards that do that use a signature scheme
that is somewhat opaque (refer to commit b5a439241f in the
vboot_reference repo for details). Futility calls that scheme
"--type usbpd1".
BUG=chromium:231574
BRANCH=ToT
CQ-DEPEND=CL:*212135
TEST=manual
To test, I obtained a reworked zinger that could be connected to
servo. I first flashed it with a dev-key-signed RO+RW image built
prior to this CL, then I applied this change, built a new image
(with a minor change to the startup message), and updated only
the RW half from Samus using
ectool --name=cros_pd flashpd 0 1 /mnt/stateful_partition/ec.RW.bin
Watching the zinger console when plugging and unplugging, I
confirmed that the RO firmware was still the original and the
verified-by-RO RW firmware was the new version.
Note: I also had to build a custom AP kernel without the cros_pd
driver, to prevent interference with the manual update.
Change-Id: I22d8e75c85dab7701af8fe98287f14ebe77dbbd4
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/264508
Reviewed-by: Mike Frysinger <vapier@chromium.org>
I2C ports initialized as per board design. Modules
assigned to its corresponding I2C port numbers
Altered the SPI flash size to match the Braswell Ref Design board
BUG=None
BRANCH=None
TEST=Tested all I2C modules on all ports using i2cscan and i2cxfer
console commands
Change-Id: I4158c1aeb29193b5bd07450ba28cdcdc2413926a
Signed-off-by: Divya Jyothi <divya.jyothi@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/264261
Reviewed-by: Shawn N <shawnn@chromium.org>
Create a USB PD device whitelist for allowing charging by default
from dual-role devices that don't set the externally powered bit.
BUG=chrome-os-partner:38785
BRANCH=samus
TEST=modify zinger and modify VID and PID to match white-listed
entry. also modify zinger to remove externally powered bit and
set dual-role power bits so that we treat as a dual-role device
by default. when you plug in this modified zinger into samus,
it still will not charge because the VID and PID are obtained
after deciding to treat it as dual-role, but when you issue
soft reset "pd 1 soft", it starts charging. the white-listed
device will always ask for a power swap if it is a sink, so
we will always get source cap after learning the VID/PID, which
should correctly trigger changing the device to be treated as
a dedicated charger.
Change-Id: Ibe7ec57f842a0b9bfb02447baf5b3327217a9516
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/264015
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Treat externally powered dualrole devices as dedicated chargers.
This allows us to default to consuming power from externally powered
dualrole devices and cancels a charger override when one is attached.
BUG=chrome-os-partner:38785
BRANCH=samus
TEST=tested with third-party dualrole device that can be externally
powered.
also tested with another samus that was hard-coded with externally
powered bit set, and deleted it's policy for power swapping. when
this externally-powered samus is plugged into a samus running this CL,
we always charge from the externally-powered samus.
Change-Id: I850eba668e86d311d9353aa3881fc3a518409630
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/263331
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
When shutting down the MAX77620 PMIC by asseting its SHDN pin, the
EN_PP3300 output of the PMIC (GPIO3) is not going off keeping the PP3300
rail up. Workaround that issue by removing the pull-up on EN_PP3300 when
we assert SHDN.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:38689
TEST=on a P5 board, type "apshutdown" and see the power state machine
going to S5, type "powerbtn" and see it going back to S0.
Change-Id: I0e5fba6da118d931b07fff58088604ee00a6bcdd
Reviewed-on: https://chromium-review.googlesource.com/263958
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>
Change sink capabilities to account for +/-5% voltage inaccuracy
for variable and battery PDOs.
BUG=none
BRANCH=samus
TEST=test with third party variable power supply and make sure it
see's our sink capabilities as 4.75V-21V.
Change-Id: Id793142c486dfc908c81c4894b2ec48f99c868f4
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/263295
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add a USB device driver for the Synopsys DWC USB device controller.
The common USB protocol stack code still need to be de-duplicated with
the STM32 implementation.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:33919
TEST=plug Cr50 to a Linux workstation and see USB descriptors using
"lsusb -v -d 18d1:5014"
Change-Id: I4a367241053de2c2d94aa06f82ea4bee51f9f89a
Reviewed-on: https://chromium-review.googlesource.com/231160
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Update EC board configuration for P5 boards :
- PMIC_THERM_L GPIO used for PMIC shutdown has moved.
- add 5V regulator control (used for VBUS only)
- the Type-C superspeed muxes control changed
- add a temporary pull-up on EN_PP3300
- add new FW_DEBUG_MODE GPIO
Try to be compatible with both P4 and P5 by detecting the board variant at
runtime.
At EC startup, USBC_SS1_USB_MODE_L/USBC_SS2_USB_MODE_L/USBC_SS_EN_L (aka
PD3/PD9/PE0 aka MUX_CONF0/1/2) now default to low level rather than high
(as the new default value on P5), but they are reset to the correct
value when initializing the PD task (high for P4, low for P5+).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:38330
TEST=Ran on P4, check board ID on P5 PCB.
Change-Id: Ie9010805a91362c2b4d5eddd825d452d6ccc5b28
Reviewed-on: https://chromium-review.googlesource.com/262310
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Setting up numbers for Battery info like input current limit,
Battery voltage, temperature limits as per the actual battery spec.
BUG=None
TEST=Tested on Braswell Ref Design
BRANCH=None
Change-Id: I66c3dfe6166d03d2cb79d80a887168f08753d22d
Signed-off-by: Divya Jyothi <divya.jyothi@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/260631
Reviewed-by: Randall Spangler <rspangler@chromium.org>
I2C Block reads were split into two i2c_xfer() calls. However, i2c_xfer() implementation for MEC
does not maintain state in between calls. This was causing block read failures because the
settings for the Control Register got corrupted. Fix this by calling i2c_xfer() only once. This
retrieves both string size and string. Only return the string back to the user.
BUG=None
TEST=Tested on Braswell Ref Design
BRANCH=None
Change-Id: Ife8fcb66425c6198d0dcf10f74e89c001ccac49a
Signed-off-by: Shamile Khan <shamile.khan@intel.com>
Signed-off-by: Divya Jyothi <divya.jyothi@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/260627
Reviewed-by: Randall Spangler <rspangler@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>
Clear curr.batt_is_charging when the battery is not present.
Add a new batt_was_removed flag to track when the battery has been
removed. This causes PWR_STATE_ERROR so the LED shows error state,
and triggers re-reading the static parameters from the battery when
it's reattached.
BUG=chrome-os-partner:38235
TEST=check the LED state on mighty
BRANCH=veyron
Change-Id: I400c22eda4bc0043adf7217166bd9f80c557d991
Signed-off-by: ZhengShunQian <zhengsq@rock-chips.com>
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/262007
Commit-Queue: Gediminas Ramanauskas <gedis@chromium.org>
Tested-by: Gediminas Ramanauskas <gedis@chromium.org>
(cherry picked from commit 6727e1dba2aafa81fa9572145413545106ae9626)
Reviewed-on: https://chromium-review.googlesource.com/262140
Not needed with kernel fix:
Commands are currenly limited to 252 bytes. Even if EC support protocol
v3, ectool would only limit the command sizes, never go beyond 252
bytes.
This reverts commit be0bd9b835.
It also remove a TODO.
CQ-DEPEND=CL:262870
TEST=With proper kernel, and firmware supporting commands > 252 bytes,
check that ectool console does not crash anymore.
/usr/sbin/ectool --name cros_sh console
returns more character than before.
Check ectool version as well.
/usr/sbin/ectool --name cros_sh version
BUG=chromium:399057,chromium:454324,chrome-os-partner:31989,chrome-os-partner:23823
BRANCH=none
Change-Id: I058ab0e6df96196a0fae186d1ffedcfa16e5dc3b
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/262885
Reviewed-by: Puthikorn Voravootivat <puthik@chromium.org>
- Updated arguments to support two sub commands:
- check: check if AC adapter is connect.
- update: trigger battery firmware update.
- All Delay values are from .cfg file.
BUG=chrome-os-partner:36310
BRANCH=none
CQ-DEPEND=CL:260868
TEST=Verified on Glimmer.
crosh> battery_firmware check
crosh> battery_firmware update
Change-Id: I7324e1f329383cf5ee62660f4ac4cb0b1c30c056
Signed-off-by: Sheng-Liang Song <ssl@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/260210
Reviewed-by: Shawn N <shawnn@chromium.org>
We're moving the hardcoded check lists out of the pre-upload script.
BUG=chromium:466264
TEST=uploading a CL w/out a branch line is rejected
BRANCH=None
Change-Id: Ifa0f8c3b4be6a20355babb6f9d8896ac8d1fb2be
Signed-off-by: Mike Frysinger <vapier@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/262490
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Contrary to the BQ2751 and BQ27741 it is sharing code with, BQ27742 does
not have a "device name" register. So we need to skip the I2C reads else
the battery_device_name() function returns an I2C error and the charge
code retries until the end-of-time to read it hogging the CPU.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:38401
TEST=run on Ryu P4 and verify that we are no longer seeing 20ms of I2C
transactions every 100ms on the battery I2C bus.
Change-Id: I961af54017f661ee928058b346a42b7206ad8217
Reviewed-on: https://chromium-review.googlesource.com/262449
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
When calling problem() with 0 as value, it's never printed on the EC
console since the problem() function is de-duplicating the messages by
checking against the last value (which is initialized at zero).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:38401
TEST=run on the current Ryu code (which has a faulty BQ27742 driver) and
see the "charge problem: static update [...]" message.
Change-Id: Iedfbc95e3751bc5b22452187b404a09b633160d7
Reviewed-on: https://chromium-review.googlesource.com/262448
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Some platforms are unable to access the 900h-9ffh region over LPC and
must instead access memmap data through the ACPI CMD / DATA ports. To
avoid racing with data updates, disallow changes to multi-byte memmap
data while in burst mode.
Linux currently enables burst mode when accessing multi-byte data and
disables it immediately afterward, though the ACPI spec defines burst mode
in a more general way.
BUG=chrome-os-partner:38224
TEST=Manual on Samus. Undefine LPC_MEMMAP and modify asl to move memmap
data to ERAM at offset 0x20. Verify system boots cleanly and battery
status is updated immediately on plug / unplug.
BRANCH=None
Change-Id: Ib848bdb491fdfece96ad0cee7a44ba85b4a1a50b
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/262072
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This required changing the USB-SPI implementation slightly
so that all work is done within the deferred callback. In
particular, this allows the board specific enable and disable
functions to do things that can only be done from a task
context, like sleeping.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Change-Id: I3f6a01ed9d6f31a3259ba0a0f6b4e123d6d2e718
Reviewed-on: https://chromium-review.googlesource.com/260964
Trybot-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
