[PATCH v1 0/9] riscv: add initial support for SpacemiT K1

[PATCH v1 0/9] riscv: add initial support for SpacemiT K1

[Yangyu Chen]

SpacemiT K1 is an ideal chip for some new extension such as RISC-V Vector
1.0 and Zicond evaluation now. Add initial support for it to allow more
people to participate in building drivers to mainline for it.

This kernel has been tested upon Banana Pi BPI-F3 board on vendor U-Boot
bootflow generated by Armbian SDK[1] and patched OpenSBI[2] to enable
Zicboz, which does not in the vendor dts on its U-Boot. Then successfully
booted to busybox on initrd with this log[3].

[1] https://github.com/BPI-SINOVOIP/armbian-build/tree/v24.04.30
[2] https://gist.github.com/cyyself/a07096e6e99c949ed13f8fa16d884402
[3] https://gist.github.com/cyyself/a2201c01f5c8955a119641f97b7d0280

Yangyu Chen (9):
  dt-bindings: vendor-prefixes: add spacemit
  dt-bindings: riscv: Add SpacemiT X60 compatibles
  dt-bindings: riscv: add SpacemiT K1 bindings
  dt-bindings: timer: Add SpacemiT K1 CLINT
  dt-bindings: interrupt-controller: Add SpacemiT K1 PLIC
  riscv: add SpacemiT SOC family Kconfig support
  riscv: dts: add initial SpacemiT K1 SoC device tree
  riscv: dts: spacemit: add Banana Pi BPI-F3 board device tree
  riscv: defconfig: enable SpacemiT SoC

 .../sifive,plic-1.0.0.yaml                    |   5 +-
 .../devicetree/bindings/riscv/cpus.yaml       |   1 +
 .../devicetree/bindings/riscv/spacemit.yaml   |  24 ++
 .../bindings/timer/sifive,clint.yaml          |   4 +-
 .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
 arch/riscv/Kconfig.socs                       |   5 +
 arch/riscv/boot/dts/Makefile                  |   1 +
 arch/riscv/boot/dts/spacemit/Makefile         |   2 +
 arch/riscv/boot/dts/spacemit/bananapi-f3.dts  |  19 ++
 arch/riscv/boot/dts/spacemit/k1.dtsi          | 281 ++++++++++++++++++
 arch/riscv/configs/defconfig                  |   1 +
 11 files changed, 343 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/riscv/spacemit.yaml
 create mode 100644 arch/riscv/boot/dts/spacemit/Makefile
 create mode 100644 arch/riscv/boot/dts/spacemit/bananapi-f3.dts
 create mode 100644 arch/riscv/boot/dts/spacemit/k1.dtsi

-- 
2.45.1

[PATCH v1 1/9] dt-bindings: vendor-prefixes: add spacemit

[Yangyu Chen]

Add new vendor strings to dt bindings for SpacemiT K1 SoC.

Link: https://www.spacemit.com/en/spacemit-key-stone-2/

Signed-off-by: Yangyu Chen <cyy@cyyself.name>
---
 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 fbf47f0bacf1..7ee6e4a89376 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -1362,6 +1362,8 @@ patternProperties:
     description: Sophgo Technology Inc.
   "^sourceparts,.*":
     description: Source Parts Inc.
+  "^spacemit,.*":
+    description: SpacemiT (Hangzhou) Technology Co. Ltd
   "^spansion,.*":
     description: Spansion Inc.
   "^sparkfun,.*":
-- 
2.45.1

Re: [PATCH v1 1/9] dt-bindings: vendor-prefixes: add spacemit

[Conor Dooley]

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

On Mon, Jun 17, 2024 at 01:20:46AM +0800, Yangyu Chen wrote:
> Add new vendor strings to dt bindings for SpacemiT K1 SoC.
> 
> Link: https://www.spacemit.com/en/spacemit-key-stone-2/
> 
> Signed-off-by: Yangyu Chen <cyy@cyyself.name>

Same nit here.
Acked-by: Conor Dooley <conor.dooley@microchip.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 fbf47f0bacf1..7ee6e4a89376 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -1362,6 +1362,8 @@ patternProperties:
>      description: Sophgo Technology Inc.
>    "^sourceparts,.*":
>      description: Source Parts Inc.
> +  "^spacemit,.*":
> +    description: SpacemiT (Hangzhou) Technology Co. Ltd
>    "^spansion,.*":
>      description: Spansion Inc.
>    "^sparkfun,.*":
> -- 
> 2.45.1
> 

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

[PATCH v1 2/9] dt-bindings: riscv: Add SpacemiT X60 compatibles

[Yangyu Chen]

The X60 is RISC-V CPU cores from SpacemiT and currently used in their K1
SoC.

Link: https://www.spacemit.com/en/spacemit-x60-core/

Signed-off-by: Yangyu Chen <cyy@cyyself.name>
---
 Documentation/devicetree/bindings/riscv/cpus.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
index d87dd50f1a4b..5ad9cb410335 100644
--- a/Documentation/devicetree/bindings/riscv/cpus.yaml
+++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
@@ -46,6 +46,7 @@ properties:
               - sifive,u7
               - sifive,u74
               - sifive,u74-mc
+              - spacemit,x60
               - thead,c906
               - thead,c910
               - thead,c920
-- 
2.45.1

Re: [PATCH v1 2/9] dt-bindings: riscv: Add SpacemiT X60 compatibles

[Conor Dooley]

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

On Mon, Jun 17, 2024 at 01:20:47AM +0800, Yangyu Chen wrote:
> The X60 is RISC-V CPU cores from SpacemiT and currently used in their K1
> SoC.
> 
> Link: https://www.spacemit.com/en/spacemit-x60-core/
> 

nit: Delete the blank line

> Signed-off-by: Yangyu Chen <cyy@cyyself.name>

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

> ---
>  Documentation/devicetree/bindings/riscv/cpus.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
> index d87dd50f1a4b..5ad9cb410335 100644
> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml
> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
> @@ -46,6 +46,7 @@ properties:
>                - sifive,u7
>                - sifive,u74
>                - sifive,u74-mc
> +              - spacemit,x60
>                - thead,c906
>                - thead,c910
>                - thead,c920
> -- 
> 2.45.1
> 

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

[PATCH v1 3/9] dt-bindings: riscv: add SpacemiT K1 bindings

[Yangyu Chen]

Add DT binding documentation for the SpacemiT K1 Soc[1] and the Banana
Pi BPi-F3 board[2] which used it.

[1] https://www.spacemit.com/en/spacemit-key-stone-2/
[2] https://docs.banana-pi.org/en/BPI-F3/BananaPi_BPI-F3

Signed-off-by: Yangyu Chen <cyy@cyyself.name>
---
 .../devicetree/bindings/riscv/spacemit.yaml   | 24 +++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/riscv/spacemit.yaml

diff --git a/Documentation/devicetree/bindings/riscv/spacemit.yaml b/Documentation/devicetree/bindings/riscv/spacemit.yaml
new file mode 100644
index 000000000000..3b151fd02473
--- /dev/null
+++ b/Documentation/devicetree/bindings/riscv/spacemit.yaml
@@ -0,0 +1,24 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/riscv/spacemit.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SpacemiT SoC-based boards
+
+description:
+  SpacemiT SoC-based boards
+
+properties:
+  $nodename:
+    const: '/'
+  compatible:
+    oneOf:
+      - items:
+          - enum:
+              - bananapi,bpi-f3
+          - const: spacemit,k1
+
+additionalProperties: true
+
+...
-- 
2.45.1

Re: [PATCH v1 3/9] dt-bindings: riscv: add SpacemiT K1 bindings

[Rob Herring (Arm)]

On Mon, 17 Jun 2024 01:20:48 +0800, Yangyu Chen wrote:
> Add DT binding documentation for the SpacemiT K1 Soc[1] and the Banana
> Pi BPi-F3 board[2] which used it.
> 
> [1] https://www.spacemit.com/en/spacemit-key-stone-2/
> [2] https://docs.banana-pi.org/en/BPI-F3/BananaPi_BPI-F3
> 
> Signed-off-by: Yangyu Chen <cyy@cyyself.name>
> ---
>  .../devicetree/bindings/riscv/spacemit.yaml   | 24 +++++++++++++++++++
>  1 file changed, 24 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/riscv/spacemit.yaml
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:

dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/riscv/spacemit.yaml: 'maintainers' is a required property
	hint: Metaschema for devicetree binding documentation
	from schema $id: http://devicetree.org/meta-schemas/base.yaml#

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/tencent_D3577BC67116D732862BE4A7B187EF4ED005@qq.com

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.

Re: [PATCH v1 3/9] dt-bindings: riscv: add SpacemiT K1 bindings

[Conor Dooley]

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

On Sun, Jun 16, 2024 at 12:42:00PM -0600, Rob Herring (Arm) wrote:
> 
> On Mon, 17 Jun 2024 01:20:48 +0800, Yangyu Chen wrote:
> > Add DT binding documentation for the SpacemiT K1 Soc[1] and the Banana
> > Pi BPi-F3 board[2] which used it.
> > 
> > [1] https://www.spacemit.com/en/spacemit-key-stone-2/
> > [2] https://docs.banana-pi.org/en/BPI-F3/BananaPi_BPI-F3
> > 
> > Signed-off-by: Yangyu Chen <cyy@cyyself.name>
> > ---
> >  .../devicetree/bindings/riscv/spacemit.yaml   | 24 +++++++++++++++++++
> >  1 file changed, 24 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/riscv/spacemit.yaml
> > 
> 
> My bot found errors running 'make dt_binding_check' on your patch:
> 
> yamllint warnings/errors:
> 
> dtschema/dtc warnings/errors:
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/riscv/spacemit.yaml: 'maintainers' is a required property

Whoever takes on platform maintainership should add themseves here.

> 	hint: Metaschema for devicetree binding documentation
> 	from schema $id: http://devicetree.org/meta-schemas/base.yaml#
> 
> doc reference errors (make refcheckdocs):
> 
> See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/tencent_D3577BC67116D732862BE4A7B187EF4ED005@qq.com
> 
> The base for the series is generally the latest rc1. A different dependency
> should be noted in *this* patch.
> 
> If you already ran 'make dt_binding_check' and didn't see the above
> error(s), then make sure 'yamllint' is installed and dt-schema is up to
> date:
> 
> pip3 install dtschema --upgrade
> 
> Please check and re-submit after running the above command yourself. Note
> that DT_SCHEMA_FILES can be set to your schema file to speed up checking
> your schema. However, it must be unset to test all examples with your schema.
> 

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

[PATCH v1 4/9] dt-bindings: timer: Add SpacemiT K1 CLINT

[Yangyu Chen]

Add compatible string for SpacemiT K1 CLINT.

Signed-off-by: Yangyu Chen <cyy@cyyself.name>
---
 Documentation/devicetree/bindings/timer/sifive,clint.yaml | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/timer/sifive,clint.yaml b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
index fced6f2d8ecb..860cf6a96b31 100644
--- a/Documentation/devicetree/bindings/timer/sifive,clint.yaml
+++ b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
@@ -43,7 +43,9 @@ properties:
               - thead,th1520-clint
           - const: thead,c900-clint
       - items:
-          - const: sifive,clint0
+          - enum:
+              - sifive,clint0
+              - spacemit,k1-clint
           - const: riscv,clint0
         deprecated: true
         description: For the QEMU virt machine only
-- 
2.45.1

Re: [PATCH v1 4/9] dt-bindings: timer: Add SpacemiT K1 CLINT

[Conor Dooley]

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

On Mon, Jun 17, 2024 at 01:20:49AM +0800, Yangyu Chen wrote:
> Add compatible string for SpacemiT K1 CLINT.
> 
> Signed-off-by: Yangyu Chen <cyy@cyyself.name>

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

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

Re: [PATCH v1 4/9] dt-bindings: timer: Add SpacemiT K1 CLINT

[Yangyu Chen]

> On Jun 18, 2024, at 23:40, Conor Dooley <conor@kernel.org> wrote:
> 
> On Mon, Jun 17, 2024 at 01:20:49AM +0800, Yangyu Chen wrote:
>> Add compatible string for SpacemiT K1 CLINT.
>> 
>> Signed-off-by: Yangyu Chen <cyy@cyyself.name>
> 
> Acked-by: Conor Dooley <conor.dooley@microchip.com>

Actually, I'm not confident about this after carefully reviewing
the file. The "riscv,clint0" is marked deprecated, and the description
is For the QEMU virtual machine only.

Re: [PATCH v1 4/9] dt-bindings: timer: Add SpacemiT K1 CLINT

[Conor Dooley]

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

On Tue, Jun 18, 2024 at 11:48:26PM +0800, Yangyu Chen wrote:
> 
> > On Jun 18, 2024, at 23:40, Conor Dooley <conor@kernel.org> wrote:
> > 
> > On Mon, Jun 17, 2024 at 01:20:49AM +0800, Yangyu Chen wrote:
> >> Add compatible string for SpacemiT K1 CLINT.
> >> 
> >> Signed-off-by: Yangyu Chen <cyy@cyyself.name>
> > 
> > Acked-by: Conor Dooley <conor.dooley@microchip.com>
> 
> Actually, I'm not confident about this after carefully reviewing
> the file. The "riscv,clint0" is marked deprecated, and the description
> is For the QEMU virtual machine only.

Right, I forgot about that portion of it. Probably, if this is sifive
plic compatible, then fall back to the sifive clint. Same, I suppose,
goes for the plic etc. The alternative is not have a fallback, modify
the driver, and future spacemit things will fall back to the k1's
compatible. I don't mind which you go for.

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

