Re: [PATCH v3 6/8] serial: Add Tegra Combined UART driver

From: Mikko Perttunen
Date: Mon Jul 02 2018 - 09:30:28 EST

On 02.07.2018 16:18, Thierry Reding wrote:
On Mon, Jul 02, 2018 at 02:40:31PM +0300, Mikko Perttunen wrote:
The Tegra Combined UART (TCU) is a mailbox-based mechanism that allows
multiplexing multiple "virtual UARTs" into a single hardware serial
port. The TCU is the primary serial port on Tegra194 devices.

Add a TCU driver utilizing the mailbox framework, as the used mailboxes
are part of Tegra HSP blocks that are already controlled by the Tegra
HSP mailbox driver.

Signed-off-by: Mikko Perttunen <mperttunen@xxxxxxxxxx>

- Removed (void) casts for unused variables.
- Changed the uart_set_options() call to be on one line, even if its
over 80 characters.
- Added defines for magic numbers.
- Style fixes.
- Changed Kconfig entry to depend on the Tegra HSP driver instead of
just the mailbox framework.
- Removed FLUSH bit, as it's unnecessary and slows down printing
- Removed call to uart_set_options
- Added mbox_free_channel calls to remove()

drivers/tty/serial/Kconfig | 9 ++
drivers/tty/serial/Makefile | 1 +
drivers/tty/serial/tegra-tcu.c | 291 +++++++++++++++++++++++++++++++++++++++
include/uapi/linux/serial_core.h | 3 +
4 files changed, 304 insertions(+)
create mode 100644 drivers/tty/serial/tegra-tcu.c

The driver looks good to me. But for my own understanding, is there some
way we can make use of the multiplexing? That is, could we add a
mechanism to have the driver filter out only a specific stream? Could we
also specify which stream to send data back to? What happens by default?
Which stream is data sent to?

There is no multiplexing on the producer/device side (i.e. what this driver does). The mailbox specified in device tree specifies the stream we send stuff to. The mailboxes are per-CPU (we use the CCPLEX mailbox here), so it cannot really be changed.

The consumer then sees the multiplexing in that it can receive from and transmit to all of the various CPUs in the system at the same time. AIUI there is also a secondary form of multiplexing where the outputs of different VMs can be multiplexed by the hypervisor, but I'm not very familiar with that.