When we are redetecting, if ID_MUX is 1, we need to switch it back.
Otherwise, no one is there to switch it and we are stuck in this state.
BUG=None
TEST=Check the EC detects device type after redetecting from device type
0x60400.
BRANCH=Spring
Original-Change-Id: I42378e2ea9177962524af7316d76c54b2518e614
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60041
(cherry picked from commit 7ebc1b269360f54dde29e3ec75f44e1976a15992)
Change-Id: I89ec974030712dea6157405a3b1bc819dc130e94
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60623
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
We've seen CABLE_DET being asserted hundreds of milliseconds after
ID_MUX is switched. To ensure video dongle is detected, let's poll
CABLE_DET for a second before declaring it an USB host.
BUG=chrome-os-partner:20405
TEST=Manual
BRANCH=Spring
Original-Change-Id: I1858f4075f526ee198b7b5f7ad2bb06cf6e3512c
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59887
Reviewed-by: Jeremy Thorpe <jeremyt@chromium.org>
(cherry picked from commit 2d37619a934264cf4f902078b081b76d607ddce1)
Change-Id: I55fba167780fb7e04157655dc5b3a2e76b8999c5
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60622
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
If we are overloading the charger and it browns out, the kernel reacts
to this event as if the charger is disconnected. This may confuses the
user as the backlight brightness might change. Let's delay this until
the device type has stabilized.
BUG=None
TEST=Plug in a charger and observe backlight brightened. Check the
backlight brightness doesn't change while the charger is overloaded.
BRANCH=Spring
Original-Change-Id: Ie89ed4261912bfd8cd75a70e5058411f1c929aa9
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59878
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
(cherry picked from commit af770935938c99e17f99eea38bc1c0f34cc862fe)
Change-Id: I9c88d08100ba54f313506d495bc8e8dba5766dc7
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60621
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This gets rid of mystery files like "ir357x" and "lp5562". All chip
names are now prefixed with their module type (e.g. "chipset_",
"led_driver_", etc.)
No functional changes; renaming files and CONFIG constants only.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all platforms
Change-Id: I3227fb0f6b0243bb08a13577cdb0f6def0e15d54
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60922
Note that the PP3300_LTE_EN signal does different things on
different boards. On peppy/slippy it controls both LTE power
and gates a wake interrupt to the PCH. On falco it just gates
the wake interrupt; module power is tied to the DX rail.
On all boards there is a separate DISABLE_L signal from the PCH.
BUG=chrome-os-partner:20513
BRANCH=falco,peppy
TEST=Manual. Verify module detectable via lsusb in S0. Verify power
to module is disabled in S3.
Signed-off-by: Dave Parker <dparker@chromium.org>
Change-Id: I4984081009e4a1ce8ad8996e97f779c545829ce5
Reviewed-on: https://gerrit.chromium.org/gerrit/60941
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Dave Parker <dparker@chromium.org>
Tested-by: Dave Parker <dparker@chromium.org>
These constants are scattered around the various interface
implementations and should be in one place. This will also clean up
the u-boot side when ec_commands.h is copied there.
BUG=chrome-os-partner:20257
BRANCH=none
TEST=build link, spring, pit; test 'ectool hello'
Change-Id: Ib1425db00ec8220538d8c5c65107ac9548009516
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60810
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add support for the TI BQ24715 smart battery charger.
It provides the system power while limiting the battery
charge limit based system power needs.
This code is based off of the bq24725 code, however there
is one change (aside from the min/max) to fit into the
current charging state machine. The charging voltage
setting is cached to provide the illusion of it being 0V
which the hardware does not allow.
BUG=chrome-os-partner:20372
BRANCH=None
TEST=Used on a board containing this charger.
Change-Id: I59af88fba6bf740e7caff72c9ed27eaf721758c4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60804
As different boards can use the same EC but use different
pins for the same functionality it is required to properly
abstract out the bank and pin used for the one wire interface.
Provide this ability.
BUG=chrome-os-partner:20372
BRANCH=None
TEST=built for failure and success on link
Change-Id: Ie20f2319d9cd6f5ec63b4178ecebc45a90a51042
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60798
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
LPC-based ECs provide a region of memory that is mapped into the AP's
address space, making it easy to read.
This CL uses an alternate EC host command to read that region, for those
systems that don't have mapped memory.
BUG=none
BRANCH=none
TEST=none
I tested this by building a special command into ectool.
Change-Id: If5cc52356f61522ae96e20d4c5d365accc299987
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59662
This came up when testing issue 242706. If you tell the EC to return
EC_RES_IN_PROGRESS, then the EC gets stuck and times out on the next
command.
I'm not entirely sure what the correct response should be, but I think that
the EC might not be doing the right thing either. In any event, this keeps
it from getting stuck.
BUG=none
BRANCH=none
TEST=manual
Try
ectool test 8 14
ectool test 0 14
The first command fails because we told it to, but the second command also
fails because the EC is expecting something else.
After this change, the second command works.
Change-Id: I513294396cff872018316c354d2c41953eb6fdf6
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59661
ectool is waiting for an empty response from the EC to tell it to stop
requesting console data. However, the EC only sends an empty response when
there is no snapshot data. In particular, it seems to send a 1 byte response
(containing just a \0 byte) when there is an empty string.
Adjust the check to stop when no data is provided.
BUG=chrome-os-partner:20639
BRANCH=none
TEST=manual
Run on test device and see that 'ectool console' now completes and does not
run forever.
Change-Id: I565f1be506833c823e5e7eca09be8b2420c8190c
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60640
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
It's still unclear why the PL6 pin which is used
for RCIN_L does not behave properly when configured
as open drain. Work around the misbehavior by
configuring the PL6 pin as an input. When it is
required to be driven low the pin is reconfigured to
an output and subsequently made an input again.
This provides the open drain semantics that are
required to eliminate leakage.
BUG=chrome-os-partner:19811
BUG=chrome-os-partner:20054
BUG=chrome-os-partner:20173
BUG=chrome-os-partner:20175
BRANCH=None
TEST=manual
'apreset warm' causes reset as expected. The pin is
configured as an input by default without open drain
or a pullup resistor:
> rw 0x40062400 (GPIODIR)
read 0x40062400 = 0x00000000
> rw 0x4006250c (GPIOODR)
read 0x4006250c = 0x00000000
> rw 0x40062510 (GPIOPUR)
read 0x40062510 = 0x00000000
Change-Id: Ia3ad6fa7fec06be1cbff6854d9341722d8617408
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60780
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Also moves low-battery condition check to discharge state for Falco.
BUG=chrome-os-partner:20649
BRANCH=falco,peppy
TEST=Use ec 'battfake' comamnd to verify charger LED shows the battery
is charged when it hits 97%. On Falco, verify the charger LED flashes
while while not on AC power when the battery is under 10% charged.
Change-Id: I58e1312775a2780945643d47c9364ca0959553ed
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60704
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This is necessary to support larger packet sizes for host protocol
ver.3. The host previously didn't have any way to know how big a
packet the EC could accept / respond with (except on LPC, where the
size is determined by the I/O window).
BUG=chrome-os-partner:20257
BRANCH=none
TEST='ectool protoinfo' returns good info; on link,
Protocol info:
protocol versions: 2 3
max request: 256 bytes
max response: 256 bytes
flags: 0x00000000
and on pit,
Protocol info:
protocol versions: 2 3
max request: 544 bytes
max response: 544 bytes
flags: 0x00000001
Change-Id: Ic1e3831d9b4a96ffbf365c0d09b6023472de39a9
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60703
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
No functional changes, just cleanup.
BUG=chrome-os-partner:20529
BRANCH=none
TEST='waitms 2000' reboots the system with a watchdog reset cause
Change-Id: I8fcee92476a287e6cb81bf9012f29c87d2aca0ba
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60680
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
If the EC receives a second host command with the same command code
within 50ms, it prints '+' instead of the full command debug output.
This reduces debug output during software sync by a factor of 20.
This is the default mode, also settable via 'hcdebug normal'.
The previous behavior is available via 'hcdebug every'.
What used to be 'hcdebug on' is now 'hcdebug params'.
'hcdebug off' turns off printing received host commands entirely,
though error result codes will still be printed.
BUG=chrome-os-partner:20647
BRANCH=none
TEST=manual
From a root shell, 'ectool hello && ectool hello' generates debug output
'[48.498943 HC 0x01]+'.
Then 'hcdebug every' and repeat. See both 0x01 commands.
Then 'hcdebug params' and repeat. See params for request/response.
Then 'hcdebug off' and repeat. No output.
Change-Id: If02baf39435c2a6183e0772a491225ebc5a0b7a6
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60666
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Version 1 of EC_CMD_FLASH_WRITE will use as big a write as possible given
the available command parameter space. Falls back to 64 byte writes on old
platforms.
BUG=chrome-os-partner:20571
BRANCH=none
TEST=Copy burn_my_ec onto a link and run it. Write size should be 64 bytes
for the first half of the update (since the old EC doesn't support ver.1
of the write command) and 240 bytes for the second half of the update.
Change-Id: I5900de3a5700d7c82a2e0c3cf9921b7ced1c0343
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60511
The maximum packet / param size differs depending on interface and
protocol version. Commands can now ask the comm interface what the
limits are, and can use preallocated buffers to avoid needless
malloc/free.
BUG=chrome-os-partner:20571
BRANCH=none
TEST=the following all work on link
burn_my_ec
ectool version
ectool chargedump
ectool console
ectool i2cxfer 5 0x41 2
Change-Id: Ib847994da3f79721e7fb4e347231b9147a3f485f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60275
ectool and burn_my_ec need to use the same lower-level interface to
the EC flash commands, rather than duplicating calling the low-level
flash read/write/erase commands.
This is a precursor to refactoring the low-level commands to support
SPI/STM32L in a follow-up CL.
BUG=chrome-os-partner:20571
BRANCH=none
TEST=in a root shell, burn_my_ec flashes both RO and RW EC code
Change-Id: I4c72690100d86dbff03b7dacc2fb248b571d3820
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60266
Previously it padded out the entire response buffer with null, which
caused an EC capable of returning large responses to overflow the AP's
input buffer.
BUG=chrome-os-partner:20525
BRANCH=none
TEST=from EC console, 'hcdebug on'
from U-boot console, 'crosec version'
HC resp for HC 0x04 should have only a single 00 byte at the end
Change-Id: I65826c1ccda15f18a59a6c34db61ee67e90511b8
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60133
Reviewed-by: Simon Glass <sjg@chromium.org>
Previously, code which needed to work on all STM32F platforms needed
to specify them by name (CHIP_VARIANT_stm32f100 ||
CHIP_VARIANT_stm32f10x), and we needed extra symlinks in the
chip/stm32/ directory to allow the build system to find
family-specific files.
Add a CHIP_FAMILY level of abstraction, so that things which are
common across all STM32F platforms don't need to specify every STM32F
variant. Make the chip build look for family-specific filenames
instead of variant-specific filenames (except for config*.h, which is
actually variant specific).
In the few places where things actually are variant-specific, keep
using the existing CHIP_VARIANT defines.
Code refactoring only; no functional changes.
BUG=chrome-os-partner:20567
BRANCH=none
TEST=build all platforms
Change-Id: I1da831aadabf8b8dd9dfde423cac13c9f43eb953
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60247
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
ectool.c has gotten monstrously huge. Refactor out some utility functions.
This is precursor work to refactoring out a lower-level flash
read/write interface.
BUG=chrome-os-partner:20571
BRANCH=none
TEST=ectool flashread 0x20000 0x80 /tmp foo -> works
Change-Id: I26dae609a73e54e8adaec56edbdce6a0bb4b8758
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60265
Reviewed-by: Vic Yang <victoryang@chromium.org>
This can be useful when the EC reboots but we don't have access to the
EC console.
BUG=chrome-os-partner:20548
TEST=Manual
BRANCH=None
Change-Id: I0b762011860d7802ffbc208ffa42920fa6ed098d
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60220
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Bitfields are now in registers.h where they belong.
BUG=chrome-os-partner:20529
BRANCH=none
TEST='crosec test' from u-boot still works
Change-Id: I726550a32b61111c906c1b10c628c5e47eff74fb
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60179
Bitfields are now in registers.h where they belong.
BUG=chrome-os-partner:20529
BRANCH=none
TEST='crosec test' from u-boot still works
Change-Id: If0d79a66a90665c8ea336a006d76ccbc00a927ec
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60139
Reviewed-by: Vic Yang <victoryang@chromium.org>
When TOT link moved to 128KB images, I missed two references to 80KB.
Fix those, so TOT now builds 128KB images for all lm4-based platforms.
BUG=chromium:252584
BRANCH=none (link branch will stay at 80KB images)
TEST=sysjump rw doesn't crash
Change-Id: I5f25cf97ec706374d03ce8ecff6572c1c84242b5
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60153
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The maximum packet length for LPC is limited by the I/O space window
size. But that's not the case for SPI or LPC. Rename LPC constant
before adding a SPI constant.
BUG=chrome-os-partner:20257
BRANCH=none
TEST=build link
Change-Id: I088327a11eff18d401c773db953700a36f9c1bb4
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59959
Explicitly use enum for dma_channel, instead of ints (since channel is
1-based in the docs and 0-based in the enum). Add enum values for
other channels like USART.
Use volatile structs instead of typecasting through REG32().
Other assorted code cleanup.
Remove DMA2 partial support, since neither STM32F100R8 nor STM32L151x
has hardware support for it and it cluttered the code.
No functional changes.
BUG=chrome-os-partner:20485
BRANCH=none
TEST=from pit root shell, 'ectool version' still works
Change-Id: Ifdd62fb287c608a684ba8fa16934dfcab83ee609
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59949
Power LED PWM now uses the same functions as the hardware timer.
BUG=chrome-os-partner:20414
BRANCH=none
TEST=Suspend system. Power button LED pulses smoothly still.
Change-Id: Ib5ca6655d815462baaf68600ad14c4c0c680a6af
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59838
Automatically drop the clock speed to 1 MHz MSI, then disable HSI and
move to lower-power flash mode. This cuts power from 2400uA to 150uA.
Note that at 1 MHz, we drop received characters on the UART if you
type too fast (or copy/paste, or use arrow keys). Clock speed can be
manually overridden back to 16 MHz via 'clock hsi'.
BUG=chrome-os-partner:20414
BRANCH=none
TEST=with AP on, 'clock' reports 16 MHz.
with AP off, 'clock' reports 1 MHz.
Change-Id: I070c80db0aa5f3a98a7bad6050890bcc2fe008d6
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59832
Modules which care about system clock frequency now hook HOOK_FREQ_CHANGE.
- hwtimer
- i2c
- uart (which is now also smart enough to use x8 oversampling instead of
x16 when the system clock is too slow to support x16)
Added 'clock' debug command to set system clock frequency.
STM32F platforms don't change clock frequency; on those platforms,
clock_get_freq() simply returns CPU_CLOCK, so behavior of those
platforms is unchanged.
BUG=chrome-os-partner:20414
BRANCH=none
TEST=from EC console:
- reboot ap-off -> to make sure AP is off during testing
- clock msi2 -> reports 2MHz clock
- battery -> reports battery info
- clock msi1 -> reports 1MHz clock
- battery -> reports battery info
- clock hsi -> reports 16MHz clock
- battery -> reports battery info
- power on -> AP powers on and host commands succeed
Change-Id: Ib8276bf124727e4fb502297ca8b3d6d4b6170241
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59645
Preserve the state of keystroke_enabled to prevent keystrokes from being
initially disabled on RO --> RW transition. This will allow us to use
the keyboard on EC cold boot.
BUG=chrome-os-partner:20430.
TEST=Manual. Verify keyboard works on EC cold boot on Peppy.
BRANCH=None.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I603a73ee0f8435c91d430a64803add345c92f025
Reviewed-on: https://gerrit.chromium.org/gerrit/59798
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
WP GPIO is active low on peppy.
TEST="gpioget WP" with hole24 open shows 1, with hole24 shorted shows 0.
BUG=chrome-os-partner:20429.
BRANCH=none.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Idf3de192c500edcb40b37269b1b66e6a5df4dd1f
Reviewed-on: https://gerrit.chromium.org/gerrit/59703
Reviewed-by: Dave Parker <dparker@chromium.org>
Clean up timer initialization code to be more general, so that we can
use timer 9 for the LSB on STM32L. Then use timer 4 for the watchdog
helper.
BUG=chrome-os-partner:18781
BRANCH=none
TEST=From EC console:
timerinfo -> current time still counts up properly
waitms 2000 -> prints watchdog info before rebooting
Change-Id: Ib0ba496b0eadb93756dcd1841857546910baf2a9
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59612
Reviewed-by: Simon Glass <sjg@chromium.org>
BUG=chrome-os-partner:19949
BRANCH=peppy
TEST=Manual. Observe output from "battery" and "charger" on EC console.
No smoke or fire observed (yet).
Signed-off-by: Dave Parker <dparker@chromium.org>
Change-Id: Ibac55bb58ebfc25de5cb625d4f503cf6e3ecec62
Reviewed-on: https://gerrit.chromium.org/gerrit/59624
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
From our measurement, it takes ~80ms for CABLE_DET to be asserted. Let's
wait for that long before giving up and declare it an USB host.
BUG=chrome-os-partner:20405
TEST=Manual
BRANCH=Spring
Original-Change-Id: I71568ed8011f9b3f2c9c2ee67aea3c771a5dbf37
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59566
(cherry picked from commit 3c1b2b757546c022d0ae0eb22e3db9feb41055c4)
Change-Id: Id2329d477f17f1db0309960ee9faeb770b2c50a0
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59667
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The device type reported by TSU6721 changed rapidly in some cases, and
we miss the change after the first one. We need to check device type
change periodically.
BUG=chrome-os-partner:20336
TEST=Plug and unplug DCP charger in suspend. Check device type is
detected correctly.
BRANCH=Spring
Original-Change-Id: Iaab4168f99637b736b8ba42f4313e248b84bdd44
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59535
Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit 69b18e5fb9890f3a638c1587968b110dc1110ba1)
Change-Id: I3cb86b0bfeb7bb02d750197405ffe385b06808e9
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59666
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
When the device suspends with video dongle plugged in, the EC tries to
turn off VFET output. However, the I2C command issued in interrupt
context causes an assertion error.
BUG=chrome-os-partner:20351
TEST=Plug in video dongle, and suspend. Wake the device up successfully.
BRANCH=spring
Change-Id: I135075e83ad0c40ecfdc9a1d8d7c2585a583a916
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59406
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This fixes the problem where the EC consumes too much power during suspend.
BUG=chrome-os-partner:20223
BRANCH=none
TEST=from root shell, 'powerd_suspend'. 1.8V_MICOM should not go up.
after resume, 'ectool hello' should still work.
Change-Id: I93b781e96bea633419e923a83f1f6d7300ae8c54
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59474
Reviewed-by: Derek Basehore <dbasehore@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
The ec driver does not yet pass the command version properly from app
to the EC. This causes a failure when trying to read flashrom write
protect status (command 0x15).
The thing is that the command version is not even important for this
command, as it was never implemented differently.
As a quick fix - mark the command descriptor as supporting both
versions.
BRANCH=none
BUG=chromium:239197
TEST=manual
. on peach_pit (with fixed flashrom, coming under a separate fix):
# flashrom -p ec --wp-status
flashrom v0.9.4 : : on Linux 3.8.11 (armv7l), built with libpci 3.1.10, GCC 4.7.x-google 20130114 (prerelease), little endian
WP: status: 0x00
WP: status.srp0: 0
WP: write protect is disabled.
WP: write protect range: start=0x00000000, len=0x00000000
#
Change-Id: I8302457cc2afdfe3bdcb50cfa2bea29969d0c107
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59462
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This lets us force the EC to return various error codes, so that we can be
sure we're seeing them.
BUG=chromium:242706
BRANCH=none
TEST=none
Trigger various errors like so:
ectool test 0 14
ectool test 1 14
ectool test 5 14
ectool test 8 14
ectool test 0 33
Change-Id: Ia951cd7afacdcce6c8ec7d35d3bfb5b113dea694
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59327
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The ec driver does not yet pass the command version properly from app
to the EC. This causes a failure when trying to use the vbnvram
context command (23). The thing is that the command version is not
even important for this command, as it was never implemented
differently.
As a quick fix - mark the command descriptor as supporting both
versions. I wonder if we should implement a "don't care" option for
situations like this.
BRANCH=none
BUG=chromium:239197
TEST=manual
. on peach_pit:
localhost ~ # mosys nvram vboot read
70000000000000000000000000000020
localhost ~ #
Change-Id: I16fcc0d6752d9e778a026717208d8d6487d5dc77
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59348
This will fix EC flash commands on pit, once the host side (u-boot and
cros_ec driver) are upgraded to match.
This change is backwards-compatible the EC still supports the existing
version 2 protocols for talking to existing AP/kernel/ectool.
Once the AP-side supports version 3 for SPI (and existing systems are
upgraded), we will remove older SPI support since we haven't shipped a
product which uses SPI.
BUG=chrome-os-partner:20257
BRANCH=none
TEST=disable cros_ec driver support in ectool; 'ectool hello' works on link
And with an old ectool which predates this CL, 'ectool hello' also works.
On pit, from u-boot prompt, 'crosec test' and 'crosec version' work, and
keyboard works.
Change-Id: I01f193e316e9aa442fe50d632dc8a4681723e282
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58908
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit-Queue: Doug Anderson <dianders@chromium.org>