[PATCH v1 5/9] dt-bindings: interrupt-controller: Add SpacemiT K1 PLIC

[Yangyu Chen]

Add compatible string for SpacemiT K1 PLIC.

Signed-off-by: Yangyu Chen <cyy@cyyself.name>
---
 .../bindings/interrupt-controller/sifive,plic-1.0.0.yaml     | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

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 709b2211276b..3d0426b56904 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
@@ -59,6 +59,7 @@ properties:
           - enum:
               - canaan,k210-plic
               - sifive,fu540-c000-plic
+              - spacemit,k1-plic
               - starfive,jh7100-plic
               - starfive,jh7110-plic
           - const: sifive,plic-1.0.0
@@ -71,7 +72,9 @@ properties:
               - thead,th1520-plic
           - const: thead,c900-plic
       - items:
-          - const: sifive,plic-1.0.0
+          - enum:
+              - sifive,plic-1.0.0
+              - spacemit,k1-plic
           - const: riscv,plic0
         deprecated: true
         description: For the QEMU virt machine only
-- 
2.45.1

Re: [PATCH v1 5/9] dt-bindings: interrupt-controller: Add SpacemiT K1 PLIC

[Conor Dooley]

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

On Mon, Jun 17, 2024 at 01:20:50AM +0800, Yangyu Chen wrote:
> Add compatible string for SpacemiT K1 PLIC.
> 
> Signed-off-by: Yangyu Chen <cyy@cyyself.name>
> ---
>  .../bindings/interrupt-controller/sifive,plic-1.0.0.yaml     | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> 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 709b2211276b..3d0426b56904 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
> @@ -59,6 +59,7 @@ properties:
>            - enum:
>                - canaan,k210-plic
>                - sifive,fu540-c000-plic
> +              - spacemit,k1-plic
>                - starfive,jh7100-plic
>                - starfive,jh7110-plic
>            - const: sifive,plic-1.0.0
> @@ -71,7 +72,9 @@ properties:
>                - thead,th1520-plic
>            - const: thead,c900-plic
>        - items:
> -          - const: sifive,plic-1.0.0
> +          - enum:
> +              - sifive,plic-1.0.0
> +              - spacemit,k1-plic

Why in two places? This isn't sifive IP, so I think we should go with
this one here.

>            - const: riscv,plic0
>          deprecated: true
>          description: For the QEMU virt machine only
> -- 
> 2.45.1
> 

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

[PATCH v1 6/9] riscv: add SpacemiT SOC family Kconfig support

[Yangyu Chen]

The first SoC in the SpacemiT series is K1, which contains 8 RISC-V
cores with RISC-V Vector v1.0 support.

Link: https://www.spacemit.com/en/spacemit-key-stone-2/

Signed-off-by: Yangyu Chen <cyy@cyyself.name>
---
 arch/riscv/Kconfig.socs | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
index f51bb24bc84c..8a5775586845 100644
--- a/arch/riscv/Kconfig.socs
+++ b/arch/riscv/Kconfig.socs
@@ -24,6 +24,11 @@ config ARCH_SOPHGO
 	help
 	  This enables support for Sophgo SoC platform hardware.
 
+config ARCH_SPACEMIT
+	bool "Sophgo SoCs"
+	help
+	  This enables support for SpacemiT SoC platform hardware.
+
 config ARCH_STARFIVE
 	def_bool SOC_STARFIVE
 
-- 
2.45.1

Re: [PATCH v1 6/9] riscv: add SpacemiT SOC family Kconfig support

[Yixun Lan]

On 01:20 Mon 17 Jun     , Yangyu Chen wrote:
> The first SoC in the SpacemiT series is K1, which contains 8 RISC-V
> cores with RISC-V Vector v1.0 support.
> 
> Link: https://www.spacemit.com/en/spacemit-key-stone-2/
> 
> Signed-off-by: Yangyu Chen <cyy@cyyself.name>
> ---
>  arch/riscv/Kconfig.socs | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
> index f51bb24bc84c..8a5775586845 100644
> --- a/arch/riscv/Kconfig.socs
> +++ b/arch/riscv/Kconfig.socs
> @@ -24,6 +24,11 @@ config ARCH_SOPHGO
>  	help
>  	  This enables support for Sophgo SoC platform hardware.
>  
> +config ARCH_SPACEMIT
> +	bool "Sophgo SoCs"
              ~~~~~ is this a copy & paste typo?
> +	help
> +	  This enables support for SpacemiT SoC platform hardware.
> +
>  config ARCH_STARFIVE
>  	def_bool SOC_STARFIVE
>  
> -- 
> 2.45.1
> 

-- 
Yixun Lan (dlan)
Gentoo Linux Developer
GPG Key ID AABEFD55

Re: [PATCH v1 6/9] riscv: add SpacemiT SOC family Kconfig support

[Yangyu Chen]

> On Jun 17, 2024, at 06:26, Yixun Lan <dlan@gentoo.org> wrote:
> 
> On 01:20 Mon 17 Jun     , Yangyu Chen wrote:
>> The first SoC in the SpacemiT series is K1, which contains 8 RISC-V
>> cores with RISC-V Vector v1.0 support.
>> 
>> Link: https://www.spacemit.com/en/spacemit-key-stone-2/
>> 
>> Signed-off-by: Yangyu Chen <cyy@cyyself.name>
>> ---
>> arch/riscv/Kconfig.socs | 5 +++++
>> 1 file changed, 5 insertions(+)
>> 
>> diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
>> index f51bb24bc84c..8a5775586845 100644
>> --- a/arch/riscv/Kconfig.socs
>> +++ b/arch/riscv/Kconfig.socs
>> @@ -24,6 +24,11 @@ config ARCH_SOPHGO
>> help
>>  This enables support for Sophgo SoC platform hardware.
>> 
>> +config ARCH_SPACEMIT
>> + bool "Sophgo SoCs"
>              ~~~~~ is this a copy & paste typo?

Yes. I will fix them soon.

>> + help
>> +  This enables support for SpacemiT SoC platform hardware.
>> +
>> config ARCH_STARFIVE
>> def_bool SOC_STARFIVE
>> 
>> -- 
>> 2.45.1
>> 
> 
> -- 
> Yixun Lan (dlan)
> Gentoo Linux Developer
> GPG Key ID AABEFD55

Re: [PATCH v1 6/9] riscv: add SpacemiT SOC family Kconfig support

[Yixun Lan]

On 01:20 Mon 17 Jun     , Yangyu Chen wrote:

> The first SoC in the SpacemiT series is K1, which contains 8 RISC-V
> cores with RISC-V Vector v1.0 support.
> 
> Link: https://www.spacemit.com/en/spacemit-key-stone-2/
> 
> Signed-off-by: Yangyu Chen <cyy@cyyself.name>
> ---
>  arch/riscv/Kconfig.socs | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
> index f51bb24bc84c..8a5775586845 100644
> --- a/arch/riscv/Kconfig.socs
> +++ b/arch/riscv/Kconfig.socs
> @@ -24,6 +24,11 @@ config ARCH_SOPHGO
>  	help
>  	  This enables support for Sophgo SoC platform hardware.
>  
> +config ARCH_SPACEMIT

should this be SOC_SPACEMIT? as it contradict with patch [9/9]
> +	bool "Sophgo SoCs"
> +	help
> +	  This enables support for SpacemiT SoC platform hardware.
> +
>  config ARCH_STARFIVE
>  	def_bool SOC_STARFIVE
>  
> -- 
> 2.45.1
> 

-- 
Yixun Lan (dlan)
Gentoo Linux Developer
GPG Key ID AABEFD55

Re: [PATCH v1 6/9] riscv: add SpacemiT SOC family Kconfig support

[Yangyu Chen]

> On Jun 17, 2024, at 07:06, Yixun Lan <dlan@gentoo.org> wrote:
> 
> On 01:20 Mon 17 Jun     , Yangyu Chen wrote:
> 
>> The first SoC in the SpacemiT series is K1, which contains 8 RISC-V
>> cores with RISC-V Vector v1.0 support.
>> 
>> Link: https://www.spacemit.com/en/spacemit-key-stone-2/
>> 
>> Signed-off-by: Yangyu Chen <cyy@cyyself.name>
>> ---
>> arch/riscv/Kconfig.socs | 5 +++++
>> 1 file changed, 5 insertions(+)
>> 
>> diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
>> index f51bb24bc84c..8a5775586845 100644
>> --- a/arch/riscv/Kconfig.socs
>> +++ b/arch/riscv/Kconfig.socs
>> @@ -24,6 +24,11 @@ config ARCH_SOPHGO
>> help
>>  This enables support for Sophgo SoC platform hardware.
>> 
>> +config ARCH_SPACEMIT
> 
> should this be SOC_SPACEMIT? as it contradict with patch [9/9]

Oh. It’s my fault. It should be ARCH_SPACEMIT on patch [9/9].

>> + bool "Sophgo SoCs"
>> + help
>> +  This enables support for SpacemiT SoC platform hardware.
>> +
>> config ARCH_STARFIVE
>> def_bool SOC_STARFIVE
>> 
>> -- 
>> 2.45.1
>> 
> 
> -- 
> Yixun Lan (dlan)
> Gentoo Linux Developer
> GPG Key ID AABEFD55

[PATCH v1 7/9] riscv: dts: add initial SpacemiT K1 SoC device tree

[Yangyu Chen]

Banana Pi BPI-F3 motherboard is powered by SpacemiT K1[1].

Key features:
- 4 cores per cluster, 2 clusters on chip
- UART IP is Intel XScale UART

Some key considerations:
- ISA string is inferred from vendor documentation[2]
- Cluster topology is inferred from datasheet[1] and L2 in vendor dts[3]
- No coherent DMA on this board
    Inferred by taking vendor ethernet and MMC drivers to the mainline
    kernel. Without dma-noncoherent in soc node, the driver fails.
- No cache nodes now
    The parameters from vendor dts are likely to be wrong. It has 512
    sets for a 32KiB L1 Cache. In this case, each set is 64B in size.
    When the size of the cache line is 64B, it is a directly mapped
    cache rather than a set-associative cache, the latter is commonly
    used. Thus, I didn't use the parameters from vendor dts.

Currently only support booting into console with only uart, other
features will be added soon later.

[1] https://docs.banana-pi.org/en/BPI-F3/SpacemiT_K1_datasheet
[2] https://developer.spacemit.com/#/documentation?token=BWbGwbx7liGW21kq9lucSA6Vnpb
[3] https://gitee.com/bianbu-linux/linux-6.1/blob/bl-v1.0.y/arch/riscv/boot/dts/spacemit/k1-x.dtsi

Signed-off-by: Yangyu Chen <cyy@cyyself.name>
---
 arch/riscv/boot/dts/spacemit/k1.dtsi | 281 +++++++++++++++++++++++++++
 1 file changed, 281 insertions(+)
 create mode 100644 arch/riscv/boot/dts/spacemit/k1.dtsi

