This series adds Bouffalolab uart driver and basic devicetrees for
Bouffalolab bl808 SoC and Sipeed M1s dock board.
Since v3:
- fix build error reported by [email protected]
- fix earlycon compatible string
- fix dtbs_check
- collect Reviewed-by tag
Since v2:
- fix dt_binding_check and dtbs_check warnings
- use uart_port_tx_limited() helper in uart driver
- collect Acked-by/Reviewed-by tag
- uart0 -> uart3
- update "riscv,ndev" property
- mv vendor prefix binding as the first patch
- add compatible string for bouffalolab bl808 plic
Since v1:
- use FIELD_PREP and FIELD_GET macro
- rewrite bflb_uart_tx_chars()
- add vendor prefix for bouffalolab
- add dt binding for bl808 compatibles
- enable SOC_BOUFFALOLAB in defconfig
- collect Reviewed-by tag
- modify commit-msg as suggested
Jisheng Zhang (10):
dt-bindings: vendor-prefixes: add bouffalolab
dt-bindings: interrupt-controller: Add bouffalolab bl808 plic
dt-bindings: serial: add documentation for Bouffalolab UART Driver
serial: bflb_uart: add Bouffalolab UART Driver
riscv: add the Bouffalolab SoC family Kconfig option
dt-bindings: riscv: Add bouffalolab bl808 board compatibles
riscv: dts: bouffalolab: add the bl808 SoC base device tree
riscv: dts: bouffalolab: add Sipeed M1s SoM and Dock devicetree
MAINTAINERS: riscv: add entry for Bouffalolab SoC
riscv: defconfig: enable BOUFFALOLAB SoC
.../sifive,plic-1.0.0.yaml | 1 +
.../bindings/riscv/bouffalolab.yaml | 29 +
.../serial/bouffalolab,bl808-uart.yaml | 47 ++
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
MAINTAINERS | 7 +
arch/riscv/Kconfig.socs | 5 +
arch/riscv/boot/dts/Makefile | 1 +
arch/riscv/boot/dts/bouffalolab/Makefile | 2 +
.../dts/bouffalolab/bl808-sipeed-m1s-dock.dts | 25 +
.../dts/bouffalolab/bl808-sipeed-m1s.dtsi | 21 +
arch/riscv/boot/dts/bouffalolab/bl808.dtsi | 73 +++
arch/riscv/configs/defconfig | 1 +
drivers/tty/serial/Kconfig | 18 +
drivers/tty/serial/Makefile | 1 +
drivers/tty/serial/bflb_uart.c | 586 ++++++++++++++++++
include/uapi/linux/serial_core.h | 3 +
16 files changed, 822 insertions(+)
create mode 100644 Documentation/devicetree/bindings/riscv/bouffalolab.yaml
create mode 100644 Documentation/devicetree/bindings/serial/bouffalolab,bl808-uart.yaml
create mode 100644 arch/riscv/boot/dts/bouffalolab/Makefile
create mode 100644 arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s-dock.dts
create mode 100644 arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s.dtsi
create mode 100644 arch/riscv/boot/dts/bouffalolab/bl808.dtsi
create mode 100644 drivers/tty/serial/bflb_uart.c
--
2.40.0
Several SoMs and boards are available that feature the Bouffalolab
bl808 SoC. Document the compatible strings.
Signed-off-by: Jisheng Zhang <[email protected]>
Acked-by: Palmer Dabbelt <[email protected]>
Reviewed-by: Conor Dooley <[email protected]>
---
.../bindings/riscv/bouffalolab.yaml | 29 +++++++++++++++++++
1 file changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/riscv/bouffalolab.yaml
diff --git a/Documentation/devicetree/bindings/riscv/bouffalolab.yaml b/Documentation/devicetree/bindings/riscv/bouffalolab.yaml
new file mode 100644
index 000000000000..3b25d1a5d04a
--- /dev/null
+++ b/Documentation/devicetree/bindings/riscv/bouffalolab.yaml
@@ -0,0 +1,29 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/riscv/bouffalolab.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bouffalo Lab Technology SoC-based boards
+
+maintainers:
+ - Jisheng Zhang <[email protected]>
+
+description:
+ Bouffalo Lab Technology SoC-based boards
+
+properties:
+ $nodename:
+ const: '/'
+ compatible:
+ oneOf:
+ - description: Carrier boards for the Sipeed M1s SoM
+ items:
+ - enum:
+ - sipeed,m1s-dock
+ - const: sipeed,m1s
+ - const: bouffalolab,bl808
+
+additionalProperties: true
+
+...
--
2.40.0
Add Jisheng Zhang as Bouffalolab SoC maintainer.
Signed-off-by: Jisheng Zhang <[email protected]>
Reviewed-by: Conor Dooley <[email protected]>
Acked-by: Palmer Dabbelt <[email protected]>
---
MAINTAINERS | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index e0ad886d3163..0ae136f2656f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -18115,6 +18115,13 @@ F: arch/riscv/
N: riscv
K: riscv
+RISC-V BOUFFALOLAB SOC SUPPORT
+M: Jisheng Zhang <[email protected]>
+L: [email protected]
+S: Maintained
+F: arch/riscv/boot/dts/bouffalolab/
+F: drivers/tty/serial/bflb_uart.c
+
RISC-V MICROCHIP FPGA SUPPORT
M: Conor Dooley <[email protected]>
M: Daire McNamara <[email protected]>
--
2.40.0
Add a baisc dtsi for the bouffalolab bl808 SoC.
Signed-off-by: Jisheng Zhang <[email protected]>
Acked-by: Palmer Dabbelt <[email protected]>
---
arch/riscv/boot/dts/bouffalolab/bl808.dtsi | 73 ++++++++++++++++++++++
1 file changed, 73 insertions(+)
create mode 100644 arch/riscv/boot/dts/bouffalolab/bl808.dtsi
diff --git a/arch/riscv/boot/dts/bouffalolab/bl808.dtsi b/arch/riscv/boot/dts/bouffalolab/bl808.dtsi
new file mode 100644
index 000000000000..87906fe51db5
--- /dev/null
+++ b/arch/riscv/boot/dts/bouffalolab/bl808.dtsi
@@ -0,0 +1,73 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+/*
+ * Copyright (C) 2022 Jisheng Zhang <[email protected]>
+ */
+
+#include <dt-bindings/interrupt-controller/irq.h>
+
+/ {
+ compatible = "bouffalolab,bl808";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ timebase-frequency = <1000000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ compatible = "thead,c906", "riscv";
+ device_type = "cpu";
+ reg = <0>;
+ d-cache-block-size = <64>;
+ d-cache-sets = <256>;
+ d-cache-size = <32768>;
+ i-cache-block-size = <64>;
+ i-cache-sets = <128>;
+ i-cache-size = <32768>;
+ mmu-type = "riscv,sv39";
+ riscv,isa = "rv64imafdc";
+
+ cpu0_intc: interrupt-controller {
+ compatible = "riscv,cpu-intc";
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ };
+ };
+ };
+
+ xtal: xtal-clk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ /* This value must be overridden by the board */
+ clock-frequency = <0>;
+ };
+
+ soc {
+ compatible = "simple-bus";
+ ranges;
+ interrupt-parent = <&plic>;
+ dma-noncoherent;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ uart3: serial@30002000 {
+ compatible = "bouffalolab,bl808-uart";
+ reg = <0x30002000 0x1000>;
+ interrupts = <20 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&xtal>;
+ status = "disabled";
+ };
+
+ plic: interrupt-controller@e0000000 {
+ compatible = "bouffalolab,bl808-plic", "thead,c900-plic";
+ reg = <0xe0000000 0x4000000>;
+ interrupts-extended = <&cpu0_intc 11>, <&cpu0_intc 9>;
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ riscv,ndev = <82>;
+ };
+ };
+};
--
2.40.0
Enable BOUFFALOLAB soc config in defconfig to allow the default
upstream kernel to boot on Sipeed M1s Dock board.
Signed-off-by: Jisheng Zhang <[email protected]>
Reviewed-by: Conor Dooley <[email protected]>
Acked-by: Palmer Dabbelt <[email protected]>
---
arch/riscv/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig
index d98d6e90b2b8..e8d77b55ce86 100644
--- a/arch/riscv/configs/defconfig
+++ b/arch/riscv/configs/defconfig
@@ -26,6 +26,7 @@ CONFIG_EXPERT=y
# CONFIG_SYSFS_SYSCALL is not set
CONFIG_PROFILING=y
CONFIG_SOC_MICROCHIP_POLARFIRE=y
+CONFIG_ARCH_BOUFFALOLAB=y
CONFIG_ARCH_RENESAS=y
CONFIG_SOC_SIFIVE=y
CONFIG_SOC_STARFIVE=y
--
2.40.0
Add the driver for Bouffalolab UART IP which is found in Bouffalolab
SoCs such as bl808.
UART driver probe will create path named "/dev/ttySx".
Signed-off-by: Jisheng Zhang <[email protected]>
---
drivers/tty/serial/Kconfig | 18 +
drivers/tty/serial/Makefile | 1 +
drivers/tty/serial/bflb_uart.c | 586 +++++++++++++++++++++++++++++++
include/uapi/linux/serial_core.h | 3 +
4 files changed, 608 insertions(+)
create mode 100644 drivers/tty/serial/bflb_uart.c
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 398e5aac2e77..abc30a0713f5 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -179,6 +179,24 @@ config SERIAL_ATMEL_TTYAT
Say Y if you have an external 8250/16C550 UART. If unsure, say N.
+config SERIAL_BFLB
+ tristate "Bouffalolab serial port support"
+ select SERIAL_CORE
+ depends on COMMON_CLK
+ help
+ This enables the driver for the Bouffalolab's serial.
+
+config SERIAL_BFLB_CONSOLE
+ bool "Support for console on Bouffalolab serial port"
+ depends on SERIAL_BFLB=y
+ select SERIAL_CORE_CONSOLE
+ select SERIAL_EARLYCON
+ help
+ Say Y here if you wish to use a Bouffalolab UART as the
+ system console (the system console is the device which
+ receives all kernel messages and warnings and which allows
+ logins in single user mode) as /dev/ttySn.
+
config SERIAL_KGDB_NMI
bool "Serial console over KGDB NMI debugger port"
depends on KGDB_SERIAL_CONSOLE
diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
index cd9afd9e3018..5788a708d327 100644
--- a/drivers/tty/serial/Makefile
+++ b/drivers/tty/serial/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_SERIAL_8250) += 8250/
obj-$(CONFIG_SERIAL_AMBA_PL010) += amba-pl010.o
obj-$(CONFIG_SERIAL_AMBA_PL011) += amba-pl011.o
+obj-$(CONFIG_SERIAL_BFLB) += bflb_uart.o
obj-$(CONFIG_SERIAL_CLPS711X) += clps711x.o
obj-$(CONFIG_SERIAL_PXA_NON8250) += pxa.o
obj-$(CONFIG_SERIAL_SA1100) += sa1100.o
diff --git a/drivers/tty/serial/bflb_uart.c b/drivers/tty/serial/bflb_uart.c
new file mode 100644
index 000000000000..3f80bba8599a
--- /dev/null
+++ b/drivers/tty/serial/bflb_uart.c
@@ -0,0 +1,586 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Based on bflb_uart.c, by Bouffalolab team
+ *
+ * Copyright (C) 2022 Jisheng Zhang <[email protected]>
+ */
+
+#include <linux/bitfield.h>
+#include <linux/clk.h>
+#include <linux/console.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/serial.h>
+#include <linux/serial_core.h>
+#include <linux/tty.h>
+#include <linux/tty_flip.h>
+
+#define UART_UTX_CONFIG 0x00
+#define UART_CR_UTX_EN BIT(0)
+#define UART_CR_UTX_CTS_EN BIT(1)
+#define UART_CR_UTX_FRM_EN BIT(2)
+#define UART_CR_UTX_PRT_EN BIT(4)
+#define UART_CR_UTX_PRT_SEL BIT(5)
+#define UART_CR_UTX_BIT_CNT_D_MSK GENMASK(10, 8)
+#define UART_CR_UTX_BIT_CNT_P_MSK GENMASK(12, 11)
+#define UART_URX_CONFIG 0x04
+#define UART_CR_URX_EN BIT(0)
+#define UART_CR_URX_PRT_EN BIT(4)
+#define UART_CR_URX_PRT_SEL BIT(5)
+#define UART_CR_URX_BIT_CNT_D_MSK GENMASK(10, 8)
+#define UART_BIT_PRD 0x08
+#define UART_CR_UTX_BIT_PRD_MSK GENMASK(15, 0)
+#define UART_CR_URX_BIT_PRD_MSK GENMASK(31, 16)
+#define UART_DATA_CONFIG 0x0c
+#define UART_CR_UART_BIT_INV BIT(0)
+#define UART_URX_RTO_TIMER 0x18
+#define UART_CR_URX_RTO_VALUE_MSK GENMASK(7, 0)
+#define UART_SW_MODE 0x1c
+#define UART_INT_STS 0x20
+#define UART_UTX_END_INT BIT(0)
+#define UART_URX_END_INT BIT(1)
+#define UART_UTX_FIFO_INT BIT(2)
+#define UART_URX_FIFO_INT BIT(3)
+#define UART_URX_RTO_INT BIT(4)
+#define UART_URX_PCE_INT BIT(5)
+#define UART_UTX_FER_INT BIT(6)
+#define UART_URX_FER_INT BIT(7)
+#define UART_URX_LSE_INT BIT(8)
+#define UART_INT_MASK 0x24
+#define UART_INT_CLEAR 0x28
+#define UART_INT_EN 0x2c
+#define UART_STATUS 0x30
+#define UART_STS_UTX_BUS_BUSY BIT(0)
+#define UART_FIFO_CONFIG_0 0x80
+#define UART_DMA_TX_EN BIT(0)
+#define UART_DMA_RX_EN BIT(1)
+#define UART_TX_FIFO_CLR BIT(2)
+#define UART_RX_FIFO_CLR BIT(3)
+#define UART_TX_FIFO_OVERFLOW BIT(4)
+#define UART_TX_FIFO_UNDERFLOW BIT(5)
+#define UART_RX_FIFO_OVERFLOW BIT(6)
+#define UART_RX_FIFO_UNDERFLOW BIT(7)
+#define UART_FIFO_CONFIG_1 0x84
+#define UART_TX_FIFO_CNT_MSK GENMASK(5, 0)
+#define UART_RX_FIFO_CNT_MSK GENMASK(13, 8)
+#define UART_TX_FIFO_TH_MSK GENMASK(20, 16)
+#define UART_RX_FIFO_TH_MSK GENMASK(28, 24)
+#define UART_FIFO_WDATA 0x88
+#define UART_FIFO_RDATA 0x8c
+#define UART_FIFO_RDATA_MSK GENMASK(7, 0)
+
+#define BFLB_UART_MAXPORTS 8
+#define BFLB_UART_BAUD 2000000
+#define BFLB_UART_RX_FIFO_TH 7
+#define BFLB_UART_TX_FIFO_TH 15
+#define BFLB_UART_URX_RTO_TIME 0x4f
+
+struct bflb_uart_port {
+ struct uart_port port;
+ struct clk *clk;
+};
+
+static struct bflb_uart_port *bflb_uart_ports[BFLB_UART_MAXPORTS];
+
+static inline u32 rdl(struct uart_port *port, u32 reg)
+{
+ return readl_relaxed(port->membase + reg);
+}
+
+static inline void wrl(struct uart_port *port, u32 reg, u32 value)
+{
+ writel_relaxed(value, port->membase + reg);
+}
+
+static inline void wrb(struct uart_port *port, u32 reg, u8 value)
+{
+ writeb_relaxed(value, port->membase + reg);
+}
+
+static unsigned int bflb_uart_tx_empty(struct uart_port *port)
+{
+ return (rdl(port, UART_FIFO_CONFIG_1) & UART_TX_FIFO_CNT_MSK) ? TIOCSER_TEMT : 0;
+}
+
+static unsigned int bflb_uart_get_mctrl(struct uart_port *port)
+{
+ return TIOCM_CAR | TIOCM_DSR | TIOCM_CTS;
+}
+
+static void bflb_uart_set_mctrl(struct uart_port *port, unsigned int sigs)
+{
+}
+
+static void bflb_uart_start_tx(struct uart_port *port)
+{
+ u32 val;
+
+ val = rdl(port, UART_UTX_CONFIG);
+ val |= UART_CR_UTX_EN;
+ wrl(port, UART_UTX_CONFIG, val);
+
+ val = rdl(port, UART_FIFO_CONFIG_1);
+ val &= ~UART_TX_FIFO_TH_MSK;
+ val |= FIELD_PREP(UART_TX_FIFO_TH_MSK, BFLB_UART_TX_FIFO_TH);
+ wrl(port, UART_FIFO_CONFIG_1, val);
+
+ val = rdl(port, UART_INT_MASK);
+ val &= ~UART_UTX_FIFO_INT;
+ wrl(port, UART_INT_MASK, val);
+}
+
+static void bflb_uart_stop_tx(struct uart_port *port)
+{
+ u32 val;
+
+ val = rdl(port, UART_INT_MASK);
+ val |= UART_UTX_FIFO_INT;
+ wrl(port, UART_INT_MASK, val);
+}
+
+static void bflb_uart_stop_rx(struct uart_port *port)
+{
+ u32 val;
+
+ val = rdl(port, UART_URX_CONFIG);
+ val &= ~UART_CR_URX_EN;
+ wrl(port, UART_URX_CONFIG, val);
+
+ val = rdl(port, UART_INT_MASK);
+ val |= UART_URX_FIFO_INT | UART_URX_RTO_INT | UART_URX_FER_INT;
+ wrl(port, UART_INT_MASK, val);
+}
+
+static void bflb_uart_set_termios(struct uart_port *port,
+ struct ktermios *termios,
+ const struct ktermios *old)
+{
+ unsigned long flags;
+ u32 valt, valr, val;
+ unsigned int baud, min;
+
+ spin_lock_irqsave(&port->lock, flags);
+
+ /* set data length */
+ val = tty_get_char_size(termios->c_cflag) - 1;
+ valt = FIELD_PREP(UART_CR_UTX_BIT_CNT_D_MSK, val);
+
+ /* calculate parity */
+ termios->c_cflag &= ~CMSPAR; /* no support mark/space */
+ if (termios->c_cflag & PARENB) {
+ valt |= UART_CR_UTX_PRT_EN;
+ if (termios->c_cflag & PARODD)
+ valt |= UART_CR_UTX_PRT_SEL;
+ }
+
+ valr = valt;
+
+ /* calculate stop bits */
+ if (termios->c_cflag & CSTOPB)
+ val = 2;
+ else
+ val = 1;
+ valt |= FIELD_PREP(UART_CR_UTX_BIT_CNT_P_MSK, val);
+
+ /* flow control */
+ if (termios->c_cflag & CRTSCTS)
+ valt |= UART_CR_UTX_CTS_EN;
+
+ /* enable TX freerunning mode */
+ valt |= UART_CR_UTX_FRM_EN;
+
+ valt |= UART_CR_UTX_EN;
+ valr |= UART_CR_URX_EN;
+
+ wrl(port, UART_UTX_CONFIG, valt);
+ wrl(port, UART_URX_CONFIG, valr);
+
+ min = port->uartclk / (UART_CR_UTX_BIT_PRD_MSK + 1);
+ baud = uart_get_baud_rate(port, termios, old, min, 4000000);
+
+ val = DIV_ROUND_CLOSEST(port->uartclk, baud) - 1;
+ val = FIELD_PREP(UART_CR_UTX_BIT_PRD_MSK, val);
+ val |= FIELD_PREP(UART_CR_URX_BIT_PRD_MSK, val);
+ wrl(port, UART_BIT_PRD, val);
+
+ uart_update_timeout(port, termios->c_cflag, baud);
+
+ spin_unlock_irqrestore(&port->lock, flags);
+}
+
+static void bflb_uart_rx_chars(struct uart_port *port)
+{
+ u8 ch;
+
+ while (rdl(port, UART_FIFO_CONFIG_1) & UART_RX_FIFO_CNT_MSK) {
+ ch = FIELD_GET(UART_FIFO_RDATA_MSK, rdl(port, UART_FIFO_RDATA));
+ port->icount.rx++;
+
+ if (uart_handle_sysrq_char(port, ch))
+ continue;
+ uart_insert_char(port, 0, 0, ch, TTY_NORMAL);
+ }
+
+ spin_unlock(&port->lock);
+ tty_flip_buffer_push(&port->state->port);
+ spin_lock(&port->lock);
+}
+
+static void bflb_uart_tx_chars(struct uart_port *port)
+{
+ u8 ch;
+
+ uart_port_tx_limited(port, ch, BFLB_UART_TX_FIFO_TH,
+ true,
+ wrl(port, UART_FIFO_WDATA, ch),
+ ({}));
+}
+
+static irqreturn_t bflb_uart_interrupt(int irq, void *data)
+{
+ struct uart_port *port = data;
+ u32 isr, val;
+
+ isr = rdl(port, UART_INT_STS);
+ wrl(port, UART_INT_CLEAR, isr);
+
+ spin_lock(&port->lock);
+
+ if (isr & UART_URX_FER_INT) {
+ /* RX FIFO error interrupt */
+ val = rdl(port, UART_FIFO_CONFIG_0);
+ if (val & UART_RX_FIFO_OVERFLOW)
+ port->icount.overrun++;
+
+ val |= UART_RX_FIFO_CLR;
+ wrl(port, UART_FIFO_CONFIG_0, val);
+ }
+
+ if (isr & (UART_URX_FIFO_INT | UART_URX_RTO_INT))
+ bflb_uart_rx_chars(port);
+
+ if (isr & UART_UTX_FIFO_INT)
+ bflb_uart_tx_chars(port);
+
+ spin_unlock(&port->lock);
+
+ return IRQ_RETVAL(isr);
+}
+
+static void bflb_uart_config_port(struct uart_port *port, int flags)
+{
+ port->type = PORT_BFLB;
+}
+
+static int bflb_uart_startup(struct uart_port *port)
+{
+ unsigned long flags;
+ int ret;
+ u32 val;
+
+ ret = devm_request_irq(port->dev, port->irq, bflb_uart_interrupt,
+ IRQF_SHARED, port->name, port);
+ if (ret) {
+ dev_err(port->dev, "fail to request serial irq %d, ret=%d\n",
+ port->irq, ret);
+ return ret;
+ }
+
+ spin_lock_irqsave(&port->lock, flags);
+
+ wrl(port, UART_INT_MASK, ~0);
+
+ wrl(port, UART_DATA_CONFIG, 0);
+ wrl(port, UART_SW_MODE, 0);
+ wrl(port, UART_URX_RTO_TIMER, FIELD_PREP(UART_CR_URX_RTO_VALUE_MSK, BFLB_UART_URX_RTO_TIME));
+
+ val = rdl(port, UART_FIFO_CONFIG_1);
+ val &= ~UART_RX_FIFO_TH_MSK;
+ val |= FIELD_PREP(UART_RX_FIFO_TH_MSK, BFLB_UART_RX_FIFO_TH);
+ wrl(port, UART_FIFO_CONFIG_1, val);
+
+ /* Unmask RX interrupts now */
+ val = rdl(port, UART_INT_MASK);
+ val &= ~(UART_URX_FIFO_INT | UART_URX_RTO_INT | UART_URX_FER_INT);
+ wrl(port, UART_INT_MASK, val);
+
+ val = rdl(port, UART_UTX_CONFIG);
+ val |= UART_CR_UTX_EN;
+ wrl(port, UART_UTX_CONFIG, val);
+ val = rdl(port, UART_URX_CONFIG);
+ val |= UART_CR_URX_EN;
+ wrl(port, UART_URX_CONFIG, val);
+
+ spin_unlock_irqrestore(&port->lock, flags);
+
+ return 0;
+}
+
+static void bflb_uart_shutdown(struct uart_port *port)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&port->lock, flags);
+ /* mask all interrupts now */
+ wrl(port, UART_INT_MASK, ~0);
+ spin_unlock_irqrestore(&port->lock, flags);
+}
+
+static const char *bflb_uart_type(struct uart_port *port)
+{
+ return (port->type == PORT_BFLB) ? "BFLB UART" : NULL;
+}
+
+static int bflb_uart_verify_port(struct uart_port *port,
+ struct serial_struct *ser)
+{
+ if (ser->type != PORT_UNKNOWN && ser->type != PORT_BFLB)
+ return -EINVAL;
+ return 0;
+}
+
+static const struct uart_ops bflb_uart_ops = {
+ .tx_empty = bflb_uart_tx_empty,
+ .get_mctrl = bflb_uart_get_mctrl,
+ .set_mctrl = bflb_uart_set_mctrl,
+ .start_tx = bflb_uart_start_tx,
+ .stop_tx = bflb_uart_stop_tx,
+ .stop_rx = bflb_uart_stop_rx,
+ .startup = bflb_uart_startup,
+ .shutdown = bflb_uart_shutdown,
+ .set_termios = bflb_uart_set_termios,
+ .type = bflb_uart_type,
+ .config_port = bflb_uart_config_port,
+ .verify_port = bflb_uart_verify_port,
+};
+
+#ifdef CONFIG_SERIAL_BFLB_CONSOLE
+static void bflb_console_putchar(struct uart_port *port, unsigned char ch)
+{
+ while (!(rdl(port, UART_FIFO_CONFIG_1) & UART_TX_FIFO_CNT_MSK))
+ cpu_relax();
+ wrb(port, UART_FIFO_WDATA, ch);
+}
+
+/*
+ * Interrupts are disabled on entering
+ */
+static void bflb_uart_console_write(struct console *co, const char *s,
+ u_int count)
+{
+ struct uart_port *port = &bflb_uart_ports[co->index]->port;
+ u32 status, reg, mask;
+
+ /* save then disable interrupts */
+ mask = rdl(port, UART_INT_MASK);
+ reg = ~0;
+ wrl(port, UART_INT_MASK, reg);
+
+ /* Make sure that tx is enabled */
+ reg = rdl(port, UART_UTX_CONFIG);
+ reg |= UART_CR_UTX_EN;
+ wrl(port, UART_UTX_CONFIG, reg);
+
+ uart_console_write(port, s, count, bflb_console_putchar);
+
+ /* wait for TX done */
+ do {
+ status = rdl(port, UART_STATUS);
+ } while ((status & UART_STS_UTX_BUS_BUSY));
+
+ /* restore IRQ mask */
+ wrl(port, UART_INT_MASK, mask);
+}
+
+static int bflb_uart_console_setup(struct console *co, char *options)
+{
+ struct uart_port *port;
+ struct bflb_uart_port *bp;
+ int baud = BFLB_UART_BAUD;
+ int bits = 8;
+ int parity = 'n';
+ int flow = 'n';
+ u32 val;
+
+ if (co->index >= BFLB_UART_MAXPORTS || co->index < 0)
+ return -EINVAL;
+
+ bp = bflb_uart_ports[co->index];
+ if (!bp)
+ /* Port not initialized yet - delay setup */
+ return -ENODEV;
+
+ port = &bp->port;
+
+ val = rdl(port, UART_UTX_CONFIG);
+ val |= UART_CR_UTX_EN;
+ wrl(port, UART_UTX_CONFIG, val);
+
+ if (options)
+ uart_parse_options(options, &baud, &parity, &bits, &flow);
+
+ return uart_set_options(port, co, baud, parity, bits, flow);
+}
+
+static struct uart_driver bflb_uart_driver;
+static struct console bflb_uart_console = {
+ .name = "ttyS",
+ .write = bflb_uart_console_write,
+ .device = uart_console_device,
+ .setup = bflb_uart_console_setup,
+ .flags = CON_PRINTBUFFER,
+ .index = -1,
+ .data = &bflb_uart_driver,
+};
+
+static int __init bflb_uart_console_init(void)
+{
+ register_console(&bflb_uart_console);
+ return 0;
+}
+console_initcall(bflb_uart_console_init);
+
+#define BFLB_UART_CONSOLE (&bflb_uart_console)
+
+static void bflb_uart_earlycon_write(struct console *co, const char *s,
+ unsigned int count)
+{
+ struct earlycon_device *dev = co->data;
+
+ uart_console_write(&dev->port, s, count, bflb_console_putchar);
+}
+
+static int __init bflb_uart_earlycon_setup(struct earlycon_device *dev,
+ const char *options)
+{
+ if (!dev->port.membase)
+ return -ENODEV;
+
+ dev->con->write = bflb_uart_earlycon_write;
+
+ return 0;
+}
+OF_EARLYCON_DECLARE(bflb_uart, "bouffalolab,bl808-uart", bflb_uart_earlycon_setup);
+
+#else
+
+#define BFLB_UART_CONSOLE NULL
+
+#endif /* CONFIG_SERIAL_BFLB_CONSOLE */
+
+static struct uart_driver bflb_uart_driver = {
+ .owner = THIS_MODULE,
+ .driver_name = "bflb_uart",
+ .dev_name = "ttyS",
+ .nr = BFLB_UART_MAXPORTS,
+ .cons = BFLB_UART_CONSOLE,
+};
+
+static int bflb_uart_probe(struct platform_device *pdev)
+{
+ struct uart_port *port;
+ struct bflb_uart_port *bp;
+ struct resource *res;
+ int index, irq;
+
+ index = of_alias_get_id(pdev->dev.of_node, "serial");
+ if (unlikely(index < 0 || index >= BFLB_UART_MAXPORTS)) {
+ dev_err(&pdev->dev, "got a wrong serial alias id %d\n", index);
+ return -EINVAL;
+ }
+
+ bp = devm_kzalloc(&pdev->dev, sizeof(*bp), GFP_KERNEL);
+ if (!bp)
+ return -ENOMEM;
+
+ bflb_uart_ports[index] = bp;
+ platform_set_drvdata(pdev, bp);
+ port = &bp->port;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ port->membase = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(port->membase))
+ return PTR_ERR(port->membase);
+
+ irq = platform_get_irq(pdev, 0);
+ if (irq < 0)
+ return irq;
+
+ port->mapbase = res->start;
+ port->irq = irq;
+ port->line = index;
+ port->type = PORT_BFLB;
+ port->iotype = UPIO_MEM;
+ port->fifosize = 32;
+ port->ops = &bflb_uart_ops;
+ port->flags = UPF_BOOT_AUTOCONF;
+ port->dev = &pdev->dev;
+ port->has_sysrq = IS_ENABLED(CONFIG_SERIAL_BFLB_CONSOLE);
+
+ bp->clk = devm_clk_get_enabled(&pdev->dev, NULL);
+ if (IS_ERR(bp->clk))
+ return PTR_ERR(bp->clk);
+ port->uartclk = clk_get_rate(bp->clk);
+
+ return uart_add_one_port(&bflb_uart_driver, port);
+}
+
+static int bflb_uart_remove(struct platform_device *pdev)
+{
+ struct bflb_uart_port *bp = platform_get_drvdata(pdev);
+
+ uart_remove_one_port(&bflb_uart_driver, &bp->port);
+ bflb_uart_ports[bp->port.line] = NULL;
+
+ return 0;
+}
+
+static const struct of_device_id bflb_uart_match[] = {
+ {
+ .compatible = "bouffalolab,bl808-uart",
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, bflb_uart_match);
+
+static struct platform_driver bflb_uart_platform_driver = {
+ .probe = bflb_uart_probe,
+ .remove = bflb_uart_remove,
+ .driver = {
+ .name = "bflb_uart",
+ .of_match_table = of_match_ptr(bflb_uart_match),
+ },
+};
+
+static int __init bflb_uart_init(void)
+{
+ int ret;
+
+ ret = uart_register_driver(&bflb_uart_driver);
+ if (ret)
+ return ret;
+
+ ret = platform_driver_register(&bflb_uart_platform_driver);
+ if (ret)
+ uart_unregister_driver(&bflb_uart_driver);
+
+ return ret;
+}
+
+static void __exit bflb_uart_exit(void)
+{
+ platform_driver_unregister(&bflb_uart_platform_driver);
+ uart_unregister_driver(&bflb_uart_driver);
+}
+
+module_init(bflb_uart_init);
+module_exit(bflb_uart_exit);
+
+MODULE_DESCRIPTION("Bouffalolab UART driver");
+MODULE_AUTHOR("Jisheng Zhang <[email protected]>");
+MODULE_LICENSE("GPL");
diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
index 281fa286555c..0651fcc8734f 100644
--- a/include/uapi/linux/serial_core.h
+++ b/include/uapi/linux/serial_core.h
@@ -279,4 +279,7 @@
/* Sunplus UART */
#define PORT_SUNPLUS 123
+/* Bouffalolab UART */
+#define PORT_BFLB 124
+
#endif /* _UAPILINUX_SERIAL_CORE_H */
--
2.40.0
Add bindings doc for Bouffalolab UART Driver
Signed-off-by: Jisheng Zhang <[email protected]>
Acked-by: Palmer Dabbelt <[email protected]>
---
.../serial/bouffalolab,bl808-uart.yaml | 47 +++++++++++++++++++
1 file changed, 47 insertions(+)
create mode 100644 Documentation/devicetree/bindings/serial/bouffalolab,bl808-uart.yaml
diff --git a/Documentation/devicetree/bindings/serial/bouffalolab,bl808-uart.yaml b/Documentation/devicetree/bindings/serial/bouffalolab,bl808-uart.yaml
new file mode 100644
index 000000000000..0ef858e50efb
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/bouffalolab,bl808-uart.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2022 Jisheng Zhang <[email protected]>
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/bouffalolab,bl808-uart.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bouffalolab UART Controller
+
+maintainers:
+ - Jisheng Zhang <[email protected]>
+
+allOf:
+ - $ref: serial.yaml#
+
+properties:
+ compatible:
+ const: bouffalolab,bl808-uart
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ uart0: serial@30002000 {
+ compatible = "bouffalolab,bl808-uart";
+ reg = <0x30002000 0x1000>;
+ interrupts = <53 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&xtal>;
+ };
+...
--
2.40.0
Add compatible string for bouffalolab bl808 plic.
Signed-off-by: Jisheng Zhang <[email protected]>
Reviewed-by: Conor Dooley <[email protected]>
---
.../bindings/interrupt-controller/sifive,plic-1.0.0.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
index f75736a061af..3f9439b0c163 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
@@ -65,6 +65,7 @@ properties:
- items:
- enum:
- allwinner,sun20i-d1-plic
+ - bouffalolab,bl808-plic
- const: thead,c900-plic
- items:
- const: sifive,plic-1.0.0
--
2.40.0
The Bouffalolab bl808 SoC contains three riscv CPUs, namely M0, D0 and
LP. The D0 is 64bit RISC-V GC compatible, so can run linux.
Signed-off-by: Jisheng Zhang <[email protected]>
Reviewed-by: Conor Dooley <[email protected]>
Acked-by: Palmer Dabbelt <[email protected]>
---
arch/riscv/Kconfig.socs | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
index 1cf69f958f10..33220b5144bb 100644
--- a/arch/riscv/Kconfig.socs
+++ b/arch/riscv/Kconfig.socs
@@ -1,5 +1,10 @@
menu "SoC selection"
+config ARCH_BOUFFALOLAB
+ bool "Bouffalolab SoCs"
+ help
+ This enables support for Bouffalolab SoC platforms.
+
config ARCH_MICROCHIP_POLARFIRE
def_bool SOC_MICROCHIP_POLARFIRE
--
2.40.0
Sipeed manufactures a M1s system-on-module and dock board, add basic
support for them.
Signed-off-by: Jisheng Zhang <[email protected]>
Acked-by: Palmer Dabbelt <[email protected]>
---
arch/riscv/boot/dts/Makefile | 1 +
arch/riscv/boot/dts/bouffalolab/Makefile | 2 ++
.../dts/bouffalolab/bl808-sipeed-m1s-dock.dts | 25 +++++++++++++++++++
.../dts/bouffalolab/bl808-sipeed-m1s.dtsi | 21 ++++++++++++++++
4 files changed, 49 insertions(+)
create mode 100644 arch/riscv/boot/dts/bouffalolab/Makefile
create mode 100644 arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s-dock.dts
create mode 100644 arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s.dtsi
diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile
index f0d9f89054f8..133e6c38c9b0 100644
--- a/arch/riscv/boot/dts/Makefile
+++ b/arch/riscv/boot/dts/Makefile
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
subdir-y += allwinner
+subdir-y += bouffalolab
subdir-y += sifive
subdir-y += starfive
subdir-y += canaan
diff --git a/arch/riscv/boot/dts/bouffalolab/Makefile b/arch/riscv/boot/dts/bouffalolab/Makefile
new file mode 100644
index 000000000000..5419964e892d
--- /dev/null
+++ b/arch/riscv/boot/dts/bouffalolab/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+dtb-$(CONFIG_SOC_BOUFFALOLAB) += bl808-sipeed-m1s-dock.dtb
diff --git a/arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s-dock.dts b/arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s-dock.dts
new file mode 100644
index 000000000000..aa6cf909cd4d
--- /dev/null
+++ b/arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s-dock.dts
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+/*
+ * Copyright (C) 2022 Jisheng Zhang <[email protected]>
+ */
+
+/dts-v1/;
+
+#include "bl808-sipeed-m1s.dtsi"
+
+/ {
+ model = "Sipeed M1s Dock";
+ compatible = "sipeed,m1s-dock", "sipeed,m1s", "bouffalolab,bl808";
+
+ aliases {
+ serial3 = &uart3;
+ };
+
+ chosen {
+ stdout-path = "serial3:2000000n8";
+ };
+};
+
+&uart3 {
+ status = "okay";
+};
diff --git a/arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s.dtsi b/arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s.dtsi
new file mode 100644
index 000000000000..5026de768534
--- /dev/null
+++ b/arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s.dtsi
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+/*
+ * Copyright (C) 2022 Jisheng Zhang <[email protected]>
+ */
+
+/dts-v1/;
+
+#include "bl808.dtsi"
+
+/ {
+ compatible = "sipeed,m1s", "bouffalolab,bl808";
+
+ memory@50000000 {
+ device_type = "memory";
+ reg = <0x50000000 0x04000000>;
+ };
+};
+
+&xtal {
+ clock-frequency = <40000000>;
+};
--
2.40.0
In the following commits, we will support bl808 SoC which is from
Bouffalo Lab Technology (Nanjing) Co., Ltd.
Add bouffalolab vendor prefix binding.
Link: https://en.bouffalolab.com/
Signed-off-by: Jisheng Zhang <[email protected]>
Reviewed-by: Conor Dooley <[email protected]>
Acked-by: Palmer Dabbelt <[email protected]>
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 82d39ab0231b..3566346f2f9e 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -200,6 +200,8 @@ patternProperties:
description: BOE Technology Group Co., Ltd.
"^bosch,.*":
description: Bosch Sensortec GmbH
+ "^bouffalolab,.*":
+ description: Bouffalo Lab Technology (Nanjing) Co., Ltd.
"^boundary,.*":
description: Boundary Devices Inc.
"^brcm,.*":
--
2.40.0
On Thu, May 18, 2023 at 11:22:37PM +0800, Jisheng Zhang wrote:
> Add bindings doc for Bouffalolab UART Driver
>
> Signed-off-by: Jisheng Zhang <[email protected]>
> Acked-by: Palmer Dabbelt <[email protected]>
Reviewed-by: Conor Dooley <[email protected]>
As I said previously, happy to grab the non-serial parts of the series
once Greg (or Jiri?) pick the serial bits.
Cheers,
Conor.
> ---
> .../serial/bouffalolab,bl808-uart.yaml | 47 +++++++++++++++++++
> 1 file changed, 47 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/serial/bouffalolab,bl808-uart.yaml
>
> diff --git a/Documentation/devicetree/bindings/serial/bouffalolab,bl808-uart.yaml b/Documentation/devicetree/bindings/serial/bouffalolab,bl808-uart.yaml
> new file mode 100644
> index 000000000000..0ef858e50efb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/serial/bouffalolab,bl808-uart.yaml
> @@ -0,0 +1,47 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (C) 2022 Jisheng Zhang <[email protected]>
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/serial/bouffalolab,bl808-uart.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Bouffalolab UART Controller
> +
> +maintainers:
> + - Jisheng Zhang <[email protected]>
> +
> +allOf:
> + - $ref: serial.yaml#
> +
> +properties:
> + compatible:
> + const: bouffalolab,bl808-uart
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> +
> + uart0: serial@30002000 {
> + compatible = "bouffalolab,bl808-uart";
> + reg = <0x30002000 0x1000>;
> + interrupts = <53 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&xtal>;
> + };
> +...
> --
> 2.40.0
>
Hi Jisheng,
On 5/18/23 10:22, Jisheng Zhang wrote:
> Add bindings doc for Bouffalolab UART Driver
>
> Signed-off-by: Jisheng Zhang <[email protected]>
> Acked-by: Palmer Dabbelt <[email protected]>
> ---
> .../serial/bouffalolab,bl808-uart.yaml | 47 +++++++++++++++++++
> 1 file changed, 47 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/serial/bouffalolab,bl808-uart.yaml
>
> diff --git a/Documentation/devicetree/bindings/serial/bouffalolab,bl808-uart.yaml b/Documentation/devicetree/bindings/serial/bouffalolab,bl808-uart.yaml
> new file mode 100644
> index 000000000000..0ef858e50efb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/serial/bouffalolab,bl808-uart.yaml
> @@ -0,0 +1,47 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (C) 2022 Jisheng Zhang <[email protected]>
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/serial/bouffalolab,bl808-uart.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Bouffalolab UART Controller
> +
> +maintainers:
> + - Jisheng Zhang <[email protected]>
> +
> +allOf:
> + - $ref: serial.yaml#
> +
> +properties:
> + compatible:
> + const: bouffalolab,bl808-uart
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
This is not complete. There are separate APB and module (baud) clocks,
as well as a peripheral reset line. If we are going to keep the binding
stable, these need to be described up front.
(I still don't fully understand the clock tree, and so far that has been
the main blocker for me sending a follow-up series with additional
bindings for hardware that's otherwise already supported, like the
Ethernet MAC.)
Regards,
Samuel
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> +
> + uart0: serial@30002000 {
> + compatible = "bouffalolab,bl808-uart";
> + reg = <0x30002000 0x1000>;
> + interrupts = <53 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&xtal>;
> + };
> +...
Hi Jisheng,
Thanks for updating this series!
On 5/18/23 10:22, Jisheng Zhang wrote:
> In the following commits, we will support bl808 SoC which is from
> Bouffalo Lab Technology (Nanjing) Co., Ltd.
>
> Add bouffalolab vendor prefix binding.
>
> Link: https://en.bouffalolab.com/
> Signed-off-by: Jisheng Zhang <[email protected]>
> Reviewed-by: Conor Dooley <[email protected]>
> Acked-by: Palmer Dabbelt <[email protected]>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> index 82d39ab0231b..3566346f2f9e 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -200,6 +200,8 @@ patternProperties:
> description: BOE Technology Group Co., Ltd.
> "^bosch,.*":
> description: Bosch Sensortec GmbH
> + "^bouffalolab,.*":
> + description: Bouffalo Lab Technology (Nanjing) Co., Ltd.
Have you thought about using the "bflb" abbreviation as the vendor
prefix, like you use throughout the driver code? This would save quite
some space in the DTB, and seems to be the most common variant seen in
the vendor SDK:
bouffalo_sdk$ git grep -i bflb | wc -l
14364
bouffalo_sdk$ git grep -i bouffalo | wc -l
1042
bouffalo_sdk$ git grep -i bouffalolab | wc -l
179
So that is what we were using for bringing up Linux and U-Boot over at
https://github.com/openbouffalo.
On the other hand, "bouffalolab" is certainly accurate as well, so I
understand if you prefer it. And we will of course adapt to whatever
gets merged, since our goal is upstreaming.
The vendor code drop[1] provided only one example, "bflb-uart,uart0",
which is not very helpful. Maybe you have received further information
from them?
What do you think?
Regards,
Samuel
[1]:
https://github.com/bouffalolab/bl808_linux/blob/main/linux-5.10.4-808/drivers/tty/serial/bflb_uart.c#L700
Hi Jisheng,
On 5/18/23 10:22, Jisheng Zhang wrote:
> Sipeed manufactures a M1s system-on-module and dock board, add basic
> support for them.
>
> Signed-off-by: Jisheng Zhang <[email protected]>
> Acked-by: Palmer Dabbelt <[email protected]>
> ---
> arch/riscv/boot/dts/Makefile | 1 +
> arch/riscv/boot/dts/bouffalolab/Makefile | 2 ++
> .../dts/bouffalolab/bl808-sipeed-m1s-dock.dts | 25 +++++++++++++++++++
> .../dts/bouffalolab/bl808-sipeed-m1s.dtsi | 21 ++++++++++++++++
> 4 files changed, 49 insertions(+)
> create mode 100644 arch/riscv/boot/dts/bouffalolab/Makefile
> create mode 100644 arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s-dock.dts
> create mode 100644 arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s.dtsi
>
> diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile
> index f0d9f89054f8..133e6c38c9b0 100644
> --- a/arch/riscv/boot/dts/Makefile
> +++ b/arch/riscv/boot/dts/Makefile
> @@ -1,5 +1,6 @@
> # SPDX-License-Identifier: GPL-2.0
> subdir-y += allwinner
> +subdir-y += bouffalolab
> subdir-y += sifive
> subdir-y += starfive
> subdir-y += canaan
> diff --git a/arch/riscv/boot/dts/bouffalolab/Makefile b/arch/riscv/boot/dts/bouffalolab/Makefile
> new file mode 100644
> index 000000000000..5419964e892d
> --- /dev/null
> +++ b/arch/riscv/boot/dts/bouffalolab/Makefile
> @@ -0,0 +1,2 @@
> +# SPDX-License-Identifier: GPL-2.0
> +dtb-$(CONFIG_SOC_BOUFFALOLAB) += bl808-sipeed-m1s-dock.dtb
> diff --git a/arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s-dock.dts b/arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s-dock.dts
> new file mode 100644
> index 000000000000..aa6cf909cd4d
> --- /dev/null
> +++ b/arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s-dock.dts
> @@ -0,0 +1,25 @@
> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> +/*
> + * Copyright (C) 2022 Jisheng Zhang <[email protected]>
> + */
> +
> +/dts-v1/;
> +
> +#include "bl808-sipeed-m1s.dtsi"
> +
> +/ {
> + model = "Sipeed M1s Dock";
> + compatible = "sipeed,m1s-dock", "sipeed,m1s", "bouffalolab,bl808";
> +
> + aliases {
> + serial3 = &uart3;
> + };
> +
> + chosen {
> + stdout-path = "serial3:2000000n8";
> + };
> +};
> +
> +&uart3 {
> + status = "okay";
> +};
> diff --git a/arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s.dtsi b/arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s.dtsi
> new file mode 100644
> index 000000000000..5026de768534
> --- /dev/null
> +++ b/arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s.dtsi
> @@ -0,0 +1,21 @@
> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> +/*
> + * Copyright (C) 2022 Jisheng Zhang <[email protected]>
> + */
> +
> +/dts-v1/;
> +
> +#include "bl808.dtsi"
> +
> +/ {
> + compatible = "sipeed,m1s", "bouffalolab,bl808";
> +
> + memory@50000000 {
> + device_type = "memory";
> + reg = <0x50000000 0x04000000>;
> + };
Especially since the SoC contains three heterogeneous CPUs, the firmware
may want to divide the PSRAM among them, so I do not think it is a good
idea to define this statically. (Or would all of the DTs contain this
same node, and then use reserved-memory nodes to cover the other CPUs'
allocations?)
Regards,
Samuel
> +};
> +
> +&xtal {
> + clock-frequency = <40000000>;
> +};
Hi Jisheng,
On 5/18/23 10:22, Jisheng Zhang wrote:
> Add a baisc dtsi for the bouffalolab bl808 SoC.
>
> Signed-off-by: Jisheng Zhang <[email protected]>
> Acked-by: Palmer Dabbelt <[email protected]>
> ---
> arch/riscv/boot/dts/bouffalolab/bl808.dtsi | 73 ++++++++++++++++++++++
> 1 file changed, 73 insertions(+)
> create mode 100644 arch/riscv/boot/dts/bouffalolab/bl808.dtsi
>
> diff --git a/arch/riscv/boot/dts/bouffalolab/bl808.dtsi b/arch/riscv/boot/dts/bouffalolab/bl808.dtsi
> new file mode 100644
> index 000000000000..87906fe51db5
> --- /dev/null
> +++ b/arch/riscv/boot/dts/bouffalolab/bl808.dtsi
> @@ -0,0 +1,73 @@
> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> +/*
> + * Copyright (C) 2022 Jisheng Zhang <[email protected]>
> + */
> +
> +#include <dt-bindings/interrupt-controller/irq.h>
> +
> +/ {
> + compatible = "bouffalolab,bl808";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + cpus {
> + timebase-frequency = <1000000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu0: cpu@0 {
> + compatible = "thead,c906", "riscv";
> + device_type = "cpu";
> + reg = <0>;
> + d-cache-block-size = <64>;
> + d-cache-sets = <256>;
> + d-cache-size = <32768>;
> + i-cache-block-size = <64>;
> + i-cache-sets = <128>;
> + i-cache-size = <32768>;
> + mmu-type = "riscv,sv39";
> + riscv,isa = "rv64imafdc";
> +
> + cpu0_intc: interrupt-controller {
> + compatible = "riscv,cpu-intc";
> + interrupt-controller;
> + #address-cells = <0>;
> + #interrupt-cells = <1>;
> + };
> + };
> + };
> +
> + xtal: xtal-clk {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + /* This value must be overridden by the board */
> + clock-frequency = <0>;
> + };
> +
> + soc {
> + compatible = "simple-bus";
> + ranges;
> + interrupt-parent = <&plic>;
> + dma-noncoherent;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + uart3: serial@30002000 {
> + compatible = "bouffalolab,bl808-uart";
> + reg = <0x30002000 0x1000>;
> + interrupts = <20 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&xtal>;
This isn't strictly accurate, and gives you the right frequency if you
are using the vendor "low_load" bootloader. Without that (e.g. when
loading U-Boot directly from the boot ROM), the routing is:
MM_MUXPLL_160M / 1 => MM_BCLK1X
MM_BCLK1X / 1 => MM_UART
So this UART module clock is 160 MHz, not 40 MHz.
The way to make this work reliably is to add drivers for the clock tree
(from the preliminary work at [1][2], we'll need at least five of them),
but that is a huge effort, so I'm not sure what we want to do for now.
Regards,
Samuel
[1]: https://github.com/openbouffalo/u-boot/commit/3ca800850f30
[2]: https://github.com/openbouffalo/u-boot/commits/bl808/clk-reset
> + status = "disabled";
> + };
> +
> + plic: interrupt-controller@e0000000 {
> + compatible = "bouffalolab,bl808-plic", "thead,c900-plic";
> + reg = <0xe0000000 0x4000000>;
> + interrupts-extended = <&cpu0_intc 11>, <&cpu0_intc 9>;
> + interrupt-controller;
> + #address-cells = <0>;
> + #interrupt-cells = <2>;
> + riscv,ndev = <82>;
> + };
> + };
> +};
Hi Jisheng, DT maintainers,
On 5/18/23 10:22, Jisheng Zhang wrote:
> Several SoMs and boards are available that feature the Bouffalolab
> bl808 SoC. Document the compatible strings.
>
> Signed-off-by: Jisheng Zhang <[email protected]>
> Acked-by: Palmer Dabbelt <[email protected]>
> Reviewed-by: Conor Dooley <[email protected]>
> ---
> .../bindings/riscv/bouffalolab.yaml | 29 +++++++++++++++++++
> 1 file changed, 29 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/riscv/bouffalolab.yaml
>
> diff --git a/Documentation/devicetree/bindings/riscv/bouffalolab.yaml b/Documentation/devicetree/bindings/riscv/bouffalolab.yaml
> new file mode 100644
> index 000000000000..3b25d1a5d04a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/riscv/bouffalolab.yaml
> @@ -0,0 +1,29 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/riscv/bouffalolab.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Bouffalo Lab Technology SoC-based boards
> +
> +maintainers:
> + - Jisheng Zhang <[email protected]>
> +
> +description:
> + Bouffalo Lab Technology SoC-based boards
> +
> +properties:
> + $nodename:
> + const: '/'
> + compatible:
> + oneOf:
> + - description: Carrier boards for the Sipeed M1s SoM
> + items:
> + - enum:
> + - sipeed,m1s-dock
> + - const: sipeed,m1s
> + - const: bouffalolab,bl808
As mentioned in the message for patch 5, "The Bouffalolab bl808 SoC
contains three riscv CPUs, namely M0, D0 and LP. The D0 is 64bit RISC-V
GC compatible, so can run linux."
I have also been running U-Boot and NOMMU Linux on the less powerful,
but still quite fast, "M0" core. However, this core needs a different
DTB because:
1) The CPU is different (T-HEAD E907 instead of C906).
2) The interrupt routing is completely different.
a. The M0 core contains a CLIC instead of a PLIC.
b. The peripherals in the SoC are split between two buses. Those
on one bus have their IRQs directly connected to M0, and share
a multiplexed IRQ connection to D0; and vice versa for the
other bus. So each bus's interrupt-parent needs to be swapped.
Using some preprocessor magic like we did for Allwinner and Renesas, I
was able to share most of the SoC and board DTs between the cores[1].
However, this still ends up with two DTs for each board. So here are my
questions:
- Is this acceptable?
- Is there precedent for how we should name the two board DTs?
- How does this affect the board and SoC compatible strings?
- Should there be a separate "bouffalolab,bl808-d0" in addition to
"bouffalolab,bl808"?
- Is it acceptable to use the same board compatible string for both,
since the _board_ part of the DT does not change, only things
inside the SoC?
It would be possible to avoid having two DTs per board by guarding all
of the differences behind "#ifdef CONFIG_64BIT", but that seems wrong
because you would end up with two totally incompatible DTBs named the
same thing, depending on how the DTB was built.
Thoughts?
Regards,
Samuel
[1]: https://github.com/openbouffalo/u-boot/commit/3ca800850f30
On 5/18/23 10:22, Jisheng Zhang wrote:
> Add compatible string for bouffalolab bl808 plic.
>
> Signed-off-by: Jisheng Zhang <[email protected]>
> Reviewed-by: Conor Dooley <[email protected]>
> ---
> .../bindings/interrupt-controller/sifive,plic-1.0.0.yaml | 1 +
> 1 file changed, 1 insertion(+)
Indeed, this is a T-HEAD C906. So ignoring the question I raised about
the vendor prefix:
Reviewed-by: Samuel Holland <[email protected]>
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
> index f75736a061af..3f9439b0c163 100644
> --- a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
> +++ b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
> @@ -65,6 +65,7 @@ properties:
> - items:
> - enum:
> - allwinner,sun20i-d1-plic
> + - bouffalolab,bl808-plic
> - const: thead,c900-plic
> - items:
> - const: sifive,plic-1.0.0
On Thu, May 18, 2023 at 10:31:35PM -0500, Samuel Holland wrote:
> Hi Jisheng, DT maintainers,
Sick, thanks for piping up Samuel!
Both Rob and Krzysztof are not around at the moment, so that probably
leaves it up to me.. I'm adding Arnd in case he has a take here too.
> On 5/18/23 10:22, Jisheng Zhang wrote:
> > Several SoMs and boards are available that feature the Bouffalolab
> > bl808 SoC. Document the compatible strings.
> >
> > Signed-off-by: Jisheng Zhang <[email protected]>
> > Acked-by: Palmer Dabbelt <[email protected]>
> > Reviewed-by: Conor Dooley <[email protected]>
> > ---
> > .../bindings/riscv/bouffalolab.yaml | 29 +++++++++++++++++++
> > 1 file changed, 29 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/riscv/bouffalolab.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/riscv/bouffalolab.yaml b/Documentation/devicetree/bindings/riscv/bouffalolab.yaml
> > new file mode 100644
> > index 000000000000..3b25d1a5d04a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/riscv/bouffalolab.yaml
> > @@ -0,0 +1,29 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/riscv/bouffalolab.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Bouffalo Lab Technology SoC-based boards
> > +
> > +maintainers:
> > + - Jisheng Zhang <[email protected]>
> > +
> > +description:
> > + Bouffalo Lab Technology SoC-based boards
> > +
> > +properties:
> > + $nodename:
> > + const: '/'
> > + compatible:
> > + oneOf:
> > + - description: Carrier boards for the Sipeed M1s SoM
> > + items:
> > + - enum:
> > + - sipeed,m1s-dock
> > + - const: sipeed,m1s
> > + - const: bouffalolab,bl808
>
> As mentioned in the message for patch 5, "The Bouffalolab bl808 SoC
> contains three riscv CPUs, namely M0, D0 and LP. The D0 is 64bit RISC-V
> GC compatible, so can run linux."
>
> I have also been running U-Boot and NOMMU Linux on the less powerful,
> but still quite fast, "M0" core. However, this core needs a different
> DTB because:
> 1) The CPU is different (T-HEAD E907 instead of C906).
> 2) The interrupt routing is completely different.
> a. The M0 core contains a CLIC instead of a PLIC.
> b. The peripherals in the SoC are split between two buses. Those
> on one bus have their IRQs directly connected to M0, and share
> a multiplexed IRQ connection to D0; and vice versa for the
> other bus. So each bus's interrupt-parent needs to be swapped.
>
> Using some preprocessor magic like we did for Allwinner and Renesas, I
> was able to share most of the SoC and board DTs between the cores[1].
> However, this still ends up with two DTs for each board. So here are my
> questions:
> - Is this acceptable?
I expected it to look worse than it actually turned out to be.
I don't think Krzysztof in particular is a fan of having conditional
bits in dts files, but for the shared arm/riscv stuff there was not
really another sensible option.
> - Is there precedent for how we should name the two board DTs?
Arnd might have some idea about precedent here, but I like your naming
well enough.
> - How does this affect the board and SoC compatible strings?
> - Should there be a separate "bouffalolab,bl808-d0" in addition to
> "bouffalolab,bl808"?
What ordering were you intending here?
"pine64,0x64" "bouffalolab,bl808" "bouffalolab,bl808-d0"?
That doesn't really seem correct though, as it does not get less specific
as you move right.
"pine64,0x64" "bouffalolab,bl808-d0" "bouffalolab,bl808" doesn't seem
right either though, for the same sort of reason.
> - Is it acceptable to use the same board compatible string for both,
> since the _board_ part of the DT does not change, only things
> inside the SoC?
I think you may need to have 2 compatibles per board, depending on which
cpu. Perhaps even as verbose as:
"pine61,0x64-d0" "pine64,0x64" "bouffalolab,bl808-d0" "bouffalolab,bl808"
Not exactly straightforward though, is it!
> It would be possible to avoid having two DTs per board by guarding all
> of the differences behind "#ifdef CONFIG_64BIT", but that seems wrong
> because you would end up with two totally incompatible DTBs named the
> same thing, depending on how the DTB was built.
I think having 2 dtbs is fine, and as I mentioned, I've seen Krzysztof
complain previously about conditional bits like that.
Cheers,
Conor.
On Thu, May 18, 2023 at 09:53:12PM -0500, Samuel Holland wrote:
> Hi Jisheng,
>
> Thanks for updating this series!
>
> On 5/18/23 10:22, Jisheng Zhang wrote:
> > In the following commits, we will support bl808 SoC which is from
> > Bouffalo Lab Technology (Nanjing) Co., Ltd.
> >
> > Add bouffalolab vendor prefix binding.
> >
> > Link: https://en.bouffalolab.com/
> > Signed-off-by: Jisheng Zhang <[email protected]>
> > Reviewed-by: Conor Dooley <[email protected]>
> > Acked-by: Palmer Dabbelt <[email protected]>
> > ---
> > Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> > index 82d39ab0231b..3566346f2f9e 100644
> > --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> > +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> > @@ -200,6 +200,8 @@ patternProperties:
> > description: BOE Technology Group Co., Ltd.
> > "^bosch,.*":
> > description: Bosch Sensortec GmbH
> > + "^bouffalolab,.*":
> > + description: Bouffalo Lab Technology (Nanjing) Co., Ltd.
>
> Have you thought about using the "bflb" abbreviation as the vendor
I did think about bflb vs bouffalolab. Here is what I thought: I came
across "marvell" vs "mrvl" sevral years ago, I got an impression
"marvell" vendor prefix is preferred if I read the discussions
correctly.
As for Bouffalolab vendor prefix, I have no preference, maybe DT
maintainers can provide inputs here.
Rob, Conor, Krzysztof, what's your opinion?
Thanks
> prefix, like you use throughout the driver code? This would save quite
> some space in the DTB, and seems to be the most common variant seen in
> the vendor SDK:
>
> bouffalo_sdk$ git grep -i bflb | wc -l
> 14364
> bouffalo_sdk$ git grep -i bouffalo | wc -l
> 1042
> bouffalo_sdk$ git grep -i bouffalolab | wc -l
> 179
>
> So that is what we were using for bringing up Linux and U-Boot over at
> https://github.com/openbouffalo.
>
> On the other hand, "bouffalolab" is certainly accurate as well, so I
> understand if you prefer it. And we will of course adapt to whatever
> gets merged, since our goal is upstreaming.
>
> The vendor code drop[1] provided only one example, "bflb-uart,uart0",
> which is not very helpful. Maybe you have received further information
> from them?
>
> What do you think?
>
> Regards,
> Samuel
>
> [1]:
> https://github.com/bouffalolab/bl808_linux/blob/main/linux-5.10.4-808/drivers/tty/serial/bflb_uart.c#L700
>
On Thu, May 18, 2023 at 10:00:50PM -0500, Samuel Holland wrote:
> Hi Jisheng,
Hi Samuel,
>
> On 5/18/23 10:22, Jisheng Zhang wrote:
> > Add bindings doc for Bouffalolab UART Driver
> >
> > Signed-off-by: Jisheng Zhang <[email protected]>
> > Acked-by: Palmer Dabbelt <[email protected]>
> > ---
> > .../serial/bouffalolab,bl808-uart.yaml | 47 +++++++++++++++++++
> > 1 file changed, 47 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/serial/bouffalolab,bl808-uart.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/serial/bouffalolab,bl808-uart.yaml b/Documentation/devicetree/bindings/serial/bouffalolab,bl808-uart.yaml
> > new file mode 100644
> > index 000000000000..0ef858e50efb
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/serial/bouffalolab,bl808-uart.yaml
> > @@ -0,0 +1,47 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +# Copyright (C) 2022 Jisheng Zhang <[email protected]>
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/serial/bouffalolab,bl808-uart.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Bouffalolab UART Controller
> > +
> > +maintainers:
> > + - Jisheng Zhang <[email protected]>
> > +
> > +allOf:
> > + - $ref: serial.yaml#
> > +
> > +properties:
> > + compatible:
> > + const: bouffalolab,bl808-uart
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + clocks:
> > + maxItems: 1
>
> This is not complete. There are separate APB and module (baud) clocks,
> as well as a peripheral reset line. If we are going to keep the binding
> stable, these need to be described up front.
IIUC, the only requirement is to keep the driver compatible with both
new dts and old dts. clk tree and reset can be added latter. I have seen
sevral such examples from other SoCs' mainline progress.
>
> (I still don't fully understand the clock tree, and so far that has been
> the main blocker for me sending a follow-up series with additional
> bindings for hardware that's otherwise already supported, like the
> Ethernet MAC.)
>
> Regards,
> Samuel
>
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - interrupts
> > + - clocks
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/interrupt-controller/irq.h>
> > +
> > + uart0: serial@30002000 {
> > + compatible = "bouffalolab,bl808-uart";
> > + reg = <0x30002000 0x1000>;
> > + interrupts = <53 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&xtal>;
> > + };
> > +...
>
On Sun, May 21, 2023 at 05:29:47PM +0800, Jisheng Zhang wrote:
> On Fri, May 19, 2023 at 12:55:02PM +0100, Conor Dooley wrote:
> > On Thu, May 18, 2023 at 10:31:35PM -0500, Samuel Holland wrote:
> > > Hi Jisheng, DT maintainers,
> >
> > Sick, thanks for piping up Samuel!
> > Both Rob and Krzysztof are not around at the moment, so that probably
> > leaves it up to me.. I'm adding Arnd in case he has a take here too.
> >
> > > On 5/18/23 10:22, Jisheng Zhang wrote:
> > > > Several SoMs and boards are available that feature the Bouffalolab
> > > > bl808 SoC. Document the compatible strings.
> > > >
> > > > Signed-off-by: Jisheng Zhang <[email protected]>
> > > > Acked-by: Palmer Dabbelt <[email protected]>
> > > > Reviewed-by: Conor Dooley <[email protected]>
> > > > ---
> > > > .../bindings/riscv/bouffalolab.yaml | 29 +++++++++++++++++++
> > > > 1 file changed, 29 insertions(+)
> > > > create mode 100644 Documentation/devicetree/bindings/riscv/bouffalolab.yaml
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/riscv/bouffalolab.yaml b/Documentation/devicetree/bindings/riscv/bouffalolab.yaml
> > > > new file mode 100644
> > > > index 000000000000..3b25d1a5d04a
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/riscv/bouffalolab.yaml
> > > > @@ -0,0 +1,29 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/riscv/bouffalolab.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: Bouffalo Lab Technology SoC-based boards
> > > > +
> > > > +maintainers:
> > > > + - Jisheng Zhang <[email protected]>
> > > > +
> > > > +description:
> > > > + Bouffalo Lab Technology SoC-based boards
> > > > +
> > > > +properties:
> > > > + $nodename:
> > > > + const: '/'
> > > > + compatible:
> > > > + oneOf:
> > > > + - description: Carrier boards for the Sipeed M1s SoM
> > > > + items:
> > > > + - enum:
> > > > + - sipeed,m1s-dock
> > > > + - const: sipeed,m1s
> > > > + - const: bouffalolab,bl808
> > >
> > > As mentioned in the message for patch 5, "The Bouffalolab bl808 SoC
> > > contains three riscv CPUs, namely M0, D0 and LP. The D0 is 64bit RISC-V
> > > GC compatible, so can run linux."
> > >
> > > I have also been running U-Boot and NOMMU Linux on the less powerful,
> > > but still quite fast, "M0" core. However, this core needs a different
>
> Just FYI, I successfully ran nommu rv32 linux kernel on the "M0" core
> with some patches to the riscv head and irqchip driver.
>
> > > DTB because:
> > > 1) The CPU is different (T-HEAD E907 instead of C906).
> > > 2) The interrupt routing is completely different.
> > > a. The M0 core contains a CLIC instead of a PLIC.
> > > b. The peripherals in the SoC are split between two buses. Those
> > > on one bus have their IRQs directly connected to M0, and share
> > > a multiplexed IRQ connection to D0; and vice versa for the
> > > other bus. So each bus's interrupt-parent needs to be swapped.
> > >
> > > Using some preprocessor magic like we did for Allwinner and Renesas, I
> > > was able to share most of the SoC and board DTs between the cores[1].
> > > However, this still ends up with two DTs for each board. So here are my
> > > questions:
> > > - Is this acceptable?
> >
> > I expected it to look worse than it actually turned out to be.
> > I don't think Krzysztof in particular is a fan of having conditional
> > bits in dts files, but for the shared arm/riscv stuff there was not
> > really another sensible option.
> >
> > > - Is there precedent for how we should name the two board DTs?
> >
> > Arnd might have some idea about precedent here, but I like your naming
> > well enough.
> >
> > > - How does this affect the board and SoC compatible strings?
> > > - Should there be a separate "bouffalolab,bl808-d0" in addition to
> > > "bouffalolab,bl808"?
> >
> > What ordering were you intending here?
> > "pine64,0x64" "bouffalolab,bl808" "bouffalolab,bl808-d0"?
> >
> > That doesn't really seem correct though, as it does not get less specific
> > as you move right.
> >
> > "pine64,0x64" "bouffalolab,bl808-d0" "bouffalolab,bl808" doesn't seem
> > right either though, for the same sort of reason.
> >
> > > - Is it acceptable to use the same board compatible string for both,
> > > since the _board_ part of the DT does not change, only things
> > > inside the SoC?
>
> what about describing the DT as the SoC is, e.g
> lp: cpu@0 {
> ...
> status = disabled;
> };
>
> m0: cpu@1 {
> ...
> status = disabled;
> };
>
> d0: cpu@2 {
> ...
> status = disabled;
> };
>
> Then in m0 dts:
> &m0 {
> status = okay;
> };
>
> in d0 dts:
> &m0 {
typo:
&d0 {
> status = okay;
> };
>
>
> >
> > I think you may need to have 2 compatibles per board, depending on which
> > cpu. Perhaps even as verbose as:
> > "pine61,0x64-d0" "pine64,0x64" "bouffalolab,bl808-d0" "bouffalolab,bl808"
> >
> > Not exactly straightforward though, is it!
> >
> > > It would be possible to avoid having two DTs per board by guarding all
> > > of the differences behind "#ifdef CONFIG_64BIT", but that seems wrong
> > > because you would end up with two totally incompatible DTBs named the
> > > same thing, depending on how the DTB was built.
> >
> > I think having 2 dtbs is fine, and as I mentioned, I've seen Krzysztof
> > complain previously about conditional bits like that.
> >
> > Cheers,
> > Conor.
>
>
On Fri, May 19, 2023 at 12:55:02PM +0100, Conor Dooley wrote:
> On Thu, May 18, 2023 at 10:31:35PM -0500, Samuel Holland wrote:
> > Hi Jisheng, DT maintainers,
>
> Sick, thanks for piping up Samuel!
> Both Rob and Krzysztof are not around at the moment, so that probably
> leaves it up to me.. I'm adding Arnd in case he has a take here too.
>
> > On 5/18/23 10:22, Jisheng Zhang wrote:
> > > Several SoMs and boards are available that feature the Bouffalolab
> > > bl808 SoC. Document the compatible strings.
> > >
> > > Signed-off-by: Jisheng Zhang <[email protected]>
> > > Acked-by: Palmer Dabbelt <[email protected]>
> > > Reviewed-by: Conor Dooley <[email protected]>
> > > ---
> > > .../bindings/riscv/bouffalolab.yaml | 29 +++++++++++++++++++
> > > 1 file changed, 29 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/riscv/bouffalolab.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/riscv/bouffalolab.yaml b/Documentation/devicetree/bindings/riscv/bouffalolab.yaml
> > > new file mode 100644
> > > index 000000000000..3b25d1a5d04a
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/riscv/bouffalolab.yaml
> > > @@ -0,0 +1,29 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/riscv/bouffalolab.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Bouffalo Lab Technology SoC-based boards
> > > +
> > > +maintainers:
> > > + - Jisheng Zhang <[email protected]>
> > > +
> > > +description:
> > > + Bouffalo Lab Technology SoC-based boards
> > > +
> > > +properties:
> > > + $nodename:
> > > + const: '/'
> > > + compatible:
> > > + oneOf:
> > > + - description: Carrier boards for the Sipeed M1s SoM
> > > + items:
> > > + - enum:
> > > + - sipeed,m1s-dock
> > > + - const: sipeed,m1s
> > > + - const: bouffalolab,bl808
> >
> > As mentioned in the message for patch 5, "The Bouffalolab bl808 SoC
> > contains three riscv CPUs, namely M0, D0 and LP. The D0 is 64bit RISC-V
> > GC compatible, so can run linux."
> >
> > I have also been running U-Boot and NOMMU Linux on the less powerful,
> > but still quite fast, "M0" core. However, this core needs a different
Just FYI, I successfully ran nommu rv32 linux kernel on the "M0" core
with some patches to the riscv head and irqchip driver.
> > DTB because:
> > 1) The CPU is different (T-HEAD E907 instead of C906).
> > 2) The interrupt routing is completely different.
> > a. The M0 core contains a CLIC instead of a PLIC.
> > b. The peripherals in the SoC are split between two buses. Those
> > on one bus have their IRQs directly connected to M0, and share
> > a multiplexed IRQ connection to D0; and vice versa for the
> > other bus. So each bus's interrupt-parent needs to be swapped.
> >
> > Using some preprocessor magic like we did for Allwinner and Renesas, I
> > was able to share most of the SoC and board DTs between the cores[1].
> > However, this still ends up with two DTs for each board. So here are my
> > questions:
> > - Is this acceptable?
>
> I expected it to look worse than it actually turned out to be.
> I don't think Krzysztof in particular is a fan of having conditional
> bits in dts files, but for the shared arm/riscv stuff there was not
> really another sensible option.
>
> > - Is there precedent for how we should name the two board DTs?
>
> Arnd might have some idea about precedent here, but I like your naming
> well enough.
>
> > - How does this affect the board and SoC compatible strings?
> > - Should there be a separate "bouffalolab,bl808-d0" in addition to
> > "bouffalolab,bl808"?
>
> What ordering were you intending here?
> "pine64,0x64" "bouffalolab,bl808" "bouffalolab,bl808-d0"?
>
> That doesn't really seem correct though, as it does not get less specific
> as you move right.
>
> "pine64,0x64" "bouffalolab,bl808-d0" "bouffalolab,bl808" doesn't seem
> right either though, for the same sort of reason.
>
> > - Is it acceptable to use the same board compatible string for both,
> > since the _board_ part of the DT does not change, only things
> > inside the SoC?
what about describing the DT as the SoC is, e.g
lp: cpu@0 {
...
status = disabled;
};
m0: cpu@1 {
...
status = disabled;
};
d0: cpu@2 {
...
status = disabled;
};
Then in m0 dts:
&m0 {
status = okay;
};
in d0 dts:
&m0 {
status = okay;
};
>
> I think you may need to have 2 compatibles per board, depending on which
> cpu. Perhaps even as verbose as:
> "pine61,0x64-d0" "pine64,0x64" "bouffalolab,bl808-d0" "bouffalolab,bl808"
>
> Not exactly straightforward though, is it!
>
> > It would be possible to avoid having two DTs per board by guarding all
> > of the differences behind "#ifdef CONFIG_64BIT", but that seems wrong
> > because you would end up with two totally incompatible DTBs named the
> > same thing, depending on how the DTB was built.
>
> I think having 2 dtbs is fine, and as I mentioned, I've seen Krzysztof
> complain previously about conditional bits like that.
>
> Cheers,
> Conor.
On Thu, May 18, 2023 at 10:55:21PM -0500, Samuel Holland wrote:
> Hi Jisheng,
>
> On 5/18/23 10:22, Jisheng Zhang wrote:
> > Sipeed manufactures a M1s system-on-module and dock board, add basic
> > support for them.
> >
> > Signed-off-by: Jisheng Zhang <[email protected]>
> > Acked-by: Palmer Dabbelt <[email protected]>
> > ---
> > arch/riscv/boot/dts/Makefile | 1 +
> > arch/riscv/boot/dts/bouffalolab/Makefile | 2 ++
> > .../dts/bouffalolab/bl808-sipeed-m1s-dock.dts | 25 +++++++++++++++++++
> > .../dts/bouffalolab/bl808-sipeed-m1s.dtsi | 21 ++++++++++++++++
> > 4 files changed, 49 insertions(+)
> > create mode 100644 arch/riscv/boot/dts/bouffalolab/Makefile
> > create mode 100644 arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s-dock.dts
> > create mode 100644 arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s.dtsi
> >
> > diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile
> > index f0d9f89054f8..133e6c38c9b0 100644
> > --- a/arch/riscv/boot/dts/Makefile
> > +++ b/arch/riscv/boot/dts/Makefile
> > @@ -1,5 +1,6 @@
> > # SPDX-License-Identifier: GPL-2.0
> > subdir-y += allwinner
> > +subdir-y += bouffalolab
> > subdir-y += sifive
> > subdir-y += starfive
> > subdir-y += canaan
> > diff --git a/arch/riscv/boot/dts/bouffalolab/Makefile b/arch/riscv/boot/dts/bouffalolab/Makefile
> > new file mode 100644
> > index 000000000000..5419964e892d
> > --- /dev/null
> > +++ b/arch/riscv/boot/dts/bouffalolab/Makefile
> > @@ -0,0 +1,2 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +dtb-$(CONFIG_SOC_BOUFFALOLAB) += bl808-sipeed-m1s-dock.dtb
> > diff --git a/arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s-dock.dts b/arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s-dock.dts
> > new file mode 100644
> > index 000000000000..aa6cf909cd4d
> > --- /dev/null
> > +++ b/arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s-dock.dts
> > @@ -0,0 +1,25 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> > +/*
> > + * Copyright (C) 2022 Jisheng Zhang <[email protected]>
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include "bl808-sipeed-m1s.dtsi"
> > +
> > +/ {
> > + model = "Sipeed M1s Dock";
> > + compatible = "sipeed,m1s-dock", "sipeed,m1s", "bouffalolab,bl808";
> > +
> > + aliases {
> > + serial3 = &uart3;
> > + };
> > +
> > + chosen {
> > + stdout-path = "serial3:2000000n8";
> > + };
> > +};
> > +
> > +&uart3 {
> > + status = "okay";
> > +};
> > diff --git a/arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s.dtsi b/arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s.dtsi
> > new file mode 100644
> > index 000000000000..5026de768534
> > --- /dev/null
> > +++ b/arch/riscv/boot/dts/bouffalolab/bl808-sipeed-m1s.dtsi
> > @@ -0,0 +1,21 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> > +/*
> > + * Copyright (C) 2022 Jisheng Zhang <[email protected]>
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include "bl808.dtsi"
> > +
> > +/ {
> > + compatible = "sipeed,m1s", "bouffalolab,bl808";
> > +
> > + memory@50000000 {
> > + device_type = "memory";
> > + reg = <0x50000000 0x04000000>;
> > + };
>
> Especially since the SoC contains three heterogeneous CPUs, the firmware
> may want to divide the PSRAM among them, so I do not think it is a good
> idea to define this statically. (Or would all of the DTs contain this
do you want the bootloader/firmware e.g uboot to add the memory node
dynamically?
But to be honest, nowdays most SoCs contain some heterogeneous CPUs, and
in real products some of those CPUs need to use DDR memory.
FWICT, their dtbs(in arch/arm64/boot/dts/...) still define the memory
statically. I believe this is acchieved by dynamically update the memory
node of DT. This solution doesn't make obvious difference with the uboot
adding memory node solution.
> same node, and then use reserved-memory nodes to cover the other CPUs'
> allocations?)
>
> Regards,
> Samuel
>
> > +};
> > +
> > +&xtal {
> > + clock-frequency = <40000000>;
> > +};
>
On Sun, May 21, 2023 at 05:02:23PM +0800, Jisheng Zhang wrote:
> On Thu, May 18, 2023 at 09:53:12PM -0500, Samuel Holland wrote:
> > Hi Jisheng,
> >
> > Thanks for updating this series!
> >
> > On 5/18/23 10:22, Jisheng Zhang wrote:
> > > In the following commits, we will support bl808 SoC which is from
> > > Bouffalo Lab Technology (Nanjing) Co., Ltd.
> > >
> > > Add bouffalolab vendor prefix binding.
> > >
> > > Link: https://en.bouffalolab.com/
> > > Signed-off-by: Jisheng Zhang <[email protected]>
> > > Reviewed-by: Conor Dooley <[email protected]>
> > > Acked-by: Palmer Dabbelt <[email protected]>
> > > ---
> > > Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> > > index 82d39ab0231b..3566346f2f9e 100644
> > > --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> > > +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> > > @@ -200,6 +200,8 @@ patternProperties:
> > > description: BOE Technology Group Co., Ltd.
> > > "^bosch,.*":
> > > description: Bosch Sensortec GmbH
> > > + "^bouffalolab,.*":
> > > + description: Bouffalo Lab Technology (Nanjing) Co., Ltd.
> >
> > Have you thought about using the "bflb" abbreviation as the vendor
>
> I did think about bflb vs bouffalolab. Here is what I thought: I came
> across "marvell" vs "mrvl" sevral years ago, I got an impression
> "marvell" vendor prefix is preferred if I read the discussions
> correctly.
>
> As for Bouffalolab vendor prefix, I have no preference, maybe DT
> maintainers can provide inputs here.
> Rob, Conor, Krzysztof, what's your opinion?
I had a look through the blame for vendor-prefixes.yaml since I had no
clue how easy it would be to find the marvell discussion - the commit
for gateworks' deprecated entry (done by Krzysztof says "Favor the
longer one (more descriptive)" & I think the same point is valid here.
I would have no idea what "bflb" was if I came across it in isolation!
Cheers,
Conor.
On Sun, May 21, 2023 at 05:13:38PM +0800, Jisheng Zhang wrote:
> On Thu, May 18, 2023 at 10:00:50PM -0500, Samuel Holland wrote:
> > On 5/18/23 10:22, Jisheng Zhang wrote:
> > This is not complete. There are separate APB and module (baud) clocks,
> > as well as a peripheral reset line. If we are going to keep the binding
> > stable, these need to be described up front.
>
> IIUC, the only requirement is to keep the driver compatible with both
> new dts and old dts. clk tree and reset can be added latter. I have seen
> sevral such examples from other SoCs' mainline progress.
It is generally preferred to add bindings in as complete a state as
possible. The driver doesn't need to actually make use of all of the
properties though, and can add the other bits as if/when they are
required.
Cheers,
Conor.
On Thu, May 18, 2023 at 11:22:38PM +0800, Jisheng Zhang wrote:
> Add the driver for Bouffalolab UART IP which is found in Bouffalolab
> SoCs such as bl808.
New uarts are being created that are NOT 8250-like? Why????
>
> UART driver probe will create path named "/dev/ttySx".
>
> Signed-off-by: Jisheng Zhang <[email protected]>
> ---
> drivers/tty/serial/Kconfig | 18 +
> drivers/tty/serial/Makefile | 1 +
> drivers/tty/serial/bflb_uart.c | 586 +++++++++++++++++++++++++++++++
> include/uapi/linux/serial_core.h | 3 +
> 4 files changed, 608 insertions(+)
> create mode 100644 drivers/tty/serial/bflb_uart.c
>
> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> index 398e5aac2e77..abc30a0713f5 100644
> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -179,6 +179,24 @@ config SERIAL_ATMEL_TTYAT
>
> Say Y if you have an external 8250/16C550 UART. If unsure, say N.
>
> +config SERIAL_BFLB
> + tristate "Bouffalolab serial port support"
> + select SERIAL_CORE
> + depends on COMMON_CLK
> + help
> + This enables the driver for the Bouffalolab's serial.
> +
> +config SERIAL_BFLB_CONSOLE
> + bool "Support for console on Bouffalolab serial port"
> + depends on SERIAL_BFLB=y
> + select SERIAL_CORE_CONSOLE
> + select SERIAL_EARLYCON
> + help
> + Say Y here if you wish to use a Bouffalolab UART as the
> + system console (the system console is the device which
> + receives all kernel messages and warnings and which allows
> + logins in single user mode) as /dev/ttySn.
> +
> config SERIAL_KGDB_NMI
> bool "Serial console over KGDB NMI debugger port"
> depends on KGDB_SERIAL_CONSOLE
> diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
> index cd9afd9e3018..5788a708d327 100644
> --- a/drivers/tty/serial/Makefile
> +++ b/drivers/tty/serial/Makefile
> @@ -25,6 +25,7 @@ obj-$(CONFIG_SERIAL_8250) += 8250/
>
> obj-$(CONFIG_SERIAL_AMBA_PL010) += amba-pl010.o
> obj-$(CONFIG_SERIAL_AMBA_PL011) += amba-pl011.o
> +obj-$(CONFIG_SERIAL_BFLB) += bflb_uart.o
> obj-$(CONFIG_SERIAL_CLPS711X) += clps711x.o
> obj-$(CONFIG_SERIAL_PXA_NON8250) += pxa.o
> obj-$(CONFIG_SERIAL_SA1100) += sa1100.o
> diff --git a/drivers/tty/serial/bflb_uart.c b/drivers/tty/serial/bflb_uart.c
> new file mode 100644
> index 000000000000..3f80bba8599a
> --- /dev/null
> +++ b/drivers/tty/serial/bflb_uart.c
> @@ -0,0 +1,586 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Based on bflb_uart.c, by Bouffalolab team
> + *
> + * Copyright (C) 2022 Jisheng Zhang <[email protected]>
It is 2023 :)
> + */
> +
> +#include <linux/bitfield.h>
> +#include <linux/clk.h>
> +#include <linux/console.h>
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/serial.h>
> +#include <linux/serial_core.h>
> +#include <linux/tty.h>
> +#include <linux/tty_flip.h>
> +
> +#define UART_UTX_CONFIG 0x00
> +#define UART_CR_UTX_EN BIT(0)
> +#define UART_CR_UTX_CTS_EN BIT(1)
> +#define UART_CR_UTX_FRM_EN BIT(2)
> +#define UART_CR_UTX_PRT_EN BIT(4)
> +#define UART_CR_UTX_PRT_SEL BIT(5)
> +#define UART_CR_UTX_BIT_CNT_D_MSK GENMASK(10, 8)
> +#define UART_CR_UTX_BIT_CNT_P_MSK GENMASK(12, 11)
> +#define UART_URX_CONFIG 0x04
> +#define UART_CR_URX_EN BIT(0)
> +#define UART_CR_URX_PRT_EN BIT(4)
> +#define UART_CR_URX_PRT_SEL BIT(5)
> +#define UART_CR_URX_BIT_CNT_D_MSK GENMASK(10, 8)
> +#define UART_BIT_PRD 0x08
> +#define UART_CR_UTX_BIT_PRD_MSK GENMASK(15, 0)
> +#define UART_CR_URX_BIT_PRD_MSK GENMASK(31, 16)
> +#define UART_DATA_CONFIG 0x0c
> +#define UART_CR_UART_BIT_INV BIT(0)
> +#define UART_URX_RTO_TIMER 0x18
> +#define UART_CR_URX_RTO_VALUE_MSK GENMASK(7, 0)
> +#define UART_SW_MODE 0x1c
> +#define UART_INT_STS 0x20
> +#define UART_UTX_END_INT BIT(0)
> +#define UART_URX_END_INT BIT(1)
> +#define UART_UTX_FIFO_INT BIT(2)
> +#define UART_URX_FIFO_INT BIT(3)
> +#define UART_URX_RTO_INT BIT(4)
> +#define UART_URX_PCE_INT BIT(5)
> +#define UART_UTX_FER_INT BIT(6)
> +#define UART_URX_FER_INT BIT(7)
> +#define UART_URX_LSE_INT BIT(8)
> +#define UART_INT_MASK 0x24
> +#define UART_INT_CLEAR 0x28
> +#define UART_INT_EN 0x2c
> +#define UART_STATUS 0x30
> +#define UART_STS_UTX_BUS_BUSY BIT(0)
> +#define UART_FIFO_CONFIG_0 0x80
> +#define UART_DMA_TX_EN BIT(0)
> +#define UART_DMA_RX_EN BIT(1)
> +#define UART_TX_FIFO_CLR BIT(2)
> +#define UART_RX_FIFO_CLR BIT(3)
> +#define UART_TX_FIFO_OVERFLOW BIT(4)
> +#define UART_TX_FIFO_UNDERFLOW BIT(5)
> +#define UART_RX_FIFO_OVERFLOW BIT(6)
> +#define UART_RX_FIFO_UNDERFLOW BIT(7)
> +#define UART_FIFO_CONFIG_1 0x84
> +#define UART_TX_FIFO_CNT_MSK GENMASK(5, 0)
> +#define UART_RX_FIFO_CNT_MSK GENMASK(13, 8)
> +#define UART_TX_FIFO_TH_MSK GENMASK(20, 16)
> +#define UART_RX_FIFO_TH_MSK GENMASK(28, 24)
> +#define UART_FIFO_WDATA 0x88
> +#define UART_FIFO_RDATA 0x8c
> +#define UART_FIFO_RDATA_MSK GENMASK(7, 0)
> +
> +#define BFLB_UART_MAXPORTS 8
> +#define BFLB_UART_BAUD 2000000
> +#define BFLB_UART_RX_FIFO_TH 7
> +#define BFLB_UART_TX_FIFO_TH 15
> +#define BFLB_UART_URX_RTO_TIME 0x4f
> +
> +struct bflb_uart_port {
> + struct uart_port port;
> + struct clk *clk;
> +};
> +
> +static struct bflb_uart_port *bflb_uart_ports[BFLB_UART_MAXPORTS];
> +
> +static inline u32 rdl(struct uart_port *port, u32 reg)
> +{
> + return readl_relaxed(port->membase + reg);
> +}
> +
> +static inline void wrl(struct uart_port *port, u32 reg, u32 value)
> +{
> + writel_relaxed(value, port->membase + reg);
> +}
> +
> +static inline void wrb(struct uart_port *port, u32 reg, u8 value)
> +{
> + writeb_relaxed(value, port->membase + reg);
> +}
> +
> +static unsigned int bflb_uart_tx_empty(struct uart_port *port)
> +{
> + return (rdl(port, UART_FIFO_CONFIG_1) & UART_TX_FIFO_CNT_MSK) ? TIOCSER_TEMT : 0;
> +}
> +
> +static unsigned int bflb_uart_get_mctrl(struct uart_port *port)
> +{
> + return TIOCM_CAR | TIOCM_DSR | TIOCM_CTS;
> +}
> +
> +static void bflb_uart_set_mctrl(struct uart_port *port, unsigned int sigs)
> +{
> +}
Why is a blank function required here?
> --- a/include/uapi/linux/serial_core.h
> +++ b/include/uapi/linux/serial_core.h
> @@ -279,4 +279,7 @@
> /* Sunplus UART */
> #define PORT_SUNPLUS 123
>
> +/* Bouffalolab UART */
> +#define PORT_BFLB 124
Why is this required? What userspace code is going to need this?
thanks,
greg k-h
On Tue, May 30, 2023 at 11:36:00AM +0100, Greg Kroah-Hartman wrote:
> On Thu, May 18, 2023 at 11:22:38PM +0800, Jisheng Zhang wrote:
> > Add the driver for Bouffalolab UART IP which is found in Bouffalolab
> > SoCs such as bl808.
>
> New uarts are being created that are NOT 8250-like? Why????
Hi,
I'm not sure I understand your meaning. I guess you mean writing the new
uart driver following 8250 style. And the latest example is
sunplus-uart.c, it can be used as an example how to write a 8250 style
driver for new non-8250 uart IP.
If the above guesses are wrong, could you please provide more details?
Thanks
>
>
> >
> > UART driver probe will create path named "/dev/ttySx".
> >
> > Signed-off-by: Jisheng Zhang <[email protected]>
> > ---
> > drivers/tty/serial/Kconfig | 18 +
> > drivers/tty/serial/Makefile | 1 +
> > drivers/tty/serial/bflb_uart.c | 586 +++++++++++++++++++++++++++++++
> > include/uapi/linux/serial_core.h | 3 +
> > 4 files changed, 608 insertions(+)
> > create mode 100644 drivers/tty/serial/bflb_uart.c
> >
> > diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> > index 398e5aac2e77..abc30a0713f5 100644
> > --- a/drivers/tty/serial/Kconfig
> > +++ b/drivers/tty/serial/Kconfig
> > @@ -179,6 +179,24 @@ config SERIAL_ATMEL_TTYAT
> >
> > Say Y if you have an external 8250/16C550 UART. If unsure, say N.
> >
> > +config SERIAL_BFLB
> > + tristate "Bouffalolab serial port support"
> > + select SERIAL_CORE
> > + depends on COMMON_CLK
> > + help
> > + This enables the driver for the Bouffalolab's serial.
> > +
> > +config SERIAL_BFLB_CONSOLE
> > + bool "Support for console on Bouffalolab serial port"
> > + depends on SERIAL_BFLB=y
> > + select SERIAL_CORE_CONSOLE
> > + select SERIAL_EARLYCON
> > + help
> > + Say Y here if you wish to use a Bouffalolab UART as the
> > + system console (the system console is the device which
> > + receives all kernel messages and warnings and which allows
> > + logins in single user mode) as /dev/ttySn.
> > +
> > config SERIAL_KGDB_NMI
> > bool "Serial console over KGDB NMI debugger port"
> > depends on KGDB_SERIAL_CONSOLE
> > diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
> > index cd9afd9e3018..5788a708d327 100644
> > --- a/drivers/tty/serial/Makefile
> > +++ b/drivers/tty/serial/Makefile
> > @@ -25,6 +25,7 @@ obj-$(CONFIG_SERIAL_8250) += 8250/
> >
> > obj-$(CONFIG_SERIAL_AMBA_PL010) += amba-pl010.o
> > obj-$(CONFIG_SERIAL_AMBA_PL011) += amba-pl011.o
> > +obj-$(CONFIG_SERIAL_BFLB) += bflb_uart.o
> > obj-$(CONFIG_SERIAL_CLPS711X) += clps711x.o
> > obj-$(CONFIG_SERIAL_PXA_NON8250) += pxa.o
> > obj-$(CONFIG_SERIAL_SA1100) += sa1100.o
> > diff --git a/drivers/tty/serial/bflb_uart.c b/drivers/tty/serial/bflb_uart.c
> > new file mode 100644
> > index 000000000000..3f80bba8599a
> > --- /dev/null
> > +++ b/drivers/tty/serial/bflb_uart.c
> > @@ -0,0 +1,586 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Based on bflb_uart.c, by Bouffalolab team
> > + *
> > + * Copyright (C) 2022 Jisheng Zhang <[email protected]>
>
> It is 2023 :)
>
> > + */
> > +
> > +#include <linux/bitfield.h>
> > +#include <linux/clk.h>
> > +#include <linux/console.h>
> > +#include <linux/kernel.h>
> > +#include <linux/init.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/io.h>
> > +#include <linux/module.h>
> > +#include <linux/of.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/serial.h>
> > +#include <linux/serial_core.h>
> > +#include <linux/tty.h>
> > +#include <linux/tty_flip.h>
> > +
> > +#define UART_UTX_CONFIG 0x00
> > +#define UART_CR_UTX_EN BIT(0)
> > +#define UART_CR_UTX_CTS_EN BIT(1)
> > +#define UART_CR_UTX_FRM_EN BIT(2)
> > +#define UART_CR_UTX_PRT_EN BIT(4)
> > +#define UART_CR_UTX_PRT_SEL BIT(5)
> > +#define UART_CR_UTX_BIT_CNT_D_MSK GENMASK(10, 8)
> > +#define UART_CR_UTX_BIT_CNT_P_MSK GENMASK(12, 11)
> > +#define UART_URX_CONFIG 0x04
> > +#define UART_CR_URX_EN BIT(0)
> > +#define UART_CR_URX_PRT_EN BIT(4)
> > +#define UART_CR_URX_PRT_SEL BIT(5)
> > +#define UART_CR_URX_BIT_CNT_D_MSK GENMASK(10, 8)
> > +#define UART_BIT_PRD 0x08
> > +#define UART_CR_UTX_BIT_PRD_MSK GENMASK(15, 0)
> > +#define UART_CR_URX_BIT_PRD_MSK GENMASK(31, 16)
> > +#define UART_DATA_CONFIG 0x0c
> > +#define UART_CR_UART_BIT_INV BIT(0)
> > +#define UART_URX_RTO_TIMER 0x18
> > +#define UART_CR_URX_RTO_VALUE_MSK GENMASK(7, 0)
> > +#define UART_SW_MODE 0x1c
> > +#define UART_INT_STS 0x20
> > +#define UART_UTX_END_INT BIT(0)
> > +#define UART_URX_END_INT BIT(1)
> > +#define UART_UTX_FIFO_INT BIT(2)
> > +#define UART_URX_FIFO_INT BIT(3)
> > +#define UART_URX_RTO_INT BIT(4)
> > +#define UART_URX_PCE_INT BIT(5)
> > +#define UART_UTX_FER_INT BIT(6)
> > +#define UART_URX_FER_INT BIT(7)
> > +#define UART_URX_LSE_INT BIT(8)
> > +#define UART_INT_MASK 0x24
> > +#define UART_INT_CLEAR 0x28
> > +#define UART_INT_EN 0x2c
> > +#define UART_STATUS 0x30
> > +#define UART_STS_UTX_BUS_BUSY BIT(0)
> > +#define UART_FIFO_CONFIG_0 0x80
> > +#define UART_DMA_TX_EN BIT(0)
> > +#define UART_DMA_RX_EN BIT(1)
> > +#define UART_TX_FIFO_CLR BIT(2)
> > +#define UART_RX_FIFO_CLR BIT(3)
> > +#define UART_TX_FIFO_OVERFLOW BIT(4)
> > +#define UART_TX_FIFO_UNDERFLOW BIT(5)
> > +#define UART_RX_FIFO_OVERFLOW BIT(6)
> > +#define UART_RX_FIFO_UNDERFLOW BIT(7)
> > +#define UART_FIFO_CONFIG_1 0x84
> > +#define UART_TX_FIFO_CNT_MSK GENMASK(5, 0)
> > +#define UART_RX_FIFO_CNT_MSK GENMASK(13, 8)
> > +#define UART_TX_FIFO_TH_MSK GENMASK(20, 16)
> > +#define UART_RX_FIFO_TH_MSK GENMASK(28, 24)
> > +#define UART_FIFO_WDATA 0x88
> > +#define UART_FIFO_RDATA 0x8c
> > +#define UART_FIFO_RDATA_MSK GENMASK(7, 0)
> > +
> > +#define BFLB_UART_MAXPORTS 8
> > +#define BFLB_UART_BAUD 2000000
> > +#define BFLB_UART_RX_FIFO_TH 7
> > +#define BFLB_UART_TX_FIFO_TH 15
> > +#define BFLB_UART_URX_RTO_TIME 0x4f
> > +
> > +struct bflb_uart_port {
> > + struct uart_port port;
> > + struct clk *clk;
> > +};
> > +
> > +static struct bflb_uart_port *bflb_uart_ports[BFLB_UART_MAXPORTS];
> > +
> > +static inline u32 rdl(struct uart_port *port, u32 reg)
> > +{
> > + return readl_relaxed(port->membase + reg);
> > +}
> > +
> > +static inline void wrl(struct uart_port *port, u32 reg, u32 value)
> > +{
> > + writel_relaxed(value, port->membase + reg);
> > +}
> > +
> > +static inline void wrb(struct uart_port *port, u32 reg, u8 value)
> > +{
> > + writeb_relaxed(value, port->membase + reg);
> > +}
> > +
> > +static unsigned int bflb_uart_tx_empty(struct uart_port *port)
> > +{
> > + return (rdl(port, UART_FIFO_CONFIG_1) & UART_TX_FIFO_CNT_MSK) ? TIOCSER_TEMT : 0;
> > +}
> > +
> > +static unsigned int bflb_uart_get_mctrl(struct uart_port *port)
> > +{
> > + return TIOCM_CAR | TIOCM_DSR | TIOCM_CTS;
> > +}
> > +
> > +static void bflb_uart_set_mctrl(struct uart_port *port, unsigned int sigs)
> > +{
> > +}
>
> Why is a blank function required here?
>
>
> > --- a/include/uapi/linux/serial_core.h
> > +++ b/include/uapi/linux/serial_core.h
> > @@ -279,4 +279,7 @@
> > /* Sunplus UART */
> > #define PORT_SUNPLUS 123
> >
> > +/* Bouffalolab UART */
> > +#define PORT_BFLB 124
>
> Why is this required? What userspace code is going to need this?
>
> thanks,
>
> greg k-h
On Wed, May 31, 2023 at 10:09:56PM +0800, Jisheng Zhang wrote:
> On Tue, May 30, 2023 at 11:36:00AM +0100, Greg Kroah-Hartman wrote:
> > On Thu, May 18, 2023 at 11:22:38PM +0800, Jisheng Zhang wrote:
> > > Add the driver for Bouffalolab UART IP which is found in Bouffalolab
> > > SoCs such as bl808.
> >
> > New uarts are being created that are NOT 8250-like? Why????
>
> Hi,
>
> I'm not sure I understand your meaning. I guess you mean writing the new
> uart driver following 8250 style. And the latest example is
> sunplus-uart.c, it can be used as an example how to write a 8250 style
> driver for new non-8250 uart IP.
No, I mean, "why are hardware designers creating new UARTs in 2023 that
are NOT 8250-based"? Why do they want to constantly reinvent the wheel?
thanks,
greg k-h
On Wed, May 31, 2023 at 03:34:02PM +0100, Greg Kroah-Hartman wrote:
> On Wed, May 31, 2023 at 10:09:56PM +0800, Jisheng Zhang wrote:
> > On Tue, May 30, 2023 at 11:36:00AM +0100, Greg Kroah-Hartman wrote:
> > > On Thu, May 18, 2023 at 11:22:38PM +0800, Jisheng Zhang wrote:
> > > > Add the driver for Bouffalolab UART IP which is found in Bouffalolab
> > > > SoCs such as bl808.
> > >
> > > New uarts are being created that are NOT 8250-like? Why????
> >
> > Hi,
> >
> > I'm not sure I understand your meaning. I guess you mean writing the new
> > uart driver following 8250 style. And the latest example is
> > sunplus-uart.c, it can be used as an example how to write a 8250 style
> > driver for new non-8250 uart IP.
>
> No, I mean, "why are hardware designers creating new UARTs in 2023 that
> are NOT 8250-based"? Why do they want to constantly reinvent the wheel?
haha, to be honest, I dunno the reason either. For me, the HW has been there
and is linux capable, I want to mainline its support.
On Thu, May 18, 2023 at 10:31:35PM -0500, Samuel Holland wrote:
> Hi Jisheng, DT maintainers,
>
> On 5/18/23 10:22, Jisheng Zhang wrote:
> > Several SoMs and boards are available that feature the Bouffalolab
> > bl808 SoC. Document the compatible strings.
> >
> > Signed-off-by: Jisheng Zhang <[email protected]>
> > Acked-by: Palmer Dabbelt <[email protected]>
> > Reviewed-by: Conor Dooley <[email protected]>
> > ---
> > .../bindings/riscv/bouffalolab.yaml | 29 +++++++++++++++++++
> > 1 file changed, 29 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/riscv/bouffalolab.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/riscv/bouffalolab.yaml b/Documentation/devicetree/bindings/riscv/bouffalolab.yaml
> > new file mode 100644
> > index 000000000000..3b25d1a5d04a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/riscv/bouffalolab.yaml
> > @@ -0,0 +1,29 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/riscv/bouffalolab.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Bouffalo Lab Technology SoC-based boards
> > +
> > +maintainers:
> > + - Jisheng Zhang <[email protected]>
> > +
> > +description:
> > + Bouffalo Lab Technology SoC-based boards
> > +
> > +properties:
> > + $nodename:
> > + const: '/'
> > + compatible:
> > + oneOf:
> > + - description: Carrier boards for the Sipeed M1s SoM
> > + items:
> > + - enum:
> > + - sipeed,m1s-dock
> > + - const: sipeed,m1s
> > + - const: bouffalolab,bl808
>
> As mentioned in the message for patch 5, "The Bouffalolab bl808 SoC
> contains three riscv CPUs, namely M0, D0 and LP. The D0 is 64bit RISC-V
> GC compatible, so can run linux."
>
> I have also been running U-Boot and NOMMU Linux on the less powerful,
> but still quite fast, "M0" core. However, this core needs a different
> DTB because:
> 1) The CPU is different (T-HEAD E907 instead of C906).
> 2) The interrupt routing is completely different.
> a. The M0 core contains a CLIC instead of a PLIC.
> b. The peripherals in the SoC are split between two buses. Those
> on one bus have their IRQs directly connected to M0, and share
> a multiplexed IRQ connection to D0; and vice versa for the
> other bus. So each bus's interrupt-parent needs to be swapped.
Can't you include the dts file and then just override
'interrupt-parent'?
> Using some preprocessor magic like we did for Allwinner and Renesas, I
> was able to share most of the SoC and board DTs between the cores[1].
> However, this still ends up with two DTs for each board. So here are my
> questions:
> - Is this acceptable?
> - Is there precedent for how we should name the two board DTs?
> - How does this affect the board and SoC compatible strings?
> - Should there be a separate "bouffalolab,bl808-d0" in addition to
> "bouffalolab,bl808"?
Probably. A DT is ultimately the view of the hardware from a CPU's
perspective. Different views, different compatibles.
> - Is it acceptable to use the same board compatible string for both,
> since the _board_ part of the DT does not change, only things
> inside the SoC?
Yes.
>
> It would be possible to avoid having two DTs per board by guarding all
> of the differences behind "#ifdef CONFIG_64BIT", but that seems wrong
> because you would end up with two totally incompatible DTBs named the
> same thing, depending on how the DTB was built.
You can't have CONFIG_ options in .dts files.
Rob
On Sun, May 21, 2023 at 05:02:23PM +0800, Jisheng Zhang wrote:
> On Thu, May 18, 2023 at 09:53:12PM -0500, Samuel Holland wrote:
> > Hi Jisheng,
> >
> > Thanks for updating this series!
> >
> > On 5/18/23 10:22, Jisheng Zhang wrote:
> > > In the following commits, we will support bl808 SoC which is from
> > > Bouffalo Lab Technology (Nanjing) Co., Ltd.
> > >
> > > Add bouffalolab vendor prefix binding.
> > >
> > > Link: https://en.bouffalolab.com/
> > > Signed-off-by: Jisheng Zhang <[email protected]>
> > > Reviewed-by: Conor Dooley <[email protected]>
> > > Acked-by: Palmer Dabbelt <[email protected]>
> > > ---
> > > Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> > > index 82d39ab0231b..3566346f2f9e 100644
> > > --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> > > +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> > > @@ -200,6 +200,8 @@ patternProperties:
> > > description: BOE Technology Group Co., Ltd.
> > > "^bosch,.*":
> > > description: Bosch Sensortec GmbH
> > > + "^bouffalolab,.*":
> > > + description: Bouffalo Lab Technology (Nanjing) Co., Ltd.
> >
> > Have you thought about using the "bflb" abbreviation as the vendor
>
> I did think about bflb vs bouffalolab. Here is what I thought: I came
> across "marvell" vs "mrvl" sevral years ago, I got an impression
> "marvell" vendor prefix is preferred if I read the discussions
> correctly.
>
> As for Bouffalolab vendor prefix, I have no preference, maybe DT
> maintainers can provide inputs here.
> Rob, Conor, Krzysztof, what's your opinion?
The general preference is to match the vendor's domain name (minus the
.com, etc.). Originally, the preference was stock ticker symbol, but
we've pretty much moved away from that.
So that's 'bouffalolab'.
Acked-by: Rob Herring <[email protected]>
Rob