[PATCH v4 00/10] riscv: add Bouffalolab bl808 support

[PATCH v4 00/10] riscv: add Bouffalolab bl808 support

[Jisheng Zhang]

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 lkp@intel.com
  - 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

[PATCH v4 01/10] dt-bindings: vendor-prefixes: add bouffalolab

[Jisheng Zhang]

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 <jszhang@kernel.org>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
---
 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

Re: [PATCH v4 01/10] dt-bindings: vendor-prefixes: add bouffalolab

[Samuel Holland]

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 <jszhang@kernel.org>
> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
> Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
> ---
>  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

Re: [PATCH v4 01/10] dt-bindings: vendor-prefixes: add bouffalolab

[Jisheng Zhang]

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 <jszhang@kernel.org>
> > Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
> > Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
> > ---
> >  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
> 

Re: [PATCH v4 01/10] dt-bindings: vendor-prefixes: add bouffalolab

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 2193 bytes --]

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 <jszhang@kernel.org>
> > > Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
> > > Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
> > > ---
> > >  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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v4 01/10] dt-bindings: vendor-prefixes: add bouffalolab

[Rob Herring]

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 <jszhang@kernel.org>
> > > Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
> > > Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
> > > ---
> > >  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 <robh@kernel.org>

Rob

[PATCH v4 02/10] dt-bindings: interrupt-controller: Add bouffalolab bl808 plic

[Jisheng Zhang]

Add compatible string for bouffalolab bl808 plic.

Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
---
 .../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

Re: [PATCH v4 02/10] dt-bindings: interrupt-controller: Add bouffalolab bl808 plic

[Samuel Holland]

On 5/18/23 10:22, Jisheng Zhang wrote:
> Add compatible string for bouffalolab bl808 plic.
> 
> Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
> ---
>  .../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 <samuel@sholland.org>

> 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

[PATCH v4 03/10] dt-bindings: serial: add documentation for Bouffalolab UART Driver

[Jisheng Zhang]

Add bindings doc for Bouffalolab UART Driver

Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
---
 .../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 <jszhang@kernel.org>
+%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 <jszhang@kernel.org>
+
+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

Re: [PATCH v4 03/10] dt-bindings: serial: add documentation for Bouffalolab UART Driver

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 2045 bytes --]

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 <jszhang@kernel.org>
> Acked-by: Palmer Dabbelt <palmer@rivosinc.com>

Reviewed-by: Conor Dooley <conor.dooley@microchip.com>

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 <jszhang@kernel.org>
> +%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 <jszhang@kernel.org>
> +
> +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
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v4 03/10] dt-bindings: serial: add documentation for Bouffalolab UART Driver

[Samuel Holland]

Hi Jisheng,

On 5/18/23 10:22, Jisheng Zhang wrote:
> Add bindings doc for Bouffalolab UART Driver
> 
> Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
> Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
> ---
>  .../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 <jszhang@kernel.org>
> +%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 <jszhang@kernel.org>
> +
> +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>;
> +    };
> +...

Re: [PATCH v4 03/10] dt-bindings: serial: add documentation for Bouffalolab UART Driver

[Jisheng Zhang]

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 <jszhang@kernel.org>
> > Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
> > ---
> >  .../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 <jszhang@kernel.org>
> > +%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 <jszhang@kernel.org>
> > +
> > +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>;
> > +    };
> > +...
> 

Re: [PATCH v4 03/10] dt-bindings: serial: add documentation for Bouffalolab UART Driver

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 831 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[PATCH v4 04/10] serial: bflb_uart: add Bouffalolab UART Driver

[Jisheng Zhang]

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 <jszhang@kernel.org>
---
 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 <jszhang@kernel.org>
+ */
+
+#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 <jszhang@kernel.org>");
+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

Re: [PATCH v4 04/10] serial: bflb_uart: add Bouffalolab UART Driver

[Greg Kroah-Hartman]

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 <jszhang@kernel.org>
> ---
>  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 <jszhang@kernel.org>

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

Re: [PATCH v4 04/10] serial: bflb_uart: add Bouffalolab UART Driver

[Jisheng Zhang]

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 <jszhang@kernel.org>
> > ---
> >  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 <jszhang@kernel.org>
> 
> 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

Re: [PATCH v4 04/10] serial: bflb_uart: add Bouffalolab UART Driver

[Greg Kroah-Hartman]

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

Re: [PATCH v4 04/10] serial: bflb_uart: add Bouffalolab UART Driver

[Jisheng Zhang]

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.