diff --git a/arch/riscv/boot/dts/spacemit/k1.dtsi b/arch/riscv/boot/dts/spacemit/k1.dtsi
new file mode 100644
index 000000000000..58f9e143c659
--- /dev/null
+++ b/arch/riscv/boot/dts/spacemit/k1.dtsi
@@ -0,0 +1,281 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+/*
+ * Copyright (C) 2024 Yangyu Chen <cyy@cyyself.name>
+ */
+
+/dts-v1/;
+/ {
+	#address-cells = <2>;
+	#size-cells = <2>;
+	model = "SpacemiT K1";
+	compatible = "spacemit,k1";
+
+	aliases {
+		serial0 = &uart0;
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		timebase-frequency = <10000000>;
+
+		cpu-map {
+			cluster0 {
+				core0 {
+					cpu = <&cpu_0>;
+				};
+				core1 {
+					cpu = <&cpu_1>;
+				};
+				core2 {
+					cpu = <&cpu_2>;
+				};
+				core3 {
+					cpu = <&cpu_3>;
+				};
+			};
+
+			cluster1 {
+				core0 {
+					cpu = <&cpu_4>;
+				};
+				core1 {
+					cpu = <&cpu_5>;
+				};
+				core2 {
+					cpu = <&cpu_6>;
+				};
+				core3 {
+					cpu = <&cpu_7>;
+				};
+			};
+		};
+
+		cpu_0: cpu@0 {
+			compatible = "spacemit,x60", "riscv";
+			device_type = "cpu";
+			reg = <0>;
+			riscv,isa = "rv64imafdcv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
+			riscv,isa-base = "rv64i";
+			riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "v", "zicbom",
+					       "zicbop", "zicboz", "zicntr", "zicond", "zicsr",
+					       "zifencei", "zihintpause", "zihpm", "zfh", "zba",
+					       "zbb", "zbc", "zbs", "zkt", "zvfh", "zvkt",
+					       "sscofpmf", "sstc", "svinval", "svnapot", "svpbmt";
+			riscv,cbom-block-size = <64>;
+			riscv,cbop-block-size = <64>;
+			riscv,cboz-block-size = <64>;
+			mmu-type = "riscv,sv39";
+
+			cpu0_intc: interrupt-controller {
+				compatible = "riscv,cpu-intc";
+				interrupt-controller;
+				#interrupt-cells = <1>;
+			};
+		};
+		cpu_1: cpu@1 {
+			compatible = "spacemit,x60", "riscv";
+			device_type = "cpu";
+			reg = <1>;
+			riscv,isa = "rv64imafdcv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
+			riscv,isa-base = "rv64i";
+			riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "v", "zicbom",
+					       "zicbop", "zicboz", "zicntr", "zicond", "zicsr",
+					       "zifencei", "zihintpause", "zihpm", "zfh", "zba",
+					       "zbb", "zbc", "zbs", "zkt", "zvfh", "zvkt",
+					       "sscofpmf", "sstc", "svinval", "svnapot", "svpbmt";
+			riscv,cbom-block-size = <64>;
+			riscv,cbop-block-size = <64>;
+			riscv,cboz-block-size = <64>;
+			mmu-type = "riscv,sv39";
+
+			cpu1_intc: interrupt-controller {
+				compatible = "riscv,cpu-intc";
+				interrupt-controller;
+				#interrupt-cells = <1>;
+			};
+		};
+		cpu_2: cpu@2 {
+			compatible = "spacemit,x60", "riscv";
+			device_type = "cpu";
+			reg = <2>;
+			riscv,isa = "rv64imafdcv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
+			riscv,isa-base = "rv64i";
+			riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "v", "zicbom",
+					       "zicbop", "zicboz", "zicntr", "zicond", "zicsr",
+					       "zifencei", "zihintpause", "zihpm", "zfh", "zba",
+					       "zbb", "zbc", "zbs", "zkt", "zvfh", "zvkt",
+					       "sscofpmf", "sstc", "svinval", "svnapot", "svpbmt";
+			riscv,cbom-block-size = <64>;
+			riscv,cbop-block-size = <64>;
+			riscv,cboz-block-size = <64>;
+			mmu-type = "riscv,sv39";
+
+			cpu2_intc: interrupt-controller {
+				compatible = "riscv,cpu-intc";
+				interrupt-controller;
+				#interrupt-cells = <1>;
+			};
+		};
+		cpu_3: cpu@3 {
+			compatible = "spacemit,x60", "riscv";
+			device_type = "cpu";
+			reg = <3>;
+			riscv,isa = "rv64imafdcv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
+			riscv,isa-base = "rv64i";
+			riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "v", "zicbom",
+					       "zicbop", "zicboz", "zicntr", "zicond", "zicsr",
+					       "zifencei", "zihintpause", "zihpm", "zfh", "zba",
+					       "zbb", "zbc", "zbs", "zkt", "zvfh", "zvkt",
+					       "sscofpmf", "sstc", "svinval", "svnapot", "svpbmt";
+			riscv,cbom-block-size = <64>;
+			riscv,cbop-block-size = <64>;
+			riscv,cboz-block-size = <64>;
+			mmu-type = "riscv,sv39";
+
+			cpu3_intc: interrupt-controller {
+				compatible = "riscv,cpu-intc";
+				interrupt-controller;
+				#interrupt-cells = <1>;
+			};
+		};
+		cpu_4: cpu@4 {
+			compatible = "spacemit,x60", "riscv";
+			device_type = "cpu";
+			reg = <4>;
+			riscv,isa = "rv64imafdcv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
+			riscv,isa-base = "rv64i";
+			riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "v", "zicbom",
+					       "zicbop", "zicboz", "zicntr", "zicond", "zicsr",
+					       "zifencei", "zihintpause", "zihpm", "zfh", "zba",
+					       "zbb", "zbc", "zbs", "zkt", "zvfh", "zvkt",
+					       "sscofpmf", "sstc", "svinval", "svnapot", "svpbmt";
+			riscv,cbom-block-size = <64>;
+			riscv,cbop-block-size = <64>;
+			riscv,cboz-block-size = <64>;
+			mmu-type = "riscv,sv39";
+
+			cpu4_intc: interrupt-controller {
+				compatible = "riscv,cpu-intc";
+				interrupt-controller;
+				#interrupt-cells = <1>;
+			};
+		};
+		cpu_5: cpu@5 {
+			compatible = "spacemit,x60", "riscv";
+			device_type = "cpu";
+			reg = <5>;
+			riscv,isa = "rv64imafdcv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
+			riscv,isa-base = "rv64i";
+			riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "v", "zicbom",
+					       "zicbop", "zicboz", "zicntr", "zicond", "zicsr",
+					       "zifencei", "zihintpause", "zihpm", "zfh", "zba",
+					       "zbb", "zbc", "zbs", "zkt", "zvfh", "zvkt",
+					       "sscofpmf", "sstc", "svinval", "svnapot", "svpbmt";
+			riscv,cbom-block-size = <64>;
+			riscv,cbop-block-size = <64>;
+			riscv,cboz-block-size = <64>;
+			mmu-type = "riscv,sv39";
+
+			cpu5_intc: interrupt-controller {
+				compatible = "riscv,cpu-intc";
+				interrupt-controller;
+				#interrupt-cells = <1>;
+			};
+		};
+		cpu_6: cpu@6 {
+			compatible = "spacemit,x60", "riscv";
+			device_type = "cpu";
+			reg = <6>;
+			riscv,isa = "rv64imafdcv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
+			riscv,isa-base = "rv64i";
+			riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "v", "zicbom",
+					       "zicbop", "zicboz", "zicntr", "zicond", "zicsr",
+					       "zifencei", "zihintpause", "zihpm", "zfh", "zba",
+					       "zbb", "zbc", "zbs", "zkt", "zvfh", "zvkt",
+					       "sscofpmf", "sstc", "svinval", "svnapot", "svpbmt";
+			riscv,cbom-block-size = <64>;
+			riscv,cbop-block-size = <64>;
+			riscv,cboz-block-size = <64>;
+			mmu-type = "riscv,sv39";
+
+			cpu6_intc: interrupt-controller {
+				compatible = "riscv,cpu-intc";
+				interrupt-controller;
+				#interrupt-cells = <1>;
+			};
+		};
+		cpu_7: cpu@7 {
+			compatible = "spacemit,x60", "riscv";
+			device_type = "cpu";
+			reg = <7>;
+			riscv,isa = "rv64imafdcv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
+			riscv,isa-base = "rv64i";
+			riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "v", "zicbom",
+					       "zicbop", "zicboz", "zicntr", "zicond", "zicsr",
+					       "zifencei", "zihintpause", "zihpm", "zfh", "zba",
+					       "zbb", "zbc", "zbs", "zkt", "zvfh", "zvkt",
+					       "sscofpmf", "sstc", "svinval", "svnapot", "svpbmt";
+			riscv,cbom-block-size = <64>;
+			riscv,cbop-block-size = <64>;
+			riscv,cboz-block-size = <64>;
+			mmu-type = "riscv,sv39";
+
+			cpu7_intc: interrupt-controller {
+				compatible = "riscv,cpu-intc";
+				interrupt-controller;
+				#interrupt-cells = <1>;
+			};
+		};
+
+	};
+
+	soc {
+		compatible = "simple-bus";
+		interrupt-parent = <&plic>;
+		#address-cells = <2>;
+		#size-cells = <2>;
+		dma-noncoherent;
+		ranges;
+
+		plic: interrupt-controller@e0000000 {
+			compatible = "spacemit,k1-plic", "riscv,plic0";
+			reg = <0x0 0xe0000000 0x0 0x4000000>;
+			interrupts-extended = <&cpu0_intc 11>, <&cpu0_intc 9>,
+					      <&cpu1_intc 11>, <&cpu1_intc 9>,
+					      <&cpu2_intc 11>, <&cpu2_intc 9>,
+					      <&cpu3_intc 11>, <&cpu3_intc 9>,
+					      <&cpu4_intc 11>, <&cpu4_intc 9>,
+					      <&cpu5_intc 11>, <&cpu5_intc 9>,
+					      <&cpu6_intc 11>, <&cpu6_intc 9>,
+					      <&cpu7_intc 11>, <&cpu7_intc 9>;
+			interrupt-controller;
+			#address-cells = <0>;
+			#interrupt-cells = <1>;
+			riscv,ndev = <159>;
+		};
+
+		clint: timer@e4000000 {
+			compatible = "spacemit,k1-clint", "riscv,clint0";
+			reg = <0x0 0xe4000000 0x0 010000>;
+			interrupts-extended = <&cpu0_intc 3>, <&cpu0_intc 7>,
+					      <&cpu1_intc 3>, <&cpu1_intc 7>,
+					      <&cpu2_intc 3>, <&cpu2_intc 7>,
+					      <&cpu3_intc 3>, <&cpu3_intc 7>,
+					      <&cpu4_intc 3>, <&cpu4_intc 7>,
+					      <&cpu5_intc 3>, <&cpu5_intc 7>,
+					      <&cpu6_intc 3>, <&cpu6_intc 7>,
+					      <&cpu7_intc 3>, <&cpu7_intc 7>;
+		};
+
+		uart0: serial@d4017000 {
+			compatible = "intel,xscale-uart";
+			reg = <0x0 0xd4017000 0x0 0x100>;
+			interrupts = <42>;
+			clock-frequency = <14000000>;
+			reg-shift = <2>;
+			reg-io-width = <4>;
+			status = "disabled";
+		};
+	};
+};
-- 
2.45.1

Re: [PATCH v1 7/9] riscv: dts: add initial SpacemiT K1 SoC device tree

[Yixun Lan]

On 01:20 Mon 17 Jun     , Yangyu Chen wrote:
> Banana Pi BPI-F3 motherboard is powered by SpacemiT K1[1].
> 
.. snip
> +		uart0: serial@d4017000 {
> +			compatible = "intel,xscale-uart";
are you sure the uart IP is fully compatible with xscale?
otherwise I'd suggest to introduce a vendor specific one..

> +			reg = <0x0 0xd4017000 0x0 0x100>;
> +			interrupts = <42>;
> +			clock-frequency = <14000000>;
> +			reg-shift = <2>;
> +			reg-io-width = <4>;
> +			status = "disabled";
> +		};
> +	};
> +};
it's better to also add other uart nodes, I feel it's more complete

-- 
Yixun Lan (dlan)
Gentoo Linux Developer
GPG Key ID AABEFD55

Re: [PATCH v1 7/9] riscv: dts: add initial SpacemiT K1 SoC device tree

[Yangyu Chen]

> On Jun 17, 2024, at 06:53, Yixun Lan <dlan@gentoo.org> wrote:
> 
> On 01:20 Mon 17 Jun     , Yangyu Chen wrote:
>> Banana Pi BPI-F3 motherboard is powered by SpacemiT K1[1].
>> 
> .. snip
>> + uart0: serial@d4017000 {
>> + compatible = "intel,xscale-uart";
> are you sure the uart IP is fully compatible with xscale?
> otherwise I'd suggest to introduce a vendor specific one..
> 

Sounds like a good idea. I will add it soon.

>> + reg = <0x0 0xd4017000 0x0 0x100>;
>> + interrupts = <42>;
>> + clock-frequency = <14000000>;
>> + reg-shift = <2>;
>> + reg-io-width = <4>;
>> + status = "disabled";
>> + };
>> + };
>> +};
> it's better to also add other uart nodes, I feel it's more complete
> 

I should test it before adding them. However, if I remember correctly,
there is only one UART on BPI-F3.

> -- 
> Yixun Lan (dlan)
> Gentoo Linux Developer
> GPG Key ID AABEFD55

Re: [PATCH v1 7/9] riscv: dts: add initial SpacemiT K1 SoC device tree

[Yixun Lan]

Hi Yangyu

On 10:10 Mon 17 Jun     , Yangyu Chen wrote:
> 
> 
> > On Jun 17, 2024, at 06:53, Yixun Lan <dlan@gentoo.org> wrote:
> > 
> > On 01:20 Mon 17 Jun     , Yangyu Chen wrote:
> >> Banana Pi BPI-F3 motherboard is powered by SpacemiT K1[1].
> >> 
> > .. snip
> >> + uart0: serial@d4017000 {
> >> + compatible = "intel,xscale-uart";
> > are you sure the uart IP is fully compatible with xscale?
> > otherwise I'd suggest to introduce a vendor specific one..
> > 
> 
> Sounds like a good idea. I will add it soon.
> 
> >> + reg = <0x0 0xd4017000 0x0 0x100>;
> >> + interrupts = <42>;
> >> + clock-frequency = <14000000>;
> >> + reg-shift = <2>;
> >> + reg-io-width = <4>;
> >> + status = "disabled";
> >> + };
> >> + };
> >> +};
> > it's better to also add other uart nodes, I feel it's more complete
> > 
> 
> I should test it before adding them. However, if I remember correctly,
> there is only one UART on BPI-F3.
I'm not talking about BPI-F3 specifically, but from the SoC perspective
you can check vendor's dts file of k1-x.dtsi, there are uart0-uart9(uart1 is
missing)..

> 
> > -- 
> > Yixun Lan (dlan)
> > Gentoo Linux Developer
> > GPG Key ID AABEFD55

-- 
Yixun Lan (dlan)
Gentoo Linux Developer
GPG Key ID AABEFD55

Re: [PATCH v1 7/9] riscv: dts: add initial SpacemiT K1 SoC device tree

[Conor Dooley]

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

