The serial driver hangs in cases when FIFO has more than single word to be
processed. Easiest way to reproduce is to paste a string of greater than 4
characters in cli.
Clearing the RXSTALE interrupt without draining all the characters from FIFO
leads to the issue as the driver is dependent on msm_boot_uart_dm_read
function to reinitialize for next transfer.
Logically the driver is organized in such a manner that next transfer never
gets initiated till rx_data_read < total_rx_data. Clearing the RXSTALE without
consideration of total number of characters (or words) unprocessed makes the
msm_boot_uart_dm_read to return on the first if conditional. Thus the driver is
stuck forever.
A quick fix is to avoid clearing the stale interrupt. Reset is handled whenever
a new transfer is initialized in msm_boot_uart_dm_init_rx_transfer.
BUG=chrome-os-partner:29542
TEST=manual
-Paste a string greater than 4 characters in cli.
Change-Id: I016afb01a77cd14764f0176f6bf144fb29796c2f
Signed-off-by: Yogesh Lal <ylal@codeaurora.org>
Reviewed-on: https://chromium-review.googlesource.com/209512
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Add support board veyron:
1)Support driver rktimer
2)Support driver rkserial
3)Support config.veyron
BUG=chrome-os-partner:29778
TEST=emerge-veyron libpayload
Change-Id: I2cccedf3b62883dd372842a7972e93f2ebbfb282
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/206184
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
This adds a UART driver for the ipq8064 controller. It still does not
quite work in the receive direction - the receive FIFO returns read
data in 32 bit chunks, which means that 4 keys need to be pressed
before a character pops out of the driver (and it reports it as a
single character).
This issue is being addressed separately, the driver is being checked
in to facilitate concurrent development.
BUG=chrome-os-partner:27784, chrome-os-partner:29313
TEST=with deptcharge modifications in place, the AP148 board comes up
to the depthcharge prompt:
Starting depthcharge on storm...
storm:
Change-Id: Ief2cfcca73494be5c4147881144470078adcefb8
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202045
Reviewed-by: Deepa Dinamani <deepad@codeaurora.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
The console output driver framework in libpayload is currently built on
the putchar primitive, meaning that every driver's function gets called
one character at a time. This becomes an issue when we add drivers that
could output multiple characters at a time, but have a high constant
overhead per invocation (such as the planned GDB stub, which needs to
wrap a special frame around output strings and wait for an
acknowledgement from the server).
This patch adds a new 'write' function pointer to the
console_output_driver structure as an alternative to 'putchar'. Output
drivers need to provide at least one of the two ('write' is preferred if
available). The CBMEM console driver is ported as a proof of concept
(since it's our most performace-critical driver and should in theory
benefit the most from less function pointer invocations, although it's
probably still negligible compared to the big sprawling mess that is
printf()).
Even with this fix, the problem remains that printf() was written with
the putchar primitive in mind. Even though normal text already contains
an optimization to allow multiple characters at a time, almost all
formatting directives cause their output (including things like
padding whitespace) to be putchar()ed one character at a time.
Therefore, this patch reworks parts of the output code (especially
number printing) to all but remove that inefficiency (directives still
invoke an extra write() call, but at least not one per character). Since
I'm touching printf() core code anyway, I also tried to salvage what I
could from that weird, broken "return negative on error" code path (not
that any of our current output drivers can trigger it anyway).
A final consequence of this patch is that the responsibility to prepend
line feeds with carriage returns is moved into the output driver
implementations. Doing this only makes sense for drivers with explicit
cursor position control (i.e. serial or video), and things like the
CBMEM console that appears like a normal file to the system really have
no business containing carriage returns (we don't want people to
accidentally associate us with Windows, now, do we?).
BUG=chrome-os-partner:18390
TEST=Made sure video and CBMEM console still look good, tried printf()
with as many weird edge-case strings as I could find and compared serial
output as well as sprintf() return value.
Change-Id: Ie05ae489332a0103461620f5348774b6d4afd91a
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196384
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
These drivers need to be ready right away and never really fit into the
depthcharge driver model anyway.
CQ-DEPEND=CL:194063
BUG=None
TEST=Built and booted on nyan and peach_pit. Built for nyan_big, nyan_blaze,
and daisy.
BRANCH=None
Change-Id: I9570dee53c57d42ef4cd956f66a878ce39a2dc20
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/194057
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