[PATCH v4 05/10] riscv: add the Bouffalolab SoC family Kconfig option

[Jisheng Zhang]

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 <jszhang@kernel.org>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
---
 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

[PATCH v4 06/10] dt-bindings: riscv: Add bouffalolab bl808 board compatibles

[Jisheng Zhang]

Several SoMs and boards are available that feature the Bouffalolab
bl808 SoC. Document the compatible strings.

Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
---
 .../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 <jszhang@kernel.org>
+
+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

Re: [PATCH v4 06/10] dt-bindings: riscv: Add bouffalolab bl808 board compatibles

[Samuel Holland]

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 <jszhang@kernel.org>
> Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
> ---
>  .../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 <jszhang@kernel.org>
> +
> +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

Re: [PATCH v4 06/10] dt-bindings: riscv: Add bouffalolab bl808 board compatibles

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 4670 bytes --]

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 <jszhang@kernel.org>
> > Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
> > Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
> > ---
> >  .../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 <jszhang@kernel.org>
> > +
> > +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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v4 06/10] dt-bindings: riscv: Add bouffalolab bl808 board compatibles

[Jisheng Zhang]

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 <jszhang@kernel.org>
> > > Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
> > > Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
> > > ---
> > >  .../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 <jszhang@kernel.org>
> > > +
> > > +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.

Re: [PATCH v4 06/10] dt-bindings: riscv: Add bouffalolab bl808 board compatibles

[Jisheng Zhang]

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 <jszhang@kernel.org>
> > > > Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
> > > > Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
> > > > ---
> > > >  .../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 <jszhang@kernel.org>
> > > > +
> > > > +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.
> 
> 

Re: [PATCH v4 06/10] dt-bindings: riscv: Add bouffalolab bl808 board compatibles

[Rob Herring]

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 <jszhang@kernel.org>
> > Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
> > Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
> > ---
> >  .../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 <jszhang@kernel.org>
> > +
> > +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

[PATCH v4 07/10] riscv: dts: bouffalolab: add the bl808 SoC base device tree

[Jisheng Zhang]

Add a baisc dtsi for the bouffalolab bl808 SoC.

Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
---
 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 <jszhang@kernel.org>
+ */
+
+#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

Re: [PATCH v4 07/10] riscv: dts: bouffalolab: add the bl808 SoC base device tree

[Samuel Holland]

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 <jszhang@kernel.org>
> Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
> ---
>  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 <jszhang@kernel.org>
> + */
> +
> +#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>;
> +		};
> +	};
> +};

[PATCH v4 08/10] riscv: dts: bouffalolab: add Sipeed M1s SoM and Dock devicetree

[Jisheng Zhang]

Sipeed manufactures a M1s system-on-module and dock board, add basic
support for them.

Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
---
 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 <jszhang@kernel.org>
+ */
+
+/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 <jszhang@kernel.org>
+ */
+
+/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

Re: [PATCH v4 08/10] riscv: dts: bouffalolab: add Sipeed M1s SoM and Dock devicetree

[Samuel Holland]

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 <jszhang@kernel.org>
> Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
> ---
>  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 <jszhang@kernel.org>
> + */
> +
> +/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 <jszhang@kernel.org>
> + */
> +
> +/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>;
> +};

Re: [PATCH v4 08/10] riscv: dts: bouffalolab: add Sipeed M1s SoM and Dock devicetree

[Jisheng Zhang]

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 <jszhang@kernel.org>
> > Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
> > ---
> >  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 <jszhang@kernel.org>
> > + */
> > +
> > +/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 <jszhang@kernel.org>
> > + */
> > +
> > +/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>;
> > +};
> 

[PATCH v4 09/10] MAINTAINERS: riscv: add entry for Bouffalolab SoC

[Jisheng Zhang]

Add Jisheng Zhang as Bouffalolab SoC maintainer.

Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
---
 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 <jszhang@kernel.org>
+L:	linux-riscv@lists.infradead.org
+S:	Maintained
+F:	arch/riscv/boot/dts/bouffalolab/
+F:	drivers/tty/serial/bflb_uart.c
+
 RISC-V MICROCHIP FPGA SUPPORT
 M:	Conor Dooley <conor.dooley@microchip.com>
 M:	Daire McNamara <daire.mcnamara@microchip.com>
-- 
2.40.0

[PATCH v4 10/10] riscv: defconfig: enable BOUFFALOLAB SoC

[Jisheng Zhang]

Enable BOUFFALOLAB soc config in defconfig to allow the default
upstream kernel to boot on Sipeed M1s Dock board.

Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
---
 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