On Sun, Jun 16, 2024 at 10:53:14PM +0000, Yixun Lan wrote:
> On 01:20 Mon 17 Jun     , Yangyu Chen wrote:
> > Banana Pi BPI-F3 motherboard is powered by SpacemiT K1[1].
> > 
> .. snip
> > +		uart0: serial@d4017000 {
> > +			compatible = "intel,xscale-uart";
> are you sure the uart IP is fully compatible with xscale?
> otherwise I'd suggest to introduce a vendor specific one..

Definitely add a soc-specific compatible here, even if fully compatible
with the xscale uart. There's a marvell device doing this already.

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

Re: [PATCH v1 7/9] riscv: dts: add initial SpacemiT K1 SoC device tree

[Jisheng Zhang]

On Mon, Jun 17, 2024 at 01:20:52AM +0800, Yangyu Chen wrote:
> Banana Pi BPI-F3 motherboard is powered by SpacemiT K1[1].
> 
> Key features:
> - 4 cores per cluster, 2 clusters on chip
> - UART IP is Intel XScale UART
> 
> Some key considerations:
> - ISA string is inferred from vendor documentation[2]
> - Cluster topology is inferred from datasheet[1] and L2 in vendor dts[3]
> - No coherent DMA on this board
>     Inferred by taking vendor ethernet and MMC drivers to the mainline
>     kernel. Without dma-noncoherent in soc node, the driver fails.
> - No cache nodes now
>     The parameters from vendor dts are likely to be wrong. It has 512
>     sets for a 32KiB L1 Cache. In this case, each set is 64B in size.
>     When the size of the cache line is 64B, it is a directly mapped
>     cache rather than a set-associative cache, the latter is commonly
>     used. Thus, I didn't use the parameters from vendor dts.
> 
> Currently only support booting into console with only uart, other
> features will be added soon later.

Hi Yangyu,

Per recent practice of cv1800b and th1520 upstream, I think a complete
initial support would include pinctrl, clk and reset, I have received
the complains from the community. So can you please bring the pinctrl
clk  and reset at the same time?

Thanks

> 
> [1] https://docs.banana-pi.org/en/BPI-F3/SpacemiT_K1_datasheet
> [2] https://developer.spacemit.com/#/documentation?token=BWbGwbx7liGW21kq9lucSA6Vnpb
> [3] https://gitee.com/bianbu-linux/linux-6.1/blob/bl-v1.0.y/arch/riscv/boot/dts/spacemit/k1-x.dtsi
> 
> Signed-off-by: Yangyu Chen <cyy@cyyself.name>
> ---
>  arch/riscv/boot/dts/spacemit/k1.dtsi | 281 +++++++++++++++++++++++++++
>  1 file changed, 281 insertions(+)
>  create mode 100644 arch/riscv/boot/dts/spacemit/k1.dtsi
> 
> diff --git a/arch/riscv/boot/dts/spacemit/k1.dtsi b/arch/riscv/boot/dts/spacemit/k1.dtsi
> new file mode 100644
> index 000000000000..58f9e143c659
> --- /dev/null
> +++ b/arch/riscv/boot/dts/spacemit/k1.dtsi
> @@ -0,0 +1,281 @@
> +// SPDX-License-Identifier: GPL-2.0 OR MIT
> +/*
> + * Copyright (C) 2024 Yangyu Chen <cyy@cyyself.name>
> + */
> +
> +/dts-v1/;
> +/ {
> +	#address-cells = <2>;
> +	#size-cells = <2>;
> +	model = "SpacemiT K1";
> +	compatible = "spacemit,k1";
> +
> +	aliases {
> +		serial0 = &uart0;
> +	};
> +
> +	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		timebase-frequency = <10000000>;
> +
> +		cpu-map {
> +			cluster0 {
> +				core0 {
> +					cpu = <&cpu_0>;
> +				};
> +				core1 {
> +					cpu = <&cpu_1>;
> +				};
> +				core2 {
> +					cpu = <&cpu_2>;
> +				};
> +				core3 {
> +					cpu = <&cpu_3>;
> +				};
> +			};
> +
> +			cluster1 {
> +				core0 {
> +					cpu = <&cpu_4>;
> +				};
> +				core1 {
> +					cpu = <&cpu_5>;
> +				};
> +				core2 {
> +					cpu = <&cpu_6>;
> +				};
> +				core3 {
> +					cpu = <&cpu_7>;
> +				};
> +			};
> +		};
> +
> +		cpu_0: cpu@0 {
> +			compatible = "spacemit,x60", "riscv";
> +			device_type = "cpu";
> +			reg = <0>;
> +			riscv,isa = "rv64imafdcv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
> +			riscv,isa-base = "rv64i";
> +			riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "v", "zicbom",
> +					       "zicbop", "zicboz", "zicntr", "zicond", "zicsr",
> +					       "zifencei", "zihintpause", "zihpm", "zfh", "zba",
> +					       "zbb", "zbc", "zbs", "zkt", "zvfh", "zvkt",
> +					       "sscofpmf", "sstc", "svinval", "svnapot", "svpbmt";
> +			riscv,cbom-block-size = <64>;
> +			riscv,cbop-block-size = <64>;
> +			riscv,cboz-block-size = <64>;
> +			mmu-type = "riscv,sv39";
> +
> +			cpu0_intc: interrupt-controller {
> +				compatible = "riscv,cpu-intc";
> +				interrupt-controller;
> +				#interrupt-cells = <1>;
> +			};
> +		};
> +		cpu_1: cpu@1 {
> +			compatible = "spacemit,x60", "riscv";
> +			device_type = "cpu";
> +			reg = <1>;
> +			riscv,isa = "rv64imafdcv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
> +			riscv,isa-base = "rv64i";
> +			riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "v", "zicbom",
> +					       "zicbop", "zicboz", "zicntr", "zicond", "zicsr",
> +					       "zifencei", "zihintpause", "zihpm", "zfh", "zba",
> +					       "zbb", "zbc", "zbs", "zkt", "zvfh", "zvkt",
> +					       "sscofpmf", "sstc", "svinval", "svnapot", "svpbmt";
> +			riscv,cbom-block-size = <64>;
> +			riscv,cbop-block-size = <64>;
> +			riscv,cboz-block-size = <64>;
> +			mmu-type = "riscv,sv39";
> +
> +			cpu1_intc: interrupt-controller {
> +				compatible = "riscv,cpu-intc";
> +				interrupt-controller;
> +				#interrupt-cells = <1>;
> +			};
> +		};
> +		cpu_2: cpu@2 {
> +			compatible = "spacemit,x60", "riscv";
> +			device_type = "cpu";
> +			reg = <2>;
> +			riscv,isa = "rv64imafdcv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
> +			riscv,isa-base = "rv64i";
> +			riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "v", "zicbom",
> +					       "zicbop", "zicboz", "zicntr", "zicond", "zicsr",
> +					       "zifencei", "zihintpause", "zihpm", "zfh", "zba",
> +					       "zbb", "zbc", "zbs", "zkt", "zvfh", "zvkt",
> +					       "sscofpmf", "sstc", "svinval", "svnapot", "svpbmt";
> +			riscv,cbom-block-size = <64>;
> +			riscv,cbop-block-size = <64>;
> +			riscv,cboz-block-size = <64>;
> +			mmu-type = "riscv,sv39";
> +
> +			cpu2_intc: interrupt-controller {
> +				compatible = "riscv,cpu-intc";
> +				interrupt-controller;
> +				#interrupt-cells = <1>;
> +			};
> +		};
> +		cpu_3: cpu@3 {
> +			compatible = "spacemit,x60", "riscv";
> +			device_type = "cpu";
> +			reg = <3>;
> +			riscv,isa = "rv64imafdcv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
> +			riscv,isa-base = "rv64i";
> +			riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "v", "zicbom",
> +					       "zicbop", "zicboz", "zicntr", "zicond", "zicsr",
> +					       "zifencei", "zihintpause", "zihpm", "zfh", "zba",
> +					       "zbb", "zbc", "zbs", "zkt", "zvfh", "zvkt",
> +					       "sscofpmf", "sstc", "svinval", "svnapot", "svpbmt";
> +			riscv,cbom-block-size = <64>;
> +			riscv,cbop-block-size = <64>;
> +			riscv,cboz-block-size = <64>;
> +			mmu-type = "riscv,sv39";
> +
> +			cpu3_intc: interrupt-controller {
> +				compatible = "riscv,cpu-intc";
> +				interrupt-controller;
> +				#interrupt-cells = <1>;
> +			};
> +		};
> +		cpu_4: cpu@4 {
> +			compatible = "spacemit,x60", "riscv";
> +			device_type = "cpu";
> +			reg = <4>;
> +			riscv,isa = "rv64imafdcv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
> +			riscv,isa-base = "rv64i";
> +			riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "v", "zicbom",
> +					       "zicbop", "zicboz", "zicntr", "zicond", "zicsr",
> +					       "zifencei", "zihintpause", "zihpm", "zfh", "zba",
> +					       "zbb", "zbc", "zbs", "zkt", "zvfh", "zvkt",
> +					       "sscofpmf", "sstc", "svinval", "svnapot", "svpbmt";
> +			riscv,cbom-block-size = <64>;
> +			riscv,cbop-block-size = <64>;
> +			riscv,cboz-block-size = <64>;
> +			mmu-type = "riscv,sv39";
> +
> +			cpu4_intc: interrupt-controller {
> +				compatible = "riscv,cpu-intc";
> +				interrupt-controller;
> +				#interrupt-cells = <1>;
> +			};
> +		};
> +		cpu_5: cpu@5 {
> +			compatible = "spacemit,x60", "riscv";
> +			device_type = "cpu";
> +			reg = <5>;
> +			riscv,isa = "rv64imafdcv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
> +			riscv,isa-base = "rv64i";
> +			riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "v", "zicbom",
> +					       "zicbop", "zicboz", "zicntr", "zicond", "zicsr",
> +					       "zifencei", "zihintpause", "zihpm", "zfh", "zba",
> +					       "zbb", "zbc", "zbs", "zkt", "zvfh", "zvkt",
> +					       "sscofpmf", "sstc", "svinval", "svnapot", "svpbmt";
> +			riscv,cbom-block-size = <64>;
> +			riscv,cbop-block-size = <64>;
> +			riscv,cboz-block-size = <64>;
> +			mmu-type = "riscv,sv39";
> +
> +			cpu5_intc: interrupt-controller {
> +				compatible = "riscv,cpu-intc";
> +				interrupt-controller;
> +				#interrupt-cells = <1>;
> +			};
> +		};
> +		cpu_6: cpu@6 {
> +			compatible = "spacemit,x60", "riscv";
> +			device_type = "cpu";
> +			reg = <6>;
> +			riscv,isa = "rv64imafdcv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
> +			riscv,isa-base = "rv64i";
> +			riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "v", "zicbom",
> +					       "zicbop", "zicboz", "zicntr", "zicond", "zicsr",
> +					       "zifencei", "zihintpause", "zihpm", "zfh", "zba",
> +					       "zbb", "zbc", "zbs", "zkt", "zvfh", "zvkt",
> +					       "sscofpmf", "sstc", "svinval", "svnapot", "svpbmt";
> +			riscv,cbom-block-size = <64>;
> +			riscv,cbop-block-size = <64>;
> +			riscv,cboz-block-size = <64>;
> +			mmu-type = "riscv,sv39";
> +
> +			cpu6_intc: interrupt-controller {
> +				compatible = "riscv,cpu-intc";
> +				interrupt-controller;
> +				#interrupt-cells = <1>;
> +			};
> +		};
> +		cpu_7: cpu@7 {
> +			compatible = "spacemit,x60", "riscv";
> +			device_type = "cpu";
> +			reg = <7>;
> +			riscv,isa = "rv64imafdcv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
> +			riscv,isa-base = "rv64i";
> +			riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "v", "zicbom",
> +					       "zicbop", "zicboz", "zicntr", "zicond", "zicsr",
> +					       "zifencei", "zihintpause", "zihpm", "zfh", "zba",
> +					       "zbb", "zbc", "zbs", "zkt", "zvfh", "zvkt",
> +					       "sscofpmf", "sstc", "svinval", "svnapot", "svpbmt";
> +			riscv,cbom-block-size = <64>;
> +			riscv,cbop-block-size = <64>;
> +			riscv,cboz-block-size = <64>;
> +			mmu-type = "riscv,sv39";
> +
> +			cpu7_intc: interrupt-controller {
> +				compatible = "riscv,cpu-intc";
> +				interrupt-controller;
> +				#interrupt-cells = <1>;
> +			};
> +		};
> +
> +	};
> +
> +	soc {
> +		compatible = "simple-bus";
> +		interrupt-parent = <&plic>;
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		dma-noncoherent;
> +		ranges;
> +
> +		plic: interrupt-controller@e0000000 {
> +			compatible = "spacemit,k1-plic", "riscv,plic0";
> +			reg = <0x0 0xe0000000 0x0 0x4000000>;
> +			interrupts-extended = <&cpu0_intc 11>, <&cpu0_intc 9>,
> +					      <&cpu1_intc 11>, <&cpu1_intc 9>,
> +					      <&cpu2_intc 11>, <&cpu2_intc 9>,
> +					      <&cpu3_intc 11>, <&cpu3_intc 9>,
> +					      <&cpu4_intc 11>, <&cpu4_intc 9>,
> +					      <&cpu5_intc 11>, <&cpu5_intc 9>,
> +					      <&cpu6_intc 11>, <&cpu6_intc 9>,
> +					      <&cpu7_intc 11>, <&cpu7_intc 9>;
> +			interrupt-controller;
> +			#address-cells = <0>;
> +			#interrupt-cells = <1>;
> +			riscv,ndev = <159>;
> +		};
> +
> +		clint: timer@e4000000 {
> +			compatible = "spacemit,k1-clint", "riscv,clint0";
> +			reg = <0x0 0xe4000000 0x0 010000>;
> +			interrupts-extended = <&cpu0_intc 3>, <&cpu0_intc 7>,
> +					      <&cpu1_intc 3>, <&cpu1_intc 7>,
> +					      <&cpu2_intc 3>, <&cpu2_intc 7>,
> +					      <&cpu3_intc 3>, <&cpu3_intc 7>,
> +					      <&cpu4_intc 3>, <&cpu4_intc 7>,
> +					      <&cpu5_intc 3>, <&cpu5_intc 7>,
> +					      <&cpu6_intc 3>, <&cpu6_intc 7>,
> +					      <&cpu7_intc 3>, <&cpu7_intc 7>;
> +		};
> +
> +		uart0: serial@d4017000 {
> +			compatible = "intel,xscale-uart";
> +			reg = <0x0 0xd4017000 0x0 0x100>;
> +			interrupts = <42>;
> +			clock-frequency = <14000000>;
> +			reg-shift = <2>;
> +			reg-io-width = <4>;
> +			status = "disabled";
> +		};
> +	};
> +};
> -- 
> 2.45.1
> 
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v1 7/9] riscv: dts: add initial SpacemiT K1 SoC device tree

