[PATCH v5 00/13] Canaan devicetree fixes

[PATCH v5 00/13] Canaan devicetree fixes

[Conor Dooley]

From: Conor Dooley <conor.dooley@microchip.com>

Hey all,
This series should rid us of dtbs_check errors for the RISC-V Canaan k210
based boards. To make keeping it that way a little easier, I changed the
Canaan devicetree Makefile so that it would build all of the devicetrees
in the directory if SOC_CANAAN.

I *DO NOT* have any Canaan hardware so I have not tested any of this in
action. Since I sent v1, I tried to buy some since it's cheap - but could
out of the limited stockists none seemed to want to deliver to Ireland :(
I based the series on next-20220617.

Thanks,
Conor.

Changes since v4:
- add Rob's tags from v3
- sram: rephrase the binding description
- ASoC: dropped the applied binding

Changes since v3:
- dts: drop the bogus "regs" property pointed out by Niklas
- dma/timer: add Serge's reviews (and expand on the dma interrupt
  description)
- dts: add Niklas' T-b where I felt it was suitable. lmk if you think it
  applies more broadly
- spi: drop the applied spi dt-binding change. Thanks Mark.

Changes since v2:
- i2s: added clocks maxItems
- dma: unconditionally extended the interrupts & dropped canaan
  compatible
- timer: as per Sergey, split the timer dts nodes in 2 & drop the
  binding patch
- ili9341: add a canaan specific compatible to the binding and dts

Changes since v1:
- I added a new dt node & compatible for the SRAM memory controller due
  Damien's wish to preserve the inter-op with U-Boot.
- The dw-apb-ssi binding now uses the default rx/tx widths
- A new patch fixes bus {ranges,reg} warnings
- Rearranged the patches in a slightly more logical order

Conor Dooley (13):
  dt-bindings: display: convert ilitek,ili9341.txt to dt-schema
  dt-bindings: display: ili9341: document canaan kd233's lcd
  dt-bindings: dma: dw-axi-dmac: extend the number of interrupts
  dt-bindings: memory-controllers: add canaan k210 sram controller
  riscv: dts: canaan: fix the k210's memory node
  riscv: dts: canaan: fix the k210's timer nodes
  riscv: dts: canaan: fix mmc node names
  riscv: dts: canaan: fix kd233 display spi frequency
  riscv: dts: canaan: use custom compatible for k210 i2s
  riscv: dts: canaan: remove spi-max-frequency from controllers
  riscv: dts: canaan: fix bus {ranges,reg} warnings
  riscv: dts: canaan: add specific compatible for kd233's LCD
  riscv: dts: canaan: build all devicetress if SOC_CANAAN

 .../bindings/display/ilitek,ili9341.txt       | 27 -------
 .../display/panel/ilitek,ili9341.yaml         | 49 +++++++++----
 .../bindings/dma/snps,dw-axi-dmac.yaml        |  7 +-
 .../memory-controllers/canaan,k210-sram.yaml  | 52 +++++++++++++
 arch/riscv/boot/dts/canaan/Makefile           | 10 ++-
 arch/riscv/boot/dts/canaan/canaan_kd233.dts   |  6 +-
 arch/riscv/boot/dts/canaan/k210.dtsi          | 73 +++++++++++++------
 .../riscv/boot/dts/canaan/sipeed_maix_bit.dts |  2 +-
 .../boot/dts/canaan/sipeed_maix_dock.dts      |  2 +-
 arch/riscv/boot/dts/canaan/sipeed_maix_go.dts |  2 +-
 .../boot/dts/canaan/sipeed_maixduino.dts      |  2 +-
 11 files changed, 159 insertions(+), 73 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/display/ilitek,ili9341.txt
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/canaan,k210-sram.yaml


base-commit: b6f1f2fa2bddd69ff46a190b8120bd440fd50563
-- 
2.37.0

[PATCH v5 01/13] dt-bindings: display: convert ilitek,ili9341.txt to dt-schema

[Conor Dooley]

From: Conor Dooley <conor.dooley@microchip.com>

A dt-schema binding for the Ilitek ili9341 was created as
panel/ilitek,ili9341.yaml but the txt binding was ignored in the
process. Move the remaining items in the txt binding to the yaml one &
delete it.

The example in the txt binding has a spi-max-frequency which disagrees
with the yaml replacement (and its own documentation) so change that to
conform with the binding. There are no users in tree of the Adafruit
yx240qv29 to check against.

Link: https://cdn-learn.adafruit.com/assets/assets/000/046/879/original/SPEC-YX240QV29-T_Rev.A__1_.pdf
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
---
 .../bindings/display/ilitek,ili9341.txt       | 27 -----------
 .../display/panel/ilitek,ili9341.yaml         | 48 +++++++++++++------
 2 files changed, 34 insertions(+), 41 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/display/ilitek,ili9341.txt

diff --git a/Documentation/devicetree/bindings/display/ilitek,ili9341.txt b/Documentation/devicetree/bindings/display/ilitek,ili9341.txt
deleted file mode 100644
index 169b32e4ee4e..000000000000
--- a/Documentation/devicetree/bindings/display/ilitek,ili9341.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-Ilitek ILI9341 display panels
-
-This binding is for display panels using an Ilitek ILI9341 controller in SPI
-mode.
-
-Required properties:
-- compatible:	"adafruit,yx240qv29", "ilitek,ili9341"
-- dc-gpios:	D/C pin
-- reset-gpios:	Reset pin
-
-The node for this driver must be a child node of a SPI controller, hence
-all mandatory properties described in ../spi/spi-bus.txt must be specified.
-
-Optional properties:
-- rotation:	panel rotation in degrees counter clockwise (0,90,180,270)
-- backlight:	phandle of the backlight device attached to the panel
-
-Example:
-	display@0{
-		compatible = "adafruit,yx240qv29", "ilitek,ili9341";
-		reg = <0>;
-		spi-max-frequency = <32000000>;
-		dc-gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>;
-		reset-gpios = <&gpio0 8 GPIO_ACTIVE_HIGH>;
-		rotation = <270>;
-		backlight = <&backlight>;
-	};
diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml
index 6058948a9764..c5571391ca28 100644
--- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml
+++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml
@@ -21,6 +21,7 @@ properties:
   compatible:
     items:
       - enum:
+          - adafruit,yx240qv29
           # ili9341 240*320 Color on stm32f429-disco board
           - st,sf-tc240t-9370-t
       - const: ilitek,ili9341
@@ -47,31 +48,50 @@ properties:
   vddi-led-supply:
     description: Voltage supply for the LED driver (1.65 .. 3.3 V)
 
-additionalProperties: false
+unevaluatedProperties: false
 
 required:
   - compatible
   - reg
   - dc-gpios
-  - port
+
+if:
+  properties:
+    compatible:
+      contains:
+        enum:
+          - st,sf-tc240t-9370-t
+then:
+  required:
+    - port
 
 examples:
   - |+
+    #include <dt-bindings/gpio/gpio.h>
     spi {
         #address-cells = <1>;
         #size-cells = <0>;
         panel: display@0 {
-                 compatible = "st,sf-tc240t-9370-t",
-                              "ilitek,ili9341";
-                 reg = <0>;
-                 spi-3wire;
-                 spi-max-frequency = <10000000>;
-                 dc-gpios = <&gpiod 13 0>;
-                 port {
-                         panel_in: endpoint {
-                           remote-endpoint = <&display_out>;
-                      };
-                 };
-             };
+            compatible = "st,sf-tc240t-9370-t",
+                         "ilitek,ili9341";
+            reg = <0>;
+            spi-3wire;
+            spi-max-frequency = <10000000>;
+            dc-gpios = <&gpiod 13 0>;
+            port {
+                panel_in: endpoint {
+                    remote-endpoint = <&display_out>;
+                };
+            };
+        };
+        display@1{
+            compatible = "adafruit,yx240qv29", "ilitek,ili9341";
+            reg = <1>;
+            spi-max-frequency = <10000000>;
+            dc-gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>;
+            reset-gpios = <&gpio0 8 GPIO_ACTIVE_HIGH>;
+            rotation = <270>;
+            backlight = <&backlight>;
         };
+    };
 ...
-- 
2.37.0

[PATCH v5 02/13] dt-bindings: display: ili9341: document canaan kd233's lcd

[Conor Dooley]

From: Conor Dooley <conor.dooley@microchip.com>

The Canaan KD233 development board has a built in LCD.
Add a specific compatible for it.

Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
---
 .../devicetree/bindings/display/panel/ilitek,ili9341.yaml        | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml
index c5571391ca28..99e0cb9440cf 100644
--- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml
+++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml
@@ -24,6 +24,7 @@ properties:
           - adafruit,yx240qv29
           # ili9341 240*320 Color on stm32f429-disco board
           - st,sf-tc240t-9370-t
+          - canaan,kd233-tft
       - const: ilitek,ili9341
 
   reg: true
-- 
2.37.0

Re: [PATCH v5 02/13] dt-bindings: display: ili9341: document canaan kd233's lcd

[Conor.Dooley]

DRM Maintainers,
I've not had a comment on patch 1 & 2 (the DRM applicable ones)
from from the files listed maintainer on any version. I'd love
to get these device trees fixed for v5.20 if possible, so I am
bumping a little early b/c it looks like there may not be long
left before the mw opens.

