As a short term workaround for the I2C problem of PI3USB9281, we're
gating its SCL input when it's not addressed. This workaround will be
removed once we have the silicon fix.
BUG=chrome-os-partner:31526
TEST=Sanity check on P0 boards.
BRANCH=None
Change-Id: I57daf25f2ad2d94ac7e4192050b4d6bbdae9d51d
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/214064
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Added atomic or/clear when modify a share register
LM4_SYSTEM_SRI2C_ADDR among different i2c ports.
BUG=None
BRANCH=ToT
TEST=Verified on Samus.
Signed-off-by: Sheng-Liang Song <ssl@chromium.org>
Change-Id: Ibf64b05a800ce2b8ddf9735bd3a762ab02031bc8
Reviewed-on: https://chromium-review.googlesource.com/213196
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Host i2c driver in ryu does not allow to snoop the byte
stream to abort the transaction. This make host i2c
driver to be in the dead state if the response message from
ec is shorter than host expected length.
This patch will make ec to send 0xec after end of response
message until get the 'NAK' answer from host to fixed this
issue which occur in these 2 situations.
1. When ec encounters host command error.
2. When response message is a null terminated string.
BUG=chrome-os-partner:31367
TEST='ectool version' runs fine on ryu
BRANCH=none
Change-Id: Icad0f0fde6cca4abd9c833c6d179143e4c5c0561
Signed-off-by: Puthikorn Voravootivat <puthik@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/213177
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
implement USB mass storage class using the bulk-only transport
protocol with the transparent SCSI command set.
BRANCH=none
BUG=none
TEST=verify that usb mass storage functions on windows xp, 7, 8, mac os x, goobuntu precise
Change-Id: Ideecad55bd275df7b30aa4a3ed263304a3a109cd
Signed-off-by: Dominic Chen <ddchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/206303
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
During flash erase operation, read is stalled and thus interrupt might
be serviced later. This can cause PD communication to fail and thus the
board reboots if there is no battery. Print a warning message in this
case.
BUG=chrome-os-partner:31127,chrome-os-partner:31207,chrome-os-partner:31362
TEST=Boot Ryu, on software sync, see warning message before board
reboots.
BRANCH=None
Change-Id: If327a4f533fd2dfa83f92531148bd52ace927e03
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212264
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Certain i2c host drivers don't allow one to snoop the byte
stream to abort a transaction. Allow those devices to make
forward progress by sending out the '0xec' byte for any
requests coming through after an EC host command error.
BUG=chrome-os-partner:30784
BRANCH=None
TEST=Ran on ryu. Allowed passthru probing which normally hung
the system because of there not being a passthrue device
on ryu -- error returned. Instead the command returns
successfully by returning 0xec for the unfilled bytes.
Change-Id: Ibcab5ade1f727f3852995437105eb9fa693caadf
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212165
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The i2c_packet structure wasn't always being initialized
in the error path. It's possible to crash the EC if the first
command processed hit this error path. Instead, unconditionally
set all the i2c_packet fields.
BUG=chrome-os-partner:30784
BRANCH=None
TEST=Built and ran on ryu.
Change-Id: Ic6d7c63f61d59c4449fbb20f656c1bfb835db8be
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212164
Reviewed-by: Alec Berg <alecaberg@chromium.org>
The wrong define was being used when checking the I2C ISR status.
The wrong define just so happened to be the correct bit.
BUG=chrome-os-partner:30784
BRANCH=None
TEST=Built and ran on ryu.
Change-Id: I6c7aad34f5e7c7ace4db4442147023346b6285bc
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212163
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Seems like STM32_SPI_CR2_FRXTH from 5d208b99(STM32F0 SPI Fixes) was not enough
to "disable" RX FIFO from the F0 series. There were still a few bytes stuck in
the FIFO just after a command with a long sequence of 00 bytes.
This increases the dummy bytes read just before a DMA transfer to 4(size of the
FIFO).
BUG=none
BRANCH=none
TEST=Veyron with the new EC should survive the AP booting. ectool version will
work right away after boot. This change should not affect other STM32 chips
because reading dummy bytes from an empty register is essentially a NOP.
Change-Id: I812208622a75ecce82433eb6c12595fee3c1428b
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/212297
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Add back the test but only enable USB PD tasks for usb_pd test. This
should ensure that we do not break existing tests.
BUG=chrome-os-partner:31200,chromium:402335
TEST=make buildall
BRANCH=None
Change-Id: I4daa41a96a1067362b2c40a2a09fce733843bdff
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211923
Reviewed-by: Alec Berg <alecaberg@chromium.org>
After sending a message, we wait for up to 2.7 ms for reply. If we don't
get one, we retry for up to twice. Therefore, a undelivered message
could take up to >8ms. To prevent starving other tasks, let's yield to
other tasks on retries and rely on interrupt to wake us.
BUG=chrome-os-partner:28341
TEST=Plug in zinger on port 0 and C-to-A dongle on port 1. Check that
port 0 drops connection less frequently.
BRANCH=None
Change-Id: If85a70fd1140fef69d79243b198703ce601f8030
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211281
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Initial commit of usb_pd unit test. The test cases are very simple.
We'll add more test cases in similar format.
BUG=chrome-os-partner:31200
TEST=Pass usb_pd test
BRANCH=None
Change-Id: I9e3de5b2c032ee1d3670cde6d8227ce0378ae8a0
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211643
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
HAS_TASK_HOSTCMD is not a good indicator that we intend to use I2C Host Commands
On platforms such a veyron we use an STM32F0 with SPI HC for example however
i2c-stm32f0.c was very eager to still provide host commands via I2C.
If one wants to use I2C host commands they need to define
CONFIG_HOSTCMD_I2C_SLAVE_ADDR anyway, so the presence of that is a better
indicator.
The boards that want I2C host commands are ryu and samus_pd.
veyron/pinky needs SPI host commands, so this patch makes this case possible.
The rest of the boards that use STM32F0 do not have HAS_TASK_HOSTCMD set.
BUG=None
TEST=make buildall -j
BRANCH=None
Change-Id: Ia5561afdc6e72019c24c5c4b775944b2b88cb950
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211434
Reviewed-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
There is nothing chip-specific in the software CRC implementation. Let's
move it to common so that we can reuse it for other chips and unit
tests.
BUG=chrome-os-partner:31200
TEST=Define CONFIG_SW_CRC for host. Check crc.c compiles fine.
BRANCH=None
Change-Id: Icdc1d105c55c38ff07410cb5d733a31dbac53aea
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211494
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The STM32F0 has a fancier SPI than the L1 series we've been using so far.
Notably it supports 16 bit data packing. This mode is activated automatically
by reading/writing to the SPI_DR register as 16 bits. We do not want this
feature since we only do 8 bit operations. This change prevents a misalignment
of the data where the MCU thinks it's doing 16 bit transfers and we want 8 bit
transfers.
Another unwanted feature is the FIFO. We rely on DMA and some buffers instead.
Keeping the FIFO enabled causes extra characters. The way this patch disables
the fifo is by changing the FIFO reception threshold to only 1 byte (which is
the same behavior that L1 has with no FIFO). Setting the FRXTH bit on the L1
chips should not affect anything as that area of the register is reserved.
BUG=none
BRANCH=none
TEST=Try SPI on both STM32L1xx(preexisting support, should not be broken) and
STM32F0(new support/veyron)
Change-Id: I90dc6bb8a82881e70058443591acaebc44ba982b
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/211476
Reviewed-by: Doug Anderson <dianders@chromium.org>
Packets can be 128 bytes, and are preceded by a prefix byte. So we
need a 129-byte buffer, not a 128-byte buffer.
BUG=chrome-os-partner:30079
BRANCH=none
TEST=do pd software sync; see that 128-byte packets transfer correctly
Change-Id: Ic1e6cfec2c042537768d1cd0eecea509cc90c052
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/210502
Reviewed-by: Alec Berg <alecaberg@chromium.org>
When the EC sends longer commands to the PD chip (such as flash
erase/write over the passthru from AP), allow it to take a second
instead of the default 100ms timeout.
BUG=chrome-os-partner:30935
BRANCH=none
TEST=samus boots
battery command works from EC console
ectool passthru of flash erase to PD works (requires hacked ectool)
Change-Id: I08ff94f7ac6aee351aa73c9d28b5fd715d463b3a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209936
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Board bring up. GPIO / UART / timer / console / task / hook are
working now.
BRANCH=tot
BUG=none
TEST=run on evaluation board and see LED 0/1 are blinking.
Console commands are available to use.
Change-Id: If93a2c94b8abe1c2c931c03a7a12ddd2bed9d9f6
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209403
Reviewed-by: Vic Yang <victoryang@chromium.org>
The interrupt handler is hardcoded to I2C1. We should choose between
I2C1 and I2C2 based on I2C_PORT_EC.
BUG=chrome-os-partner:30707
TEST=On Ryu, ectool hello and see ACK.
BRANCH=None
Change-Id: I07055b0ee7459e6cac5585737e200ff2d5814a34
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209960
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
for interface specific requests, the interface number is equivalent to
(wIndex & 0xff). this corresponds to ep0_buf_rx[2], since the setup
packet has format: bmRequestType (1), bRequest (1), wValue (2),
wIndex (2), wLength (2).
BUG=none
BRANCH=none
TEST=verify stm32 does not panic with multiple interfaces
Change-Id: Ied7750035f87fa81f9a6c03c6e73ae606c110398
Signed-off-by: Dominic Chen <ddchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209903
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Adds dual USB-PD port support for samus. Both ports are in dual-role
and can perform either role.
Both ports work fine when only one of the ports is in use. But,
still having problems with PD errors on the lower priority port (port
0). If you have a charger plugged into port 0, and a type-C USB dongle
plugged into port 1, then port 1 has higher priority, and in the
SRC_DISCONNECTED state, every 1.5 seconds when it sends source cap
packet, we occasionally drop pings on port 0, which results in a
lot of start/stop charging.
BUG=chrome-os-partner:28585
BRANCH=none
TEST=Tested on samus to make sure both ports work when I
plug in a charger and a type-C USB dongle with a pull-down on the CC
line. Tested on plankton and zinger to make sure PD works as expected.
Change-Id: Ie7bde3e258f5cd23a0b82b626c0993a45b0df074
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200750
Reviewed-by: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
Increase RAM_SIZE for all stm32f07x chips to 16kB to use all of
on chip SRAM.
BUG=none
BRANCH=none
TEST=added 4000 byte array, verified in ec.RO.map that we are using
the new RAM space (bss size over 0x2000), loaded on samus and
verified that we could read and write to the 4000 byte array.
Change-Id: Ided3ce7c5fb353c9c37a01e6ed64f03786717e9b
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209847
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
Check for warm reboot before initializing ADC. Part of the initialization
process involves calibration of the ADC, which can only be done when the
ADC peripheral is disabled. This fixes a bug on samus_pd where jumping to
RW causes a watchdog because ADC reads hang.
BUG=chrome-os-partner:30079
BRANCH=none
TEST=on samus_pd, without this change running sysjump rw causes us to jump
to RW and then causes a watchdog. With this change sysjump rw works. Also
verified that PD communication works in RW, which means ADC channels are
being read correctly after jumping to RW.
Change-Id: Iaa41da4795c3d15a6db56b0d715e36c29417d9b6
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209331
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Only one EC was an i2c slave, samus_pd.
Now we have 2 more, ryu and ryu_sh (sensor hub).
Define a new variable: CONFIG_HOSTCMD_I2C_SLAVE_ADDR
TEST=Compiled
BRANCH=None
BUG=chrome-os-partner:30740
Change-Id: I484aaf5ca72f14a91ce261b91fbe600dca3474dc
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208978
Reviewed-by: Randall Spangler <rspangler@chromium.org>
We want repeated start instead of stop+start. Apparently, we need to set
START bit along with read configuration. Otherwise, the I2C module
generates a STOP condition.
BUG=None
TEST=Monitor I2C with a logic analyzer. See repeated start instead of
stop+start.
BRANCH=All using stm32f0.
Change-Id: I47491e240f2543e5d023e950d15468ec0e3c301b
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208760
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Previously these macros took a small integer to identify the USART
to access. This integer was token concatenated to form the macro
name that resolved to the base address. This made it imposible to
use these macros in a driver that could manage more than one USART
because there was no runtime way to go from base address (or other
unique identifier) to register address.
This change makes it possible to pass either a static compile time
known base address or a runtime variable with the base address,
thus supporting either sort of driver. The existing USART driver
has been updated to compute the base address of the console USART
and pass that at compile time, resulting in no increase in code
size.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=none
TEST=make buildall -j
Followed by manual testing of console over UART functionality
on the STM32F072 based discovery board.
Change-Id: I06547a173b1e5cf625a57019ea4b8a84d1768444
Reviewed-on: https://chromium-review.googlesource.com/208488
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Previously the F0 and L variants had almost identical driver files
and the F variant shared about half of its driver. This refactor
moves the shared code into gpio.c and gpio-f0-l.c, the latter
is for code shared between the F0 and L variants.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=none
TEST=make buildall -j
Followed by manual testing of interrupt on change and UART
functionality on STM32F0 based discovery board.
Change-Id: I920babd1861548272af2857c8bd3e4f9dac4985c
Reviewed-on: https://chromium-review.googlesource.com/207986
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Now that gpio_get_level() always returns actual pin states, we can
simplify i2c_raw_get_scl/sda().
BUG=chrome-os-partner:26483
TEST=make buildall
BRANCH=None
Change-Id: Ifefb6fa5da8f566b44c419a0ea5adec41f8925e3
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207057
Reviewed-by: Randall Spangler <rspangler@chromium.org>
For open-drain output pins, this would allow us to easily check pin
state without changing it to input.
BUG=chrome-os-partner:26483
TEST=Toggle output level and read it back.
BRANCH=None
Change-Id: Ia7ceb7a221a8f0cfec9b19a5c5baae4d5441150f
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207060
Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry-pick back to ToT)
If the AP de-asserts the SPI NSS pin while host command handler is
still processing the command, we would delay the Rx DMA setup later.
If this case happens, the pending result of handler will be dropped.
BUG=chrome-os-partner:28979
BRANCH=tot,nyan
TEST=build and play around on big.
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/204427
Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit 4be73492817f3f6c24ece75fed33eb956c0038b8)
Change-Id: Ie2a6550696760eadad3b0d6e3a4e56a2b29abdda
Original-Change-Id: I371a2a0b96b1ee0602be91338bd53d13f6abbd2e
Reviewed-on: https://chromium-review.googlesource.com/206922
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Yung-chieh Lo <yjlou@chromium.org>
Tested-by: Yung-chieh Lo <yjlou@chromium.org>
(cherry-pick back to ToT)
In setup_for_transaction(), read spi->dr into a dummy variable instead
of into in_msg[0]. Since in_msg[0] is an alias for a command's port number,
this will prevent a command's port number from being over-written if spi
transaction is terminated early while a command is still in progress.
BUG=chrome-os-partner:28979
BRANCH=nyan
TEST=passed factory_test.reboot2 test for >1000 cycles
Signed-off-by: Yen Lin <yelin@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/204355
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit 2b043665850f7c74cd6a4a7f24d7a18b01b378ac)
Change-Id: Ia412fadcd7621f45bbb096771615ce75fe445592
Oiginal-Change-Id: I308ea954d6242fce5b3a70a14660767ac88d8242
Reviewed-on: https://chromium-review.googlesource.com/206920
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Yung-chieh Lo <yjlou@chromium.org>
Tested-by: Yung-chieh Lo <yjlou@chromium.org>
Fix the beginning and end of BMC PD communication:
- Initial transmission within 1us of taking control of CC line
- CC line released between 1us and 23us after last edge
- If final bit is a 0, then add two 1 bits to the end
- No garbage after the final bit
BUG=chrome-os-partner:30132
BRANCH=none
TEST=tested with a fruitpie, samus, and zinger.
verified timing on scope.
Change-Id: Ie45695eb367a7554cf5d5b76b6fbdf1e3fc85d29
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/206453
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
These changes were made in files that did not have the [%T ... ]
pattern. These files were broken by the change because they still
contained uses of the CPRINTF macro. There were two options to fix
this, switch to the CPRINTS macro and get the timestamp added to
these strings, or switch those files back to defining the CPRINTF
macro. Switching back seems like the right thing since it doesn't
change the output of those debug messages.
This commit also adds newline termination to a few invocations of
CPRINTF that were missing it, but obviously wanted it.
This breakage is only visible with a particular set of CONFIG_
defines that no boards currently use.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=none
TEST=make buildall -j
Change-Id: I784b52dc385b29f05d7b9bc1521e37597409153b
Reviewed-on: https://chromium-review.googlesource.com/206281
Reviewed-by: Vic Yang <victoryang@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
When going into and waking from hibernation, we should keep CPU at high
clock frequency so that we can save and restore chip state faster. This
is especially true for the wake-up case as it affects AP boot time.
This CL keeps the CPU at 12MHz for saving state and clocks it up to
48MHz for restoring.
With this, the wake-up time (time from GPIO interrupt to completely
restoring chip state) reduces from 11ms to 0.85ms.
BUG=None
TEST=Measure wake-up time with logic analyzer
BRANCH=None
Change-Id: Ib470a3d38959247b082cc7a5fd2d889cdc2a15ca
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/206308
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The SPI init should run before we power up AP. Otherwise, the AP
would try to talk to EC before the EC SPI is ready. This could fail
the first SPI transcation.
BUG=chrome-os-partner:30083
BRANCH=Tot,nyan
TEST=build and run on Nyan only.
Change-Id: Ie40ba5210c49446c94c01d697aa66568730de83f
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/206181
Reviewed-by: Vic Yang <victoryang@chromium.org>
Save system states before hibernating and restore them after waking up.
This saves us from needing to reboot every time we wake up.
BUG=None
TEST=wake from hibernate. Check UART, ADC, and timer are working.
BRANCH=None
Change-Id: I044fb8a796e1560c0f748d766f4aeee4dda23342
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/205954
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
On MEC1322, we don't have indication of empty space in transmit FIFO. To
work around this, we needed to look at Tx FIFO empty bit instead. However,
this effectively made the FIFO length one. This CL fixes this by only
checking Tx FIFO empty bit every 16 characters written to Tx FIFO. This
is assuming the UART module works the same way as 16550 UART, which has
a 16-byte FIFO.
In a simple bulk write test, this improves Tx performance by 30%.
BUG=chrome-os-partner:24107
TEST=Build and boot. Check console still works.
BRANCH=None
Change-Id: I97a6f42bd11be6bb18bc339af6d9b0cf2bae4845
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/206160
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