[Conor Dooley]

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

On Mon, Jun 17, 2024 at 08:49:57PM +0800, Jisheng Zhang wrote:
> On Mon, Jun 17, 2024 at 01:20:52AM +0800, Yangyu Chen wrote:
> > Banana Pi BPI-F3 motherboard is powered by SpacemiT K1[1].
> > 
> > Key features:
> > - 4 cores per cluster, 2 clusters on chip
> > - UART IP is Intel XScale UART
> > 
> > Some key considerations:
> > - ISA string is inferred from vendor documentation[2]
> > - Cluster topology is inferred from datasheet[1] and L2 in vendor dts[3]
> > - No coherent DMA on this board
> >     Inferred by taking vendor ethernet and MMC drivers to the mainline
> >     kernel. Without dma-noncoherent in soc node, the driver fails.
> > - No cache nodes now
> >     The parameters from vendor dts are likely to be wrong. It has 512
> >     sets for a 32KiB L1 Cache. In this case, each set is 64B in size.
> >     When the size of the cache line is 64B, it is a directly mapped
> >     cache rather than a set-associative cache, the latter is commonly
> >     used. Thus, I didn't use the parameters from vendor dts.
> > 
> > Currently only support booting into console with only uart, other
> > features will be added soon later.
> 
> Hi Yangyu,
> 
> Per recent practice of cv1800b and th1520 upstream, I think a complete
> initial support would include pinctrl, clk and reset, I have received
> the complains from the community. So can you please bring the pinctrl
> clk  and reset at the same time?

What sort of complaints have you got? That the support is too minimal to
be useful?

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

Re: [PATCH v1 7/9] riscv: dts: add initial SpacemiT K1 SoC device tree

[Jisheng Zhang]

On Mon, Jun 17, 2024 at 02:29:46PM +0100, Conor Dooley wrote:
> On Mon, Jun 17, 2024 at 08:49:57PM +0800, Jisheng Zhang wrote:
> > On Mon, Jun 17, 2024 at 01:20:52AM +0800, Yangyu Chen wrote:
> > > Banana Pi BPI-F3 motherboard is powered by SpacemiT K1[1].
> > > 
> > > Key features:
> > > - 4 cores per cluster, 2 clusters on chip
> > > - UART IP is Intel XScale UART
> > > 
> > > Some key considerations:
> > > - ISA string is inferred from vendor documentation[2]
> > > - Cluster topology is inferred from datasheet[1] and L2 in vendor dts[3]
> > > - No coherent DMA on this board
> > >     Inferred by taking vendor ethernet and MMC drivers to the mainline
> > >     kernel. Without dma-noncoherent in soc node, the driver fails.
> > > - No cache nodes now
> > >     The parameters from vendor dts are likely to be wrong. It has 512
> > >     sets for a 32KiB L1 Cache. In this case, each set is 64B in size.
> > >     When the size of the cache line is 64B, it is a directly mapped
> > >     cache rather than a set-associative cache, the latter is commonly
> > >     used. Thus, I didn't use the parameters from vendor dts.
> > > 
> > > Currently only support booting into console with only uart, other
> > > features will be added soon later.
> > 
> > Hi Yangyu,
> > 
> > Per recent practice of cv1800b and th1520 upstream, I think a complete
> > initial support would include pinctrl, clk and reset, I have received
> > the complains from the community. So can you please bring the pinctrl
> > clk  and reset at the same time?
> 
> What sort of complaints have you got? That the support is too minimal to
> be useful?

For example https://lore.kernel.org/linux-riscv/95c20c6c-66cd-4f87-920b-5da766317e19@sifive.com/

Now, I think it's better to "model the clocks/resets/other dependencies"
in the initial support. So lacking of pinctrl, clk and reset doesn't
fully describe the hardware.

Re: [PATCH v1 7/9] riscv: dts: add initial SpacemiT K1 SoC device tree

[Yangyu Chen]

> On Jun 17, 2024, at 21:31, Jisheng Zhang <jszhang@kernel.org> wrote:
> 
> On Mon, Jun 17, 2024 at 02:29:46PM +0100, Conor Dooley wrote:
>> On Mon, Jun 17, 2024 at 08:49:57PM +0800, Jisheng Zhang wrote:
>>> On Mon, Jun 17, 2024 at 01:20:52AM +0800, Yangyu Chen wrote:
>>>> Banana Pi BPI-F3 motherboard is powered by SpacemiT K1[1].
>>>> 
>>>> Key features:
>>>> - 4 cores per cluster, 2 clusters on chip
>>>> - UART IP is Intel XScale UART
>>>> 
>>>> Some key considerations:
>>>> - ISA string is inferred from vendor documentation[2]
>>>> - Cluster topology is inferred from datasheet[1] and L2 in vendor dts[3]
>>>> - No coherent DMA on this board
>>>>    Inferred by taking vendor ethernet and MMC drivers to the mainline
>>>>    kernel. Without dma-noncoherent in soc node, the driver fails.
>>>> - No cache nodes now
>>>>    The parameters from vendor dts are likely to be wrong. It has 512
>>>>    sets for a 32KiB L1 Cache. In this case, each set is 64B in size.
>>>>    When the size of the cache line is 64B, it is a directly mapped
>>>>    cache rather than a set-associative cache, the latter is commonly
>>>>    used. Thus, I didn't use the parameters from vendor dts.
>>>> 
>>>> Currently only support booting into console with only uart, other
>>>> features will be added soon later.
>>> 
>>> Hi Yangyu,
>>> 
>>> Per recent practice of cv1800b and th1520 upstream, I think a complete
>>> initial support would include pinctrl, clk and reset, I have received
>>> the complains from the community. So can you please bring the pinctrl
>>> clk  and reset at the same time?
>> 
>> What sort of complaints have you got? That the support is too minimal to
>> be useful?
> 
> For example https://lore.kernel.org/linux-riscv/95c20c6c-66cd-4f87-920b-5da766317e19@sifive.com/
> 
> Now, I think it's better to "model the clocks/resets/other dependencies"
> in the initial support. So lacking of pinctrl, clk and reset doesn't
> fully describe the hardware.

Sound like a good idea. In this case, we don't need to change the
dts repeatedly after a new soc driver is supported.

[PATCH v1 8/9] riscv: dts: spacemit: add Banana Pi BPI-F3 board device tree

[Yangyu Chen]

Banana Pi BPI-F3 [1] is a industrial grade RISC-V development board, it
design with SpacemiT K1 8 core RISC-V chip [2].

Currently only support booting into console with only uart enabled,
other features will be added soon later.

[1] https://docs.banana-pi.org/en/BPI-F3/BananaPi_BPI-F3
[2] https://www.spacemit.com/en/spacemit-key-stone-2/

Signed-off-by: Yangyu Chen <cyy@cyyself.name>
---
 arch/riscv/boot/dts/Makefile                 |  1 +
 arch/riscv/boot/dts/spacemit/Makefile        |  2 ++
 arch/riscv/boot/dts/spacemit/bananapi-f3.dts | 19 +++++++++++++++++++
 3 files changed, 22 insertions(+)
 create mode 100644 arch/riscv/boot/dts/spacemit/Makefile
 create mode 100644 arch/riscv/boot/dts/spacemit/bananapi-f3.dts

diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile
index fdae05bbf556..bff887d38abe 100644
--- a/arch/riscv/boot/dts/Makefile
+++ b/arch/riscv/boot/dts/Makefile
@@ -5,6 +5,7 @@ subdir-y += microchip
 subdir-y += renesas
 subdir-y += sifive
 subdir-y += sophgo
+subdir-y += spacemit
 subdir-y += starfive
 subdir-y += thead
 
diff --git a/arch/riscv/boot/dts/spacemit/Makefile b/arch/riscv/boot/dts/spacemit/Makefile
new file mode 100644
index 000000000000..5c512f4e297d
--- /dev/null
+++ b/arch/riscv/boot/dts/spacemit/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+dtb-$(CONFIG_ARCH_SPACEMIT) += bananapi-f3.dtb
diff --git a/arch/riscv/boot/dts/spacemit/bananapi-f3.dts b/arch/riscv/boot/dts/spacemit/bananapi-f3.dts
new file mode 100644
index 000000000000..023274189b49
--- /dev/null
+++ b/arch/riscv/boot/dts/spacemit/bananapi-f3.dts
@@ -0,0 +1,19 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+/*
+ * Copyright (C) 2024 Yangyu Chen <cyy@cyyself.name>
+ */
+
+#include "k1.dtsi"
+
+/ {
+	model = "Banana Pi BPI-F3";
+	compatible = "bananapi,bpi-f3", "spacemit,k1";
+
+	chosen {
+		stdout-path = "serial0";
+	};
+};
+
+&uart0 {
+	status = "okay";
+};
-- 
2.45.1

Re: [PATCH v1 8/9] riscv: dts: spacemit: add Banana Pi BPI-F3 board device tree

[Yixun Lan]

Hi

On 01:20 Mon 17 Jun     , Yangyu Chen wrote:
> Banana Pi BPI-F3 [1] is a industrial grade RISC-V development board, it
> design with SpacemiT K1 8 core RISC-V chip [2].
> 
> Currently only support booting into console with only uart enabled,
> other features will be added soon later.
> 
> [1] https://docs.banana-pi.org/en/BPI-F3/BananaPi_BPI-F3
> [2] https://www.spacemit.com/en/spacemit-key-stone-2/
> 
> Signed-off-by: Yangyu Chen <cyy@cyyself.name>
> ---
>  arch/riscv/boot/dts/Makefile                 |  1 +
>  arch/riscv/boot/dts/spacemit/Makefile        |  2 ++
>  arch/riscv/boot/dts/spacemit/bananapi-f3.dts | 19 +++++++++++++++++++
>  3 files changed, 22 insertions(+)
>  create mode 100644 arch/riscv/boot/dts/spacemit/Makefile
>  create mode 100644 arch/riscv/boot/dts/spacemit/bananapi-f3.dts
> 
> diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile
> index fdae05bbf556..bff887d38abe 100644
> --- a/arch/riscv/boot/dts/Makefile
> +++ b/arch/riscv/boot/dts/Makefile
> @@ -5,6 +5,7 @@ subdir-y += microchip
>  subdir-y += renesas
>  subdir-y += sifive
>  subdir-y += sophgo
> +subdir-y += spacemit
>  subdir-y += starfive
>  subdir-y += thead
>  
> diff --git a/arch/riscv/boot/dts/spacemit/Makefile b/arch/riscv/boot/dts/spacemit/Makefile
> new file mode 100644
> index 000000000000..5c512f4e297d
> --- /dev/null
> +++ b/arch/riscv/boot/dts/spacemit/Makefile
> @@ -0,0 +1,2 @@
> +# SPDX-License-Identifier: GPL-2.0
> +dtb-$(CONFIG_ARCH_SPACEMIT) += bananapi-f3.dtb
Can we have "k1" prefix at least? so k1-bananapi-f3.dtb
it's much clear to let people know the board has k1 SoC,
in case vendor has more chip series..

> diff --git a/arch/riscv/boot/dts/spacemit/bananapi-f3.dts b/arch/riscv/boot/dts/spacemit/bananapi-f3.dts
> new file mode 100644
> index 000000000000..023274189b49
> --- /dev/null
> +++ b/arch/riscv/boot/dts/spacemit/bananapi-f3.dts
> @@ -0,0 +1,19 @@
> +// SPDX-License-Identifier: GPL-2.0 OR MIT
> +/*
> + * Copyright (C) 2024 Yangyu Chen <cyy@cyyself.name>
> + */
> +
> +#include "k1.dtsi"
> +
> +/ {
> +	model = "Banana Pi BPI-F3";
> +	compatible = "bananapi,bpi-f3", "spacemit,k1";
> +
> +	chosen {
> +		stdout-path = "serial0";
> +	};
> +};
> +
> +&uart0 {
> +	status = "okay";
> +};
> -- 
> 2.45.1
> 

-- 
Yixun Lan (dlan)
Gentoo Linux Developer
GPG Key ID AABEFD55

Re: [PATCH v1 8/9] riscv: dts: spacemit: add Banana Pi BPI-F3 board device tree

[Yangyu Chen]