Would you mind applying these two patches? They've both already
got Rob's R-b.

Thanks!
Conor

On 05/07/2022 22:52, Conor Dooley wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> From: Conor Dooley <conor.dooley@microchip.com>
> 
> The Canaan KD233 development board has a built in LCD.
> Add a specific compatible for it.
> 
> Reviewed-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> ---
>   .../devicetree/bindings/display/panel/ilitek,ili9341.yaml        | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml
> index c5571391ca28..99e0cb9440cf 100644
> --- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml
> @@ -24,6 +24,7 @@ properties:
>             - adafruit,yx240qv29
>             # ili9341 240*320 Color on stm32f429-disco board
>             - st,sf-tc240t-9370-t
> +          - canaan,kd233-tft
>         - const: ilitek,ili9341
> 
>     reg: true
> --
> 2.37.0
> 
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH v5 03/13] dt-bindings: dma: dw-axi-dmac: extend the number of interrupts

[Conor Dooley]

From: Conor Dooley <conor.dooley@microchip.com>

The Canaan k210 apparently has a Sysnopsys Designware AXI DMA
controller, but according to the documentation & devicetree it has 6
interrupts rather than the standard one. Support the 6 interrupt
configuration by unconditionally extending the binding to a maximum of
8 per-channel interrupts thereby matching the number of possible
channels.

Link: https://canaan-creative.com/wp-content/uploads/2020/03/kendryte_standalone_programming_guide_20190311144158_en.pdf #Page 51
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
---
 .../devicetree/bindings/dma/snps,dw-axi-dmac.yaml          | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml b/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml
index 4324a94b26b2..67aa7bb6d36a 100644
--- a/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml
+++ b/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml
@@ -34,7 +34,12 @@ properties:
       - const: axidma_apb_regs
 
   interrupts:
-    maxItems: 1
+    description:
+      If the IP-core synthesis parameter DMAX_INTR_IO_TYPE is set to 1, this
+      will be per-channel interrupts. Otherwise, this is a single combined IRQ
+      for all channels.
+    minItems: 1
+    maxItems: 8
 
   clocks:
     items:
-- 
2.37.0

Re: [PATCH v5 03/13] dt-bindings: dma: dw-axi-dmac: extend the number of interrupts

[Vinod Koul]

On 05-07-22, 22:52, Conor Dooley wrote:
> From: Conor Dooley <conor.dooley@microchip.com>
> 
> The Canaan k210 apparently has a Sysnopsys Designware AXI DMA
> controller, but according to the documentation & devicetree it has 6
> interrupts rather than the standard one. Support the 6 interrupt
> configuration by unconditionally extending the binding to a maximum of
> 8 per-channel interrupts thereby matching the number of possible
> channels.

Applied, thanks

-- 
~Vinod

Re: [PATCH v5 03/13] dt-bindings: dma: dw-axi-dmac: extend the number of interrupts

[Ben Dooks]

On 05/07/2022 22:52, Conor Dooley wrote:
> From: Conor Dooley <conor.dooley@microchip.com>
> 
> The Canaan k210 apparently has a Sysnopsys Designware AXI DMA
> controller, but according to the documentation & devicetree it has 6
> interrupts rather than the standard one. Support the 6 interrupt
> configuration by unconditionally extending the binding to a maximum of
> 8 per-channel interrupts thereby matching the number of possible
> channels.

I think you can still configure it to produce a single interrupt
even if there are per-channel interrupts available. This is from
my reading of the driver a little while ago so may not be totally
correct now.

Having per-channel irqs might be useful in the future, but as above
I think it'll require the driver to be updated to do it (and possibly
some sort of detection)


> Link: https://canaan-creative.com/wp-content/uploads/2020/03/kendryte_standalone_programming_guide_20190311144158_en.pdf #Page 51
> Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> ---
>   .../devicetree/bindings/dma/snps,dw-axi-dmac.yaml          | 7 ++++++-
>   1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml b/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml
> index 4324a94b26b2..67aa7bb6d36a 100644
> --- a/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml
> +++ b/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml
> @@ -34,7 +34,12 @@ properties:
>         - const: axidma_apb_regs
>   
>     interrupts:
> -    maxItems: 1
> +    description:
> +      If the IP-core synthesis parameter DMAX_INTR_IO_TYPE is set to 1, this
> +      will be per-channel interrupts. Otherwise, this is a single combined IRQ
> +      for all channels.
> +    minItems: 1
> +    maxItems: 8
>   
>     clocks:
>       items:


-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

https://www.codethink.co.uk/privacy.html

Re: [PATCH v5 03/13] dt-bindings: dma: dw-axi-dmac: extend the number of interrupts

[Conor.Dooley]

On 18/07/2022 16:12, Ben Dooks wrote:
> On 05/07/2022 22:52, Conor Dooley wrote:
>> From: Conor Dooley <conor.dooley@microchip.com>
>>
>> The Canaan k210 apparently has a Sysnopsys Designware AXI DMA
>> controller, but according to the documentation & devicetree it has 6
>> interrupts rather than the standard one. Support the 6 interrupt
>> configuration by unconditionally extending the binding to a maximum of
>> 8 per-channel interrupts thereby matching the number of possible
>> channels.
> 
> I think you can still configure it to produce a single interrupt
> even if there are per-channel interrupts available. This is from
> my reading of the driver a little while ago so may not be totally
> correct now.
> 
> Having per-channel irqs might be useful in the future, but as above
> I think it'll require the driver to be updated to do it (and possibly
> some sort of detection)
> 

Yah, driver would need an update. But happily that does not matter for
the validity of the binding.

[PATCH v5 04/13] dt-bindings: memory-controllers: add canaan k210 sram controller

[Conor Dooley]

From: Conor Dooley <conor.dooley@microchip.com>

The k210 U-Boot port has been using the clocks defined in the
devicetree to bring up the board's SRAM, but this violates the
dt-schema. As such, move the clocks to a dedicated node with
the same compatible string & document it.

Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
---
 .../memory-controllers/canaan,k210-sram.yaml  | 52 +++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/canaan,k210-sram.yaml

diff --git a/Documentation/devicetree/bindings/memory-controllers/canaan,k210-sram.yaml b/Documentation/devicetree/bindings/memory-controllers/canaan,k210-sram.yaml
new file mode 100644
index 000000000000..f81fb866e319
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/canaan,k210-sram.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/memory-controllers/canaan,k210-sram.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Canaan K210 SRAM memory controller
+
+description:
+  The Canaan K210 SRAM memory controller is responsible for the system's 8 MiB
+  of SRAM. The controller is initialised by the bootloader, which configures
+  its clocks, before OS bringup.
+
+maintainers:
+  - Conor Dooley <conor@kernel.org>
+
+properties:
+  compatible:
+    enum:
+      - canaan,k210-sram
+
+  clocks:
+    minItems: 1
+    items:
+      - description: sram0 clock
+      - description: sram1 clock
+      - description: aisram clock
+
+  clock-names:
+    minItems: 1
+    items:
+      - const: sram0
+      - const: sram1
+      - const: aisram
+
+required:
+  - compatible
+  - clocks
+  - clock-names
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/k210-clk.h>
+    memory-controller {
+        compatible = "canaan,k210-sram";
+        clocks = <&sysclk K210_CLK_SRAM0>,
+                 <&sysclk K210_CLK_SRAM1>,
+                 <&sysclk K210_CLK_AI>;
+        clock-names = "sram0", "sram1", "aisram";
+    };
-- 
2.37.0

Re: [PATCH v5 04/13] dt-bindings: memory-controllers: add canaan k210 sram controller

[Rob Herring]

On Tue, 05 Jul 2022 22:52:05 +0100, Conor Dooley wrote:
> From: Conor Dooley <conor.dooley@microchip.com>
> 
> The k210 U-Boot port has been using the clocks defined in the
> devicetree to bring up the board's SRAM, but this violates the
> dt-schema. As such, move the clocks to a dedicated node with
> the same compatible string & document it.
> 
> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> ---
>  .../memory-controllers/canaan,k210-sram.yaml  | 52 +++++++++++++++++++
>  1 file changed, 52 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/memory-controllers/canaan,k210-sram.yaml
> 

Reviewed-by: Rob Herring <robh@kernel.org>

Re: [PATCH v5 04/13] dt-bindings: memory-controllers: add canaan k210 sram controller

[Conor.Dooley]

Damien, Krzysztof,

I know this particular version has not been posted for all that
long, but this binding is (functionally) unchanged for a few
versions now. Are you happy with this approach Damien?
U-Boot only cares about the compatible & the clocks property,
not the regs etc.

I (lazily) tested it in U-Boot with the following diff:

