This is necessary for an imminent change which passes version data
from the host bus (LPC/I2C/SPI) into the host command handler.
BUG=chrome-os-partner:11275
TEST=from u-boot prompt, 'mkbp hash'
Change-Id: If34d0d7c6dc320ad5632becf512c30900fd61aca
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27190
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Added version mask field to DECLARE_HOST_COMMAND() because it's
convenient to do so when I'm touching all host command
implementations, but all commands simply declare version 0 and nothing
checks it yet. Will add version support in a followup CL.
This change is internal to the EC; it does not change the data sent
over the host interface.
BUG=chrome-os-partner:11275
TEST=manual
ectool version && ectool echash; should get sane data from both
ectool flashread 0x80 0x40 /tmp/foo && od -tx1 /tmp/foo
should match data from offset 0x80 of ec.bin (od -j128 -n64 -tx1 ec.bin)
Change-Id: I5699f72b8d5e1ac23929353c9a34158d76c44206
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27172
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This change shorten the timeout period to 10ms.
Experiments showed that most master mode communication status bit
changed within 2000us. Hence 10ms timeout is much reasonable than
the original value.
Signed-off-by: Rong Chang <rongchang@chromium.org>
BUG=none
TEST=manual, with i2c scope
Change-Id: Ib26795bd2e4877b5c33719e96a2c2c7c11333eab
Reviewed-on: https://gerrit.chromium.org/gerrit/27145
Tested-by: Rong Chang <rongchang@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit-Ready: Rong Chang <rongchang@chromium.org>
We choose PE2/USB1_CTL1 for BOOTCFG. If we somehow brick the EC, we can
pull this signal to ground and boot EC into boot loader to recover it.
BUG=chrome-os-partner:8769
TEST=On link:
- Factory reset EC to clear BOOTCFG
- Flash new EC binary and reboot
- rw 0x400fe1d0 to check BOOTCFG value is correctly written
- Boot normally and check EC is operating correctly
- Pull the signal to ground and reset EC, check EC stays in boot
loader. Check in this case we can program EC.
- Attempt to write different value to BOOTCFG and check BOOTCFG
doesn't change.
Change-Id: Ia6705114d495b18bd7ee4afc1e61e84a21b51198
Reviewed-on: https://gerrit.chromium.org/gerrit/27000
Reviewed-by: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
Commit-Ready: Vic Yang <victoryang@chromium.org>
Now that ACPI events are handled directly in the LPC interrupt
handler, we can simplify the host event code.
BUG=chrome-os-partner:11240
TEST=boot system; should boot
close lid; should send SMI and suspend system
Change-Id: I8c73ea31a66e94310e4460a008635a103220413e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27100
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
And only support it for port 62/66.
Also remove 'ectool queryec', because it can't touch port 62/66 once
the kernel/ACPI owns it, and query-event isn't supported on the user
command port.
BUG=chrome-os-partner:11240
TEST=boot system and check EC console output; should see event clears between
host commands 0x23, 0x8e, but no hostcmd 0x84.
[0.396780 LPC RESET# deasserted]
[0.486953 Port 80: 0x29]
[0.487415 hostcmd1 0x23]
[0.764407 Port 80: 0x88]
[0.764579 event clear 0x00000008 -> 00002080]
[0.764928 event clear 0x00000080 -> 00002000]
[0.765224 event clear 0x00002000 -> 00000000]
[0.765578 hostcmd1 0x8e]
[0.765868 hostcmd1 0x06]
Change-Id: I8ed161dbccd396d685ddf6829a27dfef87d919fb
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27095
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
BUG=chrome-os-partner:9922
TEST=manual
Press power+refresh+d.
From ec console, 'optget'. No reference to fake dev switch
From host, 'ectool vboot'. Should see either 'fake_dev=0' or no mention of fake dev switch at all.
Change-Id: I66bc5e926d6e639b206563e764bcc730cce9227c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/27061
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This fixes a small bug introduced in a previous refactoring CL where
by the data buffer offset wasn't being incremented, thus causing
writes to repeatedly write the first two bytes of the incoming data
to each chunk of memory.
BUG=chrome-os-partner:11097
TEST=successfully wrote and verified data on Snow
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I8dae00652f4d74bc6ef449297b6e78b13b21255f
Reviewed-on: https://gerrit.chromium.org/gerrit/26985
Reviewed-by: Katie Roberts-Hoffman <katierh@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit-Ready: David Hendricks <dhendrix@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Currently host_command_reboot() casts the supplied buffer and access
it directly. This works until about half-way thru the function when
the same buffer potentially gets overwritten when sending the response
code to the host.
This CL gets around that by copying the reboot parameters into a
separate buffer.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
BUG=none
TEST=Tested using 'ectool reboot_ec' on Snow (see below)
Before, EC console displayed "[Executing host reboot command]" and
ectool showed no actual change (reboot command was being overwritten
with EC_REBOOT_CANCEL):
localhost ~ # ectool version | grep 'Firmware copy'
Firmware copy: RO
localhost ~ # ectool reboot_ec A
localhost ~ # ectool version | grep 'Firmware copy'
Firmware copy: RO
With the patch applied, the EC console shows the EC boot-up messages
and ectool confirms that the jump took place:
localhost ~ # ectool version | grep 'Firmware copy'
Firmware copy: RO
localhost ~ # ectool reboot_ec A
localhost ~ # ectool version | grep 'Firmware copy'
Firmware copy: A
Change-Id: I8aca8d468d1125c3fb8d320ec0fb79d2822b0b20
Reviewed-on: https://gerrit.chromium.org/gerrit/26998
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Commit-Ready: David Hendricks <dhendrix@chromium.org>
When debug port is left unconnected, EC get garbage keypress input from
both UART ports due to UART pin floating. By clearing UART receive FIFO
when initializing UART module, this can be prevented.
BUG=chrome-os-partner:10235
TEST=Reset EC with debug port unconnected. Check u-boot doesn't get any
keypress.
Change-Id: I3e84db1f2f95a0173c11180f6afb3edb705d0ae5
Reviewed-on: https://gerrit.chromium.org/gerrit/26908
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Rong Chang <rongchang@chromium.org>
Commit-Ready: Vic Yang <victoryang@chromium.org>
If the 'percent' passed in is lower than 0, then set it to 0. If it is
higher than 100, set to 100.
BUG=chrome-os-partner:11052
TEST=Check with 'kblight', 'fanduty', and 'faninfo'.
Change-Id: If84ab12658bf136eaaf1adecc0522a977c94f98d
Reviewed-on: https://gerrit.chromium.org/gerrit/26904
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
BUG=chrome-os-partner:11046
TEST=manual
1. Try 'ectool kbpress' command from root shell with a few params when system is unlocked (WP disabled). Should work.
2. Try again when WP is enabled and locked ('flashwp lock' then 'reboot' from EC console). Should fail.
2b. Alternately, use 'syslock' to lock system for just the current boot.
Change-Id: Ic271b13b1973ff3cb83a113274d4e33655c0cf85
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/26936
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Allows 'reboot cold' as an alias for 'reboot hard', since I keep
mis-typing that anyway. Returns error for any other option.
('reboot' by itself still does a warm reboot).
BUG=none
TEST=manual
reboot -> does warm reboot
reboot hard -> does hard reboot (reason = rtc alarm)
reboot cold -> ditto
reboot foo -> prints error
Change-Id: I183714d4ba09abee3bd9a6f0d5df82389becf410
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/26924
This allows the console or AP to keep the EC in its RO code.
Previously, the EC could jump from RO to RW even if the system was
locked in pre-init.
Also, sysjump console command doesn't need to check if system is
disabled before calling system_run_image_copy(), because that function
also checks. This now matches how the host command works.
BUG=chrome-os-partner:11147
TEST=manual
syslock
sysjump A -> works
reboot
syslock
sysjump disable
sysjump A -> fails
Repeat, using 'ectool reboot_ec disable-jump' at root shell instead of
'sysjump disable' at EC console.
Change-Id: I0b168a93e97802ba30e7c225b01d70ea66e8db58
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/26898
EC software sync still needs to be able to sysjump later after the AP
decides which image the EC should be running.
BUG=chrome-os-partner:11087
TEST=manual
sysjump A
sysjump RO
sysjump A
sysjump RO
Change-Id: I74eaf10dacf6eaa6aeabae2ff3b21ad387517605
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/26896
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This makes it easier to test functionality which should be disabled
when the system is locked.
BUG=chrome-os-partner:11154
TEST=manual
sysjump a
sysjump ro
sysjump a
syslock
sysjump ro -> should fail
Change-Id: I637d5a9a795948dd45817c5e110433d12bb6618e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/26897
This test checks charging state machine works correctly:
- Charge when AC plugged. Discharge when AC unplugged.
- Shutdown when over/under-temperature during discharging.
- Stop charging when over/under-temperature during charging.
BUG=chrome-os-partner:10270
TEST=Test passed
Change-Id: I460645c70f5dcd30e258c43956ffe416c8bce906
Reviewed-on: https://gerrit.chromium.org/gerrit/26383
Reviewed-by: Rong Chang <rongchang@chromium.org>
Commit-Ready: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
For I2C bus connected to PCH, clock frequency must not exceed 100KHz.
Lower temp sensor I2C bus to meet PCH spec.
BUG=chrome-os-partner:9928
TEST=Still able to read I2C temperature sensors.
Change-Id: Idec66d9124f61dc12e763561e0364c9ddb9ffeb0
Reviewed-on: https://gerrit.chromium.org/gerrit/26884
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
Also add new 'invalid' host event bit; if the host reads this, it
knows the memory-mapped data for current events is invalid.
BUG=chrome-os-partner:11146
TEST=manual
On host, ectool eventget -> should print events = 0
On EC, hostevent set 0x80000000
On host, ectool eventget -> should print events = invalid
Reboot EC; should see debug output where event mask 0x2000 is set
during the boot process.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Change-Id: I8d3f161eec25db50ac06e3642a1a1fb8edb9590e
Reviewed-on: https://gerrit.chromium.org/gerrit/26876
512 bytes isn't enough to capture all the debug output early in the
init process, and Link EC has lots of unused RAM. stm32 doesn't, so
only do this for LM4 processor.
BUG=none
TEST=build; debug output during init shouldn't be garbled
Change-Id: Ie4fd204fa4e0c6ca99ea7eae94b095ef175836e4
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/26877
This enables lid open on Snow (and presumably Daisy).
For now we only care about interrupting on lid open (rising edge of
LID_OPEN) to turn on the AP.
BUG=chrome-os-partner:9708
TEST=Tested on Snow
Signed-off-by: David Hendricks <dhedndrix@chromium.org>
Change-Id: I8f6cb4dd9d3ebc0380c8a5e7a3f2ce967e3eff48
Reviewed-on: https://gerrit.chromium.org/gerrit/26648
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Commit-Ready: David Hendricks <dhendrix@chromium.org>
This adds a small interrupt handler for lid open/close event which
updates a state variable and wakes up the power task to decide if
action must be taken. For the suspend mode path, it will determine
which state to set the power LED in.
BUG=chrome-os-partner:9708
TEST=Lid open turns on Snow, suspend mode to be tested separately
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Ib8bb682affc5b9f6d729eb5f05d23098074e1a77
Reviewed-on: https://gerrit.chromium.org/gerrit/26647
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Commit-Ready: David Hendricks <dhendrix@chromium.org>
If we don't store PWM module state, fan would be disabled after system
jump until the next reboot. Let's preserve fan and keyboard backlight
state.
BUG=chrome-os-partner:11027
TEST=Boot and "sysjump a". Check fan is still enabled.
Change-Id: I57dbcabef79264af7fcedb8fa0c00ff6299b97d5
Reviewed-on: https://gerrit.chromium.org/gerrit/26757
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
Commit-Ready: Vic Yang <victoryang@chromium.org>
BUG=chrome-os-partner:11090
TEST=suspend laptop, then press power button; should resume from suspend
Change-Id: I36b7c62b2e115bb97d37defcd3c783af0f91d5f8
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/26730
And fix returning memory-mapped string length on LPC as well.
BUG=chrome-os-partner:11090
TEST=manual
from EC, 'hostevent set 0x40000'
from host, 'ectool eventget' --> should print 0x40000
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Change-Id: I9edbd0a1468b5d4160ce67c471332226e51fa868
Reviewed-on: https://gerrit.chromium.org/gerrit/26719
Reviewed-by: Simon Glass <sjg@chromium.org>
There are a lot of timeous in the i2c driver. When one occurs, print
out the number of it so that the root cause can more easily be
examined.
BUG=chrome-os-partner:10888
TEST=manual:
Lock up the i2c bus from the AP by running the kernel without bus
arbitration doing i2c traffic:
while true; do i2cdump -f -y 4 0x48; done >/dev/null
and using 'pmu 100' on the EC.
Then see that a timeout error is printed, for example:
i2c wait_status timeout type 2, 101387 us
Change-Id: I3fb3fcf9f07966ef4e71d4358c791fea90aba5d5
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/26830
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This command is primarily useful for testing, since it repeatedly
hammers the i2c bus.
Enable the command on snow for now.
BUG=chrome-os-partner:10888
TEST=manual:
run 'pmu 100' on snow and see that it displays the correct output.
Change-Id: I36c15af195d17f67dff4c05559d1756693a65c19
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/26829
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Change the delay for bus claim to 100ms, since in testing with the AP
requesting the bus constantly, I was able to make a 50ms timeout happen
after about 3000 transactions. With 100ms, the timeout happens only
once in 130,000 i2c transactions with both AP and EC fully loading the
i2c bus simulataneously.
The bus claim failure should never happen, but in case it does, print
an error. Also make sure we delay for a bit, to allow the AP to see the
change in state.
BUG=chrome-os-partner:10888
TEST=manual:
build for all boards
boot on snow, test:
on AP:
$ while true; do i2cdump -f -y 4 0x48; done >/dev/null
on EC:
$ pmu 10000
See that the machine operates normally with no lock-ups, etc.
Change-Id: I9a48144f560c596429c525a42c77ac41ec095ec0
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/26828
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Enable this feature so that we can be a bus master on the I2C host
port when the AP is not using it.
BUG=chrome-os-partner:10888
TEST=manual:
build for all boards
boot on snow, test that:
- keyboard still works in U-Boot
- battery charging is enabled
- U-Boot can see TPSCHROME
- keyboard works in kernel
- kernel reports battery levels correctly
Change-Id: Ie17e38feea721355a738d85f0295ed5f145c8a0c
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/26826
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This ensures that we have all available help enabled. For the moment
this is useful for development. We may revisit later.
BUG=chrome-os-partner:10895
TEST=manual:
build for all boards
Change-Id: I721e09995959638660ff417dd9420200e2e1a703
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/26173
The power button module now needs to know whether the chipset is in
the on state at init-time, in which case it doesn't need to send a
power button pulse to the chipset.
BUG=chrome-os-partner:11085
TEST=manual
1. power on AP to BIOS screen (e.g., in recovery mode)
2. At EC console, 'sysjump A'
3. system should stay powered on
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Change-Id: Ic1f509204f502d1ddf87314f0e1582c21c991156
Reviewed-on: https://gerrit.chromium.org/gerrit/26700
Reviewed-by: Simon Glass <sjg@chromium.org>
If flash starts at zero, then flash_dataptr() will return NULL for a valid
region. Change the function around so that it can be used in this case.
BUG=chrome-os-partner:10146
TEST=manual:
Modify code it print out parameters and problems, then:
Writing 256 bytes to 0x0...
0 256 64
ok 131072
Command returned error 1
> flashwrite 0 256
Writing 256 bytes to 0x0...
0 256 64
ok 131072
Command returned error 1
> flashwrite 0 255
Writing 255 bytes to 0x0...
0 255 64
Command usage/param invalid.
Usage: flashwrite offset [size]
Change-Id: I5683fc181ef780310ceff50f120735659e973784
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/26749
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Rong Chang <rongchang@chromium.org>
Rather than go through the task queue, host_command_process() processes
the command immediately, has all of its required state passed in,
allowing the caller complete control of the buffers.
BUG=chrome-os-partner:10533
TEST=manual:
build and boot on link, see that messages are stil processed
build and boot on snow, which uses this new command
See that the SPI keyboard works now
Change-Id: Ib7587de10c42caf01bc95bb4d515fd0afc3da7d8
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/25983
Reviewed-by: David Hendricks <dhendrix@chromium.org>
We see some intermittent failure on PECI read. This CL lower PECI baud
rate from 150K to 100K. Also, we poll PECI temperature 4 times per
second and average over last 4 values. We only report read error when
last 4 read all fails.
This CL also increases the external path delay, increases retry count,
and also enable timing negotiation error bypass.
BUG=chrome-os-partner:10382
TEST=Still able to read from all temperature sensors
Change-Id: I38cefeabd9e3eff4bb8e4df4138c4ffd49cd84a2
Reviewed-on: https://gerrit.chromium.org/gerrit/26554
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
Commit-Ready: Vic Yang <victoryang@chromium.org>
The current gpio_get_level() is pretty slow because it looks things up each
time. Add a new function to find out the register address and mask to use
to check the value for a particular GPIO.
Time-critical code can then use this to check a GPIO.
BUG=chrome-os-partner:10146
TEST=manual:
build and boot on snow;
Power on the board, hold power button for 10s and see that it powers off
Power control still works, thus GPIOs are functional
Change-Id: Ifc6c56f5cb811e0243e7712725a51948eabd42ab
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/26175
Sometimes it is useful to get access to the flash directly, without using
flash_read(). Add a function to do this.
Since the range checking is done in every function in flash_common,
use the new function to do it for us. That way we get a slight (64 byte)
code size reduction.
BUG=chrome-os-partner:10146
TEST=manual:
build and boot on snow with SPI flash emulation, in U-Boot:
See that the 32KB of flash has been provided correctly.
Change-Id: I6622a24234edaed371dd5b9bf43d1f3974d55e39
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/26174
The WWDG is not ideal for this purpose, since if we fail to handle its
interrupt withint 60ms or so, we get a reset. This can be a problem when we
are reporting a panic, since the uart output takes a long time.
Change to using timer 9, which is free, and make it print a watchdog warning
after one second.
BUG=chrome-os-partner:10146
TEST=manual:
build and boot on snow; waitms 1200 and see that a watchdog timeout is
reported correctly.
See that the panic message is displayed in full without a reset happening
before the end.
Change-Id: Ifc3671098e1f3a7ef409b8d1fb919d22eaa90358
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/26172
This allows us to repeatedly read the battery for testing.
BUG=chrome-os-partner:10888
TEST=manual:
build for all boards
boot on snow (cannot test i2c as it is
Change-Id: I0ed99d59355e1f228486070dcf37863563b16023
Reviewed-on: https://gerrit.chromium.org/gerrit/26290
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Commit-Ready: Simon Glass <sjg@chromium.org>
This driver was not refactored when the host_command changes were made,
although i2c was. Tidy this up.
SPI requests the command response immediately rather than going through
the task queue, since otherwise a response may take long enough that the
SPI master misses it altogether.
BUG=chrome-os-partner:10533
TEST=manual:
build and boot on snow; In U-Boot:
> sspi 4:0 240 20
See that it gets key messages back now
Change-Id: Ia2c24d4c8876fefedad4c02802f77e50d7159d03
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/25982
Use two suitable GPIOs to implement a simple arbitration scheme.
Each side owns one of the GPIOs, which are normally pulled high.
When one side wants to use I2C as a master, it pulls its GPIO low,
waits for a short period to make sure that the other side is not
also pulling its GPIO low, and then goes ahead with the transaction.
When the transaction is over, the GPIO is released, thus freeing the
I2C bus up for use by the other end.
For simplicity the terminolgy used here is EC for us, and AP for the
other end.
BUG=chrome-os-partner:10888
TEST=manual:
build for all boards
boot on snow (cannot test i2c as it is broken)
Change-Id: I97d9fbd5aba8248c8c1240baaec17db22860665c
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/26142