> On Jun 17, 2024, at 06:31, Yixun Lan <dlan@gentoo.org> wrote:
> 
> Hi
> 
> On 01:20 Mon 17 Jun     , Yangyu Chen wrote:
>> Banana Pi BPI-F3 [1] is a industrial grade RISC-V development board, it
>> design with SpacemiT K1 8 core RISC-V chip [2].
>> 
>> Currently only support booting into console with only uart enabled,
>> other features will be added soon later.
>> 
>> [1] https://docs.banana-pi.org/en/BPI-F3/BananaPi_BPI-F3
>> [2] https://www.spacemit.com/en/spacemit-key-stone-2/
>> 
>> Signed-off-by: Yangyu Chen <cyy@cyyself.name>
>> ---
>> arch/riscv/boot/dts/Makefile                 |  1 +
>> arch/riscv/boot/dts/spacemit/Makefile        |  2 ++
>> arch/riscv/boot/dts/spacemit/bananapi-f3.dts | 19 +++++++++++++++++++
>> 3 files changed, 22 insertions(+)
>> create mode 100644 arch/riscv/boot/dts/spacemit/Makefile
>> create mode 100644 arch/riscv/boot/dts/spacemit/bananapi-f3.dts
>> 
>> diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile
>> index fdae05bbf556..bff887d38abe 100644
>> --- a/arch/riscv/boot/dts/Makefile
>> +++ b/arch/riscv/boot/dts/Makefile
>> @@ -5,6 +5,7 @@ subdir-y += microchip
>> subdir-y += renesas
>> subdir-y += sifive
>> subdir-y += sophgo
>> +subdir-y += spacemit
>> subdir-y += starfive
>> subdir-y += thead
>> 
>> diff --git a/arch/riscv/boot/dts/spacemit/Makefile b/arch/riscv/boot/dts/spacemit/Makefile
>> new file mode 100644
>> index 000000000000..5c512f4e297d
>> --- /dev/null
>> +++ b/arch/riscv/boot/dts/spacemit/Makefile
>> @@ -0,0 +1,2 @@
>> +# SPDX-License-Identifier: GPL-2.0
>> +dtb-$(CONFIG_ARCH_SPACEMIT) += bananapi-f3.dtb
> Can we have "k1" prefix at least? so k1-bananapi-f3.dtb
> it's much clear to let people know the board has k1 SoC,
> in case vendor has more chip series..
> 

Sounds like a good idea. I searched other references to "Banana Pi"
in Kernel dts and found they have the prefix of soc name.

>> diff --git a/arch/riscv/boot/dts/spacemit/bananapi-f3.dts b/arch/riscv/boot/dts/spacemit/bananapi-f3.dts
>> new file mode 100644
>> index 000000000000..023274189b49
>> --- /dev/null
>> +++ b/arch/riscv/boot/dts/spacemit/bananapi-f3.dts
>> @@ -0,0 +1,19 @@
>> +// SPDX-License-Identifier: GPL-2.0 OR MIT
>> +/*
>> + * Copyright (C) 2024 Yangyu Chen <cyy@cyyself.name>
>> + */
>> +
>> +#include "k1.dtsi"
>> +
>> +/ {
>> + model = "Banana Pi BPI-F3";
>> + compatible = "bananapi,bpi-f3", "spacemit,k1";
>> +
>> + chosen {
>> + stdout-path = "serial0";
>> + };
>> +};
>> +
>> +&uart0 {
>> + status = "okay";
>> +};
>> -- 
>> 2.45.1
>> 
> 
> -- 
> Yixun Lan (dlan)
> Gentoo Linux Developer
> GPG Key ID AABEFD55

[PATCH v1 9/9] riscv: defconfig: enable SpacemiT SoC

[Yangyu Chen]

Enable SpacemiT SoC config in defconfig to allow the default upstream
kernel to boot on Banana Pi BPI-F3 board.

Signed-off-by: Yangyu Chen <cyy@cyyself.name>
---
 arch/riscv/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig
index 12dc8c73a8ac..a33e8c463c8a 100644
--- a/arch/riscv/configs/defconfig
+++ b/arch/riscv/configs/defconfig
@@ -30,6 +30,7 @@ CONFIG_ARCH_RENESAS=y
 CONFIG_ARCH_SIFIVE=y
 CONFIG_ARCH_SOPHGO=y
 CONFIG_SOC_STARFIVE=y
+CONFIG_SOC_SPACEMIT=y
 CONFIG_ARCH_SUNXI=y
 CONFIG_ARCH_THEAD=y
 CONFIG_ARCH_VIRT=y
-- 
2.45.1

Re: [PATCH v1 0/9] riscv: add initial support for SpacemiT K1

[Conor Dooley]

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

On Mon, Jun 17, 2024 at 01:18:52AM +0800, Yangyu Chen wrote:

>  .../sifive,plic-1.0.0.yaml                    |   5 +-
>  .../devicetree/bindings/riscv/cpus.yaml       |   1 +
>  .../devicetree/bindings/riscv/spacemit.yaml   |  24 ++
>  .../bindings/timer/sifive,clint.yaml          |   4 +-
>  .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
>  arch/riscv/Kconfig.socs                       |   5 +
>  arch/riscv/boot/dts/Makefile                  |   1 +
>  arch/riscv/boot/dts/spacemit/Makefile         |   2 +
>  arch/riscv/boot/dts/spacemit/bananapi-f3.dts  |  19 ++
>  arch/riscv/boot/dts/spacemit/k1.dtsi          | 281 ++++++++++++++++++
>  arch/riscv/configs/defconfig                  |   1 +

No MAINTAINERS update, so I figure that means you don't want to maintain
it going forwards? If there's someone out that that does care about the
spacemit k1 (Jesse maybe?), then I'd be more than happy to have them
look after it.

Thanks,
Conor.


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

Re: [PATCH v1 0/9] riscv: add initial support for SpacemiT K1

[Yixun Lan]

Hi Conor
 Thanks for bringing this up

On 19:35 Sun 16 Jun     , Conor Dooley wrote:
> On Mon, Jun 17, 2024 at 01:18:52AM +0800, Yangyu Chen wrote:
> 
> No MAINTAINERS update, so I figure that means you don't want to maintain
> it going forwards? If there's someone out that that does care about the
> spacemit k1 (Jesse maybe?), then I'd be more than happy to have them
> look after it.
Yangyu kind of has limited time, too many stuff for him..

I'd volunteered to help on this if it can fill the gap
Also I'd be more than happy if anyone willing step forward to co-maintain..

-- 
Yixun Lan (dlan)
Gentoo Linux Developer
GPG Key ID AABEFD55

Re: [PATCH v1 0/9] riscv: add initial support for SpacemiT K1

[Yangyu Chen]

> On Jun 17, 2024, at 06:48, Yixun Lan <dlan@gentoo.org> wrote:
> 
> Hi Conor
> Thanks for bringing this up
> 
> On 19:35 Sun 16 Jun     , Conor Dooley wrote:
>> On Mon, Jun 17, 2024 at 01:18:52AM +0800, Yangyu Chen wrote:
>> 
>> No MAINTAINERS update, so I figure that means you don't want to maintain
>> it going forwards? If there's someone out that that does care about the
>> spacemit k1 (Jesse maybe?), then I'd be more than happy to have them
>> look after it.

Actually, I don’t know how to be a maintainer. Should I have to
provide a new git tree and all the new patches merged to my tree
and then submit a git pull? Or reuse the RISC-V mailing list and
just give a review, and the patches come to soc misc tree? I would
like the latter one.

> Yangyu kind of has limited time, too many stuff for him..
> 

True. Maybe I can have a review and test the patch in one week.
However, providing a review and test in 2-3 days is sometimes hard
for me.

> I'd volunteered to help on this if it can fill the gap
> Also I'd be more than happy if anyone willing step forward to co-maintain..
> 

Thanks. Really appreciate it.

Should I provide a diff like this:

diff --git a/MAINTAINERS b/MAINTAINERS
index d6c90161c7bf..718d30996f12 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19306,6 +19306,7 @@ F:      arch/riscv/boot/dts/
 X:     arch/riscv/boot/dts/allwinner/
 X:     arch/riscv/boot/dts/renesas/
 X:     arch/riscv/boot/dts/sophgo/
+X:     arch/riscv/boot/dts/spacemit/
 
 RISC-V PMU DRIVERS
 M:     Atish Patra <atishp@atishpatra.org>
@@ -21004,6 +21005,13 @@ W:     https://linuxtv.org
 Q:     http://patchwork.linuxtv.org/project/linux-media/list/
 F:     drivers/media/dvb-frontends/sp2*
 
+SPACEMIT DEVICETREES and DRIVERS
+M:     Yangyu Chen <cyy@cyyself.name>
+M:     Yixun Lan <dlan@gentoo.org>
+S:     Maintained
+F:     Documentation/devicetree/bindings/riscv/spacemit.yaml
+F:     arch/riscv/boot/dts/spacemit/
+
 SPANISH DOCUMENTATION
 M:     Carlos Bilbao <carlos.bilbao.osdev@gmail.com>
 R:     Avadhut Naik <avadhut.naik@amd.com>

Thanks,
Yangyu Chen

> -- 
> Yixun Lan (dlan)
> Gentoo Linux Developer
> GPG Key ID AABEFD55

Re: [PATCH v1 0/9] riscv: add initial support for SpacemiT K1

[Conor Dooley]

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

On Mon, Jun 17, 2024 at 10:00:32AM +0800, Yangyu Chen wrote:
> 
> > On Jun 17, 2024, at 06:48, Yixun Lan <dlan@gentoo.org> wrote:
> > 
> > Hi Conor
> > Thanks for bringing this up
> > 
> > On 19:35 Sun 16 Jun     , Conor Dooley wrote:
> >> On Mon, Jun 17, 2024 at 01:18:52AM +0800, Yangyu Chen wrote:
> >> 
> >> No MAINTAINERS update, so I figure that means you don't want to maintain
> >> it going forwards? If there's someone out that that does care about the
> >> spacemit k1 (Jesse maybe?), then I'd be more than happy to have them
> >> look after it.
> 
> Actually, I don’t know how to be a maintainer. Should I have to
> provide a new git tree and all the new patches merged to my tree
> and then submit a git pull?

Yeah, in the ideal case :) I wrote a document with information as to
how this all works for new platform maintainers:
https://docs.kernel.org/process/maintainer-soc.html#information-for-new-submaintainers

> Or reuse the RISC-V mailing list and
> just give a review, and the patches come to soc misc tree? I would
> like the latter one.

If you don't have the time/interest/whatever in having a tree, then
sure, I can apply the patches for it. I'd rather have someone look after
a tree themselves, but this option is better than me growing another
platform to look after.

> > Yangyu kind of has limited time, too many stuff for him..
> > 
> 
> True. Maybe I can have a review and test the patch in one week.
> However, providing a review and test in 2-3 days is sometimes hard
> for me.

It would be unreasonable to expect a 2-3 day turnaround :)

> > I'd volunteered to help on this if it can fill the gap
> > Also I'd be more than happy if anyone willing step forward to co-maintain..
> > 
> 
> Thanks. Really appreciate it.
> 
> Should I provide a diff like this:
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d6c90161c7bf..718d30996f12 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -19306,6 +19306,7 @@ F:      arch/riscv/boot/dts/
>  X:     arch/riscv/boot/dts/allwinner/
>  X:     arch/riscv/boot/dts/renesas/
>  X:     arch/riscv/boot/dts/sophgo/
> +X:     arch/riscv/boot/dts/spacemit/

If you don't want to apply patches, drop this hunk.

>  RISC-V PMU DRIVERS
>  M:     Atish Patra <atishp@atishpatra.org>
> @@ -21004,6 +21005,13 @@ W:     https://linuxtv.org
>  Q:     http://patchwork.linuxtv.org/project/linux-media/list/
>  F:     drivers/media/dvb-frontends/sp2*
>  
> +SPACEMIT DEVICETREES and DRIVERS
> +M:     Yangyu Chen <cyy@cyyself.name>
> +M:     Yixun Lan <dlan@gentoo.org>

Jesse mentioned on IRC she was interested in the platform, so maybe she
would like to be involved too.

Thanks,
Conor.

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

Re: [PATCH v1 0/9] riscv: add initial support for SpacemiT K1

[Icenowy Zheng]

在 2024-06-17星期一的 10:00 +0800，Yangyu Chen写道：
> 
> > On Jun 17, 2024, at 06:48, Yixun Lan <dlan@gentoo.org> wrote:
> > 
> > Hi Conor
> > Thanks for bringing this up
> > 
> > On 19:35 Sun 16 Jun     , Conor Dooley wrote:
> > > On Mon, Jun 17, 2024 at 01:18:52AM +0800, Yangyu Chen wrote:
> > > 
> > > No MAINTAINERS update, so I figure that means you don't want to
> > > maintain
> > > it going forwards? If there's someone out that that does care
> > > about the
> > > spacemit k1 (Jesse maybe?), then I'd be more than happy to have
> > > them
> > > look after it.
> 
> Actually, I don’t know how to be a maintainer. Should I have to
> provide a new git tree and all the new patches merged to my tree
> and then submit a git pull? Or reuse the RISC-V mailing list and
> just give a review, and the patches come to soc misc tree? I would
> like the latter one.

Well I think for these SoCs the latter is the case.

BTW I could volunteer as a maintainer, or at least a reviewer here.

> 
> > Yangyu kind of has limited time, too many stuff for him..
> > 
> 
> True. Maybe I can have a review and test the patch in one week.
> However, providing a review and test in 2-3 days is sometimes hard
> for me.
> 
> > I'd volunteered to help on this if it can fill the gap
> > Also I'd be more than happy if anyone willing step forward to co-
> > maintain..
> > 
> 
> Thanks. Really appreciate it.
> 
> Should I provide a diff like this:
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d6c90161c7bf..718d30996f12 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -19306,6 +19306,7 @@ F:      arch/riscv/boot/dts/
>  X:     arch/riscv/boot/dts/allwinner/
>  X:     arch/riscv/boot/dts/renesas/
>  X:     arch/riscv/boot/dts/sophgo/
> +X:     arch/riscv/boot/dts/spacemit/
>  
>  RISC-V PMU DRIVERS
>  M:     Atish Patra <atishp@atishpatra.org>
> @@ -21004,6 +21005,13 @@ W:     https://linuxtv.org
>  Q:     http://patchwork.linuxtv.org/project/linux-media/list/
>  F:     drivers/media/dvb-frontends/sp2*
>  
> +SPACEMIT DEVICETREES and DRIVERS
> +M:     Yangyu Chen <cyy@cyyself.name>
> +M:     Yixun Lan <dlan@gentoo.org>
> +S:     Maintained
> +F:     Documentation/devicetree/bindings/riscv/spacemit.yaml
> +F:     arch/riscv/boot/dts/spacemit/
> +
>  SPANISH DOCUMENTATION
>  M:     Carlos Bilbao <carlos.bilbao.osdev@gmail.com>
>  R:     Avadhut Naik <avadhut.naik@amd.com>
> 
> Thanks,
> Yangyu Chen
> 
> > -- 
> > Yixun Lan (dlan)
> > Gentoo Linux Developer
> > GPG Key ID AABEFD55
> 
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v1 0/9] riscv: add initial support for SpacemiT K1

