g: speed up CCD UART processing

AP and EC consoles may generate a lot of bursty traffic, and cr50 UART
console to USB processing is very slow: when characters become
available, a hooks task callback is invoked, which retrieves received
characters one at a time and queues them up to the appropriate USB
transmit queue.

This patch speeds up things as follows:

  - increases the seize of USB transmit queues for AP and EC console
    channels to 512 bytes. Experiments supported by code
    instrumentation has shown that even this is not enough to avoid
    underruns, but this is a good compromise between memory use and
    performance, these sizes could be revisited later,

  - moving bytes from UART TX FIFO to USB queue happens on the
    interrupt context when UART TX interrupt is asserted

  - as many characters as possible are read from the UART first,
    before queuing function is called, and the entire received batch
    is passed to the queuing function.

    It has to be mentioned here that presently batch processing is not
    necessarily much more efficient, because queuing function becomes
    more complicated when multiple objects are passed to it, this will
    have to be dealt with in a separate patch.

There is still a lot of room for improvement:

   - functions used to queue up data are very generic, dedicated code
     could help a lot.

   - UART drivers should have methods for collecting all bytes
     available in receive FIFO in one invocation,

   - USB side of things (dequeuing data and passing it to the
     controller).

BRANCH=cr50, cr50mp
BUG=b:38448364, b:111701874

TEST=ran 'chargen' application on both AP and EC to flood the console
     channels and observed the flow of characters on the host site, it
     is pretty smooth with occasional hiccups, especially when TPM is
     active, before this patch it was impossible to have both stream
     up, both were garbled.

  -  Verified that new account can be created and user logged in on
     restarts while chargen is running, i.e. TPM task gets enough
     processing bandwidth.

  -  When EC is reset, there seem to be no lost characters on the
     console (it used to cause some garbled console output before this
     patch). The below output was collected on Coral:

  > reboot
  Rebooting!

  --- UART initialized after reboot ---
  [Reset cause: soft]
  [Image: RO, coral_v1.1.8363+2cc945d5a 2018-05-15 17:41:57 ...
  [0.003605 init buttons]
  [0.003826 Inits done]
  [0.004094 tablet mode disabled
  ]
  [0.008272 found batt:SMP]
  [0.022278 SW 0x01]
  [0.042247 hash start 0x00040000 0x00021994]
  [0.045823 Battery FET: reg 0x0018 mask 0x0018 disc 0x0000]
  [0.071136 kblight registered]
  [0.071544 PB init-on]
  [0.071818 USB charge p0 m0]
  [0.073670 ID/SKU ADC 4 = 1309 mV]
  [0.075630 ID/SKU ADC 3 = 852 mV]
  [0.076077 SKU ID: 71]
  [0.076335 Motion Sensor Count = 3]
  [0.083594 PD comm enabled]
  ...

  - did not test bitbang programming mode, it is in line for
    reworking for speeding up as well.

  - 15 iterations invocation of firmware_Cr50DevMode passes
    successfully on BoB

Change-Id: I5883012896e78951908db8fe7c1c5d92ea6cda63
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1148655
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>

1 files changed, 10 insertions, 3 deletions

diff --git a/board/cr50/board.c b/board/cr50/board.c
index 158b94b731..e92dd1f62c 100644
--- a/board/cr50/board.c
+++ b/board/cr50/board.c
@@ -32,6 +32,7 @@
 #include "trng.h"
 #include "uart_bitbang.h"
 #include "uartn.h"
+#include "usart.h"
 #include "usb_descriptor.h"
 #include "usb_hid.h"
 #include "usb_i2c.h"
@@ -103,12 +104,18 @@ struct uart_bitbang_properties bitbang_config = {
 	.rx_pinmux_regval = GC_PINMUX_GPIO1_GPIO4_SEL,
 };
 
-extern struct deferred_data ec_uart_deferred__data;
 void ec_tx_cr50_rx(enum gpio_signal signal)
 {
 	uart_bitbang_receive_char(UART_EC);
-	/* Let the USART module know that there's new bits to consume. */
-	hook_call_deferred(&ec_uart_deferred__data, 0);
+	/*
+	 * Let the USART module know that there's new bits to consume.
+	 *
+	 * When programming the EC in bitbang mode the rest of the system is
+	 * shut down, there not much else to do, so this could be processed
+	 * directly on interrupt context the same way it is done with EC
+	 * console output.
+	 */
+	send_data_to_usb(&ec_uart);
 }
 
 const char *device_state_names[] = {