Re: [PATCH v2 5/9] hw/char: Initial commit of Ibex UART

[Philippe Mathieu-Daudé]

On 5/14/20 11:59 PM, Alistair Francis wrote:
On Thu, May 14, 2020 at 11:00 AM Philippe Mathieu-Daudé
<phi...@redhat.com> wrote:

Hi Alistair,

On 5/7/20 9:13 PM, Alistair Francis wrote:
This is the initial commit of the Ibex UART device. Serial TX is
working, while RX has been implemeneted but untested.

This is based on the documentation from:
https://docs.opentitan.org/hw/ip/uart/doc/

Signed-off-by: Alistair Francis <alistair.fran...@wdc.com>
---
   MAINTAINERS                 |   2 +
   hw/char/Makefile.objs       |   1 +
   hw/char/ibex_uart.c         | 490 ++++++++++++++++++++++++++++++++++++
   hw/riscv/Kconfig            |   4 +
   include/hw/char/ibex_uart.h | 110 ++++++++
   5 files changed, 607 insertions(+)
   create mode 100644 hw/char/ibex_uart.c
   create mode 100644 include/hw/char/ibex_uart.h

diff --git a/MAINTAINERS b/MAINTAINERS
index c3d77f0861..d3d47564ce 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1236,7 +1236,9 @@ M: Alistair Francis <alistair.fran...@wdc.com>
   L: qemu-ri...@nongnu.org
   S: Supported
   F: hw/riscv/opentitan.c
+F: hw/char/ibex_uart.c
   F: include/hw/riscv/opentitan.h
+F: include/hw/char/ibex_uart.h


   SH4 Machines
diff --git a/hw/char/Makefile.objs b/hw/char/Makefile.objs
index 9e9a6c1aff..633996be5b 100644
--- a/hw/char/Makefile.objs
+++ b/hw/char/Makefile.objs
@@ -12,6 +12,7 @@ common-obj-$(CONFIG_VIRTIO_SERIAL) += virtio-console.o
   common-obj-$(CONFIG_XILINX) += xilinx_uartlite.o
   common-obj-$(CONFIG_XEN) += xen_console.o
   common-obj-$(CONFIG_CADENCE) += cadence_uart.o
+common-obj-$(CONFIG_IBEX) += ibex_uart.o

   common-obj-$(CONFIG_EXYNOS4) += exynos4210_uart.o
   common-obj-$(CONFIG_COLDFIRE) += mcf_uart.o
diff --git a/hw/char/ibex_uart.c b/hw/char/ibex_uart.c
new file mode 100644
index 0000000000..f6215ae23d
--- /dev/null
+++ b/hw/char/ibex_uart.c
@@ -0,0 +1,490 @@
+/*
+ * QEMU lowRISC Ibex UART device
+ *
+ * Copyright (c) 2020 Western Digital
+ *
+ * For details check the documentation here:
+ *    https://docs.opentitan.org/hw/ip/uart/doc/
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include "qemu/osdep.h"
+#include "hw/char/ibex_uart.h"
+#include "hw/irq.h"
+#include "hw/qdev-properties.h"
+#include "migration/vmstate.h"
+#include "qemu/log.h"
+#include "qemu/module.h"
+
+static void ibex_uart_update_irqs(IbexUartState *s)
+{
+    if (s->uart_intr_state & s->uart_intr_enable & INTR_STATE_TX_WATERMARK) {
+        qemu_set_irq(s->tx_watermark, 1);
+    } else {
+        qemu_set_irq(s->tx_watermark, 0);
+    }
+
+    if (s->uart_intr_state & s->uart_intr_enable & INTR_STATE_RX_WATERMARK) {
+        qemu_set_irq(s->rx_watermark, 1);
+    } else {
+        qemu_set_irq(s->rx_watermark, 0);

I wonder if having both bit separate can't lead to odd pulse behavior
(this function should have the same result if you invert the RX/TX
processing here). I'd be safer using a local 'raise_watermark' boolean
variable, then call qemu_set_irq() once.

I'm not sure what you mean. Are you worried that TX and RX will both
go high/low at the same time?

Disregard my comment, it was late and I misread that rx/tx are different 
outgoing IRQs (I read this as a single watermark IRQ).


Alistair


+    }
+
+    if (s->uart_intr_state & s->uart_intr_enable & INTR_STATE_TX_EMPTY) {
+        qemu_set_irq(s->tx_empty, 1);
+    } else {
+        qemu_set_irq(s->tx_empty, 0);
+    }
+
+    if (s->uart_intr_state & s->uart_intr_enable & INTR_STATE_RX_OVERFLOW) {
+        qemu_set_irq(s->rx_overflow, 1);
+    } else {
+        qemu_set_irq(s->rx_overflow, 0);
+    }
+}
[...]