[Jisheng Zhang]

On Sun, Jun 16, 2024 at 10:48:11PM +0000, Yixun Lan wrote:
> Hi Conor
>  Thanks for bringing this up
> 
> On 19:35 Sun 16 Jun     , Conor Dooley wrote:
> > On Mon, Jun 17, 2024 at 01:18:52AM +0800, Yangyu Chen wrote:
> > 
> > No MAINTAINERS update, so I figure that means you don't want to maintain
> > it going forwards? If there's someone out that that does care about the
> > spacemit k1 (Jesse maybe?), then I'd be more than happy to have them
> > look after it.
> Yangyu kind of has limited time, too many stuff for him..
> 
> I'd volunteered to help on this if it can fill the gap
> Also I'd be more than happy if anyone willing step forward to co-maintain..

Does maintainership work like this? Is willing to do enough?
FWICT, maintainership involves active patch contributing, reviewing and
maintaining the whole SoC. It is better to take over the maintainership
after showing enough patch contributions and understanding of the SoC.

> 
> -- 
> Yixun Lan (dlan)
> Gentoo Linux Developer
> GPG Key ID AABEFD55
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v1 0/9] riscv: add initial support for SpacemiT K1

[Conor Dooley]

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

On Mon, Jun 17, 2024 at 10:11:17PM +0800, Jisheng Zhang wrote:
> On Sun, Jun 16, 2024 at 10:48:11PM +0000, Yixun Lan wrote:
> > Hi Conor
> >  Thanks for bringing this up
> > 
> > On 19:35 Sun 16 Jun     , Conor Dooley wrote:
> > > On Mon, Jun 17, 2024 at 01:18:52AM +0800, Yangyu Chen wrote:
> > > 
> > > No MAINTAINERS update, so I figure that means you don't want to maintain
> > > it going forwards? If there's someone out that that does care about the
> > > spacemit k1 (Jesse maybe?), then I'd be more than happy to have them
> > > look after it.
> > Yangyu kind of has limited time, too many stuff for him..
> > 
> > I'd volunteered to help on this if it can fill the gap
> > Also I'd be more than happy if anyone willing step forward to co-maintain..
> 
> Does maintainership work like this? Is willing to do enough?
> FWICT, maintainership involves active patch contributing, reviewing and
> maintaining the whole SoC. It is better to take over the maintainership
> after showing enough patch contributions and understanding of the SoC.

I was going to reply to your other patch about providing more complete
"basic" support for the SoC, but I guess I'll reply here and address
both points. After the k230 and th1520, which were both merged with very
basic support and have made very little progress towards being a useful
platform, I'm pretty reluctant to merge another platform in a super
basic state. I was going to make this point before you brought it up,
but it's good to know I am not the only one with that view. To be clear,
I'm not pointing blame for those platforms, I'd just like to avoid a
repeat. If Yangyu doesn't have time to do any development work on the
platform, I'd like to see someone else (and as I mentioned Jesse is
interested) take on getting some of the basic driver patches written and
merge only when those are accepted. Having no in-tree clock and pinctrl
drivers is definitely a hindrance to other people doing parallel
development of drivers and I'd like to avoid that.

Getting back to your point in this mail, whoever gets the platform to
that state is well suited to looking after it going forwards. Some other
interested parties could also join as reviewers. I don't want to see
people joining as maintainers that are not going to have an interest
in the platform going forward, as that'll just end up with me as the
defacto maintainer.

Thanks,
Conor.

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

Re: [PATCH v1 0/9] riscv: add initial support for SpacemiT K1

[Yangyu Chen]

> On Jun 17, 2024, at 23:32, Conor Dooley <conor@kernel.org> wrote:
> 
> On Mon, Jun 17, 2024 at 10:11:17PM +0800, Jisheng Zhang wrote:
>> On Sun, Jun 16, 2024 at 10:48:11PM +0000, Yixun Lan wrote:
>>> Hi Conor
>>> Thanks for bringing this up
>>> 
>>> On 19:35 Sun 16 Jun     , Conor Dooley wrote:
>>>> On Mon, Jun 17, 2024 at 01:18:52AM +0800, Yangyu Chen wrote:
>>>> 
>>>> No MAINTAINERS update, so I figure that means you don't want to maintain
>>>> it going forwards? If there's someone out that that does care about the
>>>> spacemit k1 (Jesse maybe?), then I'd be more than happy to have them
>>>> look after it.
>>> Yangyu kind of has limited time, too many stuff for him..
>>> 
>>> I'd volunteered to help on this if it can fill the gap
>>> Also I'd be more than happy if anyone willing step forward to co-maintain..
>> 
>> Does maintainership work like this? Is willing to do enough?
>> FWICT, maintainership involves active patch contributing, reviewing and
>> maintaining the whole SoC. It is better to take over the maintainership
>> after showing enough patch contributions and understanding of the SoC.
> 
> I was going to reply to your other patch about providing more complete
> "basic" support for the SoC, but I guess I'll reply here and address
> both points. After the k230 and th1520, which were both merged with very
> basic support and have made very little progress towards being a useful
> platform, I'm pretty reluctant to merge another platform in a super
> basic state. I was going to make this point before you brought it up,
> but it's good to know I am not the only one with that view. To be clear,
> I'm not pointing blame for those platforms, I'd just like to avoid a
> repeat. If Yangyu doesn't have time to do any development work on the
> platform, I'd like to see someone else (and as I mentioned Jesse is
> interested) take on getting some of the basic driver patches written and
> merge only when those are accepted. Having no in-tree clock and pinctrl
> drivers is definitely a hindrance to other people doing parallel
> development of drivers and I'd like to avoid that.
> 

That's also my concern for the first time when I submitted initial
support for K230. However, for SpacemiT K1, things went differently
for its UART, and the vendor patched OpenSBI with their NOC-based
HSM. They didn't use CLINT-MSWI as SBI HSM driver.

The vendor uses a special intel pxa uart driver, marked deprecated
in the kernel and incompatible with ns16550. If we use ns16550 in
the dt, the behavior of uart is like the uart has no interrupt and
stops working permanently when fifo overruns, making many developers
not know how to start unless they use the SBI HVC console, which
needs to turn on CONFIG_NONPORTABLE.

For the OpenSBI, the vendor does not provide enough ISA string,
which their chip might support, such as Zicboz. Thus, the OpenSBI
does not correctly set up the corresponding M-Mode CSR, making the
kernel panic when the ISA string contains this extension.

These two things takes me about one week to get the initial mainline
kernel with full ISA extension and UART to work. Providing this
information in the commit message helps attract more developers to
start developing quickly.

I don't mind whether this series patch will be merged or not. The
meaning of this series is just providing these informations. However,
I think some details about bringing up a very basic kernel are
essential to attract more developers. If a platform has already
attracted some developer's attention. Providing initial support
with the commit message to show how to bring it up is not bad.

The point is that if a developer like me has already done this but
does not have much time to do further development, should the
developer become the maintainer? If not, should a developer submit
patches like this to the mailing list to provide this information
in the commit message and make it easier for other developers to
do further development?

> Getting back to your point in this mail, whoever gets the platform to
> that state is well suited to looking after it going forwards. Some other
> interested parties could also join as reviewers. I don't want to see
> people joining as maintainers that are not going to have an interest
> in the platform going forward, as that'll just end up with me as the
> defacto maintainer.
> 

I agree. I also have no confidence in joining as a maintainer.
That's why I didn't change the MAINTAINERS for the first time.

Thanks,
Yangyu Chen

Re: [PATCH v1 0/9] riscv: add initial support for SpacemiT K1

[Conor Dooley]

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

On Tue, Jun 18, 2024 at 12:39:30AM +0800, Yangyu Chen wrote:
> 
> 
> > On Jun 17, 2024, at 23:32, Conor Dooley <conor@kernel.org> wrote:
> > 
> > On Mon, Jun 17, 2024 at 10:11:17PM +0800, Jisheng Zhang wrote:
> >> On Sun, Jun 16, 2024 at 10:48:11PM +0000, Yixun Lan wrote:
> >>> Hi Conor
> >>> Thanks for bringing this up
> >>> 
> >>> On 19:35 Sun 16 Jun     , Conor Dooley wrote:
> >>>> On Mon, Jun 17, 2024 at 01:18:52AM +0800, Yangyu Chen wrote:
> >>>> 
> >>>> No MAINTAINERS update, so I figure that means you don't want to maintain
> >>>> it going forwards? If there's someone out that that does care about the
> >>>> spacemit k1 (Jesse maybe?), then I'd be more than happy to have them
> >>>> look after it.
> >>> Yangyu kind of has limited time, too many stuff for him..
> >>> 
> >>> I'd volunteered to help on this if it can fill the gap
> >>> Also I'd be more than happy if anyone willing step forward to co-maintain..
> >> 
> >> Does maintainership work like this? Is willing to do enough?
> >> FWICT, maintainership involves active patch contributing, reviewing and
> >> maintaining the whole SoC. It is better to take over the maintainership
> >> after showing enough patch contributions and understanding of the SoC.
> > 
> > I was going to reply to your other patch about providing more complete
> > "basic" support for the SoC, but I guess I'll reply here and address
> > both points. After the k230 and th1520, which were both merged with very
> > basic support and have made very little progress towards being a useful
> > platform, I'm pretty reluctant to merge another platform in a super
> > basic state. I was going to make this point before you brought it up,
> > but it's good to know I am not the only one with that view. To be clear,
> > I'm not pointing blame for those platforms, I'd just like to avoid a
> > repeat. If Yangyu doesn't have time to do any development work on the
> > platform, I'd like to see someone else (and as I mentioned Jesse is
> > interested) take on getting some of the basic driver patches written and
> > merge only when those are accepted. Having no in-tree clock and pinctrl
> > drivers is definitely a hindrance to other people doing parallel
> > development of drivers and I'd like to avoid that.
> > 
> 
> That's also my concern for the first time when I submitted initial
> support for K230. However, for SpacemiT K1, things went differently
> for its UART, and the vendor patched OpenSBI with their NOC-based
> HSM. They didn't use CLINT-MSWI as SBI HSM driver.
> 
> The vendor uses a special intel pxa uart driver, marked deprecated
> in the kernel and incompatible with ns16550. If we use ns16550 in
> the dt, the behavior of uart is like the uart has no interrupt and
> stops working permanently when fifo overruns, making many developers
> not know how to start unless they use the SBI HVC console, which
> needs to turn on CONFIG_NONPORTABLE.

This I just do not understand. Why did they use this IP? Is it free?
Did they use it before for something else? It's a rather strange design
choice to me.

> For the OpenSBI, the vendor does not provide enough ISA string,
> which their chip might support, such as Zicboz. Thus, the OpenSBI
> does not correctly set up the corresponding M-Mode CSR, making the
> kernel panic when the ISA string contains this extension.
> 
> These two things takes me about one week to get the initial mainline
> kernel with full ISA extension and UART to work. Providing this
> information in the commit message helps attract more developers to
> start developing quickly.
> 
> I don't mind whether this series patch will be merged or not. The
> meaning of this series is just providing these informations. However,
> I think some details about bringing up a very basic kernel are
> essential to attract more developers. If a platform has already
> attracted some developer's attention. Providing initial support
> with the commit message to show how to bring it up is not bad.
> 

> The point is that if a developer like me has already done this but
> does not have much time to do further development, should the
> developer become the maintainer? If not, should a developer submit
> patches like this to the mailing list to provide this information
> in the commit message and make it easier for other developers to
> do further development?

I think, as you did, sending patches for this state is very valuable.
I'd just like to see someone expand on it before it gets applied, so
that the initial platform support in the kernel is in a better state.

> > Getting back to your point in this mail, whoever gets the platform to
> > that state is well suited to looking after it going forwards. Some other
> > interested parties could also join as reviewers. I don't want to see
> > people joining as maintainers that are not going to have an interest
> > in the platform going forward, as that'll just end up with me as the
> > defacto maintainer.
> > 
> 
> I agree. I also have no confidence in joining as a maintainer.
> That's why I didn't change the MAINTAINERS for the first time.

Yeah, that's fine. Consider this part of the thread my attempt to
solicit people to maintain the platform, rather than bashing you. I
appreciate the work you've done :)

Thanks,
Conor.

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

Re: [PATCH v1 0/9] riscv: add initial support for SpacemiT K1

[Yangyu Chen]

> On Jun 18, 2024, at 01:14, Conor Dooley <conor@kernel.org> wrote:
> 
> On Tue, Jun 18, 2024 at 12:39:30AM +0800, Yangyu Chen wrote:
>> 
>> The vendor uses a special intel pxa uart driver, marked deprecated
>> in the kernel and incompatible with ns16550. If we use ns16550 in
>> the dt, the behavior of uart is like the uart has no interrupt and
>> stops working permanently when fifo overruns, making many developers
>> not know how to start unless they use the SBI HVC console, which
>> needs to turn on CONFIG_NONPORTABLE.
> 
> This I just do not understand. Why did they use this IP? Is it free?
> Did they use it before for something else? It's a rather strange design
> choice to me.