diff --git a/arch/riscv/dts/k210.dtsi b/arch/riscv/dts/k210.dtsi
index 3cc8379133..314db88340 100644
--- a/arch/riscv/dts/k210.dtsi
+++ b/arch/riscv/dts/k210.dtsi
@@ -82,11 +82,14 @@
 
        sram: memory@80000000 {
                device_type = "memory";
+               reg = <0x80000000 0x400000>, /* sram0 4 MiB */
+                     <0x80400000 0x200000>, /* sram1 2 MiB */
+                     <0x80600000 0x200000>; /* aisram 2 MiB */
+               u-boot,dm-pre-reloc;
+       };
+
+       sram_controller: memory-controller {
                compatible = "canaan,k210-sram";
-               reg = <0x80000000 0x400000>,
-                     <0x80400000 0x200000>,
-                     <0x80600000 0x200000>;
-               reg-names = "sram0", "sram1", "aisram";
                clocks = <&sysclk K210_CLK_SRAM0>,
                         <&sysclk K210_CLK_SRAM1>,
                         <&sysclk K210_CLK_AI>;

If so, could you queue this for 5.20 please Krzysztof, unless
you've got concerns about it?

Thanks,
Conor.

On 05/07/2022 22:52, Conor Dooley wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> From: Conor Dooley <conor.dooley@microchip.com>
> 
> The k210 U-Boot port has been using the clocks defined in the
> devicetree to bring up the board's SRAM, but this violates the
> dt-schema. As such, move the clocks to a dedicated node with
> the same compatible string & document it.
> 
> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> ---
>  .../memory-controllers/canaan,k210-sram.yaml  | 52 +++++++++++++++++++
>  1 file changed, 52 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/memory-controllers/canaan,k210-sram.yaml
> 
> diff --git a/Documentation/devicetree/bindings/memory-controllers/canaan,k210-sram.yaml b/Documentation/devicetree/bindings/memory-controllers/canaan,k210-sram.yaml
> new file mode 100644
> index 000000000000..f81fb866e319
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/memory-controllers/canaan,k210-sram.yaml
> @@ -0,0 +1,52 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/memory-controllers/canaan,k210-sram.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Canaan K210 SRAM memory controller
> +
> +description:
> +  The Canaan K210 SRAM memory controller is responsible for the system's 8 MiB
> +  of SRAM. The controller is initialised by the bootloader, which configures
> +  its clocks, before OS bringup.
> +
> +maintainers:
> +  - Conor Dooley <conor@kernel.org>
> +
> +properties:
> +  compatible:
> +    enum:
> +      - canaan,k210-sram
> +
> +  clocks:
> +    minItems: 1
> +    items:
> +      - description: sram0 clock
> +      - description: sram1 clock
> +      - description: aisram clock
> +
> +  clock-names:
> +    minItems: 1
> +    items:
> +      - const: sram0
> +      - const: sram1
> +      - const: aisram
> +
> +required:
> +  - compatible
> +  - clocks
> +  - clock-names
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/clock/k210-clk.h>
> +    memory-controller {
> +        compatible = "canaan,k210-sram";
> +        clocks = <&sysclk K210_CLK_SRAM0>,
> +                 <&sysclk K210_CLK_SRAM1>,
> +                 <&sysclk K210_CLK_AI>;
> +        clock-names = "sram0", "sram1", "aisram";
> +    };
> --
> 2.37.0
> 

Re: [PATCH v5 04/13] dt-bindings: memory-controllers: add canaan k210 sram controller

[Damien Le Moal]

On 7/11/22 04:39, Conor.Dooley@microchip.com wrote:
> Damien, Krzysztof,
> 
> I know this particular version has not been posted for all that
> long, but this binding is (functionally) unchanged for a few
> versions now. Are you happy with this approach Damien?
> U-Boot only cares about the compatible & the clocks property,
> not the regs etc.
> 
> I (lazily) tested it in U-Boot with the following diff:

If both the kernel and u-boot still work as expected with this change, I
am OK with it.

> 
> diff --git a/arch/riscv/dts/k210.dtsi b/arch/riscv/dts/k210.dtsi
> index 3cc8379133..314db88340 100644
> --- a/arch/riscv/dts/k210.dtsi
> +++ b/arch/riscv/dts/k210.dtsi
> @@ -82,11 +82,14 @@
>  
>         sram: memory@80000000 {
>                 device_type = "memory";
> +               reg = <0x80000000 0x400000>, /* sram0 4 MiB */
> +                     <0x80400000 0x200000>, /* sram1 2 MiB */
> +                     <0x80600000 0x200000>; /* aisram 2 MiB */
> +               u-boot,dm-pre-reloc;
> +       };
> +
> +       sram_controller: memory-controller {
>                 compatible = "canaan,k210-sram";
> -               reg = <0x80000000 0x400000>,
> -                     <0x80400000 0x200000>,
> -                     <0x80600000 0x200000>;
> -               reg-names = "sram0", "sram1", "aisram";
>                 clocks = <&sysclk K210_CLK_SRAM0>,
>                          <&sysclk K210_CLK_SRAM1>,
>                          <&sysclk K210_CLK_AI>;
> 
> If so, could you queue this for 5.20 please Krzysztof, unless
> you've got concerns about it?
> 
> Thanks,
> Conor.
> 
> On 05/07/2022 22:52, Conor Dooley wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>
>> From: Conor Dooley <conor.dooley@microchip.com>
>>
>> The k210 U-Boot port has been using the clocks defined in the
>> devicetree to bring up the board's SRAM, but this violates the
>> dt-schema. As such, move the clocks to a dedicated node with
>> the same compatible string & document it.
>>
>> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
>> ---
>>  .../memory-controllers/canaan,k210-sram.yaml  | 52 +++++++++++++++++++
>>  1 file changed, 52 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/memory-controllers/canaan,k210-sram.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/memory-controllers/canaan,k210-sram.yaml b/Documentation/devicetree/bindings/memory-controllers/canaan,k210-sram.yaml
>> new file mode 100644
>> index 000000000000..f81fb866e319
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/memory-controllers/canaan,k210-sram.yaml
>> @@ -0,0 +1,52 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/memory-controllers/canaan,k210-sram.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Canaan K210 SRAM memory controller
>> +
>> +description:
>> +  The Canaan K210 SRAM memory controller is responsible for the system's 8 MiB
>> +  of SRAM. The controller is initialised by the bootloader, which configures
>> +  its clocks, before OS bringup.
>> +
>> +maintainers:
>> +  - Conor Dooley <conor@kernel.org>
>> +
>> +properties:
>> +  compatible:
>> +    enum:
>> +      - canaan,k210-sram
>> +
>> +  clocks:
>> +    minItems: 1
>> +    items:
>> +      - description: sram0 clock
>> +      - description: sram1 clock
>> +      - description: aisram clock
>> +
>> +  clock-names:
>> +    minItems: 1
>> +    items:
>> +      - const: sram0
>> +      - const: sram1
>> +      - const: aisram
>> +
>> +required:
>> +  - compatible
>> +  - clocks
>> +  - clock-names
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> +  - |
>> +    #include <dt-bindings/clock/k210-clk.h>
>> +    memory-controller {
>> +        compatible = "canaan,k210-sram";
>> +        clocks = <&sysclk K210_CLK_SRAM0>,
>> +                 <&sysclk K210_CLK_SRAM1>,
>> +                 <&sysclk K210_CLK_AI>;
>> +        clock-names = "sram0", "sram1", "aisram";
>> +    };
>> --
>> 2.37.0
>>
> 


-- 
Damien Le Moal
Western Digital Research

Re: [PATCH v5 04/13] dt-bindings: memory-controllers: add canaan k210 sram controller

[Conor.Dooley]

On 11/07/2022 00:21, Damien Le Moal wrote:
> On 7/11/22 04:39, Conor.Dooley@microchip.com wrote:
>> Damien, Krzysztof,
>>
>> I know this particular version has not been posted for all that
>> long, but this binding is (functionally) unchanged for a few
>> versions now. Are you happy with this approach Damien?
>> U-Boot only cares about the compatible & the clocks property,
>> not the regs etc.
>>
>> I (lazily) tested it in U-Boot with the following diff:
> 
> If both the kernel and u-boot still work as expected with this change, I
> am OK with it.

It's all yours so Krzysztof :)

Thanks,
Conor.

> 
>>
>> diff --git a/arch/riscv/dts/k210.dtsi b/arch/riscv/dts/k210.dtsi
>> index 3cc8379133..314db88340 100644
>> --- a/arch/riscv/dts/k210.dtsi
>> +++ b/arch/riscv/dts/k210.dtsi
>> @@ -82,11 +82,14 @@
>>  
>>         sram: memory@80000000 {
>>                 device_type = "memory";
>> +               reg = <0x80000000 0x400000>, /* sram0 4 MiB */
>> +                     <0x80400000 0x200000>, /* sram1 2 MiB */
>> +                     <0x80600000 0x200000>; /* aisram 2 MiB */
>> +               u-boot,dm-pre-reloc;
>> +       };
>> +
>> +       sram_controller: memory-controller {
>>                 compatible = "canaan,k210-sram";
>> -               reg = <0x80000000 0x400000>,
>> -                     <0x80400000 0x200000>,
>> -                     <0x80600000 0x200000>;
>> -               reg-names = "sram0", "sram1", "aisram";
>>                 clocks = <&sysclk K210_CLK_SRAM0>,
>>                          <&sysclk K210_CLK_SRAM1>,
>>                          <&sysclk K210_CLK_AI>;
>>
>> If so, could you queue this for 5.20 please Krzysztof, unless
>> you've got concerns about it?
>>
>> Thanks,
>> Conor.
>>
>> On 05/07/2022 22:52, Conor Dooley wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>
>>> From: Conor Dooley <conor.dooley@microchip.com>
>>>
>>> The k210 U-Boot port has been using the clocks defined in the
>>> devicetree to bring up the board's SRAM, but this violates the
>>> dt-schema. As such, move the clocks to a dedicated node with
>>> the same compatible string & document it.
>>>
>>> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
>>> ---
>>>  .../memory-controllers/canaan,k210-sram.yaml  | 52 +++++++++++++++++++
>>>  1 file changed, 52 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/memory-controllers/canaan,k210-sram.yaml
>>>
>>> diff --git a/Documentation/devicetree/bindings/memory-controllers/canaan,k210-sram.yaml b/Documentation/devicetree/bindings/memory-controllers/canaan,k210-sram.yaml
>>> new file mode 100644
>>> index 000000000000..f81fb866e319
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/memory-controllers/canaan,k210-sram.yaml
>>> @@ -0,0 +1,52 @@
>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/memory-controllers/canaan,k210-sram.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: Canaan K210 SRAM memory controller
>>> +
>>> +description:
>>> +  The Canaan K210 SRAM memory controller is responsible for the system's 8 MiB
>>> +  of SRAM. The controller is initialised by the bootloader, which configures
>>> +  its clocks, before OS bringup.
>>> +
>>> +maintainers:
>>> +  - Conor Dooley <conor@kernel.org>
>>> +
>>> +properties:
>>> +  compatible:
>>> +    enum:
>>> +      - canaan,k210-sram
>>> +
>>> +  clocks:
>>> +    minItems: 1
>>> +    items:
>>> +      - description: sram0 clock
>>> +      - description: sram1 clock
>>> +      - description: aisram clock
>>> +
>>> +  clock-names:
>>> +    minItems: 1
>>> +    items:
>>> +      - const: sram0
>>> +      - const: sram1
>>> +      - const: aisram
>>> +
>>> +required:
>>> +  - compatible
>>> +  - clocks
>>> +  - clock-names
>>> +
>>> +additionalProperties: false
>>> +
>>> +examples:
>>> +  - |
>>> +    #include <dt-bindings/clock/k210-clk.h>
>>> +    memory-controller {
>>> +        compatible = "canaan,k210-sram";
>>> +        clocks = <&sysclk K210_CLK_SRAM0>,
>>> +                 <&sysclk K210_CLK_SRAM1>,
>>> +                 <&sysclk K210_CLK_AI>;
>>> +        clock-names = "sram0", "sram1", "aisram";
>>> +    };
>>> --
>>> 2.37.0
>>>
>>
> 
> 

Re: [PATCH v5 04/13] dt-bindings: memory-controllers: add canaan k210 sram controller

[Krzysztof Kozlowski]

On 12/07/2022 17:54, Conor.Dooley@microchip.com wrote:
> On 11/07/2022 00:21, Damien Le Moal wrote:
>> On 7/11/22 04:39, Conor.Dooley@microchip.com wrote:
>>> Damien, Krzysztof,
>>>
>>> I know this particular version has not been posted for all that
>>> long, but this binding is (functionally) unchanged for a few
>>> versions now. Are you happy with this approach Damien?
>>> U-Boot only cares about the compatible & the clocks property,
>>> not the regs etc.
>>>
>>> I (lazily) tested it in U-Boot with the following diff:
>>
>> If both the kernel and u-boot still work as expected with this change, I
>> am OK with it.
> 
> It's all yours so Krzysztof :)

It's too late in the cycle for me to pick it up. If you have alternate
tree to take it through, go ahead with:

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Otherwise, I'll take it after the merge window of v5.20, so in ~1 month
according to crystal ball.

Best regards,
Krzysztof

Re: [PATCH v5 04/13] dt-bindings: memory-controllers: add canaan k210 sram controller

[Conor.Dooley]

On 12/07/2022 16:59, Krzysztof Kozlowski wrote:
> On 12/07/2022 17:54, Conor.Dooley@microchip.com wrote:
>> On 11/07/2022 00:21, Damien Le Moal wrote:
>>> On 7/11/22 04:39, Conor.Dooley@microchip.com wrote:
>>>> Damien, Krzysztof,
>>>>
>>>> I know this particular version has not been posted for all that
>>>> long, but this binding is (functionally) unchanged for a few
>>>> versions now. Are you happy with this approach Damien?
>>>> U-Boot only cares about the compatible & the clocks property,
>>>> not the regs etc.
>>>>
>>>> I (lazily) tested it in U-Boot with the following diff:
>>>
>>> If both the kernel and u-boot still work as expected with this change, I
>>> am OK with it.
>>
>> It's all yours so Krzysztof :)
> 
> It's too late in the cycle for me to pick it up. If you have alternate
> tree to take it through, go ahead with:
> 
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> 
> Otherwise, I'll take it after the merge window of v5.20, so in ~1 month
> according to crystal ball.


Cool, thanks Krzysztof. I know it is late in the game for v5.20.
Part of me is hoping that Palmer can take it with the dts patches,
going to bump all the outstanding & reviewed riscv dts patches when
I send my PR this weekend.

If not, I'll remind you in a month. Thanks,
Conor.

Re: [PATCH v5 04/13] dt-bindings: memory-controllers: add canaan k210 sram controller

[Krzysztof Kozlowski]

On 06/07/2022 00:52, Conor Dooley wrote:
> From: Conor Dooley <conor.dooley@microchip.com>
> 
> The k210 U-Boot port has been using the clocks defined in the
> devicetree to bring up the board's SRAM, but this violates the
> dt-schema. As such, move the clocks to a dedicated node with
> the same compatible string & document it.
> 
> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> ---

Does not apply to my tree. Please rebase and resend.

Best regards,
Krzysztof

Re: [PATCH v5 04/13] dt-bindings: memory-controllers: add canaan k210 sram controller

[Conor.Dooley]

On 16/08/2022 10:27, Krzysztof Kozlowski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On 06/07/2022 00:52, Conor Dooley wrote:
>> From: Conor Dooley <conor.dooley@microchip.com>
>>
>> The k210 U-Boot port has been using the clocks defined in the
>> devicetree to bring up the board's SRAM, but this violates the
>> dt-schema. As such, move the clocks to a dedicated node with
>> the same compatible string & document it.
>>
>> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
>> ---
> 
> Does not apply to my tree. Please rebase and resend.

Palmer took it with the rest of the canaan stuff as per:
https://lore.kernel.org/all/eeed43cf-7bd6-9d77-9e1f-e018a236a058@linaro.org/

It is now in v6.0-rc1:
commit 727b05e46cffd74adca96ca13e57352339875586
Author: Conor Dooley <conor.dooley@microchip.com>
Date:   Tue Jul 5 22:52:05 2022 +0100

     dt-bindings: memory-controllers: add canaan k210 sram controller
     
     The k210 U-Boot port has been using the clocks defined in the
     devicetree to bring up the board's SRAM, but this violates the
     dt-schema. As such, move the clocks to a dedicated node with
     the same compatible string & document it.
     
     Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
     Reviewed-by: Rob Herring <robh@kernel.org>
     Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
     Link: https://lore.kernel.org/r/20220705215213.1802496-5-mail@conchuod.ie
     Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>

[PATCH v5 05/13] riscv: dts: canaan: fix the k210's memory node

[Conor Dooley]

From: Conor Dooley <conor.dooley@microchip.com>

The k210 U-Boot port has been using the clocks defined in the
devicetree to bring up the board's SRAM, but this violates the
dt-schema. As such, move the clocks to a dedicated node with
the same compatible string. The regs property does not fit in
either node, so is replaced by comments.

Tested-by: Niklas Cassel <niklas.cassel@wdc.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
---
 arch/riscv/boot/dts/canaan/k210.dtsi | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/riscv/boot/dts/canaan/k210.dtsi b/arch/riscv/boot/dts/canaan/k210.dtsi
index 44d338514761..cd4eae82d8b2 100644
--- a/arch/riscv/boot/dts/canaan/k210.dtsi
+++ b/arch/riscv/boot/dts/canaan/k210.dtsi
@@ -69,11 +69,13 @@ cpu1_intc: interrupt-controller {
 
 	sram: memory@80000000 {
 		device_type = "memory";
+		reg = <0x80000000 0x400000>, /* sram0 4 MiB */
+		      <0x80400000 0x200000>, /* sram1 2 MiB */
+		      <0x80600000 0x200000>; /* aisram 2 MiB */
+	};
+
+	sram_controller: memory-controller {
 		compatible = "canaan,k210-sram";
-		reg = <0x80000000 0x400000>,
-		      <0x80400000 0x200000>,
-		      <0x80600000 0x200000>;
-		reg-names = "sram0", "sram1", "aisram";
 		clocks = <&sysclk K210_CLK_SRAM0>,
 			 <&sysclk K210_CLK_SRAM1>,
 			 <&sysclk K210_CLK_AI>;
-- 
2.37.0

[PATCH v5 06/13] riscv: dts: canaan: fix the k210's timer nodes

[Conor Dooley]

From: Conor Dooley <conor.dooley@microchip.com>

The timers on the k210 have non standard interrupt configurations,
which leads to dtbs_check warnings:

k210_generic.dtb: timer@502d0000: interrupts: [[14], [15]] is too long
From schema: Documentation/devicetree/bindings/timer/snps,dw-apb-timer.yaml

Split the timer nodes in two, so that the second timer in the IP block
can actually be accessed & in the process solve the dtbs_check warning.

Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
---
 arch/riscv/boot/dts/canaan/k210.dtsi | 46 +++++++++++++++++++++++-----
 1 file changed, 38 insertions(+), 8 deletions(-)

diff --git a/arch/riscv/boot/dts/canaan/k210.dtsi b/arch/riscv/boot/dts/canaan/k210.dtsi
index cd4eae82d8b2..72f70128d751 100644
--- a/arch/riscv/boot/dts/canaan/k210.dtsi
+++ b/arch/riscv/boot/dts/canaan/k210.dtsi
@@ -319,28 +319,58 @@ fpioa: pinmux@502b0000 {
 
 			timer0: timer@502d0000 {
 				compatible = "snps,dw-apb-timer";
-				reg = <0x502D0000 0x100>;
-				interrupts = <14>, <15>;
+				reg = <0x502D0000 0x14>;
+				interrupts = <14>;
 				clocks = <&sysclk K210_CLK_TIMER0>,
 					 <&sysclk K210_CLK_APB0>;
 				clock-names = "timer", "pclk";
 				resets = <&sysrst K210_RST_TIMER0>;
 			};
 
-			timer1: timer@502e0000 {
+			timer1: timer@502d0014 {
 				compatible = "snps,dw-apb-timer";
-				reg = <0x502E0000 0x100>;
-				interrupts = <16>, <17>;
+				reg = <0x502D0014 0x14>;
+				interrupts = <15>;
+				clocks = <&sysclk K210_CLK_TIMER0>,
+					 <&sysclk K210_CLK_APB0>;
+				clock-names = "timer", "pclk";
+				resets = <&sysrst K210_RST_TIMER0>;
+			};
+
+			timer2: timer@502e0000 {
+				compatible = "snps,dw-apb-timer";
+				reg = <0x502E0000 0x14>;
+				interrupts = <16>;
 				clocks = <&sysclk K210_CLK_TIMER1>,
 					 <&sysclk K210_CLK_APB0>;
 				clock-names = "timer", "pclk";
 				resets = <&sysrst K210_RST_TIMER1>;
 			};
 
-			timer2: timer@502f0000 {
+			timer3: timer@502e0014 {
+				compatible = "snps,dw-apb-timer";
+				reg = <0x502E0014 0x114>;
+				interrupts = <17>;
+				clocks = <&sysclk K210_CLK_TIMER1>,
+					 <&sysclk K210_CLK_APB0>;
+				clock-names = "timer", "pclk";
+				resets = <&sysrst K210_RST_TIMER1>;
+			};
+
+			timer4: timer@502f0000 {
+				compatible = "snps,dw-apb-timer";
+				reg = <0x502F0000 0x14>;
+				interrupts = <18>;
+				clocks = <&sysclk K210_CLK_TIMER2>,
+					 <&sysclk K210_CLK_APB0>;
+				clock-names = "timer", "pclk";
+				resets = <&sysrst K210_RST_TIMER2>;
+			};
+
+			timer5: timer@502f0014 {
 				compatible = "snps,dw-apb-timer";
-				reg = <0x502F0000 0x100>;
-				interrupts = <18>, <19>;
+				reg = <0x502F0014 0x14>;
+				interrupts = <19>;
 				clocks = <&sysclk K210_CLK_TIMER2>,
 					 <&sysclk K210_CLK_APB0>;
 				clock-names = "timer", "pclk";
-- 
2.37.0

[PATCH v5 07/13] riscv: dts: canaan: fix mmc node names

[Conor Dooley]

From: Conor Dooley <conor.dooley@microchip.com>

The newly-converted-to-dt-schema binding expects the mmc node name to be
'^mmc(@.*)?$' so align the devicetree with the schema.

Tested-by: Niklas Cassel <niklas.cassel@wdc.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
---
 arch/riscv/boot/dts/canaan/canaan_kd233.dts     | 2 +-
 arch/riscv/boot/dts/canaan/sipeed_maix_bit.dts  | 2 +-
 arch/riscv/boot/dts/canaan/sipeed_maix_dock.dts | 2 +-
 arch/riscv/boot/dts/canaan/sipeed_maix_go.dts   | 2 +-
 arch/riscv/boot/dts/canaan/sipeed_maixduino.dts | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/riscv/boot/dts/canaan/canaan_kd233.dts b/arch/riscv/boot/dts/canaan/canaan_kd233.dts
index 039b92abf046..40992d495aa8 100644
--- a/arch/riscv/boot/dts/canaan/canaan_kd233.dts
+++ b/arch/riscv/boot/dts/canaan/canaan_kd233.dts
@@ -142,7 +142,7 @@ &spi1 {
 	cs-gpios = <&gpio0 16 GPIO_ACTIVE_LOW>;
 	status = "okay";
 
-	slot@0 {
+	mmc@0 {
 		compatible = "mmc-spi-slot";
 		reg = <0>;
 		voltage-ranges = <3300 3300>;
diff --git a/arch/riscv/boot/dts/canaan/sipeed_maix_bit.dts b/arch/riscv/boot/dts/canaan/sipeed_maix_bit.dts
index b9e30df127fe..5e809d0e11fb 100644
--- a/arch/riscv/boot/dts/canaan/sipeed_maix_bit.dts
+++ b/arch/riscv/boot/dts/canaan/sipeed_maix_bit.dts
@@ -189,7 +189,7 @@ &spi1 {
 	cs-gpios = <&gpio0 13 GPIO_ACTIVE_LOW>;
 	status = "okay";
 
-	slot@0 {
+	mmc@0 {
 		compatible = "mmc-spi-slot";
 		reg = <0>;
 		voltage-ranges = <3300 3300>;
diff --git a/arch/riscv/boot/dts/canaan/sipeed_maix_dock.dts b/arch/riscv/boot/dts/canaan/sipeed_maix_dock.dts
index 8d23401b0bbb..4be5ffac6b4a 100644
--- a/arch/riscv/boot/dts/canaan/sipeed_maix_dock.dts
+++ b/arch/riscv/boot/dts/canaan/sipeed_maix_dock.dts
@@ -191,7 +191,7 @@ &spi1 {
 	cs-gpios = <&gpio0 13 GPIO_ACTIVE_LOW>;
 	status = "okay";
 
-	slot@0 {
+	mmc@0 {
 		compatible = "mmc-spi-slot";
 		reg = <0>;
 		voltage-ranges = <3300 3300>;
diff --git a/arch/riscv/boot/dts/canaan/sipeed_maix_go.dts b/arch/riscv/boot/dts/canaan/sipeed_maix_go.dts
index 24fd83b43d9d..5c63f79b18ec 100644
--- a/arch/riscv/boot/dts/canaan/sipeed_maix_go.dts
+++ b/arch/riscv/boot/dts/canaan/sipeed_maix_go.dts
@@ -199,7 +199,7 @@ &spi1 {
 	cs-gpios = <&gpio0 13 GPIO_ACTIVE_LOW>;
 	status = "okay";
 
-	slot@0 {
+	mmc@0 {
 		compatible = "mmc-spi-slot";
 		reg = <0>;
 		voltage-ranges = <3300 3300>;
diff --git a/arch/riscv/boot/dts/canaan/sipeed_maixduino.dts b/arch/riscv/boot/dts/canaan/sipeed_maixduino.dts
index 25341f38292a..59f7eaf74655 100644
--- a/arch/riscv/boot/dts/canaan/sipeed_maixduino.dts
+++ b/arch/riscv/boot/dts/canaan/sipeed_maixduino.dts
@@ -164,7 +164,7 @@ &spi1 {
 	cs-gpios = <&gpio1_0 2 GPIO_ACTIVE_LOW>;
 	status = "okay";
 
-	slot@0 {
+	mmc@0 {
 		compatible = "mmc-spi-slot";
 		reg = <0>;
 		voltage-ranges = <3300 3300>;
-- 
2.37.0

[PATCH v5 08/13] riscv: dts: canaan: fix kd233 display spi frequency

[Conor Dooley]

From: Conor Dooley <conor.dooley@microchip.com>

The binding for the ili9341 specifies a const spi-max-frequency of 10
MHz but the kd233 devicetree entry has it listed at 15 Mhz.
Align the devicetree with the value in the binding.

Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
---
 arch/riscv/boot/dts/canaan/canaan_kd233.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/riscv/boot/dts/canaan/canaan_kd233.dts b/arch/riscv/boot/dts/canaan/canaan_kd233.dts
index 40992d495aa8..4a540158f287 100644
--- a/arch/riscv/boot/dts/canaan/canaan_kd233.dts
+++ b/arch/riscv/boot/dts/canaan/canaan_kd233.dts
@@ -130,7 +130,7 @@ panel@0 {
 		compatible = "ilitek,ili9341";
 		reg = <0>;
 		dc-gpios = <&gpio0 21 GPIO_ACTIVE_HIGH>;
-		spi-max-frequency = <15000000>;
+		spi-max-frequency = <10000000>;
 		status = "disabled";
 	};
 };
-- 
2.37.0

[PATCH v5 09/13] riscv: dts: canaan: use custom compatible for k210 i2s

[Conor Dooley]

From: Conor Dooley <conor.dooley@microchip.com>

The devicetrees using the Canaan k210 all have a sound-dai-cells value
of 1, whereas the standard binding example for the DesignWare i2s and
other use cases suggest 0. Use a k210 specific compatible which
supports this difference.

Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
---
 arch/riscv/boot/dts/canaan/k210.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/riscv/boot/dts/canaan/k210.dtsi b/arch/riscv/boot/dts/canaan/k210.dtsi
index 72f70128d751..900dc629a945 100644
--- a/arch/riscv/boot/dts/canaan/k210.dtsi
+++ b/arch/riscv/boot/dts/canaan/k210.dtsi
@@ -251,7 +251,7 @@ spi2: spi@50240000 {
 			};
 
 			i2s0: i2s@50250000 {
-				compatible = "snps,designware-i2s";
+				compatible = "canaan,k210-i2s", "snps,designware-i2s";
 				reg = <0x50250000 0x200>;
 				interrupts = <5>;
 				clocks = <&sysclk K210_CLK_I2S0>;
@@ -260,7 +260,7 @@ i2s0: i2s@50250000 {
 			};
 
 			i2s1: i2s@50260000 {
-				compatible = "snps,designware-i2s";
+				compatible = "canaan,k210-i2s", "snps,designware-i2s";
 				reg = <0x50260000 0x200>;
 				interrupts = <6>;
 				clocks = <&sysclk K210_CLK_I2S1>;
@@ -269,7 +269,7 @@ i2s1: i2s@50260000 {
 			};
 
 			i2s2: i2s@50270000 {
-				compatible = "snps,designware-i2s";
+				compatible = "canaan,k210-i2s", "snps,designware-i2s";
 				reg = <0x50270000 0x200>;
 				interrupts = <7>;
 				clocks = <&sysclk K210_CLK_I2S2>;
-- 
2.37.0

[PATCH v5 10/13] riscv: dts: canaan: remove spi-max-frequency from controllers

[Conor Dooley]

From: Conor Dooley <conor.dooley@microchip.com>

spi-max-frequency is a device, not a controller  property and should be
removed.

Link: https://lore.kernel.org/lkml/20220526014141.2872567-1-robh@kernel.org/
Tested-by: Niklas Cassel <niklas.cassel@wdc.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
---
 arch/riscv/boot/dts/canaan/k210.dtsi | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/arch/riscv/boot/dts/canaan/k210.dtsi b/arch/riscv/boot/dts/canaan/k210.dtsi
index 900dc629a945..948dc235e39d 100644
--- a/arch/riscv/boot/dts/canaan/k210.dtsi
+++ b/arch/riscv/boot/dts/canaan/k210.dtsi
@@ -451,7 +451,6 @@ spi0: spi@52000000 {
 				clock-names = "ssi_clk", "pclk";
 				resets = <&sysrst K210_RST_SPI0>;
 				reset-names = "spi";
-				spi-max-frequency = <25000000>;
 				num-cs = <4>;
 				reg-io-width = <4>;
 			};
@@ -467,7 +466,6 @@ spi1: spi@53000000 {
 				clock-names = "ssi_clk", "pclk";
 				resets = <&sysrst K210_RST_SPI1>;
 				reset-names = "spi";
-				spi-max-frequency = <25000000>;
 				num-cs = <4>;
 				reg-io-width = <4>;
 			};
@@ -483,8 +481,7 @@ spi3: spi@54000000 {
 				clock-names = "ssi_clk", "pclk";
 				resets = <&sysrst K210_RST_SPI3>;
 				reset-names = "spi";
-				/* Could possibly go up to 200 MHz */
-				spi-max-frequency = <100000000>;
+
 				num-cs = <4>;
 				reg-io-width = <4>;
 			};
-- 
2.37.0

[PATCH v5 11/13] riscv: dts: canaan: fix bus {ranges,reg} warnings

[Conor Dooley]

From: Conor Dooley <conor.dooley@microchip.com>

The k210 devicetrees warn about missing/empty reg and/or ranges
properties:
arch/riscv/boot/dts/canaan/k210.dtsi:408.22-460.5: Warning (unit_address_vs_reg): /soc/bus@52000000: node has a unit name, but no reg or ranges property
arch/riscv/boot/dts/canaan/k210.dtsi:352.22-406.5: Warning (simple_bus_reg): /soc/bus@50400000: missing or empty reg/ranges property

Add a ranges properties that naively caps the buses after the
allocation of their last devices.

Tested-by: Niklas Cassel <niklas.cassel@wdc.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
---
 arch/riscv/boot/dts/canaan/k210.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/riscv/boot/dts/canaan/k210.dtsi b/arch/riscv/boot/dts/canaan/k210.dtsi
index 948dc235e39d..a515e5fb1af3 100644
--- a/arch/riscv/boot/dts/canaan/k210.dtsi
+++ b/arch/riscv/boot/dts/canaan/k210.dtsi
@@ -163,7 +163,7 @@ apb0: bus@50200000 {
 			#address-cells = <1>;
 			#size-cells = <1>;
 			compatible = "simple-pm-bus";
-			ranges;
+			ranges = <0x50200000 0x50200000 0x200000>;
 			clocks = <&sysclk K210_CLK_APB0>;
 
 			gpio1: gpio@50200000 {
@@ -382,7 +382,7 @@ apb1: bus@50400000 {
 			#address-cells = <1>;
 			#size-cells = <1>;
 			compatible = "simple-pm-bus";
-			ranges;
+			ranges = <0x50400000 0x50400000 0x40100>;
 			clocks = <&sysclk K210_CLK_APB1>;
 
 			wdt0: watchdog@50400000 {
@@ -437,7 +437,7 @@ apb2: bus@52000000 {
 			#address-cells = <1>;
 			#size-cells = <1>;
 			compatible = "simple-pm-bus";
-			ranges;
+			ranges = <0x52000000 0x52000000 0x2000200>;
 			clocks = <&sysclk K210_CLK_APB2>;
 
 			spi0: spi@52000000 {
-- 
2.37.0

[PATCH v5 12/13] riscv: dts: canaan: add specific compatible for kd233's LCD

[Conor Dooley]

From: Conor Dooley <conor.dooley@microchip.com>

Add the recently introduced compatible for the LCD on the Canaan KD233.

Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
---
 arch/riscv/boot/dts/canaan/canaan_kd233.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/riscv/boot/dts/canaan/canaan_kd233.dts b/arch/riscv/boot/dts/canaan/canaan_kd233.dts
index 4a540158f287..b0cd0105a5bd 100644
--- a/arch/riscv/boot/dts/canaan/canaan_kd233.dts
+++ b/arch/riscv/boot/dts/canaan/canaan_kd233.dts
@@ -127,7 +127,7 @@ &spi0 {
 	cs-gpios = <&gpio0 20 GPIO_ACTIVE_HIGH>;
 
 	panel@0 {
-		compatible = "ilitek,ili9341";
+		compatible = "canaan,kd233-tft", "ilitek,ili9341";
 		reg = <0>;
 		dc-gpios = <&gpio0 21 GPIO_ACTIVE_HIGH>;
 		spi-max-frequency = <10000000>;
-- 
2.37.0

[PATCH v5 13/13] riscv: dts: canaan: build all devicetress if SOC_CANAAN

[Conor Dooley]

From: Conor Dooley <conor.dooley@microchip.com>

Testing & checking the Canaan devicetrees is inconvenient as only the
devicetree corresponding to SOC_CANAAN_K210_DTB_BUILTIN will be built.
Change the Makefile so that all devicetrees are built by default if
SOC_CANAAN but only the one specified by SOC_CANAAN_K210_DTB_BUILTIN
gets built as an object.

Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
---
 arch/riscv/boot/dts/canaan/Makefile | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/riscv/boot/dts/canaan/Makefile b/arch/riscv/boot/dts/canaan/Makefile
index c61b08ac8554..befe4eb7527b 100644
--- a/arch/riscv/boot/dts/canaan/Makefile
+++ b/arch/riscv/boot/dts/canaan/Makefile
@@ -1,3 +1,9 @@
 # SPDX-License-Identifier: GPL-2.0
-dtb-$(CONFIG_SOC_CANAAN_K210_DTB_BUILTIN) += $(addsuffix .dtb, $(CONFIG_SOC_CANAAN_K210_DTB_SOURCE))
-obj-$(CONFIG_SOC_CANAAN_K210_DTB_BUILTIN) += $(addsuffix .o, $(dtb-y))
+dtb-$(CONFIG_SOC_CANAAN) += canaan_kd233.dtb
+dtb-$(CONFIG_SOC_CANAAN) += k210_generic.dtb
+dtb-$(CONFIG_SOC_CANAAN) += sipeed_maix_bit.dtb
+dtb-$(CONFIG_SOC_CANAAN) += sipeed_maix_dock.dtb
+dtb-$(CONFIG_SOC_CANAAN) += sipeed_maix_go.dtb
+dtb-$(CONFIG_SOC_CANAAN) += sipeed_maixduino.dtb
+
+obj-$(CONFIG_SOC_CANAAN_K210_DTB_BUILTIN) += $(addsuffix .dtb.o, $(CONFIG_SOC_CANAAN_K210_DTB_SOURCE))
-- 
2.37.0

Re: [PATCH v5 00/13] Canaan devicetree fixes

[Geert Uytterhoeven]

Hi Conor,

On Tue, Jul 5, 2022 at 11:52 PM Conor Dooley <mail@conchuod.ie> wrote:
> I *DO NOT* have any Canaan hardware so I have not tested any of this in
> action. Since I sent v1, I tried to buy some since it's cheap - but could
> out of the limited stockists none seemed to want to deliver to Ireland :(
> I based the series on next-20220617.

Digi-Key does not want to ship to IRL?
The plain MAiX BiT is out-of-stock, but the kit incl. a display is
available (97 in stock).

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v5 00/13] Canaan devicetree fixes

[Conor.Dooley]

On 06/07/2022 09:03, Geert Uytterhoeven wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> Hi Conor,
> 
> On Tue, Jul 5, 2022 at 11:52 PM Conor Dooley <mail@conchuod.ie> wrote:
>> I *DO NOT* have any Canaan hardware so I have not tested any of this in
>> action. Since I sent v1, I tried to buy some since it's cheap - but could
>> out of the limited stockists none seemed to want to deliver to Ireland :(
>> I based the series on next-20220617.
> 
> Digi-Key does not want to ship to IRL?

Hmm, odd. I did check digikey - but with search terms like "canaan"
"k210" "kendryte" which returned nothing.
I've had some odd localisation problems with digikey before though
on the IE site. I'll change region to Ireland & an item will become
unavailable despite being purchasable.

> The plain MAiX BiT is out-of-stock, but the kit incl. a display is
> available (97 in stock).

Cool, make that 96 ;)
> Gr{oetje,eeting}s,
> 
>                          Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                  -- Linus Torvalds
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v5 00/13] Canaan devicetree fixes

[Damien Le Moal]

On 7/6/22 17:03, Geert Uytterhoeven wrote:
> Hi Conor,
> 
> On Tue, Jul 5, 2022 at 11:52 PM Conor Dooley <mail@conchuod.ie> wrote:
>> I *DO NOT* have any Canaan hardware so I have not tested any of this in
>> action. Since I sent v1, I tried to buy some since it's cheap - but could
>> out of the limited stockists none seemed to want to deliver to Ireland :(
>> I based the series on next-20220617.
> 
> Digi-Key does not want to ship to IRL?
> The plain MAiX BiT is out-of-stock, but the kit incl. a display is
> available (97 in stock).

Seedstudio is out of stock on the MAIX bit, but they have maixduino, which
is the same, almost (pin wiring differs, everything else is the same).

https://www.seeedstudio.com/Sipeed-Maixduino-Kit-for-RISC-V-AI-IoT-p-4047.html

And you can still find plenty of MAIX bit on Aliexpress too.

> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv


-- 
Damien Le Moal
Western Digital Research

Re: [PATCH v5 00/13] Canaan devicetree fixes

[Conor.Dooley]

On 06/07/2022 12:55, Damien Le Moal wrote:
> On 7/6/22 17:03, Geert Uytterhoeven wrote:
>> Hi Conor,
>>
>> On Tue, Jul 5, 2022 at 11:52 PM Conor Dooley <mail@conchuod.ie> wrote:
>>> I *DO NOT* have any Canaan hardware so I have not tested any of this in
>>> action. Since I sent v1, I tried to buy some since it's cheap - but could
>>> out of the limited stockists none seemed to want to deliver to Ireland :(
>>> I based the series on next-20220617.
>>
>> Digi-Key does not want to ship to IRL?
>> The plain MAiX BiT is out-of-stock, but the kit incl. a display is
>> available (97 in stock).
> 
> Seedstudio is out of stock on the MAIX bit, but they have maixduino, which
> is the same, almost (pin wiring differs, everything else is the same).

I picked one up from DigiKey this morning. Woulda been nice if they
used some of the k210 related words in the descriptions for the sake
of their search engine!

> https://www.seeedstudio.com/Sipeed-Maixduino-Kit-for-RISC-V-AI-IoT-p-4047.html

This was actually out of stock when I looked.
  
> And you can still find plenty of MAIX bit on Aliexpress too.

I dunno how it is for you, but I find that sometimes on Ali they
dislike my address and that was the case for the boards I checked
on Ali.

Either way, it's Ali and a merge window would come and go before
I'd get it!

Re: [PATCH v5 00/13] Canaan devicetree fixes

[Geert Uytterhoeven]

Hi Conor,

On Tue, Jul 5, 2022 at 11:52 PM Conor Dooley <mail@conchuod.ie> wrote:
> This series should rid us of dtbs_check errors for the RISC-V Canaan k210
> based boards. To make keeping it that way a little easier, I changed the
> Canaan devicetree Makefile so that it would build all of the devicetrees
> in the directory if SOC_CANAAN.
>
> I *DO NOT* have any Canaan hardware so I have not tested any of this in
> action. Since I sent v1, I tried to buy some since it's cheap - but could
> out of the limited stockists none seemed to want to deliver to Ireland :(
> I based the series on next-20220617.

Boots fine on SiPEED MAiX BiT, so
Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v5 00/13] Canaan devicetree fixes

[Palmer Dabbelt]

On Tue, 05 Jul 2022 14:52:01 PDT (-0700), mail@conchuod.ie wrote:
> From: Conor Dooley <conor.dooley@microchip.com>
>
> Hey all,
> This series should rid us of dtbs_check errors for the RISC-V Canaan k210
> based boards. To make keeping it that way a little easier, I changed the
> Canaan devicetree Makefile so that it would build all of the devicetrees
> in the directory if SOC_CANAAN.
>
> I *DO NOT* have any Canaan hardware so I have not tested any of this in
> action. Since I sent v1, I tried to buy some since it's cheap - but could
> out of the limited stockists none seemed to want to deliver to Ireland :(
> I based the series on next-20220617.
>
> Thanks,
> Conor.
>
> Changes since v4:
> - add Rob's tags from v3
> - sram: rephrase the binding description
> - ASoC: dropped the applied binding
>
> Changes since v3:
> - dts: drop the bogus "regs" property pointed out by Niklas
> - dma/timer: add Serge's reviews (and expand on the dma interrupt
>   description)
> - dts: add Niklas' T-b where I felt it was suitable. lmk if you think it
>   applies more broadly
> - spi: drop the applied spi dt-binding change. Thanks Mark.
>
> Changes since v2:
> - i2s: added clocks maxItems
> - dma: unconditionally extended the interrupts & dropped canaan
>   compatible
> - timer: as per Sergey, split the timer dts nodes in 2 & drop the
>   binding patch
> - ili9341: add a canaan specific compatible to the binding and dts
>
> Changes since v1:
> - I added a new dt node & compatible for the SRAM memory controller due
>   Damien's wish to preserve the inter-op with U-Boot.
> - The dw-apb-ssi binding now uses the default rx/tx widths
> - A new patch fixes bus {ranges,reg} warnings
> - Rearranged the patches in a slightly more logical order
>
> Conor Dooley (13):
>   dt-bindings: display: convert ilitek,ili9341.txt to dt-schema
>   dt-bindings: display: ili9341: document canaan kd233's lcd
>   dt-bindings: dma: dw-axi-dmac: extend the number of interrupts
>   dt-bindings: memory-controllers: add canaan k210 sram controller
>   riscv: dts: canaan: fix the k210's memory node
>   riscv: dts: canaan: fix the k210's timer nodes
>   riscv: dts: canaan: fix mmc node names
>   riscv: dts: canaan: fix kd233 display spi frequency
>   riscv: dts: canaan: use custom compatible for k210 i2s
>   riscv: dts: canaan: remove spi-max-frequency from controllers
>   riscv: dts: canaan: fix bus {ranges,reg} warnings
>   riscv: dts: canaan: add specific compatible for kd233's LCD
>   riscv: dts: canaan: build all devicetress if SOC_CANAAN
>
>  .../bindings/display/ilitek,ili9341.txt       | 27 -------
>  .../display/panel/ilitek,ili9341.yaml         | 49 +++++++++----
>  .../bindings/dma/snps,dw-axi-dmac.yaml        |  7 +-
>  .../memory-controllers/canaan,k210-sram.yaml  | 52 +++++++++++++
>  arch/riscv/boot/dts/canaan/Makefile           | 10 ++-
>  arch/riscv/boot/dts/canaan/canaan_kd233.dts   |  6 +-
>  arch/riscv/boot/dts/canaan/k210.dtsi          | 73 +++++++++++++------
>  .../riscv/boot/dts/canaan/sipeed_maix_bit.dts |  2 +-
>  .../boot/dts/canaan/sipeed_maix_dock.dts      |  2 +-
>  arch/riscv/boot/dts/canaan/sipeed_maix_go.dts |  2 +-
>  .../boot/dts/canaan/sipeed_maixduino.dts      |  2 +-
>  11 files changed, 159 insertions(+), 73 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/display/ilitek,ili9341.txt
>  create mode 100644 Documentation/devicetree/bindings/memory-controllers/canaan,k210-sram.yaml

I'm trying to sort out how to merge this one.  I'm not opposed to taking 
it through the RISC-V tree as Rob's reviewed/acked the bindings, but 
just figured I'd say something before putting anything on for-next to 
try and minimize confusion.

Unless I'm missing something it's just patch 3 that's been taken so far, 
via Vinod's tree.  I've dropped that one and put the rest on 
palmer/riscv-canaan_dt_schema, if that looks good then I'll take it into 
riscv/for-next when this loops back to the top of my queue.

Thanks!

Re: [PATCH v5 00/13] Canaan devicetree fixes

[Conor.Dooley]

On 14/07/2022 23:04, Palmer Dabbelt wrote:
> On Tue, 05 Jul 2022 14:52:01 PDT (-0700), mail@conchuod.ie wrote:
>> From: Conor Dooley <conor.dooley@microchip.com>
>>
>> Hey all,
>> This series should rid us of dtbs_check errors for the RISC-V Canaan k210
>> based boards. To make keeping it that way a little easier, I changed the
>> Canaan devicetree Makefile so that it would build all of the devicetrees
>> in the directory if SOC_CANAAN.
>>
>> I *DO NOT* have any Canaan hardware so I have not tested any of this in
>> action. Since I sent v1, I tried to buy some since it's cheap - but could
>> out of the limited stockists none seemed to want to deliver to Ireland :(
>> I based the series on next-20220617.
>>
>> Thanks,
>> Conor.
>>
>> Changes since v4:
>> - add Rob's tags from v3
>> - sram: rephrase the binding description
>> - ASoC: dropped the applied binding
>>
>> Changes since v3:
>> - dts: drop the bogus "regs" property pointed out by Niklas
>> - dma/timer: add Serge's reviews (and expand on the dma interrupt
>>   description)
>> - dts: add Niklas' T-b where I felt it was suitable. lmk if you think it
>>   applies more broadly
>> - spi: drop the applied spi dt-binding change. Thanks Mark.
>>
>> Changes since v2:
>> - i2s: added clocks maxItems
>> - dma: unconditionally extended the interrupts & dropped canaan
>>   compatible
>> - timer: as per Sergey, split the timer dts nodes in 2 & drop the
>>   binding patch
>> - ili9341: add a canaan specific compatible to the binding and dts
>>
>> Changes since v1:
>> - I added a new dt node & compatible for the SRAM memory controller due
>>   Damien's wish to preserve the inter-op with U-Boot.
>> - The dw-apb-ssi binding now uses the default rx/tx widths
>> - A new patch fixes bus {ranges,reg} warnings
>> - Rearranged the patches in a slightly more logical order
>>
>> Conor Dooley (13):
>>   dt-bindings: display: convert ilitek,ili9341.txt to dt-schema
>>   dt-bindings: display: ili9341: document canaan kd233's lcd
>>   dt-bindings: dma: dw-axi-dmac: extend the number of interrupts
>>   dt-bindings: memory-controllers: add canaan k210 sram controller
>>   riscv: dts: canaan: fix the k210's memory node
>>   riscv: dts: canaan: fix the k210's timer nodes
>>   riscv: dts: canaan: fix mmc node names
>>   riscv: dts: canaan: fix kd233 display spi frequency
>>   riscv: dts: canaan: use custom compatible for k210 i2s
>>   riscv: dts: canaan: remove spi-max-frequency from controllers
>>   riscv: dts: canaan: fix bus {ranges,reg} warnings
>>   riscv: dts: canaan: add specific compatible for kd233's LCD
>>   riscv: dts: canaan: build all devicetress if SOC_CANAAN
>>
>>  .../bindings/display/ilitek,ili9341.txt       | 27 -------
>>  .../display/panel/ilitek,ili9341.yaml         | 49 +++++++++----
>>  .../bindings/dma/snps,dw-axi-dmac.yaml        |  7 +-
>>  .../memory-controllers/canaan,k210-sram.yaml  | 52 +++++++++++++
>>  arch/riscv/boot/dts/canaan/Makefile           | 10 ++-
>>  arch/riscv/boot/dts/canaan/canaan_kd233.dts   |  6 +-
>>  arch/riscv/boot/dts/canaan/k210.dtsi          | 73 +++++++++++++------
>>  .../riscv/boot/dts/canaan/sipeed_maix_bit.dts |  2 +-
>>  .../boot/dts/canaan/sipeed_maix_dock.dts      |  2 +-
>>  arch/riscv/boot/dts/canaan/sipeed_maix_go.dts |  2 +-
>>  .../boot/dts/canaan/sipeed_maixduino.dts      |  2 +-
>>  11 files changed, 159 insertions(+), 73 deletions(-)
>>  delete mode 100644 Documentation/devicetree/bindings/display/ilitek,ili9341.txt
>>  create mode 100644 Documentation/devicetree/bindings/memory-controllers/canaan,k210-sram.yaml
> 
> I'm trying to sort out how to merge this one.  I'm not opposed to taking it through the RISC-V tree as Rob's reviewed/acked the bindings, but just figured I'd say something before putting anything on for-next to try and minimize confusion.
> 
> Unless I'm missing something it's just patch 3 that's been taken so far, via Vinod's tree.  I've dropped that one and put the rest on palmer/riscv-canaan_dt_schema, if that looks good then I'll take it into riscv/for-next when this loops back to the top of my queue.
> 
> Thanks!

Patches 1 & 2 never got review from the DRM side and patch 12
depends on those. If it comes to it, you could drop those three
(and patch 3 that Vinod took). The only other one is patch 4,
which has Krzysztof's ack as memory-controller maintainer, so
that one should be okay.
Thanks,
Conor.

Re: [PATCH v5 00/13] Canaan devicetree fixes

[Conor.Dooley]

On 14/07/2022 23:11, Conor Dooley - M52691 wrote:
> On 14/07/2022 23:04, Palmer Dabbelt wrote:
>> I'm trying to sort out how to merge this one.  I'm not opposed to taking it through the RISC-V tree as Rob's reviewed/acked the bindings, but just figured I'd say something before putting anything on for-next to try and minimize confusion.
>>
>> Unless I'm missing something it's just patch 3 that's been taken so far, via Vinod's tree.  I've dropped that one and put the rest on palmer/riscv-canaan_dt_schema, if that looks good then I'll take it into riscv/for-next when this loops back to the top of my queue.
>>
>> Thanks!
> 
> Patches 1 & 2 never got review from the DRM side and patch 12
> depends on those. If it comes to it, you could drop those three
> (and patch 3 that Vinod took). The only other one is patch 4,
> which has Krzysztof's ack as memory-controller maintainer, so
> that one should be okay.

Hey Palmer,
These fixes have been sitting on palmer/riscv-canaan_dt_schema for
a few weeks now, without an autobuilder complaint etc. Could you
move it onto for-next?
Would be nice to clear these up for 6.0 :)
Thanks,
Conor.

Re: [PATCH v5 00/13] Canaan devicetree fixes

[Palmer Dabbelt]

On Fri, 05 Aug 2022 10:51:00 PDT (-0700), Conor.Dooley@microchip.com wrote:
> On 14/07/2022 23:11, Conor Dooley - M52691 wrote:
>> On 14/07/2022 23:04, Palmer Dabbelt wrote:
>>> I'm trying to sort out how to merge this one.  I'm not opposed to taking it through the RISC-V tree as Rob's reviewed/acked the bindings, but just figured I'd say something before putting anything on for-next to try and minimize confusion.
>>>
>>> Unless I'm missing something it's just patch 3 that's been taken so far, via Vinod's tree.  I've dropped that one and put the rest on palmer/riscv-canaan_dt_schema, if that looks good then I'll take it into riscv/for-next when this loops back to the top of my queue.
>>>
>>> Thanks!
>> 
>> Patches 1 & 2 never got review from the DRM side and patch 12
>> depends on those. If it comes to it, you could drop those three
>> (and patch 3 that Vinod took). The only other one is patch 4,
>> which has Krzysztof's ack as memory-controller maintainer, so
>> that one should be okay.
> 
> Hey Palmer,
> These fixes have been sitting on palmer/riscv-canaan_dt_schema for
> a few weeks now, without an autobuilder complaint etc. Could you
> move it onto for-next?

These are on for-next.

Re: [PATCH v5 00/13] Canaan devicetree fixes

[Conor.Dooley]

On 10/08/2022 23:01, Palmer Dabbelt wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On Fri, 05 Aug 2022 10:51:00 PDT (-0700), Conor.Dooley@microchip.com wrote:
>> On 14/07/2022 23:11, Conor Dooley - M52691 wrote:
>>> On 14/07/2022 23:04, Palmer Dabbelt wrote:
>>>> I'm trying to sort out how to merge this one.  I'm not opposed to taking it through the RISC-V tree as Rob's reviewed/acked the bindings, but just figured I'd say something before putting anything on for-next to try and minimize confusion.
>>>>
>>>> Unless I'm missing something it's just patch 3 that's been taken so far, via Vinod's tree.  I've dropped that one and put the rest on palmer/riscv-canaan_dt_schema, if that looks good then I'll take it into riscv/for-next when this loops back to the top of my queue.
>>>>
>>>> Thanks!
>>>
>>> Patches 1 & 2 never got review from the DRM side and patch 12
>>> depends on those. If it comes to it, you could drop those three
>>> (and patch 3 that Vinod took). The only other one is patch 4,
>>> which has Krzysztof's ack as memory-controller maintainer, so
>>> that one should be okay.
>>
>> Hey Palmer,
>> These fixes have been sitting on palmer/riscv-canaan_dt_schema for
>> a few weeks now, without an autobuilder complaint etc. Could you
>> move it onto for-next?
> 
> These are on for-next.

Sweet, nearly clear of dtbs_check problems now :)
Thanks!