I don't know either. However, PXA is a subfamily of XScale. The
kernel also probed the UART as an XScale. So, using XScale compatible
string is OK.

Re: [PATCH v1 0/9] riscv: add initial support for SpacemiT K1

[Conor Dooley]

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

On Tue, Jun 18, 2024 at 01:42:34AM +0800, Yangyu Chen wrote:
> 
> 
> > On Jun 18, 2024, at 01:14, Conor Dooley <conor@kernel.org> wrote:
> > 
> > On Tue, Jun 18, 2024 at 12:39:30AM +0800, Yangyu Chen wrote:
> >> 
> >> The vendor uses a special intel pxa uart driver, marked deprecated
> >> in the kernel and incompatible with ns16550. If we use ns16550 in
> >> the dt, the behavior of uart is like the uart has no interrupt and
> >> stops working permanently when fifo overruns, making many developers
> >> not know how to start unless they use the SBI HVC console, which
> >> needs to turn on CONFIG_NONPORTABLE.
> > 
> > This I just do not understand. Why did they use this IP? Is it free?
> > Did they use it before for something else? It's a rather strange design
> > choice to me.
> 
> I don't know either. However, PXA is a subfamily of XScale. The
> kernel also probed the UART as an XScale. So, using XScale compatible
> string is OK.

Using a fallback to an Xscale compatible is okay, FTFY ;)

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

Re: [PATCH v1 0/9] riscv: add initial support for SpacemiT K1

[Jisheng Zhang]

On Tue, Jun 18, 2024 at 12:39:30AM +0800, Yangyu Chen wrote:
> 
> 
> > On Jun 17, 2024, at 23:32, Conor Dooley <conor@kernel.org> wrote:
> > 
> > On Mon, Jun 17, 2024 at 10:11:17PM +0800, Jisheng Zhang wrote:
> >> On Sun, Jun 16, 2024 at 10:48:11PM +0000, Yixun Lan wrote:
> >>> Hi Conor
> >>> Thanks for bringing this up
> >>> 
> >>> On 19:35 Sun 16 Jun     , Conor Dooley wrote:
> >>>> On Mon, Jun 17, 2024 at 01:18:52AM +0800, Yangyu Chen wrote:
> >>>> 
> >>>> No MAINTAINERS update, so I figure that means you don't want to maintain
> >>>> it going forwards? If there's someone out that that does care about the
> >>>> spacemit k1 (Jesse maybe?), then I'd be more than happy to have them
> >>>> look after it.
> >>> Yangyu kind of has limited time, too many stuff for him..
> >>> 
> >>> I'd volunteered to help on this if it can fill the gap
> >>> Also I'd be more than happy if anyone willing step forward to co-maintain..
> >> 
> >> Does maintainership work like this? Is willing to do enough?
> >> FWICT, maintainership involves active patch contributing, reviewing and
> >> maintaining the whole SoC. It is better to take over the maintainership
> >> after showing enough patch contributions and understanding of the SoC.
> > 
> > I was going to reply to your other patch about providing more complete
> > "basic" support for the SoC, but I guess I'll reply here and address
> > both points. After the k230 and th1520, which were both merged with very
> > basic support and have made very little progress towards being a useful
> > platform, I'm pretty reluctant to merge another platform in a super
> > basic state. I was going to make this point before you brought it up,
> > but it's good to know I am not the only one with that view. To be clear,
> > I'm not pointing blame for those platforms, I'd just like to avoid a
> > repeat. If Yangyu doesn't have time to do any development work on the
> > platform, I'd like to see someone else (and as I mentioned Jesse is
> > interested) take on getting some of the basic driver patches written and
> > merge only when those are accepted. Having no in-tree clock and pinctrl
> > drivers is definitely a hindrance to other people doing parallel
> > development of drivers and I'd like to avoid that.
> > 
> 
> That's also my concern for the first time when I submitted initial
> support for K230. However, for SpacemiT K1, things went differently
> for its UART, and the vendor patched OpenSBI with their NOC-based
> HSM. They didn't use CLINT-MSWI as SBI HSM driver.
> 
> The vendor uses a special intel pxa uart driver, marked deprecated
> in the kernel and incompatible with ns16550. If we use ns16550 in
> the dt, the behavior of uart is like the uart has no interrupt and
> stops working permanently when fifo overruns, making many developers
> not know how to start unless they use the SBI HVC console, which
> needs to turn on CONFIG_NONPORTABLE.
> 
> For the OpenSBI, the vendor does not provide enough ISA string,
> which their chip might support, such as Zicboz. Thus, the OpenSBI
> does not correctly set up the corresponding M-Mode CSR, making the
> kernel panic when the ISA string contains this extension.
> 
> These two things takes me about one week to get the initial mainline
> kernel with full ISA extension and UART to work. Providing this
> information in the commit message helps attract more developers to
> start developing quickly.
> 
> I don't mind whether this series patch will be merged or not. The
> meaning of this series is just providing these informations. However,
> I think some details about bringing up a very basic kernel are
> essential to attract more developers. If a platform has already
> attracted some developer's attention. Providing initial support
> with the commit message to show how to bring it up is not bad.
> 
> The point is that if a developer like me has already done this but
> does not have much time to do further development, should the
> developer become the maintainer? If not, should a developer submit
> patches like this to the mailing list to provide this information
> in the commit message and make it easier for other developers to
> do further development?

This patch series is valueable, especially for the person who
has passion, time to expand the series to get pinctrl, reset and clk
ready so that the SoC is properly modeled even in the initial stage.

> 
> > Getting back to your point in this mail, whoever gets the platform to
> > that state is well suited to looking after it going forwards. Some other
> > interested parties could also join as reviewers. I don't want to see
> > people joining as maintainers that are not going to have an interest
> > in the platform going forward, as that'll just end up with me as the
> > defacto maintainer.
> > 
> 
> I agree. I also have no confidence in joining as a maintainer.
> That's why I didn't change the MAINTAINERS for the first time.
> 
> Thanks,
> Yangyu Chen
> 

Re: [PATCH v1 0/9] riscv: add initial support for SpacemiT K1

[Jisheng Zhang]

On Mon, Jun 17, 2024 at 04:32:59PM +0100, Conor Dooley wrote:
> On Mon, Jun 17, 2024 at 10:11:17PM +0800, Jisheng Zhang wrote:
> > On Sun, Jun 16, 2024 at 10:48:11PM +0000, Yixun Lan wrote:
> > > Hi Conor
> > >  Thanks for bringing this up
> > > 
> > > On 19:35 Sun 16 Jun     , Conor Dooley wrote:
> > > > On Mon, Jun 17, 2024 at 01:18:52AM +0800, Yangyu Chen wrote:
> > > > 
> > > > No MAINTAINERS update, so I figure that means you don't want to maintain
> > > > it going forwards? If there's someone out that that does care about the
> > > > spacemit k1 (Jesse maybe?), then I'd be more than happy to have them
> > > > look after it.
> > > Yangyu kind of has limited time, too many stuff for him..
> > > 
> > > I'd volunteered to help on this if it can fill the gap
> > > Also I'd be more than happy if anyone willing step forward to co-maintain..
> > 
> > Does maintainership work like this? Is willing to do enough?
> > FWICT, maintainership involves active patch contributing, reviewing and
> > maintaining the whole SoC. It is better to take over the maintainership
> > after showing enough patch contributions and understanding of the SoC.
> 
> I was going to reply to your other patch about providing more complete
> "basic" support for the SoC, but I guess I'll reply here and address
> both points. After the k230 and th1520, which were both merged with very

When I saw k230 a few minutes ago, I assumed you mean k210 since I
didn't found k230 support in linus tree now. After searching the
maillist, I found oh there is a k230 series which is similar to this
series, no pinctrl, no clk, no reset. Since the incomplete K230 initial
series hasn't been merged into Linus tree now, is it possible to drop
it so that we can avoid the same mistake for k230.

> basic support and have made very little progress towards being a useful
> platform, I'm pretty reluctant to merge another platform in a super
> basic state. I was going to make this point before you brought it up,
> but it's good to know I am not the only one with that view. To be clear,
> I'm not pointing blame for those platforms, I'd just like to avoid a

Yep previously I thought it was fine to use a fixed clock or dummy clock
during the initial patches, but I changed my mind now, especially after
Samuel complained the cv1800b reset dt changes.

> repeat. If Yangyu doesn't have time to do any development work on the
> platform, I'd like to see someone else (and as I mentioned Jesse is
> interested) take on getting some of the basic driver patches written and
> merge only when those are accepted. Having no in-tree clock and pinctrl
> drivers is definitely a hindrance to other people doing parallel
> development of drivers and I'd like to avoid that.
> 
> Getting back to your point in this mail, whoever gets the platform to
> that state is well suited to looking after it going forwards. Some other

The person who can bring the platfrom support to a well-moduled state,
IE, proper clk, pinctrl, reset drivers shows the passion, the code
contribution and solid understanding of the SoC, sure he/she is
definitely suited to maintain the SoC. I just don't think it's 
a good practice a person can became maintainer even w/o one LoC
contrubition to the SoC, because IMHO code contribution matters
for maintainership.

> interested parties could also join as reviewers. I don't want to see
> people joining as maintainers that are not going to have an interest
> in the platform going forward, as that'll just end up with me as the
> defacto maintainer.

> 
> Thanks,
> Conor.

Re: [PATCH v1 0/9] riscv: add initial support for SpacemiT K1

[Conor Dooley]

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

On Tue, Jun 18, 2024 at 12:34:27PM +0800, Jisheng Zhang wrote:
> On Mon, Jun 17, 2024 at 04:32:59PM +0100, Conor Dooley wrote:
> > On Mon, Jun 17, 2024 at 10:11:17PM +0800, Jisheng Zhang wrote:
> > > On Sun, Jun 16, 2024 at 10:48:11PM +0000, Yixun Lan wrote:
> > > > Hi Conor
> > > >  Thanks for bringing this up
> > > > 
> > > > On 19:35 Sun 16 Jun     , Conor Dooley wrote:
> > > > > On Mon, Jun 17, 2024 at 01:18:52AM +0800, Yangyu Chen wrote:
> > > > > 
> > > > > No MAINTAINERS update, so I figure that means you don't want to maintain
> > > > > it going forwards? If there's someone out that that does care about the
> > > > > spacemit k1 (Jesse maybe?), then I'd be more than happy to have them
> > > > > look after it.
> > > > Yangyu kind of has limited time, too many stuff for him..
> > > > 
> > > > I'd volunteered to help on this if it can fill the gap
> > > > Also I'd be more than happy if anyone willing step forward to co-maintain..
> > > 
> > > Does maintainership work like this? Is willing to do enough?
> > > FWICT, maintainership involves active patch contributing, reviewing and
> > > maintaining the whole SoC. It is better to take over the maintainership
> > > after showing enough patch contributions and understanding of the SoC.
> > 
> > I was going to reply to your other patch about providing more complete
> > "basic" support for the SoC, but I guess I'll reply here and address
> > both points. After the k230 and th1520, which were both merged with very
> 
> When I saw k230 a few minutes ago, I assumed you mean k210 since I
> didn't found k230 support in linus tree now. After searching the
> maillist, I found oh there is a k230 series which is similar to this
> series, no pinctrl, no clk, no reset. Since the incomplete K230 initial
> series hasn't been merged into Linus tree now, is it possible to drop
> it so that we can avoid the same mistake for k230.

Yeah, I think you're right there and I should drop the k230 stuff from
for-next. I forgot that it was not already in, because I had sent it for
6.10 and Arnd didn't like some of the inter-branch dependencies that my
PR had and told me to drop it. If nobody really cares for getting the
platform to a reasonably usable state, then I guess we will just not
support it. And it seems like there's little interest in it, despite
being the first system you could buy with ratified vector. It's not a
great platform to work with documentation wise, at least as a non-Chinese
speaker like myself nor is the U-Boot M-Mode -> OpenSBI -> Linux vendor
boot flow good for iterating on kernels.

> > basic support and have made very little progress towards being a useful
> > platform, I'm pretty reluctant to merge another platform in a super
> > basic state. I was going to make this point before you brought it up,
> > but it's good to know I am not the only one with that view. To be clear,
> > I'm not pointing blame for those platforms, I'd just like to avoid a
> 
> Yep previously I thought it was fine to use a fixed clock or dummy clock
> during the initial patches, but I changed my mind now, especially after
> Samuel complained the cv1800b reset dt changes.
> 
> > repeat. If Yangyu doesn't have time to do any development work on the
> > platform, I'd like to see someone else (and as I mentioned Jesse is
> > interested) take on getting some of the basic driver patches written and
> > merge only when those are accepted. Having no in-tree clock and pinctrl
> > drivers is definitely a hindrance to other people doing parallel
> > development of drivers and I'd like to avoid that.
> > 
> > Getting back to your point in this mail, whoever gets the platform to
> > that state is well suited to looking after it going forwards. Some other
> 
> The person who can bring the platfrom support to a well-moduled state,
> IE, proper clk, pinctrl, reset drivers shows the passion, the code
> contribution and solid understanding of the SoC, sure he/she is
> definitely suited to maintain the SoC. I just don't think it's 
> a good practice a person can became maintainer even w/o one LoC
> contrubition to the SoC, because IMHO code contribution matters
> for maintainership.

Right, and the th1520 is suffering a bit from that at the moment, the
maintainers other than yourself haven't sent a single LoC for it, and
have not gotten involved after you have become unable to spend time on
it. I do know that things are likely to change there soon, which is
good.

Thanks,
Conor.

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