All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v14 00/16] RISC-V Kendryte K210 support improvements
@ 2021-02-02 10:36 Damien Le Moal
  2021-02-02 10:36   ` Damien Le Moal
                   ` (15 more replies)
  0 siblings, 16 replies; 81+ messages in thread
From: Damien Le Moal @ 2021-02-02 10:36 UTC (permalink / raw)
  To: Palmer Dabbelt, linux-riscv; +Cc: Atish Patra, Anup Patel, Sean Anderson

Resending this series as a ping. No changes, except for the FPIOA
driver patch that is removed as it is already in riscv/for-next.
I would really would like to get all this in 5.12.  Please review !


This series of patches improves support for boards based on the Canaan
Kendryte K210 RISC-V dual core SoC. Minimal support for this SoC is
already included in the kernel. These patches complete it, enabling
support for most peripherals present on the SoC as well as introducing
device trees for the various K210 boards available on the market today
from SiPeed and Kendryte.

The patches here are the remaining patches not yet applied.

Patch 1 adds the SoC clock driver.

Patches 2 to 8 add and update device tree bindings documentation to
document the K210 device tree files. In particular, patch 2 and 3
define compatible strings used for the SoC CPU and for the K210 based
boards supported.

Patches 9 to 14 update the existing K210 base device tree and add new
device tree files for several K210 based boards: MAIX Bit, MAIXDUINO,
MAIX Dock and MAIX Go boards from SiPeed and the KD233 development
board from Canaan.

Finally the last two patches updates the k210 nommu defconfig to include
the newly implemented drivers and provide a new default configuration
file enabling SD card support.

A lot of the work on the device tree and on the K210 drivers come from
the work by Sean Anderson for the U-Boot project support of the K210
SoC. Sean also helped with debugging many aspects of the K210 support.

A tree with all patches applied is available here:
https://github.com/damien-lemoal/linux, k210-sysctl-v27 branch.
A demonstration of this series used on a SiPeed MAIX Dock
board together with an I2C servo controller can be seen here:
https://damien-lemoal.github.io/linux-robot-arm/#example

This tree was used to build userspace busybox environment image that is
then copied onto an SD card formatted with ext2:
https://github.com/damien-lemoal/buildroot
Of note is that running this userspace environment requires a revert of
commit 2217b982624680d19a80ebb4600d05c8586c4f96 introduced during the
5.9 development cycle. Without this revert, execution of the init
process fails. A problem with the riscv port of elf2flt is suspected but
not confirmed. I am now starting to investigate this problem.

Reviews and comments are as always much welcome.

Changes from v13:
* Rebased on rc6
* Removed FPIOA driver patch as it is already queued.

Changes from v12:
* Addressed Rab's comments: keep SoC specific compatible string for DT
  nodes reusing existing IP blocks (e.g. PLIC and CLINT).
* Addressed dt-bindings schema file check warnings.

Changes from v11:
* Addressed Stephen's comment on the clock driver
* Fixed and added device tree bindings yaml files and fixed the device
  tree files to fix all warnings generated by make dtbs_check
* Rebased on riscv tree fixes + latest riscv for-next branches.

Changes from v10:
* Rebased on riscv tree fixes+for-next branches. Patches already applied
  to these branches were removed from this series.
* Fixed the clock driver and pinctrl driver patch titles to indicate the
  correct target sub-components.
* Applied reviewed-by tags from Anup.

Changes from v9:
* Added patch 6 to avoid DTS compilation errors after patch 9 is
  applied and until patch 16 is applied.

Changes from v8:
* Addressed Rob's comments on the sysctl driver bindings documentation
* Fixed a typo in the fpios driver bindings documentation

Changes from v7:
* Removed the __init annotation for the drivers reset, pinctrl and
  sysctl drivers probe functions as suggested by Geert. Also removed
  the __refdata annotation for the struct platform_driver variables of
  these drivers.

Changes from v6:
* Annotate struct platform_driver variables with __refdata to avoid
  section mismatch compilation errors
* Add empty sentinel entry to of_device_id tables of the sysctl, reset
  and pinctrl drivers.

Changes from v5:
* Addressed Philipp's comment on the reset controller driver
* Added patch 6 to reduce the size of the clock driver patch
  (now patch 12).

Changes from v4:
* Simplified reset controller driver using of_xlate callback as
  suggested by Philipp
* Fixed compilation error when using other configs than one of the
  nommu_k210 defconfigs.
* Addressed most clock driver comments from Stephen.
* Removed CONFIG_GPIO_SYSFS from defconfigs
* Rebased on 5.10-rc7

Changes from V3:
* Add one entry per driver in MAINTAINERS file

Changes from V2:
* Add MAINTAINERS file entry for the SoC support, listing myself as
  maintainer.
* Removed use of postcore_initcall() for declaring the drivers, using
  the regular builtin_platform_driver() instead.
* Fixed fpio pinctrl driver bindings documentation as commented by
  Geert: removed input-schmitt and added input-schmitt-disable, fixed
  typo and added input-disable and output-disable.
* Fixed device tree to have cs-gpios active low, as per the default, as
  active high necessity was an artifact of the gpio level double
  inversion bug fixed recently.
* Removed CONFIG_VT from defconfigs to reduce the kernel image size as
  suggested by Geert.

Changes from v1:
* Improved DT bindings documentation
* SPI and GPIO patches removed from this series (and being processed
  directly through the relevant subsystems directly)
* Improved device trees
* Various cleanup and improvments of the drivers

Damien Le Moal (16):
  clk: Add RISC-V Canaan Kendryte K210 clock driver
  dt-bindings: add Canaan boards compatible strings
  dt-bindings: update risc-v cpu properties
  dt-bindings: update sifive plic compatible string
  dt-bindings: update sifive clint compatible string
  dt-bindings: update sifive uart compatible string
  dt-bindings: fix sifive gpio properties
  dt-bindings: add resets property to dw-apb-timer
  riscv: Update Canaan Kendryte K210 device tree
  riscv: Add SiPeed MAIX BiT board device tree
  riscv: Add SiPeed MAIX DOCK board device tree
  riscv: Add SiPeed MAIX GO board device tree
  riscv: Add SiPeed MAIXDUINO board device tree
  riscv: Add Kendryte KD233 board device tree
  riscv: Update Canaan Kendryte K210 defconfig
  riscv: Add Canaan Kendryte K210 SD card defconfig

 .../devicetree/bindings/gpio/sifive,gpio.yaml |   21 +-
 .../sifive,plic-1.0.0.yaml                    |   20 +-
 .../devicetree/bindings/riscv/canaan.yaml     |   47 +
 .../devicetree/bindings/riscv/cpus.yaml       |    2 +
 .../bindings/serial/sifive-serial.yaml        |    1 +
 .../bindings/timer/sifive,clint.yaml          |   19 +-
 .../bindings/timer/snps,dw-apb-timer.yaml     |    3 +
 MAINTAINERS                                   |    1 +
 arch/riscv/Kconfig.socs                       |    2 +-
 arch/riscv/boot/dts/canaan/canaan_kd233.dts   |  177 +++
 arch/riscv/boot/dts/canaan/k210.dts           |   23 -
 arch/riscv/boot/dts/canaan/k210.dtsi          |  535 ++++++++-
 arch/riscv/boot/dts/canaan/k210_generic.dts   |   46 +
 .../riscv/boot/dts/canaan/sipeed_maix_bit.dts |  234 ++++
 .../boot/dts/canaan/sipeed_maix_dock.dts      |  236 ++++
 arch/riscv/boot/dts/canaan/sipeed_maix_go.dts |  244 ++++
 .../boot/dts/canaan/sipeed_maixduino.dts      |  209 ++++
 arch/riscv/configs/nommu_k210_defconfig       |   44 +-
 .../riscv/configs/nommu_k210_sdcard_defconfig |   92 ++
 drivers/clk/Kconfig                           |    8 +
 drivers/clk/Makefile                          |    1 +
 drivers/clk/clk-k210.c                        | 1012 +++++++++++++++++
 drivers/soc/canaan/Kconfig                    |   18 +-
 drivers/soc/canaan/Makefile                   |    2 +-
 drivers/soc/canaan/k210-sysctl.c              |  205 +---
 include/dt-bindings/clock/k210-clk.h          |    1 -
 include/soc/canaan/k210-sysctl.h              |    2 +
 27 files changed, 2950 insertions(+), 255 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/riscv/canaan.yaml
 create mode 100644 arch/riscv/boot/dts/canaan/canaan_kd233.dts
 delete mode 100644 arch/riscv/boot/dts/canaan/k210.dts
 create mode 100644 arch/riscv/boot/dts/canaan/k210_generic.dts
 create mode 100644 arch/riscv/boot/dts/canaan/sipeed_maix_bit.dts
 create mode 100644 arch/riscv/boot/dts/canaan/sipeed_maix_dock.dts
 create mode 100644 arch/riscv/boot/dts/canaan/sipeed_maix_go.dts
 create mode 100644 arch/riscv/boot/dts/canaan/sipeed_maixduino.dts
 create mode 100644 arch/riscv/configs/nommu_k210_sdcard_defconfig
 create mode 100644 drivers/clk/clk-k210.c

-- 
2.29.2


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 81+ messages in thread

* [PATCH v14 01/16] clk: Add RISC-V Canaan Kendryte K210 clock driver
  2021-02-02 10:36 [PATCH v14 00/16] RISC-V Kendryte K210 support improvements Damien Le Moal
@ 2021-02-02 10:36   ` Damien Le Moal
  2021-02-02 10:36   ` Damien Le Moal
                     ` (14 subsequent siblings)
  15 siblings, 0 replies; 81+ messages in thread
From: Damien Le Moal @ 2021-02-02 10:36 UTC (permalink / raw)
  To: Palmer Dabbelt, linux-riscv
  Cc: Atish Patra, Anup Patel, Sean Anderson, Stephen Boyd,
	Michael Turquette, linux-clk

Add a clock provider driver for the Canaan Kendryte K210 RISC-V SoC.
This new driver with the compatible string "canaan,k210-clk" implements
support for the full clock structure of the K210 SoC. Since it is
required for the correct operation of the SoC, this driver is
selected by default for compilation when the SOC_CANAAN option is
selected.

With this change, the k210-sysctl driver is turned into a simple
platform driver which enables its power bus clock and triggers
populating its child nodes. The sysctl driver retains the SOC early
initialization code, but the implementation now relies on the new
function k210_clk_early_init() provided by the new clk-k210 driver.

The clock structure implemented and many of the coding ideas for the
driver come from the work by Sean Anderson on the K210 support for the
U-Boot project.

Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: linux-clk@vger.kernel.org
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
---
 MAINTAINERS                      |    1 +
 drivers/clk/Kconfig              |    8 +
 drivers/clk/Makefile             |    1 +
 drivers/clk/clk-k210.c           | 1012 ++++++++++++++++++++++++++++++
 drivers/soc/canaan/Kconfig       |   18 +-
 drivers/soc/canaan/Makefile      |    2 +-
 drivers/soc/canaan/k210-sysctl.c |  205 ++----
 include/soc/canaan/k210-sysctl.h |    2 +
 8 files changed, 1071 insertions(+), 178 deletions(-)
 create mode 100644 drivers/clk/clk-k210.c

diff --git a/MAINTAINERS b/MAINTAINERS
index dfb95dbe2abe..0f9c2300779b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3878,6 +3878,7 @@ CANAAN/KENDRYTE K210 SOC SYSTEM CONTROLLER DRIVER
 M:	Damien Le Moal <damien.lemoal@wdc.com>
 L:	linux-riscv@lists.infradead.org
 S:	Maintained
+F:	Documentation/devicetree/bindings/mfd/canaan,k210-sysctl.yaml
 F:	drivers/soc/canaan/
 F:	include/soc/canaan/
 
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 85856cff506c..cb971f6632e2 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -368,6 +368,14 @@ config COMMON_CLK_FIXED_MMIO
 	help
 	  Support for Memory Mapped IO Fixed clocks
 
+config COMMON_CLK_K210
+	bool "Clock driver for the Canaan Kendryte K210 SoC"
+	depends on COMMON_CLK && OF
+	depends on RISCV && SOC_CANAAN
+	default SOC_CANAAN
+	help
+	  Support for the Canaan Kendryte K210 RISC-V SoC clocks.
+
 source "drivers/clk/actions/Kconfig"
 source "drivers/clk/analogbits/Kconfig"
 source "drivers/clk/baikal-t1/Kconfig"
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index dbdc590e7de3..5f8f9f135df5 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_COMMON_CLK_ASPEED)		+= clk-aspeed.o
 obj-$(CONFIG_MACH_ASPEED_G6)		+= clk-ast2600.o
 obj-$(CONFIG_ARCH_HIGHBANK)		+= clk-highbank.o
 obj-$(CONFIG_CLK_HSDK)			+= clk-hsdk-pll.o
+obj-$(CONFIG_COMMON_CLK_K210)		+= clk-k210.o
 obj-$(CONFIG_COMMON_CLK_LOCHNAGAR)	+= clk-lochnagar.o
 obj-$(CONFIG_COMMON_CLK_MAX77686)	+= clk-max77686.o
 obj-$(CONFIG_COMMON_CLK_MAX9485)	+= clk-max9485.o
diff --git a/drivers/clk/clk-k210.c b/drivers/clk/clk-k210.c
new file mode 100644
index 000000000000..429db4904ad6
--- /dev/null
+++ b/drivers/clk/clk-k210.c
@@ -0,0 +1,1012 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2019-20 Sean Anderson <seanga2@gmail.com>
+ * Copyright (c) 2019 Western Digital Corporation or its affiliates.
+ */
+#define pr_fmt(fmt)     "k210-clk: " fmt
+
+#include <linux/io.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+#include <linux/platform_device.h>
+#include <linux/of.h>
+#include <linux/of_clk.h>
+#include <linux/of_platform.h>
+#include <linux/of_address.h>
+#include <linux/clk-provider.h>
+#include <linux/bitfield.h>
+#include <linux/delay.h>
+#include <asm/soc.h>
+#include <soc/canaan/k210-sysctl.h>
+
+#include <dt-bindings/clock/k210-clk.h>
+
+/*
+ * Clocks parameters.
+ */
+struct k210_sysclk;
+
+struct k210_clk {
+	int id;
+	struct k210_sysclk *ksc;
+	struct clk_hw hw;
+};
+
+struct k210_clk_cfg {
+	const char *name;
+	u8 gate_reg;
+	u8 gate_bit;
+	u8 div_reg;
+	u8 div_shift;
+	u8 div_width;
+	u8 div_type;
+	u8 mux_reg;
+	u8 mux_bit;
+};
+
+enum k210_clk_div_type {
+	K210_DIV_NONE,
+	K210_DIV_ONE_BASED,
+	K210_DIV_DOUBLE_ONE_BASED,
+	K210_DIV_POWER_OF_TWO,
+};
+
+#define K210_GATE(_reg, _bit)	\
+	.gate_reg = (_reg),	\
+	.gate_bit = (_bit)
+#define K210_DIV(_reg, _shift, _width, _type)	\
+	.div_reg = (_reg),			\
+	.div_shift = (_shift),			\
+	.div_width = (_width),			\
+	.div_type = (_type)
+#define K210_MUX(_reg, _bit)	\
+	.mux_reg = (_reg),	\
+	.mux_bit = (_bit)
+
+static struct k210_clk_cfg k210_clk_cfgs[K210_NUM_CLKS] = {
+
+	/* Gated clocks, no mux, no divider */
+	[K210_CLK_CPU] = {
+		.name = "cpu",
+		K210_GATE(K210_SYSCTL_EN_CENT, 0)
+	},
+	[K210_CLK_DMA] = {
+		.name = "dma",
+		K210_GATE(K210_SYSCTL_EN_PERI, 1)
+	},
+	[K210_CLK_FFT] = {
+		.name = "fft",
+		K210_GATE(K210_SYSCTL_EN_PERI, 4)
+	},
+	[K210_CLK_GPIO] = {
+		.name = "gpio",
+		K210_GATE(K210_SYSCTL_EN_PERI, 5)
+	},
+	[K210_CLK_UART1] = {
+		.name = "uart1",
+		K210_GATE(K210_SYSCTL_EN_PERI, 16)
+	},
+	[K210_CLK_UART2] = {
+		.name = "uart2",
+		K210_GATE(K210_SYSCTL_EN_PERI, 17)
+	},
+	[K210_CLK_UART3] = {
+		.name = "uart3",
+		K210_GATE(K210_SYSCTL_EN_PERI, 18)
+	},
+	[K210_CLK_FPIOA] = {
+		.name = "fpioa",
+		K210_GATE(K210_SYSCTL_EN_PERI, 20)
+	},
+	[K210_CLK_SHA] = {
+		.name = "sha",
+		K210_GATE(K210_SYSCTL_EN_PERI, 26)
+	},
+	[K210_CLK_AES] = {
+		.name = "aes",
+		K210_GATE(K210_SYSCTL_EN_PERI, 19)
+	},
+	[K210_CLK_OTP] = {
+		.name = "otp",
+		K210_GATE(K210_SYSCTL_EN_PERI, 27)
+	},
+	[K210_CLK_RTC] = {
+		.name = "rtc",
+		K210_GATE(K210_SYSCTL_EN_PERI, 29)
+	},
+
+	/* Gated divider clocks */
+	[K210_CLK_SRAM0] = {
+		.name = "sram0",
+		K210_GATE(K210_SYSCTL_EN_CENT, 1),
+		K210_DIV(K210_SYSCTL_THR0, 0, 4, K210_DIV_ONE_BASED)
+	},
+	[K210_CLK_SRAM1] = {
+		.name = "sram1",
+		K210_GATE(K210_SYSCTL_EN_CENT, 2),
+		K210_DIV(K210_SYSCTL_THR0, 4, 4, K210_DIV_ONE_BASED)
+	},
+	[K210_CLK_ROM] = {
+		.name = "rom",
+		K210_GATE(K210_SYSCTL_EN_PERI, 0),
+		K210_DIV(K210_SYSCTL_THR0, 16, 4, K210_DIV_ONE_BASED)
+	},
+	[K210_CLK_DVP] = {
+		.name = "dvp",
+		K210_GATE(K210_SYSCTL_EN_PERI, 3),
+		K210_DIV(K210_SYSCTL_THR0, 12, 4, K210_DIV_ONE_BASED)
+	},
+	[K210_CLK_APB0] = {
+		.name = "apb0",
+		K210_GATE(K210_SYSCTL_EN_CENT, 3),
+		K210_DIV(K210_SYSCTL_SEL0, 3, 3, K210_DIV_ONE_BASED)
+	},
+	[K210_CLK_APB1] = {
+		.name = "apb1",
+		K210_GATE(K210_SYSCTL_EN_CENT, 4),
+		K210_DIV(K210_SYSCTL_SEL0, 6, 3, K210_DIV_ONE_BASED)
+	},
+	[K210_CLK_APB2] = {
+		.name = "apb2",
+		K210_GATE(K210_SYSCTL_EN_CENT, 5),
+		K210_DIV(K210_SYSCTL_SEL0, 9, 3, K210_DIV_ONE_BASED)
+	},
+	[K210_CLK_AI] = {
+		.name = "ai",
+		K210_GATE(K210_SYSCTL_EN_PERI, 2),
+		K210_DIV(K210_SYSCTL_THR0, 8, 4, K210_DIV_ONE_BASED)
+	},
+	[K210_CLK_SPI0] = {
+		.name = "spi0",
+		K210_GATE(K210_SYSCTL_EN_PERI, 6),
+		K210_DIV(K210_SYSCTL_THR1, 0, 8, K210_DIV_DOUBLE_ONE_BASED)
+	},
+	[K210_CLK_SPI1] = {
+		.name = "spi1",
+		K210_GATE(K210_SYSCTL_EN_PERI, 7),
+		K210_DIV(K210_SYSCTL_THR1, 8, 8, K210_DIV_DOUBLE_ONE_BASED)
+	},
+	[K210_CLK_SPI2] = {
+		.name = "spi2",
+		K210_GATE(K210_SYSCTL_EN_PERI, 8),
+		K210_DIV(K210_SYSCTL_THR1, 16, 8, K210_DIV_DOUBLE_ONE_BASED)
+	},
+	[K210_CLK_I2C0] = {
+		.name = "i2c0",
+		K210_GATE(K210_SYSCTL_EN_PERI, 13),
+		K210_DIV(K210_SYSCTL_THR5, 8, 8, K210_DIV_DOUBLE_ONE_BASED)
+	},
+	[K210_CLK_I2C1] = {
+		.name = "i2c1",
+		K210_GATE(K210_SYSCTL_EN_PERI, 14),
+		K210_DIV(K210_SYSCTL_THR5, 16, 8, K210_DIV_DOUBLE_ONE_BASED)
+	},
+	[K210_CLK_I2C2] = {
+		.name = "i2c2",
+		K210_GATE(K210_SYSCTL_EN_PERI, 15),
+		K210_DIV(K210_SYSCTL_THR5, 24, 8, K210_DIV_DOUBLE_ONE_BASED)
+	},
+	[K210_CLK_WDT0] = {
+		.name = "wdt0",
+		K210_GATE(K210_SYSCTL_EN_PERI, 24),
+		K210_DIV(K210_SYSCTL_THR6, 0, 8, K210_DIV_DOUBLE_ONE_BASED)
+	},
+	[K210_CLK_WDT1] = {
+		.name = "wdt1",
+		K210_GATE(K210_SYSCTL_EN_PERI, 25),
+		K210_DIV(K210_SYSCTL_THR6, 8, 8, K210_DIV_DOUBLE_ONE_BASED)
+	},
+	[K210_CLK_I2S0] = {
+		.name = "i2s0",
+		K210_GATE(K210_SYSCTL_EN_PERI, 10),
+		K210_DIV(K210_SYSCTL_THR3, 0, 16, K210_DIV_DOUBLE_ONE_BASED)
+	},
+	[K210_CLK_I2S1] = {
+		.name = "i2s1",
+		K210_GATE(K210_SYSCTL_EN_PERI, 11),
+		K210_DIV(K210_SYSCTL_THR3, 16, 16, K210_DIV_DOUBLE_ONE_BASED)
+	},
+	[K210_CLK_I2S2] = {
+		.name = "i2s2",
+		K210_GATE(K210_SYSCTL_EN_PERI, 12),
+		K210_DIV(K210_SYSCTL_THR4, 0, 16, K210_DIV_DOUBLE_ONE_BASED)
+	},
+
+	/* Divider clocks, no gate, no mux */
+	[K210_CLK_I2S0_M] = {
+		.name = "i2s0_m",
+		K210_DIV(K210_SYSCTL_THR4, 16, 8, K210_DIV_DOUBLE_ONE_BASED)
+	},
+	[K210_CLK_I2S1_M] = {
+		.name = "i2s1_m",
+		K210_DIV(K210_SYSCTL_THR4, 24, 8, K210_DIV_DOUBLE_ONE_BASED)
+	},
+	[K210_CLK_I2S2_M] = {
+		.name = "i2s2_m",
+		K210_DIV(K210_SYSCTL_THR4, 0, 8, K210_DIV_DOUBLE_ONE_BASED)
+	},
+
+	/* Muxed gated divider clocks */
+	[K210_CLK_SPI3] = {
+		.name = "spi3",
+		K210_GATE(K210_SYSCTL_EN_PERI, 9),
+		K210_DIV(K210_SYSCTL_THR1, 24, 8, K210_DIV_DOUBLE_ONE_BASED),
+		K210_MUX(K210_SYSCTL_SEL0, 12)
+	},
+	[K210_CLK_TIMER0] = {
+		.name = "timer0",
+		K210_GATE(K210_SYSCTL_EN_PERI, 21),
+		K210_DIV(K210_SYSCTL_THR2,  0, 8, K210_DIV_DOUBLE_ONE_BASED),
+		K210_MUX(K210_SYSCTL_SEL0, 13)
+	},
+	[K210_CLK_TIMER1] = {
+		.name = "timer1",
+		K210_GATE(K210_SYSCTL_EN_PERI, 22),
+		K210_DIV(K210_SYSCTL_THR2, 8, 8, K210_DIV_DOUBLE_ONE_BASED),
+		K210_MUX(K210_SYSCTL_SEL0, 14)
+	},
+	[K210_CLK_TIMER2] = {
+		.name = "timer2",
+		K210_GATE(K210_SYSCTL_EN_PERI, 23),
+		K210_DIV(K210_SYSCTL_THR2, 16, 8, K210_DIV_DOUBLE_ONE_BASED),
+		K210_MUX(K210_SYSCTL_SEL0, 15)
+	},
+};
+
+/*
+ * PLL control register bits.
+ */
+#define K210_PLL_CLKR		GENMASK(3, 0)
+#define K210_PLL_CLKF		GENMASK(9, 4)
+#define K210_PLL_CLKOD		GENMASK(13, 10)
+#define K210_PLL_BWADJ		GENMASK(19, 14)
+#define K210_PLL_RESET		(1 << 20)
+#define K210_PLL_PWRD		(1 << 21)
+#define K210_PLL_INTFB		(1 << 22)
+#define K210_PLL_BYPASS		(1 << 23)
+#define K210_PLL_TEST		(1 << 24)
+#define K210_PLL_EN		(1 << 25)
+#define K210_PLL_SEL		GENMASK(27, 26) /* PLL2 only */
+
+/*
+ * PLL lock register bits.
+ */
+#define K210_PLL_LOCK		0
+#define K210_PLL_CLEAR_SLIP	2
+#define K210_PLL_TEST_OUT	3
+
+/*
+ * Clock selector register bits.
+ */
+#define K210_ACLK_SEL		BIT(0)
+#define K210_ACLK_DIV		GENMASK(2, 1)
+
+/*
+ * PLLs.
+ */
+enum k210_pll_id {
+	K210_PLL0, K210_PLL1, K210_PLL2, K210_PLL_NUM
+};
+
+struct k210_pll {
+	enum k210_pll_id id;
+	struct k210_sysclk *ksc;
+	void __iomem *base;
+	void __iomem *reg;
+	void __iomem *lock;
+	u8 lock_shift;
+	u8 lock_width;
+	struct clk_hw hw;
+};
+#define to_k210_pll(_hw)	container_of(_hw, struct k210_pll, hw)
+
+/*
+ * PLLs configuration: by default PLL0 runs at 780 MHz and PLL1 at 299 MHz.
+ * The first 2 SRAM banks depend on ACLK/CPU clock which is by default PLL0
+ * rate divided by 2. Set PLL1 to 390 MHz so that the third SRAM bank has the
+ * same clock as the first 2.
+ */
+struct k210_pll_cfg {
+	u32 reg;
+	u8 lock_shift;
+	u8 lock_width;
+	u32 r;
+	u32 f;
+	u32 od;
+	u32 bwadj;
+};
+
+static struct k210_pll_cfg k210_plls_cfg[] = {
+	{ K210_SYSCTL_PLL0,  0, 2, 0, 59, 1, 59 }, /* 780 MHz */
+	{ K210_SYSCTL_PLL1,  8, 1, 0, 59, 3, 59 }, /* 390 MHz */
+	{ K210_SYSCTL_PLL2, 16, 1, 0, 22, 1, 22 }, /* 299 MHz */
+};
+
+/**
+ * struct k210_sysclk - sysclk driver data
+ * @node: device node
+ * @regs: system controller registers start address
+ * @clk_lock: clock setting spinlock
+ * @plls: SoC PLLs descriptors
+ * @aclk: ACLK clock
+ * @clks: All other clocks
+ */
+struct k210_sysclk {
+	struct device_node		*node;
+	void __iomem			*regs;
+	spinlock_t			clk_lock;
+	struct k210_pll			plls[K210_PLL_NUM];
+	struct clk_hw			aclk;
+	struct k210_clk			clks[K210_NUM_CLKS];
+};
+
+#define to_k210_sysclk(_hw)	container_of(_hw, struct k210_sysclk, aclk)
+
+/*
+ * Set ACLK parent selector: 0 for IN0, 1 for PLL0.
+ */
+static void k210_aclk_set_selector(void __iomem *regs, u8 sel)
+{
+	u32 reg = readl(regs + K210_SYSCTL_SEL0);
+
+	if (sel)
+		reg |= K210_ACLK_SEL;
+	else
+		reg &= K210_ACLK_SEL;
+	writel(reg, regs + K210_SYSCTL_SEL0);
+}
+
+static void k210_init_pll(void __iomem *regs, enum k210_pll_id pllid,
+			  struct k210_pll *pll)
+{
+	pll->id = pllid;
+	pll->reg = regs + k210_plls_cfg[pllid].reg;
+	pll->lock = regs + K210_SYSCTL_PLL_LOCK;
+	pll->lock_shift = k210_plls_cfg[pllid].lock_shift;
+	pll->lock_width = k210_plls_cfg[pllid].lock_width;
+}
+
+static void k210_pll_wait_for_lock(struct k210_pll *pll)
+{
+	u32 reg, mask = GENMASK(pll->lock_shift + pll->lock_width - 1,
+				pll->lock_shift);
+
+	while (true) {
+		reg = readl(pll->lock);
+		if ((reg & mask) == mask)
+			break;
+
+		reg |= BIT(pll->lock_shift + K210_PLL_CLEAR_SLIP);
+		writel(reg, pll->lock);
+	}
+}
+
+static bool k210_pll_hw_is_enabled(struct k210_pll *pll)
+{
+	u32 reg = readl(pll->reg);
+	u32 mask = K210_PLL_PWRD | K210_PLL_EN;
+
+	if (reg & K210_PLL_RESET)
+		return false;
+
+	return (reg & mask) == mask;
+}
+
+static void k210_pll_enable_hw(void __iomem *regs, struct k210_pll *pll)
+{
+	struct k210_pll_cfg *pll_cfg = &k210_plls_cfg[pll->id];
+	u32 reg;
+
+	if (k210_pll_hw_is_enabled(pll))
+		return;
+
+	/*
+	 * For PLL0, we need to re-parent ACLK to IN0 to keep the CPU cores and
+	 * SRAM running.
+	 */
+	if (pll->id == K210_PLL0)
+		k210_aclk_set_selector(regs, 0);
+
+	/* Set PLL factors */
+	reg = readl(pll->reg);
+	reg &= ~GENMASK(19, 0);
+	reg |= FIELD_PREP(K210_PLL_CLKR, pll_cfg->r);
+	reg |= FIELD_PREP(K210_PLL_CLKF, pll_cfg->f);
+	reg |= FIELD_PREP(K210_PLL_CLKOD, pll_cfg->od);
+	reg |= FIELD_PREP(K210_PLL_BWADJ, pll_cfg->bwadj);
+	reg |= K210_PLL_PWRD;
+	writel(reg, pll->reg);
+
+	/*
+	 * Reset the PLL: ensure reset is low before asserting it.
+	 * The magic NOPs come from the Kendryte reference SDK.
+	 */
+	reg &= ~K210_PLL_RESET;
+	writel(reg, pll->reg);
+	reg |= K210_PLL_RESET;
+	writel(reg, pll->reg);
+	nop();
+	nop();
+	reg &= ~K210_PLL_RESET;
+	writel(reg, pll->reg);
+
+	k210_pll_wait_for_lock(pll);
+
+	reg &= ~K210_PLL_BYPASS;
+	reg |= K210_PLL_EN;
+	writel(reg, pll->reg);
+
+	if (pll->id == K210_PLL0)
+		k210_aclk_set_selector(regs, 1);
+}
+
+static int k210_pll_enable(struct clk_hw *hw)
+{
+	struct k210_pll *pll = to_k210_pll(hw);
+	struct k210_sysclk *ksc = pll->ksc;
+	unsigned long flags;
+
+	spin_lock_irqsave(&ksc->clk_lock, flags);
+
+	k210_pll_enable_hw(ksc->regs, pll);
+
+	spin_unlock_irqrestore(&ksc->clk_lock, flags);
+
+	return 0;
+}
+
+static void k210_pll_disable(struct clk_hw *hw)
+{
+	struct k210_pll *pll = to_k210_pll(hw);
+	struct k210_sysclk *ksc = pll->ksc;
+	unsigned long flags;
+	u32 reg;
+
+	/*
+	 * Bypassing before powering off is important so child clocks do not
+	 * stop working. This is especially important for pll0, the indirect
+	 * parent of the cpu clock.
+	 */
+	spin_lock_irqsave(&ksc->clk_lock, flags);
+	reg = readl(pll->reg);
+	reg |= K210_PLL_BYPASS;
+	writel(reg, pll->reg);
+
+	reg &= ~K210_PLL_PWRD;
+	reg &= ~K210_PLL_EN;
+	writel(reg, pll->reg);
+	spin_unlock_irqrestore(&ksc->clk_lock, flags);
+}
+
+static int k210_pll_is_enabled(struct clk_hw *hw)
+{
+	return k210_pll_hw_is_enabled(to_k210_pll(hw));
+}
+
+static unsigned long k210_pll_get_rate(struct clk_hw *hw,
+				       unsigned long parent_rate)
+{
+	struct k210_pll *pll = to_k210_pll(hw);
+	u32 reg = readl(pll->reg);
+	u32 r, f, od;
+
+	if (reg & K210_PLL_BYPASS)
+		return parent_rate;
+
+	if (!(reg & K210_PLL_PWRD))
+		return 0;
+
+	r = FIELD_GET(K210_PLL_CLKR, reg) + 1;
+	f = FIELD_GET(K210_PLL_CLKF, reg) + 1;
+	od = FIELD_GET(K210_PLL_CLKOD, reg) + 1;
+
+	return (u64)parent_rate * f / (r * od);
+}
+
+static const struct clk_ops k210_pll_ops = {
+	.enable		= k210_pll_enable,
+	.disable	= k210_pll_disable,
+	.is_enabled	= k210_pll_is_enabled,
+	.recalc_rate	= k210_pll_get_rate,
+};
+
+static int k210_pll2_set_parent(struct clk_hw *hw, u8 index)
+{
+	struct k210_pll *pll = to_k210_pll(hw);
+	struct k210_sysclk *ksc = pll->ksc;
+	unsigned long flags;
+	u32 reg;
+
+	spin_lock_irqsave(&ksc->clk_lock, flags);
+
+	reg = readl(pll->reg);
+	reg &= ~K210_PLL_SEL;
+	reg |= FIELD_PREP(K210_PLL_SEL, index);
+	writel(reg, pll->reg);
+
+	spin_unlock_irqrestore(&ksc->clk_lock, flags);
+
+	return 0;
+}
+
+static u8 k210_pll2_get_parent(struct clk_hw *hw)
+{
+	struct k210_pll *pll = to_k210_pll(hw);
+	u32 reg = readl(pll->reg);
+
+	return FIELD_GET(K210_PLL_SEL, reg);
+}
+
+static const struct clk_ops k210_pll2_ops = {
+	.enable		= k210_pll_enable,
+	.disable	= k210_pll_disable,
+	.is_enabled	= k210_pll_is_enabled,
+	.recalc_rate	= k210_pll_get_rate,
+	.set_parent	= k210_pll2_set_parent,
+	.get_parent	= k210_pll2_get_parent,
+};
+
+static int k210_register_pll(struct k210_sysclk *ksc, const char *in0,
+			     enum k210_pll_id pllid, const char *name,
+			     int num_parents, const struct clk_ops *ops)
+{
+	struct k210_pll *pll = &ksc->plls[pllid];
+	struct clk_init_data init = {};
+	const struct clk_parent_data parent_data[] = {
+		{ .name = in0 },
+		{ .hw = &ksc->plls[K210_PLL0].hw },
+		{ .hw = &ksc->plls[K210_PLL1].hw },
+	};
+
+	init.name = name;
+	init.parent_data = parent_data;
+	init.num_parents = num_parents;
+	init.ops = ops;
+
+	pll->hw.init = &init;
+	pll->ksc = ksc;
+
+	return clk_hw_register(NULL, &pll->hw);
+}
+
+static int k210_register_plls(struct k210_sysclk *ksc, const char *in0)
+{
+	int i, ret;
+
+	for (i = 0; i < K210_PLL_NUM; i++)
+		k210_init_pll(ksc->regs, i, &ksc->plls[i]);
+
+	/* PLL0 and PLL1 only have IN0 as parent */
+	ret = k210_register_pll(ksc, in0, K210_PLL0, "pll0", 1, &k210_pll_ops);
+	if (ret) {
+		pr_err("%pOFP: register PLL0 failed\n", ksc->node);
+		return ret;
+	}
+	ret = k210_register_pll(ksc, in0, K210_PLL1, "pll1", 1, &k210_pll_ops);
+	if (ret) {
+		pr_err("%pOFP: register PLL1 failed\n", ksc->node);
+		return ret;
+	}
+
+	/* PLL2 has IN0, PLL0 and PLL1 as parents */
+	ret = k210_register_pll(ksc, in0, K210_PLL2, "pll2", 3, &k210_pll2_ops);
+	if (ret) {
+		pr_err("%pOFP: register PLL2 failed\n", ksc->node);
+		return ret;
+	}
+
+	return 0;
+}
+
+static int k210_aclk_set_parent(struct clk_hw *hw, u8 index)
+{
+	struct k210_sysclk *ksc = to_k210_sysclk(hw);
+	unsigned long flags;
+
+	spin_lock_irqsave(&ksc->clk_lock, flags);
+
+	k210_aclk_set_selector(ksc->regs, index);
+
+	spin_unlock_irqrestore(&ksc->clk_lock, flags);
+
+	return 0;
+}
+
+static u8 k210_aclk_get_parent(struct clk_hw *hw)
+{
+	struct k210_sysclk *ksc = to_k210_sysclk(hw);
+	u32 sel;
+
+	sel = readl(ksc->regs + K210_SYSCTL_SEL0) & K210_ACLK_SEL;
+
+	return sel ? 1 : 0;
+}
+
+static unsigned long k210_aclk_get_rate(struct clk_hw *hw,
+					unsigned long parent_rate)
+{
+	struct k210_sysclk *ksc = to_k210_sysclk(hw);
+	u32 reg = readl(ksc->regs + K210_SYSCTL_SEL0);
+	unsigned int shift;
+
+	if (!(reg & 0x1))
+		return parent_rate;
+
+	shift = FIELD_GET(K210_ACLK_DIV, reg);
+
+	return parent_rate / (2UL << shift);
+}
+
+static const struct clk_ops k210_aclk_ops = {
+	.set_parent	= k210_aclk_set_parent,
+	.get_parent	= k210_aclk_get_parent,
+	.recalc_rate	= k210_aclk_get_rate,
+};
+
+/*
+ * ACLK has IN0 and PLL0 as parents.
+ */
+static int k210_register_aclk(struct k210_sysclk *ksc, const char *in0)
+{
+	struct clk_init_data init = {};
+	const struct clk_parent_data parent_data[] = {
+		{ .name = in0 },
+		{ .hw = &ksc->plls[K210_PLL0].hw },
+	};
+	int ret;
+
+	init.name = "aclk";
+	init.parent_data = parent_data;
+	init.num_parents = 2;
+	init.ops = &k210_aclk_ops;
+	ksc->aclk.init = &init;
+
+	ret = clk_hw_register(NULL, &ksc->aclk);
+	if (ret) {
+		pr_err("%pOFP: register aclk failed\n", ksc->node);
+		return ret;
+	}
+
+	return 0;
+}
+
+#define to_k210_clk(_hw)	container_of(_hw, struct k210_clk, hw)
+
+static int k210_clk_enable(struct clk_hw *hw)
+{
+	struct k210_clk *kclk = to_k210_clk(hw);
+	struct k210_sysclk *ksc = kclk->ksc;
+	struct k210_clk_cfg *cfg = &k210_clk_cfgs[kclk->id];
+	unsigned long flags;
+	u32 reg;
+
+	if (!cfg->gate_reg)
+		return 0;
+
+	spin_lock_irqsave(&ksc->clk_lock, flags);
+	reg = readl(ksc->regs + cfg->gate_reg);
+	reg |= BIT(cfg->gate_bit);
+	writel(reg, ksc->regs + cfg->gate_reg);
+	spin_unlock_irqrestore(&ksc->clk_lock, flags);
+
+	return 0;
+}
+
+static void k210_clk_disable(struct clk_hw *hw)
+{
+	struct k210_clk *kclk = to_k210_clk(hw);
+	struct k210_sysclk *ksc = kclk->ksc;
+	struct k210_clk_cfg *cfg = &k210_clk_cfgs[kclk->id];
+	unsigned long flags;
+	u32 reg;
+
+	if (!cfg->gate_reg)
+		return;
+
+	spin_lock_irqsave(&ksc->clk_lock, flags);
+	reg = readl(ksc->regs + cfg->gate_reg);
+	reg &= ~BIT(cfg->gate_bit);
+	writel(reg, ksc->regs + cfg->gate_reg);
+	spin_unlock_irqrestore(&ksc->clk_lock, flags);
+}
+
+static int k210_clk_set_parent(struct clk_hw *hw, u8 index)
+{
+	struct k210_clk *kclk = to_k210_clk(hw);
+	struct k210_sysclk *ksc = kclk->ksc;
+	struct k210_clk_cfg *cfg = &k210_clk_cfgs[kclk->id];
+	unsigned long flags;
+	u32 reg;
+
+	spin_lock_irqsave(&ksc->clk_lock, flags);
+	reg = readl(ksc->regs + cfg->mux_reg);
+	if (index)
+		reg |= BIT(cfg->mux_bit);
+	else
+		reg &= ~BIT(cfg->mux_bit);
+	spin_unlock_irqrestore(&ksc->clk_lock, flags);
+
+	return 0;
+}
+
+static u8 k210_clk_get_parent(struct clk_hw *hw)
+{
+	struct k210_clk *kclk = to_k210_clk(hw);
+	struct k210_sysclk *ksc = kclk->ksc;
+	struct k210_clk_cfg *cfg = &k210_clk_cfgs[kclk->id];
+	unsigned long flags;
+	u32 reg, idx;
+
+	spin_lock_irqsave(&ksc->clk_lock, flags);
+	reg = readl(ksc->regs + cfg->mux_reg);
+	idx = (reg & BIT(cfg->mux_bit)) ? 1 : 0;
+	spin_unlock_irqrestore(&ksc->clk_lock, flags);
+
+	return idx;
+}
+
+static unsigned long k210_clk_get_rate(struct clk_hw *hw,
+				       unsigned long parent_rate)
+{
+	struct k210_clk *kclk = to_k210_clk(hw);
+	struct k210_sysclk *ksc = kclk->ksc;
+	struct k210_clk_cfg *cfg = &k210_clk_cfgs[kclk->id];
+	u32 reg, div_val;
+
+	if (!cfg->div_reg)
+		return parent_rate;
+
+	reg = readl(ksc->regs + cfg->div_reg);
+	div_val = (reg >> cfg->div_shift) & GENMASK(cfg->div_width - 1, 0);
+
+	switch (cfg->div_type) {
+	case K210_DIV_ONE_BASED:
+		return parent_rate / (div_val + 1);
+	case K210_DIV_DOUBLE_ONE_BASED:
+		return parent_rate / ((div_val + 1) * 2);
+	case K210_DIV_POWER_OF_TWO:
+		return parent_rate / (2UL << div_val);
+	case K210_DIV_NONE:
+	default:
+		return 0;
+	}
+}
+
+static const struct clk_ops k210_clk_mux_ops = {
+	.enable		= k210_clk_enable,
+	.disable	= k210_clk_disable,
+	.set_parent	= k210_clk_set_parent,
+	.get_parent	= k210_clk_get_parent,
+	.recalc_rate	= k210_clk_get_rate,
+};
+
+static const struct clk_ops k210_clk_ops = {
+	.enable		= k210_clk_enable,
+	.disable	= k210_clk_disable,
+	.recalc_rate	= k210_clk_get_rate,
+};
+
+static void k210_register_clk(struct k210_sysclk *ksc, int id,
+			      const struct clk_parent_data *parent_data,
+			      int num_parents, unsigned long flags)
+{
+	struct k210_clk *kclk = &ksc->clks[id];
+	struct clk_init_data init = {};
+	int ret;
+
+	init.name = k210_clk_cfgs[id].name;
+	init.flags = flags;
+	init.parent_data = parent_data;
+	init.num_parents = num_parents;
+	if (num_parents > 1)
+		init.ops = &k210_clk_mux_ops;
+	else
+		init.ops = &k210_clk_ops;
+
+	kclk->id = id;
+	kclk->ksc = ksc;
+	kclk->hw.init = &init;
+
+	ret = clk_hw_register(NULL, &kclk->hw);
+	if (ret) {
+		pr_err("%pOFP: register clock %s failed\n",
+		       ksc->node, k210_clk_cfgs[id].name);
+		kclk->id = -1;
+	}
+}
+
+/*
+ * All muxed clocks have IN0 and PLL0 as parents.
+ */
+static inline void k210_register_mux_clk(struct k210_sysclk *ksc,
+					 const char *in0, int id)
+{
+	const struct clk_parent_data parent_data[2] = {
+		{ .name = in0 },
+		{ .hw = &ksc->plls[K210_PLL0].hw },
+	};
+
+	k210_register_clk(ksc, id, parent_data, 2, 0);
+}
+
+static inline void k210_register_in0_child(struct k210_sysclk *ksc,
+					   const char *in0, int id)
+{
+	const struct clk_parent_data parent_data = {
+		.name = in0,
+	};
+
+	k210_register_clk(ksc, id, &parent_data, 1, 0);
+}
+
+static inline void k210_register_pll_child(struct k210_sysclk *ksc, int id,
+					   enum k210_pll_id pllid,
+					   unsigned long flags)
+{
+	const struct clk_parent_data parent_data = {
+		.hw = &ksc->plls[pllid].hw,
+	};
+
+	k210_register_clk(ksc, id, &parent_data, 1, flags);
+}
+
+static inline void k210_register_aclk_child(struct k210_sysclk *ksc, int id,
+					    unsigned long flags)
+{
+	const struct clk_parent_data parent_data = {
+		.hw = &ksc->aclk,
+	};
+
+	k210_register_clk(ksc, id, &parent_data, 1, flags);
+}
+
+static inline void k210_register_clk_child(struct k210_sysclk *ksc, int id,
+					   int parent_id)
+{
+	const struct clk_parent_data parent_data = {
+		.hw = &ksc->clks[parent_id].hw,
+	};
+
+	k210_register_clk(ksc, id, &parent_data, 1, 0);
+}
+
+static struct clk_hw *k210_clk_hw_onecell_get(struct of_phandle_args *clkspec,
+					      void *data)
+{
+	struct k210_sysclk *ksc = data;
+	unsigned int idx = clkspec->args[0];
+
+	if (idx >= K210_NUM_CLKS)
+		return ERR_PTR(-EINVAL);
+
+	return &ksc->clks[idx].hw;
+}
+
+static void __init k210_clk_init(struct device_node *np)
+{
+	struct device_node *sysctl_np;
+	struct k210_sysclk *ksc;
+	const char *in0;
+	int i, ret;
+
+	ksc = kzalloc(sizeof(*ksc), GFP_KERNEL);
+	if (!ksc)
+		return;
+
+	ksc->node = np;
+	spin_lock_init(&ksc->clk_lock);
+	sysctl_np = of_get_parent(np);
+	ksc->regs = of_iomap(sysctl_np, 0);
+	of_node_put(sysctl_np);
+	if (!ksc->regs) {
+		pr_err("%pOFP: failed to map registers\n", np);
+		return;
+	}
+
+	in0 = of_clk_get_parent_name(np, 0);
+	if (!in0) {
+		pr_err("%pOFP: undefined fixed-rate oscillator clock\n", np);
+		return;
+	}
+
+	ret = k210_register_plls(ksc, in0);
+	if (ret)
+		return;
+
+	ret = k210_register_aclk(ksc, in0);
+	if (ret)
+		return;
+
+	/*
+	 * Critical clocks: there are no consumers of the SRAM clocks,
+	 * including the AI clock for the third SRAM bank. The CPU clock
+	 * is only referenced by the uarths serial device and so would be
+	 * disabled if the serial console is disabled to switch to another
+	 * console. Mark all these clocks as critical so that they are never
+	 * disabled by the core clock management.
+	 */
+	k210_register_aclk_child(ksc, K210_CLK_CPU, CLK_IS_CRITICAL);
+	k210_register_aclk_child(ksc, K210_CLK_SRAM0, CLK_IS_CRITICAL);
+	k210_register_aclk_child(ksc, K210_CLK_SRAM1, CLK_IS_CRITICAL);
+	k210_register_pll_child(ksc, K210_CLK_AI, K210_PLL1, CLK_IS_CRITICAL);
+
+	/* Clocks with aclk as source */
+	k210_register_aclk_child(ksc, K210_CLK_DMA, 0);
+	k210_register_aclk_child(ksc, K210_CLK_FFT, 0);
+	k210_register_aclk_child(ksc, K210_CLK_ROM, 0);
+	k210_register_aclk_child(ksc, K210_CLK_DVP, 0);
+	k210_register_aclk_child(ksc, K210_CLK_APB0, 0);
+	k210_register_aclk_child(ksc, K210_CLK_APB1, 0);
+	k210_register_aclk_child(ksc, K210_CLK_APB2, 0);
+
+	/* Clocks with PLL0 as source */
+	k210_register_pll_child(ksc, K210_CLK_SPI0, K210_PLL0, 0);
+	k210_register_pll_child(ksc, K210_CLK_SPI1, K210_PLL0, 0);
+	k210_register_pll_child(ksc, K210_CLK_SPI2, K210_PLL0, 0);
+	k210_register_pll_child(ksc, K210_CLK_I2C0, K210_PLL0, 0);
+	k210_register_pll_child(ksc, K210_CLK_I2C1, K210_PLL0, 0);
+	k210_register_pll_child(ksc, K210_CLK_I2C2, K210_PLL0, 0);
+
+	/* Clocks with PLL2 as source */
+	k210_register_pll_child(ksc, K210_CLK_I2S0, K210_PLL2, 0);
+	k210_register_pll_child(ksc, K210_CLK_I2S1, K210_PLL2, 0);
+	k210_register_pll_child(ksc, K210_CLK_I2S2, K210_PLL2, 0);
+	k210_register_pll_child(ksc, K210_CLK_I2S0_M, K210_PLL2, 0);
+	k210_register_pll_child(ksc, K210_CLK_I2S1_M, K210_PLL2, 0);
+	k210_register_pll_child(ksc, K210_CLK_I2S2_M, K210_PLL2, 0);
+
+	/* Clocks with IN0 as source */
+	k210_register_in0_child(ksc, in0, K210_CLK_WDT0);
+	k210_register_in0_child(ksc, in0, K210_CLK_WDT1);
+	k210_register_in0_child(ksc, in0, K210_CLK_RTC);
+
+	/* Clocks with APB0 as source */
+	k210_register_clk_child(ksc, K210_CLK_GPIO, K210_CLK_APB0);
+	k210_register_clk_child(ksc, K210_CLK_UART1, K210_CLK_APB0);
+	k210_register_clk_child(ksc, K210_CLK_UART2, K210_CLK_APB0);
+	k210_register_clk_child(ksc, K210_CLK_UART3, K210_CLK_APB0);
+	k210_register_clk_child(ksc, K210_CLK_FPIOA, K210_CLK_APB0);
+	k210_register_clk_child(ksc, K210_CLK_SHA, K210_CLK_APB0);
+
+	/* Clocks with APB1 as source */
+	k210_register_clk_child(ksc, K210_CLK_AES, K210_CLK_APB1);
+	k210_register_clk_child(ksc, K210_CLK_OTP, K210_CLK_APB1);
+
+	/* Mux clocks with in0 or pll0 as source */
+	k210_register_mux_clk(ksc, in0, K210_CLK_SPI3);
+	k210_register_mux_clk(ksc, in0, K210_CLK_TIMER0);
+	k210_register_mux_clk(ksc, in0, K210_CLK_TIMER1);
+	k210_register_mux_clk(ksc, in0, K210_CLK_TIMER2);
+
+	/* Check for registration errors */
+	for (i = 0; i < K210_NUM_CLKS; i++) {
+		if (ksc->clks[i].id != i)
+			return;
+	}
+
+	ret = of_clk_add_hw_provider(np, k210_clk_hw_onecell_get, ksc);
+	if (ret) {
+		pr_err("%pOFP: add clock provider failed %d\n", np, ret);
+		return;
+	}
+
+	pr_info("%pOFP: CPU running at %lu MHz\n",
+		np, clk_hw_get_rate(&ksc->clks[K210_CLK_CPU].hw) / 1000000);
+}
+
+CLK_OF_DECLARE(k210_clk, "canaan,k210-clk", k210_clk_init);
+
+/*
+ * Enable PLL1 to be able to use the AI SRAM.
+ */
+void __init k210_clk_early_init(void __iomem *regs)
+{
+	struct k210_pll pll1;
+
+	/* Make sure ACLK selector is set to PLL0 */
+	k210_aclk_set_selector(regs, 1);
+
+	/* Startup PLL1 to enable the aisram bank for general memory use */
+	k210_init_pll(regs, K210_PLL1, &pll1);
+	k210_pll_enable_hw(regs, &pll1);
+}
diff --git a/drivers/soc/canaan/Kconfig b/drivers/soc/canaan/Kconfig
index 5232d13f07e5..8179b69518b4 100644
--- a/drivers/soc/canaan/Kconfig
+++ b/drivers/soc/canaan/Kconfig
@@ -1,14 +1,12 @@
 # SPDX-License-Identifier: GPL-2.0
 
-if SOC_CANAAN
-
-config K210_SYSCTL
+config SOC_K210_SYSCTL
 	bool "Canaan Kendryte K210 SoC system controller"
-	default y
-	depends on RISCV
+	depends on RISCV && SOC_CANAAN && OF
+	default SOC_CANAAN
+        select PM
+        select SIMPLE_PM_BUS
+        select SYSCON
+        select MFD_SYSCON
 	help
-	  Enables controlling the K210 various clocks and to enable
-	  general purpose use of the extra 2MB of SRAM normally
-	  reserved for the AI engine.
-
-endif
+	  Canaan Kendryte K210 SoC system controller driver.
diff --git a/drivers/soc/canaan/Makefile b/drivers/soc/canaan/Makefile
index 002d9ce95c0d..570280ad7967 100644
--- a/drivers/soc/canaan/Makefile
+++ b/drivers/soc/canaan/Makefile
@@ -1,3 +1,3 @@
 # SPDX-License-Identifier: GPL-2.0
 
-obj-$(CONFIG_K210_SYSCTL)	+= k210-sysctl.o
+obj-$(CONFIG_SOC_K210_SYSCTL)	+= k210-sysctl.o
diff --git a/drivers/soc/canaan/k210-sysctl.c b/drivers/soc/canaan/k210-sysctl.c
index 60b474c33d45..27a346c406bc 100644
--- a/drivers/soc/canaan/k210-sysctl.c
+++ b/drivers/soc/canaan/k210-sysctl.c
@@ -3,165 +3,45 @@
  * Copyright (c) 2019 Christoph Hellwig.
  * Copyright (c) 2019 Western Digital Corporation or its affiliates.
  */
-#include <linux/types.h>
 #include <linux/io.h>
-#include <linux/of.h>
 #include <linux/platform_device.h>
-#include <linux/clk-provider.h>
-#include <linux/clkdev.h>
-#include <linux/bitfield.h>
+#include <linux/of_platform.h>
+#include <linux/clk.h>
 #include <asm/soc.h>
 
 #include <soc/canaan/k210-sysctl.h>
 
-#define K210_SYSCTL_CLK0_FREQ		26000000UL
-
-/* Registers base address */
-#define K210_SYSCTL_SYSCTL_BASE_ADDR	0x50440000ULL
-
-/* Register bits */
-/* K210_SYSCTL_PLL1: clkr: 4bits, clkf1: 6bits, clkod: 4bits, bwadj: 4bits */
-#define PLL_RESET		(1 << 20)
-#define PLL_PWR			(1 << 21)
-#define PLL_BYPASS		(1 << 23)
-#define PLL_OUT_EN		(1 << 25)
-/* K210_SYSCTL_PLL_LOCK */
-#define PLL1_LOCK1		(1 << 8)
-#define PLL1_LOCK2		(1 << 9)
-#define PLL1_SLIP_CLEAR		(1 << 10)
-/* K210_SYSCTL_SEL0 */
-#define CLKSEL_ACLK		(1 << 0)
-/* K210_SYSCTL_CLKEN_CENT */
-#define CLKEN_CPU		(1 << 0)
-#define CLKEN_SRAM0		(1 << 1)
-#define CLKEN_SRAM1		(1 << 2)
-/* K210_SYSCTL_EN_PERI */
-#define CLKEN_ROM		(1 << 0)
-#define CLKEN_TIMER0		(1 << 21)
-#define CLKEN_RTC		(1 << 29)
-
-struct k210_sysctl {
-	void __iomem		*regs;
-	struct clk_hw		hw;
-};
-
-static void k210_set_bits(u32 val, void __iomem *reg)
-{
-	writel(readl(reg) | val, reg);
-}
-
-static void k210_clear_bits(u32 val, void __iomem *reg)
-{
-	writel(readl(reg) & ~val, reg);
-}
-
-static void k210_pll1_enable(void __iomem *regs)
-{
-	u32 val;
-
-	val = readl(regs + K210_SYSCTL_PLL1);
-	val &= ~GENMASK(19, 0);				/* clkr1 = 0 */
-	val |= FIELD_PREP(GENMASK(9, 4), 0x3B);		/* clkf1 = 59 */
-	val |= FIELD_PREP(GENMASK(13, 10), 0x3);	/* clkod1 = 3 */
-	val |= FIELD_PREP(GENMASK(19, 14), 0x3B);	/* bwadj1 = 59 */
-	writel(val, regs + K210_SYSCTL_PLL1);
-
-	k210_clear_bits(PLL_BYPASS, regs + K210_SYSCTL_PLL1);
-	k210_set_bits(PLL_PWR, regs + K210_SYSCTL_PLL1);
-
-	/*
-	 * Reset the pll. The magic NOPs come from the Kendryte reference SDK.
-	 */
-	k210_clear_bits(PLL_RESET, regs + K210_SYSCTL_PLL1);
-	k210_set_bits(PLL_RESET, regs + K210_SYSCTL_PLL1);
-	nop();
-	nop();
-	k210_clear_bits(PLL_RESET, regs + K210_SYSCTL_PLL1);
-
-	for (;;) {
-		val = readl(regs + K210_SYSCTL_PLL_LOCK);
-		if (val & PLL1_LOCK2)
-			break;
-		writel(val | PLL1_SLIP_CLEAR, regs + K210_SYSCTL_PLL_LOCK);
-	}
-
-	k210_set_bits(PLL_OUT_EN, regs + K210_SYSCTL_PLL1);
-}
-
-static unsigned long k210_sysctl_clk_recalc_rate(struct clk_hw *hw,
-		unsigned long parent_rate)
-{
-	struct k210_sysctl *s = container_of(hw, struct k210_sysctl, hw);
-	u32 clksel0, pll0;
-	u64 pll0_freq, clkr0, clkf0, clkod0;
-
-	/*
-	 * If the clock selector is not set, use the base frequency.
-	 * Otherwise, use PLL0 frequency with a frequency divisor.
-	 */
-	clksel0 = readl(s->regs + K210_SYSCTL_SEL0);
-	if (!(clksel0 & CLKSEL_ACLK))
-		return K210_SYSCTL_CLK0_FREQ;
-
-	/*
-	 * Get PLL0 frequency:
-	 * freq = base frequency * clkf0 / (clkr0 * clkod0)
-	 */
-	pll0 = readl(s->regs + K210_SYSCTL_PLL0);
-	clkr0 = 1 + FIELD_GET(GENMASK(3, 0), pll0);
-	clkf0 = 1 + FIELD_GET(GENMASK(9, 4), pll0);
-	clkod0 = 1 + FIELD_GET(GENMASK(13, 10), pll0);
-	pll0_freq = clkf0 * K210_SYSCTL_CLK0_FREQ / (clkr0 * clkod0);
-
-	/* Get the frequency divisor from the clock selector */
-	return pll0_freq / (2ULL << FIELD_GET(0x00000006, clksel0));
-}
-
-static const struct clk_ops k210_sysctl_clk_ops = {
-	.recalc_rate	= k210_sysctl_clk_recalc_rate,
-};
-
-static const struct clk_init_data k210_clk_init_data = {
-	.name		= "k210-sysctl-pll1",
-	.ops		= &k210_sysctl_clk_ops,
-};
-
 static int k210_sysctl_probe(struct platform_device *pdev)
 {
-	struct k210_sysctl *s;
-	int error;
-
-	pr_info("Kendryte K210 SoC sysctl\n");
-
-	s = devm_kzalloc(&pdev->dev, sizeof(*s), GFP_KERNEL);
-	if (!s)
-		return -ENOMEM;
-
-	s->regs = devm_ioremap_resource(&pdev->dev,
-			platform_get_resource(pdev, IORESOURCE_MEM, 0));
-	if (IS_ERR(s->regs))
-		return PTR_ERR(s->regs);
-
-	s->hw.init = &k210_clk_init_data;
-	error = devm_clk_hw_register(&pdev->dev, &s->hw);
-	if (error) {
-		dev_err(&pdev->dev, "failed to register clk");
-		return error;
+	struct device *dev = &pdev->dev;
+	struct clk *pclk;
+	int ret;
+
+	dev_info(dev, "K210 system controller\n");
+
+	/* Get power bus clock */
+	pclk = devm_clk_get(dev, NULL);
+	if (IS_ERR(pclk))
+		return dev_err_probe(dev, PTR_ERR(pclk),
+				     "Get bus clock failed\n");
+
+	ret = clk_prepare_enable(pclk);
+	if (ret) {
+		dev_err(dev, "Enable bus clock failed\n");
+		return ret;
 	}
 
-	error = devm_of_clk_add_hw_provider(&pdev->dev, of_clk_hw_simple_get,
-					    &s->hw);
-	if (error) {
-		dev_err(&pdev->dev, "adding clk provider failed\n");
-		return error;
-	}
+	/* Populate children */
+	ret = devm_of_platform_populate(dev);
+	if (ret)
+		dev_err(dev, "Populate platform failed %d\n", ret);
 
-	return 0;
+	return ret;
 }
 
 static const struct of_device_id k210_sysctl_of_match[] = {
-	{ .compatible = "kendryte,k210-sysctl", },
-	{}
+	{ .compatible = "canaan,k210-sysctl", },
+	{ /* sentinel */ },
 };
 
 static struct platform_driver k210_sysctl_driver = {
@@ -171,12 +51,13 @@ static struct platform_driver k210_sysctl_driver = {
 	},
 	.probe			= k210_sysctl_probe,
 };
+builtin_platform_driver(k210_sysctl_driver);
 
-static int __init k210_sysctl_init(void)
-{
-	return platform_driver_register(&k210_sysctl_driver);
-}
-core_initcall(k210_sysctl_init);
+/*
+ * System controller registers base address and size.
+ */
+#define K210_SYSCTL_BASE_ADDR	0x50440000ULL
+#define K210_SYSCTL_BASE_SIZE	0x1000
 
 /*
  * This needs to be called very early during initialization, given that
@@ -184,24 +65,14 @@ core_initcall(k210_sysctl_init);
  */
 static void __init k210_soc_early_init(const void *fdt)
 {
-	void __iomem *regs;
-
-	regs = ioremap(K210_SYSCTL_SYSCTL_BASE_ADDR, 0x1000);
-	if (!regs)
-		panic("K210 sysctl ioremap");
-
-	/* Enable PLL1 to make the KPU SRAM useable */
-	k210_pll1_enable(regs);
-
-	k210_set_bits(PLL_OUT_EN, regs + K210_SYSCTL_PLL0);
+	void __iomem *sysctl_base;
 
-	k210_set_bits(CLKEN_CPU | CLKEN_SRAM0 | CLKEN_SRAM1,
-		      regs + K210_SYSCTL_EN_CENT);
-	k210_set_bits(CLKEN_ROM | CLKEN_TIMER0 | CLKEN_RTC,
-		      regs + K210_SYSCTL_EN_PERI);
+	sysctl_base = ioremap(K210_SYSCTL_BASE_ADDR, K210_SYSCTL_BASE_SIZE);
+	if (!sysctl_base)
+		panic("k210-sysctl: ioremap failed");
 
-	k210_set_bits(CLKSEL_ACLK, regs + K210_SYSCTL_SEL0);
+	k210_clk_early_init(sysctl_base);
 
-	iounmap(regs);
+	iounmap(sysctl_base);
 }
-SOC_EARLY_INIT_DECLARE(generic_k210, "kendryte,k210", k210_soc_early_init);
+SOC_EARLY_INIT_DECLARE(k210_soc, "canaan,kendryte-k210", k210_soc_early_init);
diff --git a/include/soc/canaan/k210-sysctl.h b/include/soc/canaan/k210-sysctl.h
index 2e037db68f35..0c2b2c2dabca 100644
--- a/include/soc/canaan/k210-sysctl.h
+++ b/include/soc/canaan/k210-sysctl.h
@@ -38,4 +38,6 @@
 #define K210_SYSCTL_DMA_SEL1	0x68 /* DMA handshake selector 1 */
 #define K210_SYSCTL_POWER_SEL	0x6C /* IO Power Mode Select controller */
 
+void k210_clk_early_init(void __iomem *regs);
+
 #endif
-- 
2.29.2


^ permalink raw reply related	[flat|nested] 81+ messages in thread

* [PATCH v14 01/16] clk: Add RISC-V Canaan Kendryte K210 clock driver
@ 2021-02-02 10:36   ` Damien Le Moal
  0 siblings, 0 replies; 81+ messages in thread
From: Damien Le Moal @ 2021-02-02 10:36 UTC (permalink / raw)
  To: Palmer Dabbelt, linux-riscv
  Cc: Stephen Boyd, Michael Turquette, Anup Patel, Sean Anderson,
	Atish Patra, linux-clk

Add a clock provider driver for the Canaan Kendryte K210 RISC-V SoC.
This new driver with the compatible string "canaan,k210-clk" implements
support for the full clock structure of the K210 SoC. Since it is
required for the correct operation of the SoC, this driver is
selected by default for compilation when the SOC_CANAAN option is
selected.

With this change, the k210-sysctl driver is turned into a simple
platform driver which enables its power bus clock and triggers
populating its child nodes. The sysctl driver retains the SOC early
initialization code, but the implementation now relies on the new
function k210_clk_early_init() provided by the new clk-k210 driver.

The clock structure implemented and many of the coding ideas for the
driver come from the work by Sean Anderson on the K210 support for the
U-Boot project.

Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: linux-clk@vger.kernel.org
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
---
 MAINTAINERS                      |    1 +
 drivers/clk/Kconfig              |    8 +
 drivers/clk/Makefile             |    1 +
 drivers/clk/clk-k210.c           | 1012 ++++++++++++++++++++++++++++++
 drivers/soc/canaan/Kconfig       |   18 +-
 drivers/soc/canaan/Makefile      |    2 +-
 drivers/soc/canaan/k210-sysctl.c |  205 ++----
 include/soc/canaan/k210-sysctl.h |    2 +
 8 files changed, 1071 insertions(+), 178 deletions(-)
 create mode 100644 drivers/clk/clk-k210.c

diff --git a/MAINTAINERS b/MAINTAINERS
index dfb95dbe2abe..0f9c2300779b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3878,6 +3878,7 @@ CANAAN/KENDRYTE K210 SOC SYSTEM CONTROLLER DRIVER
 M:	Damien Le Moal <damien.lemoal@wdc.com>
 L:	linux-riscv@lists.infradead.org
 S:	Maintained
+F:	Documentation/devicetree/bindings/mfd/canaan,k210-sysctl.yaml
 F:	drivers/soc/canaan/
 F:	include/soc/canaan/
 
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 85856cff506c..cb971f6632e2 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -368,6 +368,14 @@ config COMMON_CLK_FIXED_MMIO
 	help
 	  Support for Memory Mapped IO Fixed clocks
 
+config COMMON_CLK_K210
+	bool "Clock driver for the Canaan Kendryte K210 SoC"
+	depends on COMMON_CLK && OF
+	depends on RISCV && SOC_CANAAN
+	default SOC_CANAAN
+	help
+	  Support for the Canaan Kendryte K210 RISC-V SoC clocks.
+
 source "drivers/clk/actions/Kconfig"
 source "drivers/clk/analogbits/Kconfig"
 source "drivers/clk/baikal-t1/Kconfig"
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index dbdc590e7de3..5f8f9f135df5 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_COMMON_CLK_ASPEED)		+= clk-aspeed.o
 obj-$(CONFIG_MACH_ASPEED_G6)		+= clk-ast2600.o
 obj-$(CONFIG_ARCH_HIGHBANK)		+= clk-highbank.o
 obj-$(CONFIG_CLK_HSDK)			+= clk-hsdk-pll.o
+obj-$(CONFIG_COMMON_CLK_K210)		+= clk-k210.o
 obj-$(CONFIG_COMMON_CLK_LOCHNAGAR)	+= clk-lochnagar.o
 obj-$(CONFIG_COMMON_CLK_MAX77686)	+= clk-max77686.o
 obj-$(CONFIG_COMMON_CLK_MAX9485)	+= clk-max9485.o
diff --git a/drivers/clk/clk-k210.c b/drivers/clk/clk-k210.c
new file mode 100644
index 000000000000..429db4904ad6
--- /dev/null
+++ b/drivers/clk/clk-k210.c
@@ -0,0 +1,1012 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2019-20 Sean Anderson <seanga2@gmail.com>
+ * Copyright (c) 2019 Western Digital Corporation or its affiliates.
+ */
+#define pr_fmt(fmt)     "k210-clk: " fmt
+
+#include <linux/io.h>
+#include <linux/slab.h>
+#include <linux/spinlock.h>
+#include <linux/platform_device.h>
+#include <linux/of.h>
+#include <linux/of_clk.h>
+#include <linux/of_platform.h>
+#include <linux/of_address.h>
+#include <linux/clk-provider.h>
+#include <linux/bitfield.h>
+#include <linux/delay.h>
+#include <asm/soc.h>
+#include <soc/canaan/k210-sysctl.h>
+
+#include <dt-bindings/clock/k210-clk.h>
+
+/*
+ * Clocks parameters.
+ */
+struct k210_sysclk;
+
+struct k210_clk {
+	int id;
+	struct k210_sysclk *ksc;
+	struct clk_hw hw;
+};
+
+struct k210_clk_cfg {
+	const char *name;
+	u8 gate_reg;
+	u8 gate_bit;
+	u8 div_reg;
+	u8 div_shift;
+	u8 div_width;
+	u8 div_type;
+	u8 mux_reg;
+	u8 mux_bit;
+};
+
+enum k210_clk_div_type {
+	K210_DIV_NONE,
+	K210_DIV_ONE_BASED,
+	K210_DIV_DOUBLE_ONE_BASED,
+	K210_DIV_POWER_OF_TWO,
+};
+
+#define K210_GATE(_reg, _bit)	\
+	.gate_reg = (_reg),	\
+	.gate_bit = (_bit)
+#define K210_DIV(_reg, _shift, _width, _type)	\
+	.div_reg = (_reg),			\
+	.div_shift = (_shift),			\
+	.div_width = (_width),			\
+	.div_type = (_type)
+#define K210_MUX(_reg, _bit)	\
+	.mux_reg = (_reg),	\
+	.mux_bit = (_bit)
+
+static struct k210_clk_cfg k210_clk_cfgs[K210_NUM_CLKS] = {
+
+	/* Gated clocks, no mux, no divider */
+	[K210_CLK_CPU] = {
+		.name = "cpu",
+		K210_GATE(K210_SYSCTL_EN_CENT, 0)
+	},
+	[K210_CLK_DMA] = {
+		.name = "dma",
+		K210_GATE(K210_SYSCTL_EN_PERI, 1)
+	},
+	[K210_CLK_FFT] = {
+		.name = "fft",
+		K210_GATE(K210_SYSCTL_EN_PERI, 4)
+	},
+	[K210_CLK_GPIO] = {
+		.name = "gpio",
+		K210_GATE(K210_SYSCTL_EN_PERI, 5)
+	},
+	[K210_CLK_UART1] = {
+		.name = "uart1",
+		K210_GATE(K210_SYSCTL_EN_PERI, 16)
+	},
+	[K210_CLK_UART2] = {
+		.name = "uart2",
+		K210_GATE(K210_SYSCTL_EN_PERI, 17)
+	},
+	[K210_CLK_UART3] = {
+		.name = "uart3",
+		K210_GATE(K210_SYSCTL_EN_PERI, 18)
+	},
+	[K210_CLK_FPIOA] = {
+		.name = "fpioa",
+		K210_GATE(K210_SYSCTL_EN_PERI, 20)
+	},
+	[K210_CLK_SHA] = {
+		.name = "sha",
+		K210_GATE(K210_SYSCTL_EN_PERI, 26)
+	},
+	[K210_CLK_AES] = {
+		.name = "aes",
+		K210_GATE(K210_SYSCTL_EN_PERI, 19)
+	},
+	[K210_CLK_OTP] = {
+		.name = "otp",
+		K210_GATE(K210_SYSCTL_EN_PERI, 27)
+	},
+	[K210_CLK_RTC] = {
+		.name = "rtc",
+		K210_GATE(K210_SYSCTL_EN_PERI, 29)
+	},
+
+	/* Gated divider clocks */
+	[K210_CLK_SRAM0] = {
+		.name = "sram0",
+		K210_GATE(K210_SYSCTL_EN_CENT, 1),
+		K210_DIV(K210_SYSCTL_THR0, 0, 4, K210_DIV_ONE_BASED)
+	},
+	[K210_CLK_SRAM1] = {
+		.name = "sram1",
+		K210_GATE(K210_SYSCTL_EN_CENT, 2),
+		K210_DIV(K210_SYSCTL_THR0, 4, 4, K210_DIV_ONE_BASED)
+	},
+	[K210_CLK_ROM] = {
+		.name = "rom",
+		K210_GATE(K210_SYSCTL_EN_PERI, 0),
+		K210_DIV(K210_SYSCTL_THR0, 16, 4, K210_DIV_ONE_BASED)
+	},
+	[K210_CLK_DVP] = {
+		.name = "dvp",
+		K210_GATE(K210_SYSCTL_EN_PERI, 3),
+		K210_DIV(K210_SYSCTL_THR0, 12, 4, K210_DIV_ONE_BASED)
+	},
+	[K210_CLK_APB0] = {
+		.name = "apb0",
+		K210_GATE(K210_SYSCTL_EN_CENT, 3),
+		K210_DIV(K210_SYSCTL_SEL0, 3, 3, K210_DIV_ONE_BASED)
+	},
+	[K210_CLK_APB1] = {
+		.name = "apb1",
+		K210_GATE(K210_SYSCTL_EN_CENT, 4),
+		K210_DIV(K210_SYSCTL_SEL0, 6, 3, K210_DIV_ONE_BASED)
+	},
+	[K210_CLK_APB2] = {
+		.name = "apb2",
+		K210_GATE(K210_SYSCTL_EN_CENT, 5),
+		K210_DIV(K210_SYSCTL_SEL0, 9, 3, K210_DIV_ONE_BASED)
+	},
+	[K210_CLK_AI] = {
+		.name = "ai",
+		K210_GATE(K210_SYSCTL_EN_PERI, 2),
+		K210_DIV(K210_SYSCTL_THR0, 8, 4, K210_DIV_ONE_BASED)
+	},
+	[K210_CLK_SPI0] = {
+		.name = "spi0",
+		K210_GATE(K210_SYSCTL_EN_PERI, 6),
+		K210_DIV(K210_SYSCTL_THR1, 0, 8, K210_DIV_DOUBLE_ONE_BASED)
+	},
+	[K210_CLK_SPI1] = {
+		.name = "spi1",
+		K210_GATE(K210_SYSCTL_EN_PERI, 7),
+		K210_DIV(K210_SYSCTL_THR1, 8, 8, K210_DIV_DOUBLE_ONE_BASED)
+	},
+	[K210_CLK_SPI2] = {
+		.name = "spi2",
+		K210_GATE(K210_SYSCTL_EN_PERI, 8),
+		K210_DIV(K210_SYSCTL_THR1, 16, 8, K210_DIV_DOUBLE_ONE_BASED)
+	},
+	[K210_CLK_I2C0] = {
+		.name = "i2c0",
+		K210_GATE(K210_SYSCTL_EN_PERI, 13),
+		K210_DIV(K210_SYSCTL_THR5, 8, 8, K210_DIV_DOUBLE_ONE_BASED)
+	},
+	[K210_CLK_I2C1] = {
+		.name = "i2c1",
+		K210_GATE(K210_SYSCTL_EN_PERI, 14),
+		K210_DIV(K210_SYSCTL_THR5, 16, 8, K210_DIV_DOUBLE_ONE_BASED)
+	},
+	[K210_CLK_I2C2] = {
+		.name = "i2c2",
+		K210_GATE(K210_SYSCTL_EN_PERI, 15),
+		K210_DIV(K210_SYSCTL_THR5, 24, 8, K210_DIV_DOUBLE_ONE_BASED)
+	},
+	[K210_CLK_WDT0] = {
+		.name = "wdt0",
+		K210_GATE(K210_SYSCTL_EN_PERI, 24),
+		K210_DIV(K210_SYSCTL_THR6, 0, 8, K210_DIV_DOUBLE_ONE_BASED)
+	},
+	[K210_CLK_WDT1] = {
+		.name = "wdt1",
+		K210_GATE(K210_SYSCTL_EN_PERI, 25),
+		K210_DIV(K210_SYSCTL_THR6, 8, 8, K210_DIV_DOUBLE_ONE_BASED)
+	},
+	[K210_CLK_I2S0] = {
+		.name = "i2s0",
+		K210_GATE(K210_SYSCTL_EN_PERI, 10),
+		K210_DIV(K210_SYSCTL_THR3, 0, 16, K210_DIV_DOUBLE_ONE_BASED)
+	},
+	[K210_CLK_I2S1] = {
+		.name = "i2s1",
+		K210_GATE(K210_SYSCTL_EN_PERI, 11),
+		K210_DIV(K210_SYSCTL_THR3, 16, 16, K210_DIV_DOUBLE_ONE_BASED)
+	},
+	[K210_CLK_I2S2] = {
+		.name = "i2s2",
+		K210_GATE(K210_SYSCTL_EN_PERI, 12),
+		K210_DIV(K210_SYSCTL_THR4, 0, 16, K210_DIV_DOUBLE_ONE_BASED)
+	},
+
+	/* Divider clocks, no gate, no mux */
+	[K210_CLK_I2S0_M] = {
+		.name = "i2s0_m",
+		K210_DIV(K210_SYSCTL_THR4, 16, 8, K210_DIV_DOUBLE_ONE_BASED)
+	},
+	[K210_CLK_I2S1_M] = {
+		.name = "i2s1_m",
+		K210_DIV(K210_SYSCTL_THR4, 24, 8, K210_DIV_DOUBLE_ONE_BASED)
+	},
+	[K210_CLK_I2S2_M] = {
+		.name = "i2s2_m",
+		K210_DIV(K210_SYSCTL_THR4, 0, 8, K210_DIV_DOUBLE_ONE_BASED)
+	},
+
+	/* Muxed gated divider clocks */
+	[K210_CLK_SPI3] = {
+		.name = "spi3",
+		K210_GATE(K210_SYSCTL_EN_PERI, 9),
+		K210_DIV(K210_SYSCTL_THR1, 24, 8, K210_DIV_DOUBLE_ONE_BASED),
+		K210_MUX(K210_SYSCTL_SEL0, 12)
+	},
+	[K210_CLK_TIMER0] = {
+		.name = "timer0",
+		K210_GATE(K210_SYSCTL_EN_PERI, 21),
+		K210_DIV(K210_SYSCTL_THR2,  0, 8, K210_DIV_DOUBLE_ONE_BASED),
+		K210_MUX(K210_SYSCTL_SEL0, 13)
+	},
+	[K210_CLK_TIMER1] = {
+		.name = "timer1",
+		K210_GATE(K210_SYSCTL_EN_PERI, 22),
+		K210_DIV(K210_SYSCTL_THR2, 8, 8, K210_DIV_DOUBLE_ONE_BASED),
+		K210_MUX(K210_SYSCTL_SEL0, 14)
+	},
+	[K210_CLK_TIMER2] = {
+		.name = "timer2",
+		K210_GATE(K210_SYSCTL_EN_PERI, 23),
+		K210_DIV(K210_SYSCTL_THR2, 16, 8, K210_DIV_DOUBLE_ONE_BASED),
+		K210_MUX(K210_SYSCTL_SEL0, 15)
+	},
+};
+
+/*
+ * PLL control register bits.
+ */
+#define K210_PLL_CLKR		GENMASK(3, 0)
+#define K210_PLL_CLKF		GENMASK(9, 4)
+#define K210_PLL_CLKOD		GENMASK(13, 10)
+#define K210_PLL_BWADJ		GENMASK(19, 14)
+#define K210_PLL_RESET		(1 << 20)
+#define K210_PLL_PWRD		(1 << 21)
+#define K210_PLL_INTFB		(1 << 22)
+#define K210_PLL_BYPASS		(1 << 23)
+#define K210_PLL_TEST		(1 << 24)
+#define K210_PLL_EN		(1 << 25)
+#define K210_PLL_SEL		GENMASK(27, 26) /* PLL2 only */
+
+/*
+ * PLL lock register bits.
+ */
+#define K210_PLL_LOCK		0
+#define K210_PLL_CLEAR_SLIP	2
+#define K210_PLL_TEST_OUT	3
+
+/*
+ * Clock selector register bits.
+ */
+#define K210_ACLK_SEL		BIT(0)
+#define K210_ACLK_DIV		GENMASK(2, 1)
+
+/*
+ * PLLs.
+ */
+enum k210_pll_id {
+	K210_PLL0, K210_PLL1, K210_PLL2, K210_PLL_NUM
+};
+
+struct k210_pll {
+	enum k210_pll_id id;
+	struct k210_sysclk *ksc;
+	void __iomem *base;
+	void __iomem *reg;
+	void __iomem *lock;
+	u8 lock_shift;
+	u8 lock_width;
+	struct clk_hw hw;
+};
+#define to_k210_pll(_hw)	container_of(_hw, struct k210_pll, hw)
+
+/*
+ * PLLs configuration: by default PLL0 runs at 780 MHz and PLL1 at 299 MHz.
+ * The first 2 SRAM banks depend on ACLK/CPU clock which is by default PLL0
+ * rate divided by 2. Set PLL1 to 390 MHz so that the third SRAM bank has the
+ * same clock as the first 2.
+ */
+struct k210_pll_cfg {
+	u32 reg;
+	u8 lock_shift;
+	u8 lock_width;
+	u32 r;
+	u32 f;
+	u32 od;
+	u32 bwadj;
+};
+
+static struct k210_pll_cfg k210_plls_cfg[] = {
+	{ K210_SYSCTL_PLL0,  0, 2, 0, 59, 1, 59 }, /* 780 MHz */
+	{ K210_SYSCTL_PLL1,  8, 1, 0, 59, 3, 59 }, /* 390 MHz */
+	{ K210_SYSCTL_PLL2, 16, 1, 0, 22, 1, 22 }, /* 299 MHz */
+};
+
+/**
+ * struct k210_sysclk - sysclk driver data
+ * @node: device node
+ * @regs: system controller registers start address
+ * @clk_lock: clock setting spinlock
+ * @plls: SoC PLLs descriptors
+ * @aclk: ACLK clock
+ * @clks: All other clocks
+ */
+struct k210_sysclk {
+	struct device_node		*node;
+	void __iomem			*regs;
+	spinlock_t			clk_lock;
+	struct k210_pll			plls[K210_PLL_NUM];
+	struct clk_hw			aclk;
+	struct k210_clk			clks[K210_NUM_CLKS];
+};
+
+#define to_k210_sysclk(_hw)	container_of(_hw, struct k210_sysclk, aclk)
+
+/*
+ * Set ACLK parent selector: 0 for IN0, 1 for PLL0.
+ */
+static void k210_aclk_set_selector(void __iomem *regs, u8 sel)
+{
+	u32 reg = readl(regs + K210_SYSCTL_SEL0);
+
+	if (sel)
+		reg |= K210_ACLK_SEL;
+	else
+		reg &= K210_ACLK_SEL;
+	writel(reg, regs + K210_SYSCTL_SEL0);
+}
+
+static void k210_init_pll(void __iomem *regs, enum k210_pll_id pllid,
+			  struct k210_pll *pll)
+{
+	pll->id = pllid;
+	pll->reg = regs + k210_plls_cfg[pllid].reg;
+	pll->lock = regs + K210_SYSCTL_PLL_LOCK;
+	pll->lock_shift = k210_plls_cfg[pllid].lock_shift;
+	pll->lock_width = k210_plls_cfg[pllid].lock_width;
+}
+
+static void k210_pll_wait_for_lock(struct k210_pll *pll)
+{
+	u32 reg, mask = GENMASK(pll->lock_shift + pll->lock_width - 1,
+				pll->lock_shift);
+
+	while (true) {
+		reg = readl(pll->lock);
+		if ((reg & mask) == mask)
+			break;
+
+		reg |= BIT(pll->lock_shift + K210_PLL_CLEAR_SLIP);
+		writel(reg, pll->lock);
+	}
+}
+
+static bool k210_pll_hw_is_enabled(struct k210_pll *pll)
+{
+	u32 reg = readl(pll->reg);
+	u32 mask = K210_PLL_PWRD | K210_PLL_EN;
+
+	if (reg & K210_PLL_RESET)
+		return false;
+
+	return (reg & mask) == mask;
+}
+
+static void k210_pll_enable_hw(void __iomem *regs, struct k210_pll *pll)
+{
+	struct k210_pll_cfg *pll_cfg = &k210_plls_cfg[pll->id];
+	u32 reg;
+
+	if (k210_pll_hw_is_enabled(pll))
+		return;
+
+	/*
+	 * For PLL0, we need to re-parent ACLK to IN0 to keep the CPU cores and
+	 * SRAM running.
+	 */
+	if (pll->id == K210_PLL0)
+		k210_aclk_set_selector(regs, 0);
+
+	/* Set PLL factors */
+	reg = readl(pll->reg);
+	reg &= ~GENMASK(19, 0);
+	reg |= FIELD_PREP(K210_PLL_CLKR, pll_cfg->r);
+	reg |= FIELD_PREP(K210_PLL_CLKF, pll_cfg->f);
+	reg |= FIELD_PREP(K210_PLL_CLKOD, pll_cfg->od);
+	reg |= FIELD_PREP(K210_PLL_BWADJ, pll_cfg->bwadj);
+	reg |= K210_PLL_PWRD;
+	writel(reg, pll->reg);
+
+	/*
+	 * Reset the PLL: ensure reset is low before asserting it.
+	 * The magic NOPs come from the Kendryte reference SDK.
+	 */
+	reg &= ~K210_PLL_RESET;
+	writel(reg, pll->reg);
+	reg |= K210_PLL_RESET;
+	writel(reg, pll->reg);
+	nop();
+	nop();
+	reg &= ~K210_PLL_RESET;
+	writel(reg, pll->reg);
+
+	k210_pll_wait_for_lock(pll);
+
+	reg &= ~K210_PLL_BYPASS;
+	reg |= K210_PLL_EN;
+	writel(reg, pll->reg);
+
+	if (pll->id == K210_PLL0)
+		k210_aclk_set_selector(regs, 1);
+}
+
+static int k210_pll_enable(struct clk_hw *hw)
+{
+	struct k210_pll *pll = to_k210_pll(hw);
+	struct k210_sysclk *ksc = pll->ksc;
+	unsigned long flags;
+
+	spin_lock_irqsave(&ksc->clk_lock, flags);
+
+	k210_pll_enable_hw(ksc->regs, pll);
+
+	spin_unlock_irqrestore(&ksc->clk_lock, flags);
+
+	return 0;
+}
+
+static void k210_pll_disable(struct clk_hw *hw)
+{
+	struct k210_pll *pll = to_k210_pll(hw);
+	struct k210_sysclk *ksc = pll->ksc;
+	unsigned long flags;
+	u32 reg;
+
+	/*
+	 * Bypassing before powering off is important so child clocks do not
+	 * stop working. This is especially important for pll0, the indirect
+	 * parent of the cpu clock.
+	 */
+	spin_lock_irqsave(&ksc->clk_lock, flags);
+	reg = readl(pll->reg);
+	reg |= K210_PLL_BYPASS;
+	writel(reg, pll->reg);
+
+	reg &= ~K210_PLL_PWRD;
+	reg &= ~K210_PLL_EN;
+	writel(reg, pll->reg);
+	spin_unlock_irqrestore(&ksc->clk_lock, flags);
+}
+
+static int k210_pll_is_enabled(struct clk_hw *hw)
+{
+	return k210_pll_hw_is_enabled(to_k210_pll(hw));
+}
+
+static unsigned long k210_pll_get_rate(struct clk_hw *hw,
+				       unsigned long parent_rate)
+{
+	struct k210_pll *pll = to_k210_pll(hw);
+	u32 reg = readl(pll->reg);
+	u32 r, f, od;
+
+	if (reg & K210_PLL_BYPASS)
+		return parent_rate;
+
+	if (!(reg & K210_PLL_PWRD))
+		return 0;
+
+	r = FIELD_GET(K210_PLL_CLKR, reg) + 1;
+	f = FIELD_GET(K210_PLL_CLKF, reg) + 1;
+	od = FIELD_GET(K210_PLL_CLKOD, reg) + 1;
+
+	return (u64)parent_rate * f / (r * od);
+}
+
+static const struct clk_ops k210_pll_ops = {
+	.enable		= k210_pll_enable,
+	.disable	= k210_pll_disable,
+	.is_enabled	= k210_pll_is_enabled,
+	.recalc_rate	= k210_pll_get_rate,
+};
+
+static int k210_pll2_set_parent(struct clk_hw *hw, u8 index)
+{
+	struct k210_pll *pll = to_k210_pll(hw);
+	struct k210_sysclk *ksc = pll->ksc;
+	unsigned long flags;
+	u32 reg;
+
+	spin_lock_irqsave(&ksc->clk_lock, flags);
+
+	reg = readl(pll->reg);
+	reg &= ~K210_PLL_SEL;
+	reg |= FIELD_PREP(K210_PLL_SEL, index);
+	writel(reg, pll->reg);
+
+	spin_unlock_irqrestore(&ksc->clk_lock, flags);
+
+	return 0;
+}
+
+static u8 k210_pll2_get_parent(struct clk_hw *hw)
+{
+	struct k210_pll *pll = to_k210_pll(hw);
+	u32 reg = readl(pll->reg);
+
+	return FIELD_GET(K210_PLL_SEL, reg);
+}
+
+static const struct clk_ops k210_pll2_ops = {
+	.enable		= k210_pll_enable,
+	.disable	= k210_pll_disable,
+	.is_enabled	= k210_pll_is_enabled,
+	.recalc_rate	= k210_pll_get_rate,
+	.set_parent	= k210_pll2_set_parent,
+	.get_parent	= k210_pll2_get_parent,
+};
+
+static int k210_register_pll(struct k210_sysclk *ksc, const char *in0,
+			     enum k210_pll_id pllid, const char *name,
+			     int num_parents, const struct clk_ops *ops)
+{
+	struct k210_pll *pll = &ksc->plls[pllid];
+	struct clk_init_data init = {};
+	const struct clk_parent_data parent_data[] = {
+		{ .name = in0 },
+		{ .hw = &ksc->plls[K210_PLL0].hw },
+		{ .hw = &ksc->plls[K210_PLL1].hw },
+	};
+
+	init.name = name;
+	init.parent_data = parent_data;
+	init.num_parents = num_parents;
+	init.ops = ops;
+
+	pll->hw.init = &init;
+	pll->ksc = ksc;
+
+	return clk_hw_register(NULL, &pll->hw);
+}
+
+static int k210_register_plls(struct k210_sysclk *ksc, const char *in0)
+{
+	int i, ret;
+
+	for (i = 0; i < K210_PLL_NUM; i++)
+		k210_init_pll(ksc->regs, i, &ksc->plls[i]);
+
+	/* PLL0 and PLL1 only have IN0 as parent */
+	ret = k210_register_pll(ksc, in0, K210_PLL0, "pll0", 1, &k210_pll_ops);
+	if (ret) {
+		pr_err("%pOFP: register PLL0 failed\n", ksc->node);
+		return ret;
+	}
+	ret = k210_register_pll(ksc, in0, K210_PLL1, "pll1", 1, &k210_pll_ops);
+	if (ret) {
+		pr_err("%pOFP: register PLL1 failed\n", ksc->node);
+		return ret;
+	}
+
+	/* PLL2 has IN0, PLL0 and PLL1 as parents */
+	ret = k210_register_pll(ksc, in0, K210_PLL2, "pll2", 3, &k210_pll2_ops);
+	if (ret) {
+		pr_err("%pOFP: register PLL2 failed\n", ksc->node);
+		return ret;
+	}
+
+	return 0;
+}
+
+static int k210_aclk_set_parent(struct clk_hw *hw, u8 index)
+{
+	struct k210_sysclk *ksc = to_k210_sysclk(hw);
+	unsigned long flags;
+
+	spin_lock_irqsave(&ksc->clk_lock, flags);
+
+	k210_aclk_set_selector(ksc->regs, index);
+
+	spin_unlock_irqrestore(&ksc->clk_lock, flags);
+
+	return 0;
+}
+
+static u8 k210_aclk_get_parent(struct clk_hw *hw)
+{
+	struct k210_sysclk *ksc = to_k210_sysclk(hw);
+	u32 sel;
+
+	sel = readl(ksc->regs + K210_SYSCTL_SEL0) & K210_ACLK_SEL;
+
+	return sel ? 1 : 0;
+}
+
+static unsigned long k210_aclk_get_rate(struct clk_hw *hw,
+					unsigned long parent_rate)
+{
+	struct k210_sysclk *ksc = to_k210_sysclk(hw);
+	u32 reg = readl(ksc->regs + K210_SYSCTL_SEL0);
+	unsigned int shift;
+
+	if (!(reg & 0x1))
+		return parent_rate;
+
+	shift = FIELD_GET(K210_ACLK_DIV, reg);
+
+	return parent_rate / (2UL << shift);
+}
+
+static const struct clk_ops k210_aclk_ops = {
+	.set_parent	= k210_aclk_set_parent,
+	.get_parent	= k210_aclk_get_parent,
+	.recalc_rate	= k210_aclk_get_rate,
+};
+
+/*
+ * ACLK has IN0 and PLL0 as parents.
+ */
+static int k210_register_aclk(struct k210_sysclk *ksc, const char *in0)
+{
+	struct clk_init_data init = {};
+	const struct clk_parent_data parent_data[] = {
+		{ .name = in0 },
+		{ .hw = &ksc->plls[K210_PLL0].hw },
+	};
+	int ret;
+
+	init.name = "aclk";
+	init.parent_data = parent_data;
+	init.num_parents = 2;
+	init.ops = &k210_aclk_ops;
+	ksc->aclk.init = &init;
+
+	ret = clk_hw_register(NULL, &ksc->aclk);
+	if (ret) {
+		pr_err("%pOFP: register aclk failed\n", ksc->node);
+		return ret;
+	}
+
+	return 0;
+}
+
+#define to_k210_clk(_hw)	container_of(_hw, struct k210_clk, hw)
+
+static int k210_clk_enable(struct clk_hw *hw)
+{
+	struct k210_clk *kclk = to_k210_clk(hw);
+	struct k210_sysclk *ksc = kclk->ksc;
+	struct k210_clk_cfg *cfg = &k210_clk_cfgs[kclk->id];
+	unsigned long flags;
+	u32 reg;
+
+	if (!cfg->gate_reg)
+		return 0;
+
+	spin_lock_irqsave(&ksc->clk_lock, flags);
+	reg = readl(ksc->regs + cfg->gate_reg);
+	reg |= BIT(cfg->gate_bit);
+	writel(reg, ksc->regs + cfg->gate_reg);
+	spin_unlock_irqrestore(&ksc->clk_lock, flags);
+
+	return 0;
+}
+
+static void k210_clk_disable(struct clk_hw *hw)
+{
+	struct k210_clk *kclk = to_k210_clk(hw);
+	struct k210_sysclk *ksc = kclk->ksc;
+	struct k210_clk_cfg *cfg = &k210_clk_cfgs[kclk->id];
+	unsigned long flags;
+	u32 reg;
+
+	if (!cfg->gate_reg)
+		return;
+
+	spin_lock_irqsave(&ksc->clk_lock, flags);
+	reg = readl(ksc->regs + cfg->gate_reg);
+	reg &= ~BIT(cfg->gate_bit);
+	writel(reg, ksc->regs + cfg->gate_reg);
+	spin_unlock_irqrestore(&ksc->clk_lock, flags);
+}
+
+static int k210_clk_set_parent(struct clk_hw *hw, u8 index)
+{
+	struct k210_clk *kclk = to_k210_clk(hw);
+	struct k210_sysclk *ksc = kclk->ksc;
+	struct k210_clk_cfg *cfg = &k210_clk_cfgs[kclk->id];
+	unsigned long flags;
+	u32 reg;
+
+	spin_lock_irqsave(&ksc->clk_lock, flags);
+	reg = readl(ksc->regs + cfg->mux_reg);
+	if (index)
+		reg |= BIT(cfg->mux_bit);
+	else
+		reg &= ~BIT(cfg->mux_bit);
+	spin_unlock_irqrestore(&ksc->clk_lock, flags);
+
+	return 0;
+}
+
+static u8 k210_clk_get_parent(struct clk_hw *hw)
+{
+	struct k210_clk *kclk = to_k210_clk(hw);
+	struct k210_sysclk *ksc = kclk->ksc;
+	struct k210_clk_cfg *cfg = &k210_clk_cfgs[kclk->id];
+	unsigned long flags;
+	u32 reg, idx;
+
+	spin_lock_irqsave(&ksc->clk_lock, flags);
+	reg = readl(ksc->regs + cfg->mux_reg);
+	idx = (reg & BIT(cfg->mux_bit)) ? 1 : 0;
+	spin_unlock_irqrestore(&ksc->clk_lock, flags);
+
+	return idx;
+}
+
+static unsigned long k210_clk_get_rate(struct clk_hw *hw,
+				       unsigned long parent_rate)
+{
+	struct k210_clk *kclk = to_k210_clk(hw);
+	struct k210_sysclk *ksc = kclk->ksc;
+	struct k210_clk_cfg *cfg = &k210_clk_cfgs[kclk->id];
+	u32 reg, div_val;
+
+	if (!cfg->div_reg)
+		return parent_rate;
+
+	reg = readl(ksc->regs + cfg->div_reg);
+	div_val = (reg >> cfg->div_shift) & GENMASK(cfg->div_width - 1, 0);
+
+	switch (cfg->div_type) {
+	case K210_DIV_ONE_BASED:
+		return parent_rate / (div_val + 1);
+	case K210_DIV_DOUBLE_ONE_BASED:
+		return parent_rate / ((div_val + 1) * 2);
+	case K210_DIV_POWER_OF_TWO:
+		return parent_rate / (2UL << div_val);
+	case K210_DIV_NONE:
+	default:
+		return 0;
+	}
+}
+
+static const struct clk_ops k210_clk_mux_ops = {
+	.enable		= k210_clk_enable,
+	.disable	= k210_clk_disable,
+	.set_parent	= k210_clk_set_parent,
+	.get_parent	= k210_clk_get_parent,
+	.recalc_rate	= k210_clk_get_rate,
+};
+
+static const struct clk_ops k210_clk_ops = {
+	.enable		= k210_clk_enable,
+	.disable	= k210_clk_disable,
+	.recalc_rate	= k210_clk_get_rate,
+};
+
+static void k210_register_clk(struct k210_sysclk *ksc, int id,
+			      const struct clk_parent_data *parent_data,
+			      int num_parents, unsigned long flags)
+{
+	struct k210_clk *kclk = &ksc->clks[id];
+	struct clk_init_data init = {};
+	int ret;
+
+	init.name = k210_clk_cfgs[id].name;
+	init.flags = flags;
+	init.parent_data = parent_data;
+	init.num_parents = num_parents;
+	if (num_parents > 1)
+		init.ops = &k210_clk_mux_ops;
+	else
+		init.ops = &k210_clk_ops;
+
+	kclk->id = id;
+	kclk->ksc = ksc;
+	kclk->hw.init = &init;
+
+	ret = clk_hw_register(NULL, &kclk->hw);
+	if (ret) {
+		pr_err("%pOFP: register clock %s failed\n",
+		       ksc->node, k210_clk_cfgs[id].name);
+		kclk->id = -1;
+	}
+}
+
+/*
+ * All muxed clocks have IN0 and PLL0 as parents.
+ */
+static inline void k210_register_mux_clk(struct k210_sysclk *ksc,
+					 const char *in0, int id)
+{
+	const struct clk_parent_data parent_data[2] = {
+		{ .name = in0 },
+		{ .hw = &ksc->plls[K210_PLL0].hw },
+	};
+
+	k210_register_clk(ksc, id, parent_data, 2, 0);
+}
+
+static inline void k210_register_in0_child(struct k210_sysclk *ksc,
+					   const char *in0, int id)
+{
+	const struct clk_parent_data parent_data = {
+		.name = in0,
+	};
+
+	k210_register_clk(ksc, id, &parent_data, 1, 0);
+}
+
+static inline void k210_register_pll_child(struct k210_sysclk *ksc, int id,
+					   enum k210_pll_id pllid,
+					   unsigned long flags)
+{
+	const struct clk_parent_data parent_data = {
+		.hw = &ksc->plls[pllid].hw,
+	};
+
+	k210_register_clk(ksc, id, &parent_data, 1, flags);
+}
+
+static inline void k210_register_aclk_child(struct k210_sysclk *ksc, int id,
+					    unsigned long flags)
+{
+	const struct clk_parent_data parent_data = {
+		.hw = &ksc->aclk,
+	};
+
+	k210_register_clk(ksc, id, &parent_data, 1, flags);
+}
+
+static inline void k210_register_clk_child(struct k210_sysclk *ksc, int id,
+					   int parent_id)
+{
+	const struct clk_parent_data parent_data = {
+		.hw = &ksc->clks[parent_id].hw,
+	};
+
+	k210_register_clk(ksc, id, &parent_data, 1, 0);
+}
+
+static struct clk_hw *k210_clk_hw_onecell_get(struct of_phandle_args *clkspec,
+					      void *data)
+{
+	struct k210_sysclk *ksc = data;
+	unsigned int idx = clkspec->args[0];
+
+	if (idx >= K210_NUM_CLKS)
+		return ERR_PTR(-EINVAL);
+
+	return &ksc->clks[idx].hw;
+}
+
+static void __init k210_clk_init(struct device_node *np)
+{
+	struct device_node *sysctl_np;
+	struct k210_sysclk *ksc;
+	const char *in0;
+	int i, ret;
+
+	ksc = kzalloc(sizeof(*ksc), GFP_KERNEL);
+	if (!ksc)
+		return;
+
+	ksc->node = np;
+	spin_lock_init(&ksc->clk_lock);
+	sysctl_np = of_get_parent(np);
+	ksc->regs = of_iomap(sysctl_np, 0);
+	of_node_put(sysctl_np);
+	if (!ksc->regs) {
+		pr_err("%pOFP: failed to map registers\n", np);
+		return;
+	}
+
+	in0 = of_clk_get_parent_name(np, 0);
+	if (!in0) {
+		pr_err("%pOFP: undefined fixed-rate oscillator clock\n", np);
+		return;
+	}
+
+	ret = k210_register_plls(ksc, in0);
+	if (ret)
+		return;
+
+	ret = k210_register_aclk(ksc, in0);
+	if (ret)
+		return;
+
+	/*
+	 * Critical clocks: there are no consumers of the SRAM clocks,
+	 * including the AI clock for the third SRAM bank. The CPU clock
+	 * is only referenced by the uarths serial device and so would be
+	 * disabled if the serial console is disabled to switch to another
+	 * console. Mark all these clocks as critical so that they are never
+	 * disabled by the core clock management.
+	 */
+	k210_register_aclk_child(ksc, K210_CLK_CPU, CLK_IS_CRITICAL);
+	k210_register_aclk_child(ksc, K210_CLK_SRAM0, CLK_IS_CRITICAL);
+	k210_register_aclk_child(ksc, K210_CLK_SRAM1, CLK_IS_CRITICAL);
+	k210_register_pll_child(ksc, K210_CLK_AI, K210_PLL1, CLK_IS_CRITICAL);
+
+	/* Clocks with aclk as source */
+	k210_register_aclk_child(ksc, K210_CLK_DMA, 0);
+	k210_register_aclk_child(ksc, K210_CLK_FFT, 0);
+	k210_register_aclk_child(ksc, K210_CLK_ROM, 0);
+	k210_register_aclk_child(ksc, K210_CLK_DVP, 0);
+	k210_register_aclk_child(ksc, K210_CLK_APB0, 0);
+	k210_register_aclk_child(ksc, K210_CLK_APB1, 0);
+	k210_register_aclk_child(ksc, K210_CLK_APB2, 0);
+
+	/* Clocks with PLL0 as source */
+	k210_register_pll_child(ksc, K210_CLK_SPI0, K210_PLL0, 0);
+	k210_register_pll_child(ksc, K210_CLK_SPI1, K210_PLL0, 0);
+	k210_register_pll_child(ksc, K210_CLK_SPI2, K210_PLL0, 0);
+	k210_register_pll_child(ksc, K210_CLK_I2C0, K210_PLL0, 0);
+	k210_register_pll_child(ksc, K210_CLK_I2C1, K210_PLL0, 0);
+	k210_register_pll_child(ksc, K210_CLK_I2C2, K210_PLL0, 0);
+
+	/* Clocks with PLL2 as source */
+	k210_register_pll_child(ksc, K210_CLK_I2S0, K210_PLL2, 0);
+	k210_register_pll_child(ksc, K210_CLK_I2S1, K210_PLL2, 0);
+	k210_register_pll_child(ksc, K210_CLK_I2S2, K210_PLL2, 0);
+	k210_register_pll_child(ksc, K210_CLK_I2S0_M, K210_PLL2, 0);
+	k210_register_pll_child(ksc, K210_CLK_I2S1_M, K210_PLL2, 0);
+	k210_register_pll_child(ksc, K210_CLK_I2S2_M, K210_PLL2, 0);
+
+	/* Clocks with IN0 as source */
+	k210_register_in0_child(ksc, in0, K210_CLK_WDT0);
+	k210_register_in0_child(ksc, in0, K210_CLK_WDT1);
+	k210_register_in0_child(ksc, in0, K210_CLK_RTC);
+
+	/* Clocks with APB0 as source */
+	k210_register_clk_child(ksc, K210_CLK_GPIO, K210_CLK_APB0);
+	k210_register_clk_child(ksc, K210_CLK_UART1, K210_CLK_APB0);
+	k210_register_clk_child(ksc, K210_CLK_UART2, K210_CLK_APB0);
+	k210_register_clk_child(ksc, K210_CLK_UART3, K210_CLK_APB0);
+	k210_register_clk_child(ksc, K210_CLK_FPIOA, K210_CLK_APB0);
+	k210_register_clk_child(ksc, K210_CLK_SHA, K210_CLK_APB0);
+
+	/* Clocks with APB1 as source */
+	k210_register_clk_child(ksc, K210_CLK_AES, K210_CLK_APB1);
+	k210_register_clk_child(ksc, K210_CLK_OTP, K210_CLK_APB1);
+
+	/* Mux clocks with in0 or pll0 as source */
+	k210_register_mux_clk(ksc, in0, K210_CLK_SPI3);
+	k210_register_mux_clk(ksc, in0, K210_CLK_TIMER0);
+	k210_register_mux_clk(ksc, in0, K210_CLK_TIMER1);
+	k210_register_mux_clk(ksc, in0, K210_CLK_TIMER2);
+
+	/* Check for registration errors */
+	for (i = 0; i < K210_NUM_CLKS; i++) {
+		if (ksc->clks[i].id != i)
+			return;
+	}
+
+	ret = of_clk_add_hw_provider(np, k210_clk_hw_onecell_get, ksc);
+	if (ret) {
+		pr_err("%pOFP: add clock provider failed %d\n", np, ret);
+		return;
+	}
+
+	pr_info("%pOFP: CPU running at %lu MHz\n",
+		np, clk_hw_get_rate(&ksc->clks[K210_CLK_CPU].hw) / 1000000);
+}
+
+CLK_OF_DECLARE(k210_clk, "canaan,k210-clk", k210_clk_init);
+
+/*
+ * Enable PLL1 to be able to use the AI SRAM.
+ */
+void __init k210_clk_early_init(void __iomem *regs)
+{
+	struct k210_pll pll1;
+
+	/* Make sure ACLK selector is set to PLL0 */
+	k210_aclk_set_selector(regs, 1);
+
+	/* Startup PLL1 to enable the aisram bank for general memory use */
+	k210_init_pll(regs, K210_PLL1, &pll1);
+	k210_pll_enable_hw(regs, &pll1);
+}
diff --git a/drivers/soc/canaan/Kconfig b/drivers/soc/canaan/Kconfig
index 5232d13f07e5..8179b69518b4 100644
--- a/drivers/soc/canaan/Kconfig
+++ b/drivers/soc/canaan/Kconfig
@@ -1,14 +1,12 @@
 # SPDX-License-Identifier: GPL-2.0
 
-if SOC_CANAAN
-
-config K210_SYSCTL
+config SOC_K210_SYSCTL
 	bool "Canaan Kendryte K210 SoC system controller"
-	default y
-	depends on RISCV
+	depends on RISCV && SOC_CANAAN && OF
+	default SOC_CANAAN
+        select PM
+        select SIMPLE_PM_BUS
+        select SYSCON
+        select MFD_SYSCON
 	help
-	  Enables controlling the K210 various clocks and to enable
-	  general purpose use of the extra 2MB of SRAM normally
-	  reserved for the AI engine.
-
-endif
+	  Canaan Kendryte K210 SoC system controller driver.
diff --git a/drivers/soc/canaan/Makefile b/drivers/soc/canaan/Makefile
index 002d9ce95c0d..570280ad7967 100644
--- a/drivers/soc/canaan/Makefile
+++ b/drivers/soc/canaan/Makefile
@@ -1,3 +1,3 @@
 # SPDX-License-Identifier: GPL-2.0
 
-obj-$(CONFIG_K210_SYSCTL)	+= k210-sysctl.o
+obj-$(CONFIG_SOC_K210_SYSCTL)	+= k210-sysctl.o
diff --git a/drivers/soc/canaan/k210-sysctl.c b/drivers/soc/canaan/k210-sysctl.c
index 60b474c33d45..27a346c406bc 100644
--- a/drivers/soc/canaan/k210-sysctl.c
+++ b/drivers/soc/canaan/k210-sysctl.c
@@ -3,165 +3,45 @@
  * Copyright (c) 2019 Christoph Hellwig.
  * Copyright (c) 2019 Western Digital Corporation or its affiliates.
  */
-#include <linux/types.h>
 #include <linux/io.h>
-#include <linux/of.h>
 #include <linux/platform_device.h>
-#include <linux/clk-provider.h>
-#include <linux/clkdev.h>
-#include <linux/bitfield.h>
+#include <linux/of_platform.h>
+#include <linux/clk.h>
 #include <asm/soc.h>
 
 #include <soc/canaan/k210-sysctl.h>
 
-#define K210_SYSCTL_CLK0_FREQ		26000000UL
-
-/* Registers base address */
-#define K210_SYSCTL_SYSCTL_BASE_ADDR	0x50440000ULL
-
-/* Register bits */
-/* K210_SYSCTL_PLL1: clkr: 4bits, clkf1: 6bits, clkod: 4bits, bwadj: 4bits */
-#define PLL_RESET		(1 << 20)
-#define PLL_PWR			(1 << 21)
-#define PLL_BYPASS		(1 << 23)
-#define PLL_OUT_EN		(1 << 25)
-/* K210_SYSCTL_PLL_LOCK */
-#define PLL1_LOCK1		(1 << 8)
-#define PLL1_LOCK2		(1 << 9)
-#define PLL1_SLIP_CLEAR		(1 << 10)
-/* K210_SYSCTL_SEL0 */
-#define CLKSEL_ACLK		(1 << 0)
-/* K210_SYSCTL_CLKEN_CENT */
-#define CLKEN_CPU		(1 << 0)
-#define CLKEN_SRAM0		(1 << 1)
-#define CLKEN_SRAM1		(1 << 2)
-/* K210_SYSCTL_EN_PERI */
-#define CLKEN_ROM		(1 << 0)
-#define CLKEN_TIMER0		(1 << 21)
-#define CLKEN_RTC		(1 << 29)
-
-struct k210_sysctl {
-	void __iomem		*regs;
-	struct clk_hw		hw;
-};
-
-static void k210_set_bits(u32 val, void __iomem *reg)
-{
-	writel(readl(reg) | val, reg);
-}
-
-static void k210_clear_bits(u32 val, void __iomem *reg)
-{
-	writel(readl(reg) & ~val, reg);
-}
-
-static void k210_pll1_enable(void __iomem *regs)
-{
-	u32 val;
-
-	val = readl(regs + K210_SYSCTL_PLL1);
-	val &= ~GENMASK(19, 0);				/* clkr1 = 0 */
-	val |= FIELD_PREP(GENMASK(9, 4), 0x3B);		/* clkf1 = 59 */
-	val |= FIELD_PREP(GENMASK(13, 10), 0x3);	/* clkod1 = 3 */
-	val |= FIELD_PREP(GENMASK(19, 14), 0x3B);	/* bwadj1 = 59 */
-	writel(val, regs + K210_SYSCTL_PLL1);
-
-	k210_clear_bits(PLL_BYPASS, regs + K210_SYSCTL_PLL1);
-	k210_set_bits(PLL_PWR, regs + K210_SYSCTL_PLL1);
-
-	/*
-	 * Reset the pll. The magic NOPs come from the Kendryte reference SDK.
-	 */
-	k210_clear_bits(PLL_RESET, regs + K210_SYSCTL_PLL1);
-	k210_set_bits(PLL_RESET, regs + K210_SYSCTL_PLL1);
-	nop();
-	nop();
-	k210_clear_bits(PLL_RESET, regs + K210_SYSCTL_PLL1);
-
-	for (;;) {
-		val = readl(regs + K210_SYSCTL_PLL_LOCK);
-		if (val & PLL1_LOCK2)
-			break;
-		writel(val | PLL1_SLIP_CLEAR, regs + K210_SYSCTL_PLL_LOCK);
-	}
-
-	k210_set_bits(PLL_OUT_EN, regs + K210_SYSCTL_PLL1);
-}
-
-static unsigned long k210_sysctl_clk_recalc_rate(struct clk_hw *hw,
-		unsigned long parent_rate)
-{
-	struct k210_sysctl *s = container_of(hw, struct k210_sysctl, hw);
-	u32 clksel0, pll0;
-	u64 pll0_freq, clkr0, clkf0, clkod0;
-
-	/*
-	 * If the clock selector is not set, use the base frequency.
-	 * Otherwise, use PLL0 frequency with a frequency divisor.
-	 */
-	clksel0 = readl(s->regs + K210_SYSCTL_SEL0);
-	if (!(clksel0 & CLKSEL_ACLK))
-		return K210_SYSCTL_CLK0_FREQ;
-
-	/*
-	 * Get PLL0 frequency:
-	 * freq = base frequency * clkf0 / (clkr0 * clkod0)
-	 */
-	pll0 = readl(s->regs + K210_SYSCTL_PLL0);
-	clkr0 = 1 + FIELD_GET(GENMASK(3, 0), pll0);
-	clkf0 = 1 + FIELD_GET(GENMASK(9, 4), pll0);
-	clkod0 = 1 + FIELD_GET(GENMASK(13, 10), pll0);
-	pll0_freq = clkf0 * K210_SYSCTL_CLK0_FREQ / (clkr0 * clkod0);
-
-	/* Get the frequency divisor from the clock selector */
-	return pll0_freq / (2ULL << FIELD_GET(0x00000006, clksel0));
-}
-
-static const struct clk_ops k210_sysctl_clk_ops = {
-	.recalc_rate	= k210_sysctl_clk_recalc_rate,
-};
-
-static const struct clk_init_data k210_clk_init_data = {
-	.name		= "k210-sysctl-pll1",
-	.ops		= &k210_sysctl_clk_ops,
-};
-
 static int k210_sysctl_probe(struct platform_device *pdev)
 {
-	struct k210_sysctl *s;
-	int error;
-
-	pr_info("Kendryte K210 SoC sysctl\n");
-
-	s = devm_kzalloc(&pdev->dev, sizeof(*s), GFP_KERNEL);
-	if (!s)
-		return -ENOMEM;
-
-	s->regs = devm_ioremap_resource(&pdev->dev,
-			platform_get_resource(pdev, IORESOURCE_MEM, 0));
-	if (IS_ERR(s->regs))
-		return PTR_ERR(s->regs);
-
-	s->hw.init = &k210_clk_init_data;
-	error = devm_clk_hw_register(&pdev->dev, &s->hw);
-	if (error) {
-		dev_err(&pdev->dev, "failed to register clk");
-		return error;
+	struct device *dev = &pdev->dev;
+	struct clk *pclk;
+	int ret;
+
+	dev_info(dev, "K210 system controller\n");
+
+	/* Get power bus clock */
+	pclk = devm_clk_get(dev, NULL);
+	if (IS_ERR(pclk))
+		return dev_err_probe(dev, PTR_ERR(pclk),
+				     "Get bus clock failed\n");
+
+	ret = clk_prepare_enable(pclk);
+	if (ret) {
+		dev_err(dev, "Enable bus clock failed\n");
+		return ret;
 	}
 
-	error = devm_of_clk_add_hw_provider(&pdev->dev, of_clk_hw_simple_get,
-					    &s->hw);
-	if (error) {
-		dev_err(&pdev->dev, "adding clk provider failed\n");
-		return error;
-	}
+	/* Populate children */
+	ret = devm_of_platform_populate(dev);
+	if (ret)
+		dev_err(dev, "Populate platform failed %d\n", ret);
 
-	return 0;
+	return ret;
 }
 
 static const struct of_device_id k210_sysctl_of_match[] = {
-	{ .compatible = "kendryte,k210-sysctl", },
-	{}
+	{ .compatible = "canaan,k210-sysctl", },
+	{ /* sentinel */ },
 };
 
 static struct platform_driver k210_sysctl_driver = {
@@ -171,12 +51,13 @@ static struct platform_driver k210_sysctl_driver = {
 	},
 	.probe			= k210_sysctl_probe,
 };
+builtin_platform_driver(k210_sysctl_driver);
 
-static int __init k210_sysctl_init(void)
-{
-	return platform_driver_register(&k210_sysctl_driver);
-}
-core_initcall(k210_sysctl_init);
+/*
+ * System controller registers base address and size.
+ */
+#define K210_SYSCTL_BASE_ADDR	0x50440000ULL
+#define K210_SYSCTL_BASE_SIZE	0x1000
 
 /*
  * This needs to be called very early during initialization, given that
@@ -184,24 +65,14 @@ core_initcall(k210_sysctl_init);
  */
 static void __init k210_soc_early_init(const void *fdt)
 {
-	void __iomem *regs;
-
-	regs = ioremap(K210_SYSCTL_SYSCTL_BASE_ADDR, 0x1000);
-	if (!regs)
-		panic("K210 sysctl ioremap");
-
-	/* Enable PLL1 to make the KPU SRAM useable */
-	k210_pll1_enable(regs);
-
-	k210_set_bits(PLL_OUT_EN, regs + K210_SYSCTL_PLL0);
+	void __iomem *sysctl_base;
 
-	k210_set_bits(CLKEN_CPU | CLKEN_SRAM0 | CLKEN_SRAM1,
-		      regs + K210_SYSCTL_EN_CENT);
-	k210_set_bits(CLKEN_ROM | CLKEN_TIMER0 | CLKEN_RTC,
-		      regs + K210_SYSCTL_EN_PERI);
+	sysctl_base = ioremap(K210_SYSCTL_BASE_ADDR, K210_SYSCTL_BASE_SIZE);
+	if (!sysctl_base)
+		panic("k210-sysctl: ioremap failed");
 
-	k210_set_bits(CLKSEL_ACLK, regs + K210_SYSCTL_SEL0);
+	k210_clk_early_init(sysctl_base);
 
-	iounmap(regs);
+	iounmap(sysctl_base);
 }
-SOC_EARLY_INIT_DECLARE(generic_k210, "kendryte,k210", k210_soc_early_init);
+SOC_EARLY_INIT_DECLARE(k210_soc, "canaan,kendryte-k210", k210_soc_early_init);
diff --git a/include/soc/canaan/k210-sysctl.h b/include/soc/canaan/k210-sysctl.h
index 2e037db68f35..0c2b2c2dabca 100644
--- a/include/soc/canaan/k210-sysctl.h
+++ b/include/soc/canaan/k210-sysctl.h
@@ -38,4 +38,6 @@
 #define K210_SYSCTL_DMA_SEL1	0x68 /* DMA handshake selector 1 */
 #define K210_SYSCTL_POWER_SEL	0x6C /* IO Power Mode Select controller */
 
+void k210_clk_early_init(void __iomem *regs);
+
 #endif
-- 
2.29.2


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply related	[flat|nested] 81+ messages in thread

* [PATCH v14 02/16] dt-bindings: add Canaan boards compatible strings
  2021-02-02 10:36 [PATCH v14 00/16] RISC-V Kendryte K210 support improvements Damien Le Moal
@ 2021-02-02 10:36   ` Damien Le Moal
  2021-02-02 10:36   ` Damien Le Moal
                     ` (14 subsequent siblings)
  15 siblings, 0 replies; 81+ messages in thread
From: Damien Le Moal @ 2021-02-02 10:36 UTC (permalink / raw)
  To: Palmer Dabbelt, linux-riscv
  Cc: Atish Patra, Anup Patel, Sean Anderson, Rob Herring, devicetree

Introduce the file riscv/canaan.yaml to document compatible strings
related to the Canaan Kendryte K210 SoC. The compatible string
"canaan,kendryte-k210" used to indicate the use of this SoC to the
early SoC init code is added. This new file also defines the compatible
strings of all supported boards based on this SoC.

Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
---
 .../devicetree/bindings/riscv/canaan.yaml     | 47 +++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/riscv/canaan.yaml

diff --git a/Documentation/devicetree/bindings/riscv/canaan.yaml b/Documentation/devicetree/bindings/riscv/canaan.yaml
new file mode 100644
index 000000000000..f8f3f286bd55
--- /dev/null
+++ b/Documentation/devicetree/bindings/riscv/canaan.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/riscv/canaan.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Canaan SoC-based boards
+
+maintainers:
+  - Damien Le Moal <damien.lemoal@wdc.com>
+
+description:
+  Canaan Kendryte K210 SoC-based boards
+
+properties:
+  $nodename:
+    const: '/'
+  compatible:
+    oneOf:
+      - items:
+          - const: sipeed,maix-bit
+          - const: sipeed,maix-bitm
+          - const: canaan,kendryte-k210
+
+      - items:
+          - const: sipeed,maix-go
+          - const: canaan,kendryte-k210
+
+      - items:
+          - const: sipeed,maix-dock-m1
+          - const: sipeed,maix-dock-m1w
+          - const: canaan,kendryte-k210
+
+      - items:
+          - const: sipeed,maixduino
+          - const: canaan,kendryte-k210
+
+      - items:
+          - const: canaan,kendryte-kd233
+          - const: canaan,kendryte-k210
+
+      - items:
+          - const: canaan,kendryte-k210
+
+additionalProperties: true
+
+...
-- 
2.29.2


^ permalink raw reply related	[flat|nested] 81+ messages in thread

* [PATCH v14 02/16] dt-bindings: add Canaan boards compatible strings
@ 2021-02-02 10:36   ` Damien Le Moal
  0 siblings, 0 replies; 81+ messages in thread
From: Damien Le Moal @ 2021-02-02 10:36 UTC (permalink / raw)
  To: Palmer Dabbelt, linux-riscv
  Cc: Atish Patra, devicetree, Anup Patel, Rob Herring, Sean Anderson

Introduce the file riscv/canaan.yaml to document compatible strings
related to the Canaan Kendryte K210 SoC. The compatible string
"canaan,kendryte-k210" used to indicate the use of this SoC to the
early SoC init code is added. This new file also defines the compatible
strings of all supported boards based on this SoC.

Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
---
 .../devicetree/bindings/riscv/canaan.yaml     | 47 +++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/riscv/canaan.yaml

diff --git a/Documentation/devicetree/bindings/riscv/canaan.yaml b/Documentation/devicetree/bindings/riscv/canaan.yaml
new file mode 100644
index 000000000000..f8f3f286bd55
--- /dev/null
+++ b/Documentation/devicetree/bindings/riscv/canaan.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/riscv/canaan.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Canaan SoC-based boards
+
+maintainers:
+  - Damien Le Moal <damien.lemoal@wdc.com>
+
+description:
+  Canaan Kendryte K210 SoC-based boards
+
+properties:
+  $nodename:
+    const: '/'
+  compatible:
+    oneOf:
+      - items:
+          - const: sipeed,maix-bit
+          - const: sipeed,maix-bitm
+          - const: canaan,kendryte-k210
+
+      - items:
+          - const: sipeed,maix-go
+          - const: canaan,kendryte-k210
+
+      - items:
+          - const: sipeed,maix-dock-m1
+          - const: sipeed,maix-dock-m1w
+          - const: canaan,kendryte-k210
+
+      - items:
+          - const: sipeed,maixduino
+          - const: canaan,kendryte-k210
+
+      - items:
+          - const: canaan,kendryte-kd233
+          - const: canaan,kendryte-k210
+
+      - items:
+          - const: canaan,kendryte-k210
+
+additionalProperties: true
+
+...
-- 
2.29.2


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply related	[flat|nested] 81+ messages in thread

* [PATCH v14 03/16] dt-bindings: update risc-v cpu properties
  2021-02-02 10:36 [PATCH v14 00/16] RISC-V Kendryte K210 support improvements Damien Le Moal
@ 2021-02-02 10:36   ` Damien Le Moal
  2021-02-02 10:36   ` Damien Le Moal
                     ` (14 subsequent siblings)
  15 siblings, 0 replies; 81+ messages in thread
From: Damien Le Moal @ 2021-02-02 10:36 UTC (permalink / raw)
  To: Palmer Dabbelt, linux-riscv
  Cc: Atish Patra, Anup Patel, Sean Anderson, Paul Walmsley,
	Rob Herring, devicetree

The Canaan Kendryte K210 SoC CPU cores are based on a rocket chip
version using a draft verion of the RISC-V ISA specifications. To avoid
any confusion with CPU cores using stable specifications, add the
compatible string "canaan,k210" for this SoC CPU cores.

Also add the "riscv,none" value to the mmu-type property to allow a DT
to indicate that the CPU being described does not have an MMU or that
it has an MMU that is not usable (which is the case for the K210 SoC).

Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
---
 Documentation/devicetree/bindings/riscv/cpus.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
index eb6843f69f7c..e534f6a7cfa1 100644
--- a/Documentation/devicetree/bindings/riscv/cpus.yaml
+++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
@@ -39,6 +39,7 @@ properties:
               - sifive,u74
               - sifive,u5
               - sifive,u7
+              - canaan,k210
           - const: riscv
       - const: riscv    # Simulator only
     description:
@@ -56,6 +57,7 @@ properties:
       - riscv,sv32
       - riscv,sv39
       - riscv,sv48
+      - riscv,none
 
   riscv,isa:
     description:
-- 
2.29.2


^ permalink raw reply related	[flat|nested] 81+ messages in thread

* [PATCH v14 03/16] dt-bindings: update risc-v cpu properties
@ 2021-02-02 10:36   ` Damien Le Moal
  0 siblings, 0 replies; 81+ messages in thread
From: Damien Le Moal @ 2021-02-02 10:36 UTC (permalink / raw)
  To: Palmer Dabbelt, linux-riscv
  Cc: devicetree, Rob Herring, Anup Patel, Sean Anderson, Atish Patra,
	Paul Walmsley

The Canaan Kendryte K210 SoC CPU cores are based on a rocket chip
version using a draft verion of the RISC-V ISA specifications. To avoid
any confusion with CPU cores using stable specifications, add the
compatible string "canaan,k210" for this SoC CPU cores.

Also add the "riscv,none" value to the mmu-type property to allow a DT
to indicate that the CPU being described does not have an MMU or that
it has an MMU that is not usable (which is the case for the K210 SoC).

Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
---
 Documentation/devicetree/bindings/riscv/cpus.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
index eb6843f69f7c..e534f6a7cfa1 100644
--- a/Documentation/devicetree/bindings/riscv/cpus.yaml
+++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
@@ -39,6 +39,7 @@ properties:
               - sifive,u74
               - sifive,u5
               - sifive,u7
+              - canaan,k210
           - const: riscv
       - const: riscv    # Simulator only
     description:
@@ -56,6 +57,7 @@ properties:
       - riscv,sv32
       - riscv,sv39
       - riscv,sv48
+      - riscv,none
 
   riscv,isa:
     description:
-- 
2.29.2


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply related	[flat|nested] 81+ messages in thread

* [PATCH v14 04/16] dt-bindings: update sifive plic compatible string
  2021-02-02 10:36 [PATCH v14 00/16] RISC-V Kendryte K210 support improvements Damien Le Moal
@ 2021-02-02 10:36   ` Damien Le Moal
  2021-02-02 10:36   ` Damien Le Moal
                     ` (14 subsequent siblings)
  15 siblings, 0 replies; 81+ messages in thread
From: Damien Le Moal @ 2021-02-02 10:36 UTC (permalink / raw)
  To: Palmer Dabbelt, linux-riscv
  Cc: Atish Patra, Anup Patel, Sean Anderson, Paul Walmsley,
	Rob Herring, devicetree

Add the compatible string "canaan,k210-plic" to the Sifive plic bindings
to indicate the use of the "sifive,plic-1.0.0" IP block in the Canaan
Kendryte K210 SoC. The description is also updated to reflect this
change, that is, that SoCs from other vendors may also use this plic
implementation.

Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
---
 .../sifive,plic-1.0.0.yaml                    | 20 ++++++++++++-------
 1 file changed, 13 insertions(+), 7 deletions(-)

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 b9a61c9f7530..3db86d329e1e 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
@@ -8,10 +8,11 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
 title: SiFive Platform-Level Interrupt Controller (PLIC)
 
 description:
-  SiFive SOCs include an implementation of the Platform-Level Interrupt Controller
-  (PLIC) high-level specification in the RISC-V Privileged Architecture
-  specification. The PLIC connects all external interrupts in the system to all
-  hart contexts in the system, via the external interrupt source in each hart.
+  SiFive other RISC-V and other SoCs include an implementation of the
+  Platform-Level Interrupt Controller (PLIC) high-level specification in
+  the RISC-V Privileged Architecture specification. The PLIC connects all
+  external interrupts in the system to all hart contexts in the system, via
+  the external interrupt source in each hart.
 
   A hart context is a privilege mode in a hardware execution thread. For example,
   in an 4 core system with 2-way SMT, you have 8 harts and probably at least two
@@ -41,9 +42,14 @@ maintainers:
 
 properties:
   compatible:
-    items:
-      - const: sifive,fu540-c000-plic
-      - const: sifive,plic-1.0.0
+    oneOf:
+      - items:
+          - const: sifive,fu540-c000-plic
+          - const: sifive,plic-1.0.0
+
+      - items:
+          - const: canaan,k210-plic
+          - const: sifive,plic-1.0.0
 
   reg:
     maxItems: 1
-- 
2.29.2


^ permalink raw reply related	[flat|nested] 81+ messages in thread

* [PATCH v14 04/16] dt-bindings: update sifive plic compatible string
@ 2021-02-02 10:36   ` Damien Le Moal
  0 siblings, 0 replies; 81+ messages in thread
From: Damien Le Moal @ 2021-02-02 10:36 UTC (permalink / raw)
  To: Palmer Dabbelt, linux-riscv
  Cc: devicetree, Rob Herring, Anup Patel, Sean Anderson, Atish Patra,
	Paul Walmsley

Add the compatible string "canaan,k210-plic" to the Sifive plic bindings
to indicate the use of the "sifive,plic-1.0.0" IP block in the Canaan
Kendryte K210 SoC. The description is also updated to reflect this
change, that is, that SoCs from other vendors may also use this plic
implementation.

Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
---
 .../sifive,plic-1.0.0.yaml                    | 20 ++++++++++++-------
 1 file changed, 13 insertions(+), 7 deletions(-)

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 b9a61c9f7530..3db86d329e1e 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
@@ -8,10 +8,11 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
 title: SiFive Platform-Level Interrupt Controller (PLIC)
 
 description:
-  SiFive SOCs include an implementation of the Platform-Level Interrupt Controller
-  (PLIC) high-level specification in the RISC-V Privileged Architecture
-  specification. The PLIC connects all external interrupts in the system to all
-  hart contexts in the system, via the external interrupt source in each hart.
+  SiFive other RISC-V and other SoCs include an implementation of the
+  Platform-Level Interrupt Controller (PLIC) high-level specification in
+  the RISC-V Privileged Architecture specification. The PLIC connects all
+  external interrupts in the system to all hart contexts in the system, via
+  the external interrupt source in each hart.
 
   A hart context is a privilege mode in a hardware execution thread. For example,
   in an 4 core system with 2-way SMT, you have 8 harts and probably at least two
@@ -41,9 +42,14 @@ maintainers:
 
 properties:
   compatible:
-    items:
-      - const: sifive,fu540-c000-plic
-      - const: sifive,plic-1.0.0
+    oneOf:
+      - items:
+          - const: sifive,fu540-c000-plic
+          - const: sifive,plic-1.0.0
+
+      - items:
+          - const: canaan,k210-plic
+          - const: sifive,plic-1.0.0
 
   reg:
     maxItems: 1
-- 
2.29.2


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply related	[flat|nested] 81+ messages in thread

* [PATCH v14 05/16] dt-bindings: update sifive clint compatible string
  2021-02-02 10:36 [PATCH v14 00/16] RISC-V Kendryte K210 support improvements Damien Le Moal
@ 2021-02-02 10:36   ` Damien Le Moal
  2021-02-02 10:36   ` Damien Le Moal
                     ` (14 subsequent siblings)
  15 siblings, 0 replies; 81+ messages in thread
From: Damien Le Moal @ 2021-02-02 10:36 UTC (permalink / raw)
  To: Palmer Dabbelt, linux-riscv
  Cc: Atish Patra, Anup Patel, Sean Anderson, Rob Herring, devicetree

Add the "canaan,k210-clint" compatible string to the Sifive clint
bindings to indicate the use of the "sifive,clint0" IP block in the
Canaan Kendryte K210 SoC. The description of the compatible string
property is also updated to reflect this addition.

Cc: Anup Patel <anup.patel@wdc.com>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
---
 .../bindings/timer/sifive,clint.yaml          | 19 +++++++++++++------
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/timer/sifive,clint.yaml b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
index 2a0e9cd9fbcf..1a7d582a208f 100644
--- a/Documentation/devicetree/bindings/timer/sifive,clint.yaml
+++ b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
@@ -22,16 +22,23 @@ description:
 
 properties:
   compatible:
-    items:
-      - const: sifive,fu540-c000-clint
-      - const: sifive,clint0
+    oneOf:
+      - items:
+          - const: sifive,fu540-c000-clint
+          - const: sifive,clint0
+
+      - items:
+          - const: canaan,k210-clint
+          - const: sifive,clint0
 
     description:
-      Should be "sifive,<chip>-clint" and "sifive,clint<version>".
+      Should be "<vendor>,<chip>-clint" and "sifive,clint<version>".
       Supported compatible strings are -
       "sifive,fu540-c000-clint" for the SiFive CLINT v0 as integrated
-      onto the SiFive FU540 chip, and "sifive,clint0" for the SiFive
-      CLINT v0 IP block with no chip integration tweaks.
+      onto the SiFive FU540 chip, "canaan,k210-clint" for the SiFive
+      CLINT v0 as integrated onto the Canaan Kendryte K210 chip, and
+      "sifive,clint0" for the SiFive CLINT v0 IP block with no chip
+      integration tweaks.
       Please refer to sifive-blocks-ip-versioning.txt for details
 
   reg:
-- 
2.29.2


^ permalink raw reply related	[flat|nested] 81+ messages in thread

* [PATCH v14 05/16] dt-bindings: update sifive clint compatible string
@ 2021-02-02 10:36   ` Damien Le Moal
  0 siblings, 0 replies; 81+ messages in thread
From: Damien Le Moal @ 2021-02-02 10:36 UTC (permalink / raw)
  To: Palmer Dabbelt, linux-riscv
  Cc: Atish Patra, devicetree, Anup Patel, Rob Herring, Sean Anderson

Add the "canaan,k210-clint" compatible string to the Sifive clint
bindings to indicate the use of the "sifive,clint0" IP block in the
Canaan Kendryte K210 SoC. The description of the compatible string
property is also updated to reflect this addition.

Cc: Anup Patel <anup.patel@wdc.com>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
---
 .../bindings/timer/sifive,clint.yaml          | 19 +++++++++++++------
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/timer/sifive,clint.yaml b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
index 2a0e9cd9fbcf..1a7d582a208f 100644
--- a/Documentation/devicetree/bindings/timer/sifive,clint.yaml
+++ b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
@@ -22,16 +22,23 @@ description:
 
 properties:
   compatible:
-    items:
-      - const: sifive,fu540-c000-clint
-      - const: sifive,clint0
+    oneOf:
+      - items:
+          - const: sifive,fu540-c000-clint
+          - const: sifive,clint0
+
+      - items:
+          - const: canaan,k210-clint
+          - const: sifive,clint0
 
     description:
-      Should be "sifive,<chip>-clint" and "sifive,clint<version>".
+      Should be "<vendor>,<chip>-clint" and "sifive,clint<version>".
       Supported compatible strings are -
       "sifive,fu540-c000-clint" for the SiFive CLINT v0 as integrated
-      onto the SiFive FU540 chip, and "sifive,clint0" for the SiFive
-      CLINT v0 IP block with no chip integration tweaks.
+      onto the SiFive FU540 chip, "canaan,k210-clint" for the SiFive
+      CLINT v0 as integrated onto the Canaan Kendryte K210 chip, and
+      "sifive,clint0" for the SiFive CLINT v0 IP block with no chip
+      integration tweaks.
       Please refer to sifive-blocks-ip-versioning.txt for details
 
   reg:
-- 
2.29.2


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply related	[flat|nested] 81+ messages in thread

* [PATCH v14 06/16] dt-bindings: update sifive uart compatible string
  2021-02-02 10:36 [PATCH v14 00/16] RISC-V Kendryte K210 support improvements Damien Le Moal
@ 2021-02-02 10:36   ` Damien Le Moal
  2021-02-02 10:36   ` Damien Le Moal
                     ` (14 subsequent siblings)
  15 siblings, 0 replies; 81+ messages in thread
From: Damien Le Moal @ 2021-02-02 10:36 UTC (permalink / raw)
  To: Palmer Dabbelt, linux-riscv
  Cc: Atish Patra, Anup Patel, Sean Anderson, Paul Walmsley,
	Rob Herring, devicetree

Add the compatible string "canaan,k210-uarths" to the sifive uart
bindings to indicate the use of this IP block in the Canaan Kendryte
K210 SoC.

Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
---
 Documentation/devicetree/bindings/serial/sifive-serial.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/serial/sifive-serial.yaml b/Documentation/devicetree/bindings/serial/sifive-serial.yaml
index 3ac5c7ff2758..5fa94dacbba9 100644
--- a/Documentation/devicetree/bindings/serial/sifive-serial.yaml
+++ b/Documentation/devicetree/bindings/serial/sifive-serial.yaml
@@ -20,6 +20,7 @@ properties:
       - enum:
           - sifive,fu540-c000-uart
           - sifive,fu740-c000-uart
+          - canaan,k210-uarths
       - const: sifive,uart0
 
     description:
-- 
2.29.2


^ permalink raw reply related	[flat|nested] 81+ messages in thread

* [PATCH v14 06/16] dt-bindings: update sifive uart compatible string
@ 2021-02-02 10:36   ` Damien Le Moal
  0 siblings, 0 replies; 81+ messages in thread
From: Damien Le Moal @ 2021-02-02 10:36 UTC (permalink / raw)
  To: Palmer Dabbelt, linux-riscv
  Cc: devicetree, Rob Herring, Anup Patel, Sean Anderson, Atish Patra,
	Paul Walmsley

Add the compatible string "canaan,k210-uarths" to the sifive uart
bindings to indicate the use of this IP block in the Canaan Kendryte
K210 SoC.

Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
---
 Documentation/devicetree/bindings/serial/sifive-serial.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/serial/sifive-serial.yaml b/Documentation/devicetree/bindings/serial/sifive-serial.yaml
index 3ac5c7ff2758..5fa94dacbba9 100644
--- a/Documentation/devicetree/bindings/serial/sifive-serial.yaml
+++ b/Documentation/devicetree/bindings/serial/sifive-serial.yaml
@@ -20,6 +20,7 @@ properties:
       - enum:
           - sifive,fu540-c000-uart
           - sifive,fu740-c000-uart
+          - canaan,k210-uarths
       - const: sifive,uart0
 
     description:
-- 
2.29.2


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply related	[flat|nested] 81+ messages in thread

* [PATCH v14 07/16] dt-bindings: fix sifive gpio properties
  2021-02-02 10:36 [PATCH v14 00/16] RISC-V Kendryte K210 support improvements Damien Le Moal
@ 2021-02-02 10:36   ` Damien Le Moal
  2021-02-02 10:36   ` Damien Le Moal
                     ` (14 subsequent siblings)
  15 siblings, 0 replies; 81+ messages in thread
From: Damien Le Moal @ 2021-02-02 10:36 UTC (permalink / raw)
  To: Palmer Dabbelt, linux-riscv
  Cc: Atish Patra, Anup Patel, Sean Anderson, Paul Walmsley,
	Rob Herring, devicetree

The sifive gpio IP block supports up to 32 GPIOs. Reflect that in the
interrupts property description and maxItems. Also add the standard
ngpios property to describe the number of GPIOs available on the
implementation.

Also add the "canaan,k210-gpiohs" compatible string to indicate the use
of this gpio controller in the Canaan Kendryte K210 SoC. If this
compatible string is used, do not define the clocks property as
required as the K210 SoC does not have a software controllable clock
for the Sifive gpio IP block.

Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
---
 .../devicetree/bindings/gpio/sifive,gpio.yaml | 21 ++++++++++++++++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
index ab22056f8b44..2cef18ca737c 100644
--- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
@@ -16,6 +16,7 @@ properties:
       - enum:
           - sifive,fu540-c000-gpio
           - sifive,fu740-c000-gpio
+          - canaan,k210-gpiohs
       - const: sifive,gpio0
 
   reg:
@@ -23,9 +24,9 @@ properties:
 
   interrupts:
     description:
-      interrupt mapping one per GPIO. Maximum 16 GPIOs.
+      interrupt mapping one per GPIO. Maximum 32 GPIOs.
     minItems: 1
-    maxItems: 16
+    maxItems: 32
 
   interrupt-controller: true
 
@@ -38,6 +39,10 @@ properties:
   "#gpio-cells":
     const: 2
 
+  ngpios:
+    minimum: 1
+    maximum: 32
+
   gpio-controller: true
 
 required:
@@ -46,10 +51,20 @@ required:
   - interrupts
   - interrupt-controller
   - "#interrupt-cells"
-  - clocks
   - "#gpio-cells"
   - gpio-controller
 
+if:
+  properties:
+    compatible:
+      contains:
+        enum:
+          - sifive,fu540-c000-gpio
+          - sifive,fu740-c000-gpio
+then:
+  required:
+    - clocks
+
 additionalProperties: false
 
 examples:
-- 
2.29.2


^ permalink raw reply related	[flat|nested] 81+ messages in thread

* [PATCH v14 07/16] dt-bindings: fix sifive gpio properties
@ 2021-02-02 10:36   ` Damien Le Moal
  0 siblings, 0 replies; 81+ messages in thread
From: Damien Le Moal @ 2021-02-02 10:36 UTC (permalink / raw)
  To: Palmer Dabbelt, linux-riscv
  Cc: devicetree, Rob Herring, Anup Patel, Sean Anderson, Atish Patra,
	Paul Walmsley

The sifive gpio IP block supports up to 32 GPIOs. Reflect that in the
interrupts property description and maxItems. Also add the standard
ngpios property to describe the number of GPIOs available on the
implementation.

Also add the "canaan,k210-gpiohs" compatible string to indicate the use
of this gpio controller in the Canaan Kendryte K210 SoC. If this
compatible string is used, do not define the clocks property as
required as the K210 SoC does not have a software controllable clock
for the Sifive gpio IP block.

Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
---
 .../devicetree/bindings/gpio/sifive,gpio.yaml | 21 ++++++++++++++++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
index ab22056f8b44..2cef18ca737c 100644
--- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
@@ -16,6 +16,7 @@ properties:
       - enum:
           - sifive,fu540-c000-gpio
           - sifive,fu740-c000-gpio
+          - canaan,k210-gpiohs
       - const: sifive,gpio0
 
   reg:
@@ -23,9 +24,9 @@ properties:
 
   interrupts:
     description:
-      interrupt mapping one per GPIO. Maximum 16 GPIOs.
+      interrupt mapping one per GPIO. Maximum 32 GPIOs.
     minItems: 1
-    maxItems: 16
+    maxItems: 32
 
   interrupt-controller: true
 
@@ -38,6 +39,10 @@ properties:
   "#gpio-cells":
     const: 2
 
+  ngpios:
+    minimum: 1
+    maximum: 32
+
   gpio-controller: true
 
 required:
@@ -46,10 +51,20 @@ required:
   - interrupts
   - interrupt-controller
   - "#interrupt-cells"
-  - clocks
   - "#gpio-cells"
   - gpio-controller
 
+if:
+  properties:
+    compatible:
+      contains:
+        enum:
+          - sifive,fu540-c000-gpio
+          - sifive,fu740-c000-gpio
+then:
+  required:
+    - clocks
+
 additionalProperties: false
 
 examples:
-- 
2.29.2


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply related	[flat|nested] 81+ messages in thread

* [PATCH v14 08/16] dt-bindings: add resets property to dw-apb-timer
  2021-02-02 10:36 [PATCH v14 00/16] RISC-V Kendryte K210 support improvements Damien Le Moal
@ 2021-02-02 10:36   ` Damien Le Moal
  2021-02-02 10:36   ` Damien Le Moal
                     ` (14 subsequent siblings)
  15 siblings, 0 replies; 81+ messages in thread
From: Damien Le Moal @ 2021-02-02 10:36 UTC (permalink / raw)
  To: Palmer Dabbelt, linux-riscv
  Cc: Atish Patra, Anup Patel, Sean Anderson, Daniel Lezcano,
	Rob Herring, devicetree

The Synopsis DesignWare APB timer driver
(drivers/clocksource/dw_apb_timer_of.c) indirectly uses the resets
property of its node as it executes the function of_reset_control_get().
Make sure that this property is documented in
timer/snps,dw-apb-timer.yaml to avoid make dtbs_check warnings.

Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
---
 Documentation/devicetree/bindings/timer/snps,dw-apb-timer.yaml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/timer/snps,dw-apb-timer.yaml b/Documentation/devicetree/bindings/timer/snps,dw-apb-timer.yaml
index d65faf289a83..d33c9205a909 100644
--- a/Documentation/devicetree/bindings/timer/snps,dw-apb-timer.yaml
+++ b/Documentation/devicetree/bindings/timer/snps,dw-apb-timer.yaml
@@ -24,6 +24,9 @@ properties:
   interrupts:
     maxItems: 1
 
+  resets:
+    maxItems: 1
+
   clocks:
     minItems: 1
     items:
-- 
2.29.2


^ permalink raw reply related	[flat|nested] 81+ messages in thread

* [PATCH v14 08/16] dt-bindings: add resets property to dw-apb-timer
@ 2021-02-02 10:36   ` Damien Le Moal
  0 siblings, 0 replies; 81+ messages in thread
From: Damien Le Moal @ 2021-02-02 10:36 UTC (permalink / raw)
  To: Palmer Dabbelt, linux-riscv
  Cc: Rob Herring, Daniel Lezcano, devicetree, Anup Patel,
	Sean Anderson, Atish Patra

The Synopsis DesignWare APB timer driver
(drivers/clocksource/dw_apb_timer_of.c) indirectly uses the resets
property of its node as it executes the function of_reset_control_get().
Make sure that this property is documented in
timer/snps,dw-apb-timer.yaml to avoid make dtbs_check warnings.

Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
---
 Documentation/devicetree/bindings/timer/snps,dw-apb-timer.yaml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/timer/snps,dw-apb-timer.yaml b/Documentation/devicetree/bindings/timer/snps,dw-apb-timer.yaml
index d65faf289a83..d33c9205a909 100644
--- a/Documentation/devicetree/bindings/timer/snps,dw-apb-timer.yaml
+++ b/Documentation/devicetree/bindings/timer/snps,dw-apb-timer.yaml
@@ -24,6 +24,9 @@ properties:
   interrupts:
     maxItems: 1
 
+  resets:
+    maxItems: 1
+
   clocks:
     minItems: 1
     items:
-- 
2.29.2


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply related	[flat|nested] 81+ messages in thread

* [PATCH v14 09/16] riscv: Update Canaan Kendryte K210 device tree
  2021-02-02 10:36 [PATCH v14 00/16] RISC-V Kendryte K210 support improvements Damien Le Moal
@ 2021-02-02 10:36   ` Damien Le Moal
  2021-02-02 10:36   ` Damien Le Moal
                     ` (14 subsequent siblings)
  15 siblings, 0 replies; 81+ messages in thread
From: Damien Le Moal @ 2021-02-02 10:36 UTC (permalink / raw)
  To: Palmer Dabbelt, linux-riscv
  Cc: Atish Patra, Anup Patel, Sean Anderson, Rob Herring, devicetree

Update the Canaan Kendryte K210 base device tree k210.dtsi to define
all peripherals of the SoC, their clocks and reset lines. The device
tree file k210.dts is renamed to k210_generic.dts and becomes the
default value selection of the SOC_CANAAN_K210_DTB_BUILTIN_SOURCE
configuration option. No device beside the serial console is defined by
this device tree. This makes this generic device tree suitable for use
with a builtin initramfs with all known K210 based boards.

These changes result in the K210_CLK_ACLK clock ID to be unused and
removed from the dt-bindings k210-clk.h header file.

Most updates to the k210.dtsi file come from Sean Anderson's work on
U-Boot support for the K210.

Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
---
 arch/riscv/Kconfig.socs                     |   2 +-
 arch/riscv/boot/dts/canaan/k210.dts         |  23 -
 arch/riscv/boot/dts/canaan/k210.dtsi        | 535 +++++++++++++++++++-
 arch/riscv/boot/dts/canaan/k210_generic.dts |  46 ++
 include/dt-bindings/clock/k210-clk.h        |   1 -
 5 files changed, 554 insertions(+), 53 deletions(-)
 delete mode 100644 arch/riscv/boot/dts/canaan/k210.dts
 create mode 100644 arch/riscv/boot/dts/canaan/k210_generic.dts

diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
index 6402746c68f3..7efcece8896c 100644
--- a/arch/riscv/Kconfig.socs
+++ b/arch/riscv/Kconfig.socs
@@ -51,7 +51,7 @@ config SOC_CANAAN_K210_DTB_SOURCE
 	string "Source file for the Canaan Kendryte K210 builtin DTB"
 	depends on SOC_CANAAN
 	depends on SOC_CANAAN_K210_DTB_BUILTIN
-	default "k210"
+	default "k210_generic"
 	help
 	  Base name (without suffix, relative to arch/riscv/boot/dts/canaan)
 	  for the DTS file that will be used to produce the DTB linked into the
diff --git a/arch/riscv/boot/dts/canaan/k210.dts b/arch/riscv/boot/dts/canaan/k210.dts
deleted file mode 100644
index 0d1f28fce6b2..000000000000
--- a/arch/riscv/boot/dts/canaan/k210.dts
+++ /dev/null
@@ -1,23 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright (C) 2020 Western Digital Corporation or its affiliates.
- */
-
-/dts-v1/;
-
-#include "k210.dtsi"
-
-/ {
-	model = "Kendryte K210 generic";
-	compatible = "kendryte,k210";
-
-	chosen {
-		bootargs = "earlycon console=ttySIF0";
-		stdout-path = "serial0";
-	};
-};
-
-&uarths0 {
-	status = "okay";
-};
-
diff --git a/arch/riscv/boot/dts/canaan/k210.dtsi b/arch/riscv/boot/dts/canaan/k210.dtsi
index 354b263195a3..63c1f4c98d6c 100644
--- a/arch/riscv/boot/dts/canaan/k210.dtsi
+++ b/arch/riscv/boot/dts/canaan/k210.dtsi
@@ -1,9 +1,11 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
- * Copyright (C) 2019 Sean Anderson <seanga2@gmail.com>
+ * Copyright (C) 2019-20 Sean Anderson <seanga2@gmail.com>
  * Copyright (C) 2020 Western Digital Corporation or its affiliates.
  */
 #include <dt-bindings/clock/k210-clk.h>
+#include <dt-bindings/pinctrl/k210-fpioa.h>
+#include <dt-bindings/reset/k210-rst.h>
 
 / {
 	/*
@@ -12,14 +14,33 @@ / {
 	 */
 	#address-cells = <1>;
 	#size-cells = <1>;
-	compatible = "kendryte,k210";
+	compatible = "canaan,kendryte-k210";
 
 	aliases {
+		cpu0 = &cpu0;
+		cpu1 = &cpu1;
+		dma0 = &dmac0;
+		gpio0 = &gpio0;
+		gpio1 = &gpio1_0;
+		i2c0 = &i2c0;
+		i2c1 = &i2c1;
+		i2c2 = &i2c2;
+		pinctrl0 = &fpioa;
 		serial0 = &uarths0;
+		serial1 = &uart1;
+		serial2 = &uart2;
+		serial3 = &uart3;
+		spi0 = &spi0;
+		spi1 = &spi1;
+		spi2 = &spi2;
+		spi3 = &spi3;
+		timer0 = &timer0;
+		timer1 = &timer1;
+		timer2 = &timer2;
 	};
 
 	/*
-	 * The K210 has an sv39 MMU following the priviledge specification v1.9.
+	 * The K210 has an sv39 MMU following the privileged specification v1.9.
 	 * Since this is a non-ratified draft specification, the kernel does not
 	 * support it and the K210 support enabled only for the !MMU case.
 	 * Be consistent with this by setting the CPUs MMU type to "none".
@@ -30,14 +51,14 @@ cpus {
 		timebase-frequency = <7800000>;
 		cpu0: cpu@0 {
 			device_type = "cpu";
+			compatible = "canaan,k210", "riscv";
 			reg = <0>;
-			compatible = "kendryte,k210", "sifive,rocket0", "riscv";
 			riscv,isa = "rv64imafdc";
-			mmu-type = "none";
-			i-cache-size = <0x8000>;
+			mmu-type = "riscv,none";
 			i-cache-block-size = <64>;
-			d-cache-size = <0x8000>;
+			i-cache-size = <0x8000>;
 			d-cache-block-size = <64>;
+			d-cache-size = <0x8000>;
 			cpu0_intc: interrupt-controller {
 				#interrupt-cells = <1>;
 				interrupt-controller;
@@ -46,14 +67,14 @@ cpu0_intc: interrupt-controller {
 		};
 		cpu1: cpu@1 {
 			device_type = "cpu";
+			compatible = "canaan,k210", "riscv";
 			reg = <1>;
-			compatible = "kendryte,k210", "sifive,rocket0", "riscv";
 			riscv,isa = "rv64imafdc";
-			mmu-type = "none";
-			i-cache-size = <0x8000>;
+			mmu-type = "riscv,none";
 			i-cache-block-size = <64>;
-			d-cache-size = <0x8000>;
+			i-cache-size = <0x8000>;
 			d-cache-block-size = <64>;
+			d-cache-size = <0x8000>;
 			cpu1_intc: interrupt-controller {
 				#interrupt-cells = <1>;
 				interrupt-controller;
@@ -64,10 +85,15 @@ cpu1_intc: interrupt-controller {
 
 	sram: memory@80000000 {
 		device_type = "memory";
+		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>;
+		clock-names = "sram0", "sram1", "aisram";
 	};
 
 	clocks {
@@ -81,40 +107,493 @@ in0: oscillator {
 	soc {
 		#address-cells = <1>;
 		#size-cells = <1>;
-		compatible = "kendryte,k210-soc", "simple-bus";
+		compatible = "simple-bus";
 		ranges;
 		interrupt-parent = <&plic0>;
 
-		sysctl: sysctl@50440000 {
-			compatible = "kendryte,k210-sysctl", "simple-mfd";
-			reg = <0x50440000 0x1000>;
-			#clock-cells = <1>;
+		debug0: debug@0 {
+			compatible = "canaan,k210-debug", "riscv,debug";
+			reg = <0x0 0x1000>;
+			status = "disabled";
+		};
+
+		rom0: nvmem@1000 {
+			reg = <0x1000 0x1000>;
+			read-only;
+			status = "disabled";
 		};
 
 		clint0: clint@2000000 {
-			#interrupt-cells = <1>;
-			compatible = "riscv,clint0";
+			compatible = "canaan,k210-clint", "sifive,clint0";
 			reg = <0x2000000 0xC000>;
-			interrupts-extended =  <&cpu0_intc 3 &cpu0_intc 7
-						&cpu1_intc 3 &cpu1_intc 7>;
+			interrupts-extended = <&cpu0_intc 3 &cpu0_intc 7
+					      &cpu1_intc 3 &cpu1_intc 7>;
 		};
 
-		plic0: interrupt-controller@c000000 {
+		plic0: interrupt-controller@C000000 {
 			#interrupt-cells = <1>;
-			interrupt-controller;
-			compatible = "kendryte,k210-plic0", "riscv,plic0";
+			#address-cells = <0>;
+			compatible = "canaan,k210-plic", "sifive,plic-1.0.0";
 			reg = <0xC000000 0x4000000>;
-			interrupts-extended = <&cpu0_intc 11>, <&cpu0_intc 0xffffffff>,
-					      <&cpu1_intc 11>, <&cpu1_intc 0xffffffff>;
+			interrupt-controller;
+			interrupts-extended = <&cpu0_intc 11 &cpu1_intc 11>;
 			riscv,ndev = <65>;
-			riscv,max-priority = <7>;
 		};
 
 		uarths0: serial@38000000 {
-			compatible = "kendryte,k210-uarths", "sifive,uart0";
+			compatible = "canaan,k210-uarths", "sifive,uart0";
 			reg = <0x38000000 0x1000>;
 			interrupts = <33>;
-			clocks = <&sysctl K210_CLK_CPU>;
+			clocks = <&sysclk K210_CLK_CPU>;
+			status = "disabled";
+		};
+
+		gpio0: gpio-controller@38001000 {
+			#interrupt-cells = <2>;
+			#gpio-cells = <2>;
+			compatible = "canaan,k210-gpiohs", "sifive,gpio0";
+			reg = <0x38001000 0x1000>;
+			interrupt-controller;
+			interrupts = <34 35 36 37 38 39 40 41
+				      42 43 44 45 46 47 48 49
+				      50 51 52 53 54 55 56 57
+				      58 59 60 61 62 63 64 65>;
+			gpio-controller;
+			ngpios = <32>;
+			status = "disabled";
+		};
+
+		kpu0: kpu@40800000 {
+			compatible = "canaan,k210-kpu";
+			reg = <0x40800000 0xc00000>;
+			interrupts = <25>;
+			clocks = <&sysclk K210_CLK_AI>;
+			status = "disabled";
+		};
+
+		fft0: fft@42000000 {
+			compatible = "canaan,k210-fft";
+			reg = <0x42000000 0x400000>;
+			interrupts = <26>;
+			clocks = <&sysclk K210_CLK_FFT>;
+			resets = <&sysrst K210_RST_FFT>;
+			status = "disabled";
+		};
+
+		dmac0: dma-controller@50000000 {
+			compatible = "snps,axi-dma-1.01a";
+			reg = <0x50000000 0x1000>;
+			interrupts = <27 28 29 30 31 32>;
+			clocks = <&sysclk K210_CLK_DMA>, <&sysclk K210_CLK_DMA>;
+			clock-names = "core-clk", "cfgr-clk";
+			resets = <&sysrst K210_RST_DMA>;
+			dma-channels = <6>;
+			snps,dma-masters = <2>;
+			snps,priority = <0 1 2 3 4 5>;
+			snps,data-width = <5>;
+			snps,block-size = <0x200000 0x200000 0x200000
+					   0x200000 0x200000 0x200000>;
+			snps,axi-max-burst-len = <256>;
+			status = "disabled";
+		};
+
+		apb0: bus@50200000 {
+			#address-cells = <1>;
+			#size-cells = <1>;
+			compatible = "simple-pm-bus";
+			ranges;
+			clocks = <&sysclk K210_CLK_APB0>;
+
+			gpio1: gpio@50200000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "snps,dw-apb-gpio";
+				reg = <0x50200000 0x80>;
+				clocks = <&sysclk K210_CLK_APB0>,
+					 <&sysclk K210_CLK_GPIO>;
+				clock-names = "bus", "db";
+				resets = <&sysrst K210_RST_GPIO>;
+				status = "disabled";
+
+				gpio1_0: gpio-port@0 {
+					#gpio-cells = <2>;
+					#interrupt-cells = <2>;
+					compatible = "snps,dw-apb-gpio-port";
+					reg = <0>;
+					interrupt-controller;
+					interrupts = <23>;
+					gpio-controller;
+					ngpios = <8>;
+				};
+			};
+
+			uart1: serial@50210000 {
+				compatible = "snps,dw-apb-uart";
+				reg = <0x50210000 0x100>;
+				interrupts = <11>;
+				clocks = <&sysclk K210_CLK_UART1>,
+					 <&sysclk K210_CLK_APB0>;
+				clock-names = "baudclk", "apb_pclk";
+				resets = <&sysrst K210_RST_UART1>;
+				reg-io-width = <4>;
+				reg-shift = <2>;
+				dcd-override;
+				dsr-override;
+				cts-override;
+				ri-override;
+				status = "disabled";
+			};
+
+			uart2: serial@50220000 {
+				compatible = "snps,dw-apb-uart";
+				reg = <0x50220000 0x100>;
+				interrupts = <12>;
+				clocks = <&sysclk K210_CLK_UART2>,
+					 <&sysclk K210_CLK_APB0>;
+				clock-names = "baudclk", "apb_pclk";
+				resets = <&sysrst K210_RST_UART2>;
+				reg-io-width = <4>;
+				reg-shift = <2>;
+				dcd-override;
+				dsr-override;
+				cts-override;
+				ri-override;
+				status = "disabled";
+			};
+
+			uart3: serial@50230000 {
+				compatible = "snps,dw-apb-uart";
+				reg = <0x50230000 0x100>;
+				interrupts = <13>;
+				clocks = <&sysclk K210_CLK_UART3>,
+					 <&sysclk K210_CLK_APB0>;
+				clock-names = "baudclk", "apb_pclk";
+				resets = <&sysrst K210_RST_UART3>;
+				reg-io-width = <4>;
+				reg-shift = <2>;
+				dcd-override;
+				dsr-override;
+				cts-override;
+				ri-override;
+				status = "disabled";
+			};
+
+			spi2: spi@50240000 {
+				compatible = "canaan,k210-spi";
+				spi-slave;
+				reg = <0x50240000 0x100>;
+				interrupts = <3>;
+				clocks = <&sysclk K210_CLK_SPI2>,
+					 <&sysclk K210_CLK_APB0>;
+				clock-names = "ssi_clk", "pclk";
+				resets = <&sysrst K210_RST_SPI2>;
+				spi-max-frequency = <25000000>;
+				status = "disabled";
+			};
+
+			i2s0: i2s@50250000 {
+				compatible = "snps,designware-i2s";
+				reg = <0x50250000 0x200>;
+				interrupts = <5>;
+				clocks = <&sysclk K210_CLK_I2S0>;
+				clock-names = "i2sclk";
+				resets = <&sysrst K210_RST_I2S0>;
+				status = "disabled";
+			};
+
+			apu0: sound@520250200 {
+				compatible = "canaan,k210-apu";
+				reg = <0x50250200 0x200>;
+				status = "disabled";
+			};
+
+			i2s1: i2s@50260000 {
+				compatible = "snps,designware-i2s";
+				reg = <0x50260000 0x200>;
+				interrupts = <6>;
+				clocks = <&sysclk K210_CLK_I2S1>;
+				clock-names = "i2sclk";
+				resets = <&sysrst K210_RST_I2S1>;
+				status = "disabled";
+			};
+
+			i2s2: i2s@50270000 {
+				compatible = "snps,designware-i2s";
+				reg = <0x50270000 0x200>;
+				interrupts = <7>;
+				clocks = <&sysclk K210_CLK_I2S2>;
+				clock-names = "i2sclk";
+				resets = <&sysrst K210_RST_I2S2>;
+				status = "disabled";
+			};
+
+			i2c0: i2c@50280000 {
+				compatible = "snps,designware-i2c";
+				reg = <0x50280000 0x100>;
+				interrupts = <8>;
+				clocks = <&sysclk K210_CLK_I2C0>,
+					 <&sysclk K210_CLK_APB0>;
+				clock-names = "ref", "pclk";
+				resets = <&sysrst K210_RST_I2C0>;
+				status = "disabled";
+			};
+
+			i2c1: i2c@50290000 {
+				compatible = "snps,designware-i2c";
+				reg = <0x50290000 0x100>;
+				interrupts = <9>;
+				clocks = <&sysclk K210_CLK_I2C1>,
+					 <&sysclk K210_CLK_APB0>;
+				clock-names = "ref", "pclk";
+				resets = <&sysrst K210_RST_I2C1>;
+				status = "disabled";
+			};
+
+			i2c2: i2c@502A0000 {
+				compatible = "snps,designware-i2c";
+				reg = <0x502A0000 0x100>;
+				interrupts = <10>;
+				clocks = <&sysclk K210_CLK_I2C2>,
+					 <&sysclk K210_CLK_APB0>;
+				clock-names = "ref", "pclk";
+				resets = <&sysrst K210_RST_I2C2>;
+				status = "disabled";
+			};
+
+			fpioa: pinmux@502B0000 {
+				compatible = "canaan,k210-fpioa";
+				reg = <0x502B0000 0x100>;
+				clocks = <&sysclk K210_CLK_FPIOA>,
+					 <&sysclk K210_CLK_APB0>;
+				clock-names = "ref", "pclk";
+				resets = <&sysrst K210_RST_FPIOA>;
+				canaan,k210-sysctl-power = <&sysctl 108>;
+				status = "disabled";
+			};
+
+			sha256: sha256@502C0000 {
+				compatible = "canaan,k210-sha256";
+				reg = <0x502C0000 0x100>;
+				clocks = <&sysclk K210_CLK_SHA>;
+				resets = <&sysrst K210_RST_SHA>;
+				status = "disabled";
+			};
+
+			timer0: timer@502D0000 {
+				compatible = "snps,dw-apb-timer";
+				reg = <0x502D0000 0x100>;
+				interrupts = <14 15>;
+				clocks = <&sysclk K210_CLK_TIMER0>,
+					 <&sysclk K210_CLK_APB0>;
+				clock-names = "timer", "pclk";
+				resets = <&sysrst K210_RST_TIMER0>;
+				status = "disabled";
+			};
+
+			timer1: timer@502E0000 {
+				compatible = "snps,dw-apb-timer";
+				reg = <0x502E0000 0x100>;
+				interrupts = <16 17>;
+				clocks = <&sysclk K210_CLK_TIMER1>,
+					 <&sysclk K210_CLK_APB0>;
+				clock-names = "timer", "pclk";
+				resets = <&sysrst K210_RST_TIMER1>;
+				status = "disabled";
+			};
+
+			timer2: timer@502F0000 {
+				compatible = "snps,dw-apb-timer";
+				reg = <0x502F0000 0x100>;
+				interrupts = <18 19>;
+				clocks = <&sysclk K210_CLK_TIMER2>,
+					 <&sysclk K210_CLK_APB0>;
+				clock-names = "timer", "pclk";
+				resets = <&sysrst K210_RST_TIMER2>;
+				status = "disabled";
+			};
+		};
+
+		apb1: bus@50400000 {
+			#address-cells = <1>;
+			#size-cells = <1>;
+			compatible = "simple-pm-bus";
+			ranges;
+			clocks = <&sysclk K210_CLK_APB1>;
+
+			wdt0: watchdog@50400000 {
+				compatible = "snps,dw-wdt";
+				reg = <0x50400000 0x100>;
+				interrupts = <21>;
+				clocks = <&sysclk K210_CLK_WDT0>,
+					 <&sysclk K210_CLK_APB1>;
+				clock-names = "tclk", "pclk";
+				resets = <&sysrst K210_RST_WDT0>;
+				status = "disabled";
+			};
+
+			wdt1: watchdog@50410000 {
+				compatible = "snps,dw-wdt";
+				reg = <0x50410000 0x100>;
+				interrupts = <22>;
+				clocks = <&sysclk K210_CLK_WDT1>,
+					 <&sysclk K210_CLK_APB1>;
+				clock-names = "tclk", "pclk";
+				resets = <&sysrst K210_RST_WDT1>;
+				status = "disabled";
+			};
+
+			otp0: nvmem@50420000 {
+				#address-cells = <1>;
+				#size-cells = <1>;
+				compatible = "canaan,k210-otp";
+				reg = <0x50420000 0x100>,
+				      <0x88000000 0x20000>;
+				reg-names = "reg", "mem";
+				clocks = <&sysclk K210_CLK_ROM>;
+				resets = <&sysrst K210_RST_ROM>;
+				read-only;
+				status = "disabled";
+
+				/* Bootloader */
+				firmware@00000 {
+					reg = <0x00000 0xC200>;
+				};
+
+				/*
+				 * config string as described in RISC-V
+				 * privileged spec 1.9
+				 */
+				config-1-9@1c000 {
+					reg = <0x1C000 0x1000>;
+				};
+
+				/*
+				 * Device tree containing only registers,
+				 * interrupts, and cpus
+				 */
+				fdt@1d000 {
+					reg = <0x1D000 0x2000>;
+				};
+
+				/* CPU/ROM credits */
+				credits@1f000 {
+					reg = <0x1F000 0x1000>;
+				};
+			};
+
+			dvp0: camera@50430000 {
+				compatible = "canaan,k210-dvp";
+				reg = <0x50430000 0x100>;
+				interrupts = <24>;
+				clocks = <&sysclk K210_CLK_DVP>;
+				resets = <&sysrst K210_RST_DVP>;
+				canaan,k210-misc-offset = <&sysctl 84>;
+				status = "disabled";
+			};
+
+			sysctl: syscon@50440000 {
+				compatible = "canaan,k210-sysctl",
+					     "syscon", "simple-mfd";
+				reg = <0x50440000 0x100>;
+				clocks = <&sysclk K210_CLK_APB1>;
+				clock-names = "pclk";
+
+				sysclk: clock-controller {
+					#clock-cells = <1>;
+					compatible = "canaan,k210-clk";
+					clocks = <&in0>;
+				};
+
+				sysrst: reset-controller {
+					compatible = "canaan,k210-rst";
+					#reset-cells = <1>;
+				};
+
+				reboot: syscon-reboot {
+					compatible = "syscon-reboot";
+					regmap = <&sysctl>;
+					offset = <48>;
+					mask = <1>;
+					value = <1>;
+				};
+			};
+
+			aes0: aes@50450000 {
+				compatible = "canaan,k210-aes";
+				reg = <0x50450000 0x100>;
+				clocks = <&sysclk K210_CLK_AES>;
+				resets = <&sysrst K210_RST_AES>;
+				status = "disabled";
+			};
+
+			rtc: rtc@50460000 {
+				compatible = "canaan,k210-rtc";
+				reg = <0x50460000 0x100>;
+				clocks = <&in0>;
+				resets = <&sysrst K210_RST_RTC>;
+				interrupts = <20>;
+				status = "disabled";
+			};
+		};
+
+		apb2: bus@52000000 {
+			#address-cells = <1>;
+			#size-cells = <1>;
+			compatible = "simple-pm-bus";
+			ranges;
+			clocks = <&sysclk K210_CLK_APB2>;
+
+			spi0: spi@52000000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "canaan,k210-spi";
+				reg = <0x52000000 0x100>;
+				interrupts = <1>;
+				clocks = <&sysclk K210_CLK_SPI0>,
+					 <&sysclk K210_CLK_APB2>;
+				clock-names = "ssi_clk", "pclk";
+				resets = <&sysrst K210_RST_SPI0>;
+				reset-names = "spi";
+				spi-max-frequency = <25000000>;
+				num-cs = <4>;
+				reg-io-width = <4>;
+				status = "disabled";
+			};
+
+			spi1: spi@53000000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "canaan,k210-spi";
+				reg = <0x53000000 0x100>;
+				interrupts = <2>;
+				clocks = <&sysclk K210_CLK_SPI1>,
+					 <&sysclk K210_CLK_APB2>;
+				clock-names = "ssi_clk", "pclk";
+				resets = <&sysrst K210_RST_SPI1>;
+				reset-names = "spi";
+				spi-max-frequency = <25000000>;
+				num-cs = <4>;
+				reg-io-width = <4>;
+				status = "disabled";
+			};
+
+			spi3: spi@54000000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "snps,dwc-ssi-1.01a";
+				reg = <0x54000000 0x200>;
+				interrupts = <4>;
+				clocks = <&sysclk K210_CLK_SPI3>,
+					 <&sysclk K210_CLK_APB2>;
+				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>;
+				status = "disabled";
+			};
 		};
 	};
 };
diff --git a/arch/riscv/boot/dts/canaan/k210_generic.dts b/arch/riscv/boot/dts/canaan/k210_generic.dts
new file mode 100644
index 000000000000..396c8ca4d24d
--- /dev/null
+++ b/arch/riscv/boot/dts/canaan/k210_generic.dts
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019-20 Sean Anderson <seanga2@gmail.com>
+ * Copyright (C) 2020 Western Digital Corporation or its affiliates.
+ */
+
+/dts-v1/;
+
+#include "k210.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+
+/ {
+	model = "Kendryte K210 generic";
+	compatible = "canaan,kendryte-k210";
+
+	chosen {
+		bootargs = "earlycon console=ttySIF0";
+		stdout-path = "serial0:115200n8";
+	};
+};
+
+&fpioa {
+	pinctrl-0 = <&jtag_pins>;
+	pinctrl-names = "default";
+	status = "okay";
+
+	jtag_pins: jtag-pinmux {
+		pinmux = <K210_FPIOA(0, K210_PCF_JTAG_TCLK)>,
+			 <K210_FPIOA(1, K210_PCF_JTAG_TDI)>,
+			 <K210_FPIOA(2, K210_PCF_JTAG_TMS)>,
+			 <K210_FPIOA(3, K210_PCF_JTAG_TDO)>;
+	};
+
+	uarths_pins: uarths-pinmux {
+		pinmux = <K210_FPIOA(4, K210_PCF_UARTHS_RX)>,
+			 <K210_FPIOA(5, K210_PCF_UARTHS_TX)>;
+	};
+};
+
+&uarths0 {
+	pinctrl-0 = <&uarths_pins>;
+	pinctrl-names = "default";
+	status = "okay";
+};
diff --git a/include/dt-bindings/clock/k210-clk.h b/include/dt-bindings/clock/k210-clk.h
index a48176ad3c23..b2de702cbf75 100644
--- a/include/dt-bindings/clock/k210-clk.h
+++ b/include/dt-bindings/clock/k210-clk.h
@@ -9,7 +9,6 @@
 /*
  * Kendryte K210 SoC clock identifiers (arbitrary values).
  */
-#define K210_CLK_ACLK	0
 #define K210_CLK_CPU	0
 #define K210_CLK_SRAM0	1
 #define K210_CLK_SRAM1	2
-- 
2.29.2


^ permalink raw reply related	[flat|nested] 81+ messages in thread

* [PATCH v14 09/16] riscv: Update Canaan Kendryte K210 device tree
@ 2021-02-02 10:36   ` Damien Le Moal
  0 siblings, 0 replies; 81+ messages in thread
From: Damien Le Moal @ 2021-02-02 10:36 UTC (permalink / raw)
  To: Palmer Dabbelt, linux-riscv
  Cc: Atish Patra, devicetree, Anup Patel, Rob Herring, Sean Anderson

Update the Canaan Kendryte K210 base device tree k210.dtsi to define
all peripherals of the SoC, their clocks and reset lines. The device
tree file k210.dts is renamed to k210_generic.dts and becomes the
default value selection of the SOC_CANAAN_K210_DTB_BUILTIN_SOURCE
configuration option. No device beside the serial console is defined by
this device tree. This makes this generic device tree suitable for use
with a builtin initramfs with all known K210 based boards.

These changes result in the K210_CLK_ACLK clock ID to be unused and
removed from the dt-bindings k210-clk.h header file.

Most updates to the k210.dtsi file come from Sean Anderson's work on
U-Boot support for the K210.

Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
---
 arch/riscv/Kconfig.socs                     |   2 +-
 arch/riscv/boot/dts/canaan/k210.dts         |  23 -
 arch/riscv/boot/dts/canaan/k210.dtsi        | 535 +++++++++++++++++++-
 arch/riscv/boot/dts/canaan/k210_generic.dts |  46 ++
 include/dt-bindings/clock/k210-clk.h        |   1 -
 5 files changed, 554 insertions(+), 53 deletions(-)
 delete mode 100644 arch/riscv/boot/dts/canaan/k210.dts
 create mode 100644 arch/riscv/boot/dts/canaan/k210_generic.dts

diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
index 6402746c68f3..7efcece8896c 100644
--- a/arch/riscv/Kconfig.socs
+++ b/arch/riscv/Kconfig.socs
@@ -51,7 +51,7 @@ config SOC_CANAAN_K210_DTB_SOURCE
 	string "Source file for the Canaan Kendryte K210 builtin DTB"
 	depends on SOC_CANAAN
 	depends on SOC_CANAAN_K210_DTB_BUILTIN
-	default "k210"
+	default "k210_generic"
 	help
 	  Base name (without suffix, relative to arch/riscv/boot/dts/canaan)
 	  for the DTS file that will be used to produce the DTB linked into the
diff --git a/arch/riscv/boot/dts/canaan/k210.dts b/arch/riscv/boot/dts/canaan/k210.dts
deleted file mode 100644
index 0d1f28fce6b2..000000000000
--- a/arch/riscv/boot/dts/canaan/k210.dts
+++ /dev/null
@@ -1,23 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright (C) 2020 Western Digital Corporation or its affiliates.
- */
-
-/dts-v1/;
-
-#include "k210.dtsi"
-
-/ {
-	model = "Kendryte K210 generic";
-	compatible = "kendryte,k210";
-
-	chosen {
-		bootargs = "earlycon console=ttySIF0";
-		stdout-path = "serial0";
-	};
-};
-
-&uarths0 {
-	status = "okay";
-};
-
diff --git a/arch/riscv/boot/dts/canaan/k210.dtsi b/arch/riscv/boot/dts/canaan/k210.dtsi
index 354b263195a3..63c1f4c98d6c 100644
--- a/arch/riscv/boot/dts/canaan/k210.dtsi
+++ b/arch/riscv/boot/dts/canaan/k210.dtsi
@@ -1,9 +1,11 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
- * Copyright (C) 2019 Sean Anderson <seanga2@gmail.com>
+ * Copyright (C) 2019-20 Sean Anderson <seanga2@gmail.com>
  * Copyright (C) 2020 Western Digital Corporation or its affiliates.
  */
 #include <dt-bindings/clock/k210-clk.h>
+#include <dt-bindings/pinctrl/k210-fpioa.h>
+#include <dt-bindings/reset/k210-rst.h>
 
 / {
 	/*
@@ -12,14 +14,33 @@ / {
 	 */
 	#address-cells = <1>;
 	#size-cells = <1>;
-	compatible = "kendryte,k210";
+	compatible = "canaan,kendryte-k210";
 
 	aliases {
+		cpu0 = &cpu0;
+		cpu1 = &cpu1;
+		dma0 = &dmac0;
+		gpio0 = &gpio0;
+		gpio1 = &gpio1_0;
+		i2c0 = &i2c0;
+		i2c1 = &i2c1;
+		i2c2 = &i2c2;
+		pinctrl0 = &fpioa;
 		serial0 = &uarths0;
+		serial1 = &uart1;
+		serial2 = &uart2;
+		serial3 = &uart3;
+		spi0 = &spi0;
+		spi1 = &spi1;
+		spi2 = &spi2;
+		spi3 = &spi3;
+		timer0 = &timer0;
+		timer1 = &timer1;
+		timer2 = &timer2;
 	};
 
 	/*
-	 * The K210 has an sv39 MMU following the priviledge specification v1.9.
+	 * The K210 has an sv39 MMU following the privileged specification v1.9.
 	 * Since this is a non-ratified draft specification, the kernel does not
 	 * support it and the K210 support enabled only for the !MMU case.
 	 * Be consistent with this by setting the CPUs MMU type to "none".
@@ -30,14 +51,14 @@ cpus {
 		timebase-frequency = <7800000>;
 		cpu0: cpu@0 {
 			device_type = "cpu";
+			compatible = "canaan,k210", "riscv";
 			reg = <0>;
-			compatible = "kendryte,k210", "sifive,rocket0", "riscv";
 			riscv,isa = "rv64imafdc";
-			mmu-type = "none";
-			i-cache-size = <0x8000>;
+			mmu-type = "riscv,none";
 			i-cache-block-size = <64>;
-			d-cache-size = <0x8000>;
+			i-cache-size = <0x8000>;
 			d-cache-block-size = <64>;
+			d-cache-size = <0x8000>;
 			cpu0_intc: interrupt-controller {
 				#interrupt-cells = <1>;
 				interrupt-controller;
@@ -46,14 +67,14 @@ cpu0_intc: interrupt-controller {
 		};
 		cpu1: cpu@1 {
 			device_type = "cpu";
+			compatible = "canaan,k210", "riscv";
 			reg = <1>;
-			compatible = "kendryte,k210", "sifive,rocket0", "riscv";
 			riscv,isa = "rv64imafdc";
-			mmu-type = "none";
-			i-cache-size = <0x8000>;
+			mmu-type = "riscv,none";
 			i-cache-block-size = <64>;
-			d-cache-size = <0x8000>;
+			i-cache-size = <0x8000>;
 			d-cache-block-size = <64>;
+			d-cache-size = <0x8000>;
 			cpu1_intc: interrupt-controller {
 				#interrupt-cells = <1>;
 				interrupt-controller;
@@ -64,10 +85,15 @@ cpu1_intc: interrupt-controller {
 
 	sram: memory@80000000 {
 		device_type = "memory";
+		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>;
+		clock-names = "sram0", "sram1", "aisram";
 	};
 
 	clocks {
@@ -81,40 +107,493 @@ in0: oscillator {
 	soc {
 		#address-cells = <1>;
 		#size-cells = <1>;
-		compatible = "kendryte,k210-soc", "simple-bus";
+		compatible = "simple-bus";
 		ranges;
 		interrupt-parent = <&plic0>;
 
-		sysctl: sysctl@50440000 {
-			compatible = "kendryte,k210-sysctl", "simple-mfd";
-			reg = <0x50440000 0x1000>;
-			#clock-cells = <1>;
+		debug0: debug@0 {
+			compatible = "canaan,k210-debug", "riscv,debug";
+			reg = <0x0 0x1000>;
+			status = "disabled";
+		};
+
+		rom0: nvmem@1000 {
+			reg = <0x1000 0x1000>;
+			read-only;
+			status = "disabled";
 		};
 
 		clint0: clint@2000000 {
-			#interrupt-cells = <1>;
-			compatible = "riscv,clint0";
+			compatible = "canaan,k210-clint", "sifive,clint0";
 			reg = <0x2000000 0xC000>;
-			interrupts-extended =  <&cpu0_intc 3 &cpu0_intc 7
-						&cpu1_intc 3 &cpu1_intc 7>;
+			interrupts-extended = <&cpu0_intc 3 &cpu0_intc 7
+					      &cpu1_intc 3 &cpu1_intc 7>;
 		};
 
-		plic0: interrupt-controller@c000000 {
+		plic0: interrupt-controller@C000000 {
 			#interrupt-cells = <1>;
-			interrupt-controller;
-			compatible = "kendryte,k210-plic0", "riscv,plic0";
+			#address-cells = <0>;
+			compatible = "canaan,k210-plic", "sifive,plic-1.0.0";
 			reg = <0xC000000 0x4000000>;
-			interrupts-extended = <&cpu0_intc 11>, <&cpu0_intc 0xffffffff>,
-					      <&cpu1_intc 11>, <&cpu1_intc 0xffffffff>;
+			interrupt-controller;
+			interrupts-extended = <&cpu0_intc 11 &cpu1_intc 11>;
 			riscv,ndev = <65>;
-			riscv,max-priority = <7>;
 		};
 
 		uarths0: serial@38000000 {
-			compatible = "kendryte,k210-uarths", "sifive,uart0";
+			compatible = "canaan,k210-uarths", "sifive,uart0";
 			reg = <0x38000000 0x1000>;
 			interrupts = <33>;
-			clocks = <&sysctl K210_CLK_CPU>;
+			clocks = <&sysclk K210_CLK_CPU>;
+			status = "disabled";
+		};
+
+		gpio0: gpio-controller@38001000 {
+			#interrupt-cells = <2>;
+			#gpio-cells = <2>;
+			compatible = "canaan,k210-gpiohs", "sifive,gpio0";
+			reg = <0x38001000 0x1000>;
+			interrupt-controller;
+			interrupts = <34 35 36 37 38 39 40 41
+				      42 43 44 45 46 47 48 49
+				      50 51 52 53 54 55 56 57
+				      58 59 60 61 62 63 64 65>;
+			gpio-controller;
+			ngpios = <32>;
+			status = "disabled";
+		};
+
+		kpu0: kpu@40800000 {
+			compatible = "canaan,k210-kpu";
+			reg = <0x40800000 0xc00000>;
+			interrupts = <25>;
+			clocks = <&sysclk K210_CLK_AI>;
+			status = "disabled";
+		};
+
+		fft0: fft@42000000 {
+			compatible = "canaan,k210-fft";
+			reg = <0x42000000 0x400000>;
+			interrupts = <26>;
+			clocks = <&sysclk K210_CLK_FFT>;
+			resets = <&sysrst K210_RST_FFT>;
+			status = "disabled";
+		};
+
+		dmac0: dma-controller@50000000 {
+			compatible = "snps,axi-dma-1.01a";
+			reg = <0x50000000 0x1000>;
+			interrupts = <27 28 29 30 31 32>;
+			clocks = <&sysclk K210_CLK_DMA>, <&sysclk K210_CLK_DMA>;
+			clock-names = "core-clk", "cfgr-clk";
+			resets = <&sysrst K210_RST_DMA>;
+			dma-channels = <6>;
+			snps,dma-masters = <2>;
+			snps,priority = <0 1 2 3 4 5>;
+			snps,data-width = <5>;
+			snps,block-size = <0x200000 0x200000 0x200000
+					   0x200000 0x200000 0x200000>;
+			snps,axi-max-burst-len = <256>;
+			status = "disabled";
+		};
+
+		apb0: bus@50200000 {
+			#address-cells = <1>;
+			#size-cells = <1>;
+			compatible = "simple-pm-bus";
+			ranges;
+			clocks = <&sysclk K210_CLK_APB0>;
+
+			gpio1: gpio@50200000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "snps,dw-apb-gpio";
+				reg = <0x50200000 0x80>;
+				clocks = <&sysclk K210_CLK_APB0>,
+					 <&sysclk K210_CLK_GPIO>;
+				clock-names = "bus", "db";
+				resets = <&sysrst K210_RST_GPIO>;
+				status = "disabled";
+
+				gpio1_0: gpio-port@0 {
+					#gpio-cells = <2>;
+					#interrupt-cells = <2>;
+					compatible = "snps,dw-apb-gpio-port";
+					reg = <0>;
+					interrupt-controller;
+					interrupts = <23>;
+					gpio-controller;
+					ngpios = <8>;
+				};
+			};
+
+			uart1: serial@50210000 {
+				compatible = "snps,dw-apb-uart";
+				reg = <0x50210000 0x100>;
+				interrupts = <11>;
+				clocks = <&sysclk K210_CLK_UART1>,
+					 <&sysclk K210_CLK_APB0>;
+				clock-names = "baudclk", "apb_pclk";
+				resets = <&sysrst K210_RST_UART1>;
+				reg-io-width = <4>;
+				reg-shift = <2>;
+				dcd-override;
+				dsr-override;
+				cts-override;
+				ri-override;
+				status = "disabled";
+			};
+
+			uart2: serial@50220000 {
+				compatible = "snps,dw-apb-uart";
+				reg = <0x50220000 0x100>;
+				interrupts = <12>;
+				clocks = <&sysclk K210_CLK_UART2>,
+					 <&sysclk K210_CLK_APB0>;
+				clock-names = "baudclk", "apb_pclk";
+				resets = <&sysrst K210_RST_UART2>;
+				reg-io-width = <4>;
+				reg-shift = <2>;
+				dcd-override;
+				dsr-override;
+				cts-override;
+				ri-override;
+				status = "disabled";
+			};
+
+			uart3: serial@50230000 {
+				compatible = "snps,dw-apb-uart";
+				reg = <0x50230000 0x100>;
+				interrupts = <13>;
+				clocks = <&sysclk K210_CLK_UART3>,
+					 <&sysclk K210_CLK_APB0>;
+				clock-names = "baudclk", "apb_pclk";
+				resets = <&sysrst K210_RST_UART3>;
+				reg-io-width = <4>;
+				reg-shift = <2>;
+				dcd-override;
+				dsr-override;
+				cts-override;
+				ri-override;
+				status = "disabled";
+			};
+
+			spi2: spi@50240000 {
+				compatible = "canaan,k210-spi";
+				spi-slave;
+				reg = <0x50240000 0x100>;
+				interrupts = <3>;
+				clocks = <&sysclk K210_CLK_SPI2>,
+					 <&sysclk K210_CLK_APB0>;
+				clock-names = "ssi_clk", "pclk";
+				resets = <&sysrst K210_RST_SPI2>;
+				spi-max-frequency = <25000000>;
+				status = "disabled";
+			};
+
+			i2s0: i2s@50250000 {
+				compatible = "snps,designware-i2s";
+				reg = <0x50250000 0x200>;
+				interrupts = <5>;
+				clocks = <&sysclk K210_CLK_I2S0>;
+				clock-names = "i2sclk";
+				resets = <&sysrst K210_RST_I2S0>;
+				status = "disabled";
+			};
+
+			apu0: sound@520250200 {
+				compatible = "canaan,k210-apu";
+				reg = <0x50250200 0x200>;
+				status = "disabled";
+			};
+
+			i2s1: i2s@50260000 {
+				compatible = "snps,designware-i2s";
+				reg = <0x50260000 0x200>;
+				interrupts = <6>;
+				clocks = <&sysclk K210_CLK_I2S1>;
+				clock-names = "i2sclk";
+				resets = <&sysrst K210_RST_I2S1>;
+				status = "disabled";
+			};
+
+			i2s2: i2s@50270000 {
+				compatible = "snps,designware-i2s";
+				reg = <0x50270000 0x200>;
+				interrupts = <7>;
+				clocks = <&sysclk K210_CLK_I2S2>;
+				clock-names = "i2sclk";
+				resets = <&sysrst K210_RST_I2S2>;
+				status = "disabled";
+			};
+
+			i2c0: i2c@50280000 {
+				compatible = "snps,designware-i2c";
+				reg = <0x50280000 0x100>;
+				interrupts = <8>;
+				clocks = <&sysclk K210_CLK_I2C0>,
+					 <&sysclk K210_CLK_APB0>;
+				clock-names = "ref", "pclk";
+				resets = <&sysrst K210_RST_I2C0>;
+				status = "disabled";
+			};
+
+			i2c1: i2c@50290000 {
+				compatible = "snps,designware-i2c";
+				reg = <0x50290000 0x100>;
+				interrupts = <9>;
+				clocks = <&sysclk K210_CLK_I2C1>,
+					 <&sysclk K210_CLK_APB0>;
+				clock-names = "ref", "pclk";
+				resets = <&sysrst K210_RST_I2C1>;
+				status = "disabled";
+			};
+
+			i2c2: i2c@502A0000 {
+				compatible = "snps,designware-i2c";
+				reg = <0x502A0000 0x100>;
+				interrupts = <10>;
+				clocks = <&sysclk K210_CLK_I2C2>,
+					 <&sysclk K210_CLK_APB0>;
+				clock-names = "ref", "pclk";
+				resets = <&sysrst K210_RST_I2C2>;
+				status = "disabled";
+			};
+
+			fpioa: pinmux@502B0000 {
+				compatible = "canaan,k210-fpioa";
+				reg = <0x502B0000 0x100>;
+				clocks = <&sysclk K210_CLK_FPIOA>,
+					 <&sysclk K210_CLK_APB0>;
+				clock-names = "ref", "pclk";
+				resets = <&sysrst K210_RST_FPIOA>;
+				canaan,k210-sysctl-power = <&sysctl 108>;
+				status = "disabled";
+			};
+
+			sha256: sha256@502C0000 {
+				compatible = "canaan,k210-sha256";
+				reg = <0x502C0000 0x100>;
+				clocks = <&sysclk K210_CLK_SHA>;
+				resets = <&sysrst K210_RST_SHA>;
+				status = "disabled";
+			};
+
+			timer0: timer@502D0000 {
+				compatible = "snps,dw-apb-timer";
+				reg = <0x502D0000 0x100>;
+				interrupts = <14 15>;
+				clocks = <&sysclk K210_CLK_TIMER0>,
+					 <&sysclk K210_CLK_APB0>;
+				clock-names = "timer", "pclk";
+				resets = <&sysrst K210_RST_TIMER0>;
+				status = "disabled";
+			};
+
+			timer1: timer@502E0000 {
+				compatible = "snps,dw-apb-timer";
+				reg = <0x502E0000 0x100>;
+				interrupts = <16 17>;
+				clocks = <&sysclk K210_CLK_TIMER1>,
+					 <&sysclk K210_CLK_APB0>;
+				clock-names = "timer", "pclk";
+				resets = <&sysrst K210_RST_TIMER1>;
+				status = "disabled";
+			};
+
+			timer2: timer@502F0000 {
+				compatible = "snps,dw-apb-timer";
+				reg = <0x502F0000 0x100>;
+				interrupts = <18 19>;
+				clocks = <&sysclk K210_CLK_TIMER2>,
+					 <&sysclk K210_CLK_APB0>;
+				clock-names = "timer", "pclk";
+				resets = <&sysrst K210_RST_TIMER2>;
+				status = "disabled";
+			};
+		};
+
+		apb1: bus@50400000 {
+			#address-cells = <1>;
+			#size-cells = <1>;
+			compatible = "simple-pm-bus";
+			ranges;
+			clocks = <&sysclk K210_CLK_APB1>;
+
+			wdt0: watchdog@50400000 {
+				compatible = "snps,dw-wdt";
+				reg = <0x50400000 0x100>;
+				interrupts = <21>;
+				clocks = <&sysclk K210_CLK_WDT0>,
+					 <&sysclk K210_CLK_APB1>;
+				clock-names = "tclk", "pclk";
+				resets = <&sysrst K210_RST_WDT0>;
+				status = "disabled";
+			};
+
+			wdt1: watchdog@50410000 {
+				compatible = "snps,dw-wdt";
+				reg = <0x50410000 0x100>;
+				interrupts = <22>;
+				clocks = <&sysclk K210_CLK_WDT1>,
+					 <&sysclk K210_CLK_APB1>;
+				clock-names = "tclk", "pclk";
+				resets = <&sysrst K210_RST_WDT1>;
+				status = "disabled";
+			};
+
+			otp0: nvmem@50420000 {
+				#address-cells = <1>;
+				#size-cells = <1>;
+				compatible = "canaan,k210-otp";
+				reg = <0x50420000 0x100>,
+				      <0x88000000 0x20000>;
+				reg-names = "reg", "mem";
+				clocks = <&sysclk K210_CLK_ROM>;
+				resets = <&sysrst K210_RST_ROM>;
+				read-only;
+				status = "disabled";
+
+				/* Bootloader */
+				firmware@00000 {
+					reg = <0x00000 0xC200>;
+				};
+
+				/*
+				 * config string as described in RISC-V
+				 * privileged spec 1.9
+				 */
+				config-1-9@1c000 {
+					reg = <0x1C000 0x1000>;
+				};
+
+				/*
+				 * Device tree containing only registers,
+				 * interrupts, and cpus
+				 */
+				fdt@1d000 {
+					reg = <0x1D000 0x2000>;
+				};
+
+				/* CPU/ROM credits */
+				credits@1f000 {
+					reg = <0x1F000 0x1000>;
+				};
+			};
+
+			dvp0: camera@50430000 {
+				compatible = "canaan,k210-dvp";
+				reg = <0x50430000 0x100>;
+				interrupts = <24>;
+				clocks = <&sysclk K210_CLK_DVP>;
+				resets = <&sysrst K210_RST_DVP>;
+				canaan,k210-misc-offset = <&sysctl 84>;
+				status = "disabled";
+			};
+
+			sysctl: syscon@50440000 {
+				compatible = "canaan,k210-sysctl",
+					     "syscon", "simple-mfd";
+				reg = <0x50440000 0x100>;
+				clocks = <&sysclk K210_CLK_APB1>;
+				clock-names = "pclk";
+
+				sysclk: clock-controller {
+					#clock-cells = <1>;
+					compatible = "canaan,k210-clk";
+					clocks = <&in0>;
+				};
+
+				sysrst: reset-controller {
+					compatible = "canaan,k210-rst";
+					#reset-cells = <1>;
+				};
+
+				reboot: syscon-reboot {
+					compatible = "syscon-reboot";
+					regmap = <&sysctl>;
+					offset = <48>;
+					mask = <1>;
+					value = <1>;
+				};
+			};
+
+			aes0: aes@50450000 {
+				compatible = "canaan,k210-aes";
+				reg = <0x50450000 0x100>;
+				clocks = <&sysclk K210_CLK_AES>;
+				resets = <&sysrst K210_RST_AES>;
+				status = "disabled";
+			};
+
+			rtc: rtc@50460000 {
+				compatible = "canaan,k210-rtc";
+				reg = <0x50460000 0x100>;
+				clocks = <&in0>;
+				resets = <&sysrst K210_RST_RTC>;
+				interrupts = <20>;
+				status = "disabled";
+			};
+		};
+
+		apb2: bus@52000000 {
+			#address-cells = <1>;
+			#size-cells = <1>;
+			compatible = "simple-pm-bus";
+			ranges;
+			clocks = <&sysclk K210_CLK_APB2>;
+
+			spi0: spi@52000000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "canaan,k210-spi";
+				reg = <0x52000000 0x100>;
+				interrupts = <1>;
+				clocks = <&sysclk K210_CLK_SPI0>,
+					 <&sysclk K210_CLK_APB2>;
+				clock-names = "ssi_clk", "pclk";
+				resets = <&sysrst K210_RST_SPI0>;
+				reset-names = "spi";
+				spi-max-frequency = <25000000>;
+				num-cs = <4>;
+				reg-io-width = <4>;
+				status = "disabled";
+			};
+
+			spi1: spi@53000000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "canaan,k210-spi";
+				reg = <0x53000000 0x100>;
+				interrupts = <2>;
+				clocks = <&sysclk K210_CLK_SPI1>,
+					 <&sysclk K210_CLK_APB2>;
+				clock-names = "ssi_clk", "pclk";
+				resets = <&sysrst K210_RST_SPI1>;
+				reset-names = "spi";
+				spi-max-frequency = <25000000>;
+				num-cs = <4>;
+				reg-io-width = <4>;
+				status = "disabled";
+			};
+
+			spi3: spi@54000000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				compatible = "snps,dwc-ssi-1.01a";
+				reg = <0x54000000 0x200>;
+				interrupts = <4>;
+				clocks = <&sysclk K210_CLK_SPI3>,
+					 <&sysclk K210_CLK_APB2>;
+				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>;
+				status = "disabled";
+			};
 		};
 	};
 };
diff --git a/arch/riscv/boot/dts/canaan/k210_generic.dts b/arch/riscv/boot/dts/canaan/k210_generic.dts
new file mode 100644
index 000000000000..396c8ca4d24d
--- /dev/null
+++ b/arch/riscv/boot/dts/canaan/k210_generic.dts
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019-20 Sean Anderson <seanga2@gmail.com>
+ * Copyright (C) 2020 Western Digital Corporation or its affiliates.
+ */
+
+/dts-v1/;
+
+#include "k210.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+
+/ {
+	model = "Kendryte K210 generic";
+	compatible = "canaan,kendryte-k210";
+
+	chosen {
+		bootargs = "earlycon console=ttySIF0";
+		stdout-path = "serial0:115200n8";
+	};
+};
+
+&fpioa {
+	pinctrl-0 = <&jtag_pins>;
+	pinctrl-names = "default";
+	status = "okay";
+
+	jtag_pins: jtag-pinmux {
+		pinmux = <K210_FPIOA(0, K210_PCF_JTAG_TCLK)>,
+			 <K210_FPIOA(1, K210_PCF_JTAG_TDI)>,
+			 <K210_FPIOA(2, K210_PCF_JTAG_TMS)>,
+			 <K210_FPIOA(3, K210_PCF_JTAG_TDO)>;
+	};
+
+	uarths_pins: uarths-pinmux {
+		pinmux = <K210_FPIOA(4, K210_PCF_UARTHS_RX)>,
+			 <K210_FPIOA(5, K210_PCF_UARTHS_TX)>;
+	};
+};
+
+&uarths0 {
+	pinctrl-0 = <&uarths_pins>;
+	pinctrl-names = "default";
+	status = "okay";
+};
diff --git a/include/dt-bindings/clock/k210-clk.h b/include/dt-bindings/clock/k210-clk.h
index a48176ad3c23..b2de702cbf75 100644
--- a/include/dt-bindings/clock/k210-clk.h
+++ b/include/dt-bindings/clock/k210-clk.h
@@ -9,7 +9,6 @@
 /*
  * Kendryte K210 SoC clock identifiers (arbitrary values).
  */
-#define K210_CLK_ACLK	0
 #define K210_CLK_CPU	0
 #define K210_CLK_SRAM0	1
 #define K210_CLK_SRAM1	2
-- 
2.29.2


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply related	[flat|nested] 81+ messages in thread

* [PATCH v14 10/16] riscv: Add SiPeed MAIX BiT board device tree
  2021-02-02 10:36 [PATCH v14 00/16] RISC-V Kendryte K210 support improvements Damien Le Moal
@ 2021-02-02 10:36   ` Damien Le Moal
  2021-02-02 10:36   ` Damien Le Moal
                     ` (14 subsequent siblings)
  15 siblings, 0 replies; 81+ messages in thread
From: Damien Le Moal @ 2021-02-02 10:36 UTC (permalink / raw)
  To: Palmer Dabbelt, linux-riscv
  Cc: Atish Patra, Anup Patel, Sean Anderson, Rob Herring, devicetree

Add the device tree sipeed_maix_bit.dts for the SiPeed MAIX BiT and
MAIX BiTm boards. This device tree enables LEDs, gpio, i2c and spi/mmc
SD card devices.

Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
---
 .../riscv/boot/dts/canaan/sipeed_maix_bit.dts | 234 ++++++++++++++++++
 1 file changed, 234 insertions(+)
 create mode 100644 arch/riscv/boot/dts/canaan/sipeed_maix_bit.dts

diff --git a/arch/riscv/boot/dts/canaan/sipeed_maix_bit.dts b/arch/riscv/boot/dts/canaan/sipeed_maix_bit.dts
new file mode 100644
index 000000000000..11e491410f00
--- /dev/null
+++ b/arch/riscv/boot/dts/canaan/sipeed_maix_bit.dts
@@ -0,0 +1,234 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019-20 Sean Anderson <seanga2@gmail.com>
+ * Copyright (C) 2020 Western Digital Corporation or its affiliates.
+ */
+
+/dts-v1/;
+
+#include "k210.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+
+/ {
+	model = "SiPeed MAIX BiT";
+	compatible = "sipeed,maix-bit", "sipeed,maix-bitm",
+		     "canaan,kendryte-k210";
+
+	chosen {
+		bootargs = "earlycon console=ttySIF0";
+		stdout-path = "serial0:115200n8";
+	};
+
+	gpio-leds {
+		compatible = "gpio-leds";
+
+		led0 {
+			color = <LED_COLOR_ID_GREEN>;
+			label = "green";
+			gpios = <&gpio1_0 4 GPIO_ACTIVE_LOW>;
+		};
+
+		led1 {
+			color = <LED_COLOR_ID_RED>;
+			label = "red";
+			gpios = <&gpio1_0 5 GPIO_ACTIVE_LOW>;
+		};
+
+		led2 {
+			color = <LED_COLOR_ID_BLUE>;
+			label = "blue";
+			gpios = <&gpio1_0 6 GPIO_ACTIVE_LOW>;
+		};
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+
+		boot {
+			label = "BOOT";
+			linux,code = <BTN_0>;
+			gpios = <&gpio0 0 GPIO_ACTIVE_LOW>;
+		};
+	};
+
+	sound {
+		compatible = "simple-audio-card";
+		simple-audio-card,format = "i2s";
+		status = "disabled";
+
+		simple-audio-card,cpu {
+			sound-dai = <&i2s0 0>;
+		};
+
+		simple-audio-card,codec {
+			sound-dai = <&mic>;
+		};
+	};
+
+	mic: mic {
+		#sound-dai-cells = <0>;
+		compatible = "memsensing,msm261s4030h0";
+		status = "disabled";
+	};
+};
+
+&fpioa {
+	pinctrl-names = "default";
+	pinctrl-0 = <&jtag_pinctrl>;
+	status = "okay";
+
+	jtag_pinctrl: jtag-pinmux {
+		pinmux = <K210_FPIOA(0, K210_PCF_JTAG_TCLK)>,
+			 <K210_FPIOA(1, K210_PCF_JTAG_TDI)>,
+			 <K210_FPIOA(2, K210_PCF_JTAG_TMS)>,
+			 <K210_FPIOA(3, K210_PCF_JTAG_TDO)>;
+	};
+
+	uarths_pinctrl: uarths-pinmux {
+		pinmux = <K210_FPIOA(4, K210_PCF_UARTHS_RX)>,
+			 <K210_FPIOA(5, K210_PCF_UARTHS_TX)>;
+	};
+
+	gpio_pinctrl: gpio-pinmux {
+		pinmux = <K210_FPIOA(8, K210_PCF_GPIO0)>,
+			 <K210_FPIOA(9, K210_PCF_GPIO1)>,
+			 <K210_FPIOA(10, K210_PCF_GPIO2)>,
+			 <K210_FPIOA(11, K210_PCF_GPIO3)>,
+			 <K210_FPIOA(12, K210_PCF_GPIO4)>,
+			 <K210_FPIOA(13, K210_PCF_GPIO5)>,
+			 <K210_FPIOA(14, K210_PCF_GPIO6)>,
+			 <K210_FPIOA(15, K210_PCF_GPIO7)>;
+	};
+
+	gpiohs_pinctrl: gpiohs-pinmux {
+		pinmux = <K210_FPIOA(16, K210_PCF_GPIOHS0)>,
+			 <K210_FPIOA(17, K210_PCF_GPIOHS1)>,
+			 <K210_FPIOA(21, K210_PCF_GPIOHS5)>,
+			 <K210_FPIOA(22, K210_PCF_GPIOHS6)>,
+			 <K210_FPIOA(23, K210_PCF_GPIOHS7)>,
+			 <K210_FPIOA(24, K210_PCF_GPIOHS8)>,
+			 <K210_FPIOA(25, K210_PCF_GPIOHS9)>,
+			 <K210_FPIOA(32, K210_PCF_GPIOHS16)>,
+			 <K210_FPIOA(33, K210_PCF_GPIOHS17)>,
+			 <K210_FPIOA(34, K210_PCF_GPIOHS18)>,
+			 <K210_FPIOA(35, K210_PCF_GPIOHS19)>;
+	};
+
+	i2s0_pinctrl: i2s0-pinmux {
+		pinmux = <K210_FPIOA(18, K210_PCF_I2S0_SCLK)>,
+			 <K210_FPIOA(19, K210_PCF_I2S0_WS)>,
+			 <K210_FPIOA(20, K210_PCF_I2S0_IN_D0)>;
+	};
+
+	dvp_pinctrl: dvp-pinmux {
+		pinmux = <K210_FPIOA(40, K210_PCF_SCCB_SDA)>,
+			 <K210_FPIOA(41, K210_PCF_SCCB_SCLK)>,
+			 <K210_FPIOA(42, K210_PCF_DVP_RST)>,
+			 <K210_FPIOA(43, K210_PCF_DVP_VSYNC)>,
+			 <K210_FPIOA(44, K210_PCF_DVP_PWDN)>,
+			 <K210_FPIOA(45, K210_PCF_DVP_HSYNC)>,
+			 <K210_FPIOA(46, K210_PCF_DVP_XCLK)>,
+			 <K210_FPIOA(47, K210_PCF_DVP_PCLK)>;
+	};
+
+	spi0_pinctrl: spi0-pinmux {
+		pinmux = <K210_FPIOA(36, K210_PCF_GPIOHS20)>,  /* cs */
+			 <K210_FPIOA(37, K210_PCF_GPIOHS21)>,  /* rst */
+			 <K210_FPIOA(38, K210_PCF_GPIOHS22)>,  /* dc */
+			 <K210_FPIOA(39, K210_PCF_SPI0_SCLK)>; /* wr */
+	};
+
+	spi1_pinctrl: spi1-pinmux {
+		pinmux = <K210_FPIOA(26, K210_PCF_SPI1_D1)>,
+			 <K210_FPIOA(27, K210_PCF_SPI1_SCLK)>,
+			 <K210_FPIOA(28, K210_PCF_SPI1_D0)>,
+			 <K210_FPIOA(29, K210_PCF_GPIOHS13)>; /* cs */
+	};
+
+	i2c1_pinctrl: i2c1-pinmux {
+		pinmux = <K210_FPIOA(30, K210_PCF_I2C1_SCLK)>,
+			 <K210_FPIOA(31, K210_PCF_I2C1_SDA)>;
+	};
+};
+
+&uarths0 {
+	pinctrl-0 = <&uarths_pinctrl>;
+	pinctrl-names = "default";
+	status = "okay";
+};
+
+&gpio0 {
+	pinctrl-0 = <&gpiohs_pinctrl>;
+	pinctrl-names = "default";
+	status = "okay";
+};
+
+&gpio1 {
+	pinctrl-0 = <&gpio_pinctrl>;
+	pinctrl-names = "default";
+	status = "okay";
+};
+
+&i2s0 {
+	#sound-dai-cells = <1>;
+	pinctrl-0 = <&i2s0_pinctrl>;
+	pinctrl-names = "default";
+};
+
+&i2c1 {
+	pinctrl-0 = <&i2c1_pinctrl>;
+	pinctrl-names = "default";
+	clock-frequency = <400000>;
+	status = "okay";
+};
+
+&dvp0 {
+	pinctrl-0 = <&dvp_pinctrl>;
+	pinctrl-names = "default";
+};
+
+&spi0 {
+	pinctrl-0 = <&spi0_pinctrl>;
+	pinctrl-names = "default";
+	num-cs = <1>;
+	cs-gpios = <&gpio0 20 GPIO_ACTIVE_HIGH>;
+
+	panel@0 {
+		compatible = "sitronix,st7789v";
+		reg = <0>;
+		reset-gpios = <&gpio0 21 GPIO_ACTIVE_LOW>;
+		dc-gpios = <&gpio0 22 GPIO_ACTIVE_HIGH>;
+		spi-max-frequency = <15000000>;
+		spi-cs-high;
+		status = "disabled";
+	};
+};
+
+&spi1 {
+	pinctrl-0 = <&spi1_pinctrl>;
+	pinctrl-names = "default";
+	num-cs = <1>;
+	cs-gpios = <&gpio0 13 GPIO_ACTIVE_LOW>;
+	status = "okay";
+
+	slot@0 {
+		compatible = "mmc-spi-slot";
+		reg = <0>;
+		voltage-ranges = <3300 3300>;
+		spi-max-frequency = <25000000>;
+		broken-cd;
+	};
+};
+
+&spi3 {
+	spi-flash@0 {
+		compatible = "jedec,spi-nor";
+		reg = <0>;
+		spi-max-frequency = <50000000>;
+		m25p,fast-read;
+		broken-flash-reset;
+	};
+};
-- 
2.29.2


^ permalink raw reply related	[flat|nested] 81+ messages in thread

* [PATCH v14 10/16] riscv: Add SiPeed MAIX BiT board device tree
@ 2021-02-02 10:36   ` Damien Le Moal
  0 siblings, 0 replies; 81+ messages in thread
From: Damien Le Moal @ 2021-02-02 10:36 UTC (permalink / raw)
  To: Palmer Dabbelt, linux-riscv
  Cc: Atish Patra, devicetree, Anup Patel, Rob Herring, Sean Anderson

Add the device tree sipeed_maix_bit.dts for the SiPeed MAIX BiT and
MAIX BiTm boards. This device tree enables LEDs, gpio, i2c and spi/mmc
SD card devices.

Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
---
 .../riscv/boot/dts/canaan/sipeed_maix_bit.dts | 234 ++++++++++++++++++
 1 file changed, 234 insertions(+)
 create mode 100644 arch/riscv/boot/dts/canaan/sipeed_maix_bit.dts

diff --git a/arch/riscv/boot/dts/canaan/sipeed_maix_bit.dts b/arch/riscv/boot/dts/canaan/sipeed_maix_bit.dts
new file mode 100644
index 000000000000..11e491410f00
--- /dev/null
+++ b/arch/riscv/boot/dts/canaan/sipeed_maix_bit.dts
@@ -0,0 +1,234 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019-20 Sean Anderson <seanga2@gmail.com>
+ * Copyright (C) 2020 Western Digital Corporation or its affiliates.
+ */
+
+/dts-v1/;
+
+#include "k210.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+
+/ {
+	model = "SiPeed MAIX BiT";
+	compatible = "sipeed,maix-bit", "sipeed,maix-bitm",
+		     "canaan,kendryte-k210";
+
+	chosen {
+		bootargs = "earlycon console=ttySIF0";
+		stdout-path = "serial0:115200n8";
+	};
+
+	gpio-leds {
+		compatible = "gpio-leds";
+
+		led0 {
+			color = <LED_COLOR_ID_GREEN>;
+			label = "green";
+			gpios = <&gpio1_0 4 GPIO_ACTIVE_LOW>;
+		};
+
+		led1 {
+			color = <LED_COLOR_ID_RED>;
+			label = "red";
+			gpios = <&gpio1_0 5 GPIO_ACTIVE_LOW>;
+		};
+
+		led2 {
+			color = <LED_COLOR_ID_BLUE>;
+			label = "blue";
+			gpios = <&gpio1_0 6 GPIO_ACTIVE_LOW>;
+		};
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+
+		boot {
+			label = "BOOT";
+			linux,code = <BTN_0>;
+			gpios = <&gpio0 0 GPIO_ACTIVE_LOW>;
+		};
+	};
+
+	sound {
+		compatible = "simple-audio-card";
+		simple-audio-card,format = "i2s";
+		status = "disabled";
+
+		simple-audio-card,cpu {
+			sound-dai = <&i2s0 0>;
+		};
+
+		simple-audio-card,codec {
+			sound-dai = <&mic>;
+		};
+	};
+
+	mic: mic {
+		#sound-dai-cells = <0>;
+		compatible = "memsensing,msm261s4030h0";
+		status = "disabled";
+	};
+};
+
+&fpioa {
+	pinctrl-names = "default";
+	pinctrl-0 = <&jtag_pinctrl>;
+	status = "okay";
+
+	jtag_pinctrl: jtag-pinmux {
+		pinmux = <K210_FPIOA(0, K210_PCF_JTAG_TCLK)>,
+			 <K210_FPIOA(1, K210_PCF_JTAG_TDI)>,
+			 <K210_FPIOA(2, K210_PCF_JTAG_TMS)>,
+			 <K210_FPIOA(3, K210_PCF_JTAG_TDO)>;
+	};
+
+	uarths_pinctrl: uarths-pinmux {
+		pinmux = <K210_FPIOA(4, K210_PCF_UARTHS_RX)>,
+			 <K210_FPIOA(5, K210_PCF_UARTHS_TX)>;
+	};
+
+	gpio_pinctrl: gpio-pinmux {
+		pinmux = <K210_FPIOA(8, K210_PCF_GPIO0)>,
+			 <K210_FPIOA(9, K210_PCF_GPIO1)>,
+			 <K210_FPIOA(10, K210_PCF_GPIO2)>,
+			 <K210_FPIOA(11, K210_PCF_GPIO3)>,
+			 <K210_FPIOA(12, K210_PCF_GPIO4)>,
+			 <K210_FPIOA(13, K210_PCF_GPIO5)>,
+			 <K210_FPIOA(14, K210_PCF_GPIO6)>,
+			 <K210_FPIOA(15, K210_PCF_GPIO7)>;
+	};
+
+	gpiohs_pinctrl: gpiohs-pinmux {
+		pinmux = <K210_FPIOA(16, K210_PCF_GPIOHS0)>,
+			 <K210_FPIOA(17, K210_PCF_GPIOHS1)>,
+			 <K210_FPIOA(21, K210_PCF_GPIOHS5)>,
+			 <K210_FPIOA(22, K210_PCF_GPIOHS6)>,
+			 <K210_FPIOA(23, K210_PCF_GPIOHS7)>,
+			 <K210_FPIOA(24, K210_PCF_GPIOHS8)>,
+			 <K210_FPIOA(25, K210_PCF_GPIOHS9)>,
+			 <K210_FPIOA(32, K210_PCF_GPIOHS16)>,
+			 <K210_FPIOA(33, K210_PCF_GPIOHS17)>,
+			 <K210_FPIOA(34, K210_PCF_GPIOHS18)>,
+			 <K210_FPIOA(35, K210_PCF_GPIOHS19)>;
+	};
+
+	i2s0_pinctrl: i2s0-pinmux {
+		pinmux = <K210_FPIOA(18, K210_PCF_I2S0_SCLK)>,
+			 <K210_FPIOA(19, K210_PCF_I2S0_WS)>,
+			 <K210_FPIOA(20, K210_PCF_I2S0_IN_D0)>;
+	};
+
+	dvp_pinctrl: dvp-pinmux {
+		pinmux = <K210_FPIOA(40, K210_PCF_SCCB_SDA)>,
+			 <K210_FPIOA(41, K210_PCF_SCCB_SCLK)>,
+			 <K210_FPIOA(42, K210_PCF_DVP_RST)>,
+			 <K210_FPIOA(43, K210_PCF_DVP_VSYNC)>,
+			 <K210_FPIOA(44, K210_PCF_DVP_PWDN)>,
+			 <K210_FPIOA(45, K210_PCF_DVP_HSYNC)>,
+			 <K210_FPIOA(46, K210_PCF_DVP_XCLK)>,
+			 <K210_FPIOA(47, K210_PCF_DVP_PCLK)>;
+	};
+
+	spi0_pinctrl: spi0-pinmux {
+		pinmux = <K210_FPIOA(36, K210_PCF_GPIOHS20)>,  /* cs */
+			 <K210_FPIOA(37, K210_PCF_GPIOHS21)>,  /* rst */
+			 <K210_FPIOA(38, K210_PCF_GPIOHS22)>,  /* dc */
+			 <K210_FPIOA(39, K210_PCF_SPI0_SCLK)>; /* wr */
+	};
+
+	spi1_pinctrl: spi1-pinmux {
+		pinmux = <K210_FPIOA(26, K210_PCF_SPI1_D1)>,
+			 <K210_FPIOA(27, K210_PCF_SPI1_SCLK)>,
+			 <K210_FPIOA(28, K210_PCF_SPI1_D0)>,
+			 <K210_FPIOA(29, K210_PCF_GPIOHS13)>; /* cs */
+	};
+
+	i2c1_pinctrl: i2c1-pinmux {
+		pinmux = <K210_FPIOA(30, K210_PCF_I2C1_SCLK)>,
+			 <K210_FPIOA(31, K210_PCF_I2C1_SDA)>;
+	};
+};
+
+&uarths0 {
+	pinctrl-0 = <&uarths_pinctrl>;
+	pinctrl-names = "default";
+	status = "okay";
+};
+
+&gpio0 {
+	pinctrl-0 = <&gpiohs_pinctrl>;
+	pinctrl-names = "default";
+	status = "okay";
+};
+
+&gpio1 {
+	pinctrl-0 = <&gpio_pinctrl>;
+	pinctrl-names = "default";
+	status = "okay";
+};
+
+&i2s0 {
+	#sound-dai-cells = <1>;
+	pinctrl-0 = <&i2s0_pinctrl>;
+	pinctrl-names = "default";
+};
+
+&i2c1 {
+	pinctrl-0 = <&i2c1_pinctrl>;
+	pinctrl-names = "default";
+	clock-frequency = <400000>;
+	status = "okay";
+};
+
+&dvp0 {
+	pinctrl-0 = <&dvp_pinctrl>;
+	pinctrl-names = "default";
+};
+
+&spi0 {
+	pinctrl-0 = <&spi0_pinctrl>;
+	pinctrl-names = "default";
+	num-cs = <1>;
+	cs-gpios = <&gpio0 20 GPIO_ACTIVE_HIGH>;
+
+	panel@0 {
+		compatible = "sitronix,st7789v";
+		reg = <0>;
+		reset-gpios = <&gpio0 21 GPIO_ACTIVE_LOW>;
+		dc-gpios = <&gpio0 22 GPIO_ACTIVE_HIGH>;
+		spi-max-frequency = <15000000>;
+		spi-cs-high;
+		status = "disabled";
+	};
+};
+
+&spi1 {
+	pinctrl-0 = <&spi1_pinctrl>;
+	pinctrl-names = "default";
+	num-cs = <1>;
+	cs-gpios = <&gpio0 13 GPIO_ACTIVE_LOW>;
+	status = "okay";
+
+	slot@0 {
+		compatible = "mmc-spi-slot";
+		reg = <0>;
+		voltage-ranges = <3300 3300>;
+		spi-max-frequency = <25000000>;
+		broken-cd;
+	};
+};
+
+&spi3 {
+	spi-flash@0 {
+		compatible = "jedec,spi-nor";
+		reg = <0>;
+		spi-max-frequency = <50000000>;
+		m25p,fast-read;
+		broken-flash-reset;
+	};
+};
-- 
2.29.2


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply related	[flat|nested] 81+ messages in thread

* [PATCH v14 11/16] riscv: Add SiPeed MAIX DOCK board device tree
  2021-02-02 10:36 [PATCH v14 00/16] RISC-V Kendryte K210 support improvements Damien Le Moal
@ 2021-02-02 10:36   ` Damien Le Moal
  2021-02-02 10:36   ` Damien Le Moal
                     ` (14 subsequent siblings)
  15 siblings, 0 replies; 81+ messages in thread
From: Damien Le Moal @ 2021-02-02 10:36 UTC (permalink / raw)
  To: Palmer Dabbelt, linux-riscv
  Cc: Atish Patra, Anup Patel, Sean Anderson, Rob Herring, devicetree

Add the device tree sipeed_maix_dock.dts for the SiPeed MAIX DOCK m1
and m1w boards. This device tree enables LEDs, gpio, i2c and spi/mmc
SD card devices.

Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
---
 .../boot/dts/canaan/sipeed_maix_dock.dts      | 236 ++++++++++++++++++
 1 file changed, 236 insertions(+)
 create mode 100644 arch/riscv/boot/dts/canaan/sipeed_maix_dock.dts

diff --git a/arch/riscv/boot/dts/canaan/sipeed_maix_dock.dts b/arch/riscv/boot/dts/canaan/sipeed_maix_dock.dts
new file mode 100644
index 000000000000..fae0149a8740
--- /dev/null
+++ b/arch/riscv/boot/dts/canaan/sipeed_maix_dock.dts
@@ -0,0 +1,236 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019-20 Sean Anderson <seanga2@gmail.com>
+ * Copyright (C) 2020 Western Digital Corporation or its affiliates.
+ */
+
+/dts-v1/;
+
+#include "k210.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+
+/ {
+	model = "SiPeed MAIX Dock";
+	compatible = "sipeed,maix-dock-m1", "sipeed,maix-dock-m1w",
+		     "canaan,kendryte-k210";
+
+	chosen {
+		bootargs = "earlycon console=ttySIF0";
+		stdout-path = "serial0:115200n8";
+	};
+
+	gpio-leds {
+		compatible = "gpio-leds";
+
+		/*
+		 * Note: the board wiring drawing documents green on
+		 * gpio #4, red on gpio #5 and blue on gpio #6. However,
+		 * the board is actually wired differently as defined here.
+		 */
+		led0 {
+			color = <LED_COLOR_ID_BLUE>;
+			label = "blue";
+			gpios = <&gpio1_0 4 GPIO_ACTIVE_LOW>;
+		};
+
+		led1 {
+			color = <LED_COLOR_ID_GREEN>;
+			label = "green";
+			gpios = <&gpio1_0 5 GPIO_ACTIVE_LOW>;
+		};
+
+		led2 {
+			color = <LED_COLOR_ID_RED>;
+			label = "red";
+			gpios = <&gpio1_0 6 GPIO_ACTIVE_LOW>;
+		};
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+
+		boot {
+			label = "BOOT";
+			linux,code = <BTN_0>;
+			gpios = <&gpio0 0 GPIO_ACTIVE_LOW>;
+		};
+	};
+
+	sound {
+		compatible = "simple-audio-card";
+		simple-audio-card,format = "i2s";
+		status = "disabled";
+
+		simple-audio-card,cpu {
+			sound-dai = <&i2s0 0>;
+		};
+
+		simple-audio-card,codec {
+			sound-dai = <&mic>;
+		};
+	};
+
+	mic: mic {
+		#sound-dai-cells = <0>;
+		compatible = "memsensing,msm261s4030h0";
+		status = "disabled";
+	};
+};
+
+&fpioa {
+	pinctrl-0 = <&jtag_pinctrl>;
+	pinctrl-names = "default";
+	status = "okay";
+
+	jtag_pinctrl: jtag-pinmux {
+		pinmux = <K210_FPIOA(0, K210_PCF_JTAG_TCLK)>,
+			 <K210_FPIOA(1, K210_PCF_JTAG_TDI)>,
+			 <K210_FPIOA(2, K210_PCF_JTAG_TMS)>,
+			 <K210_FPIOA(3, K210_PCF_JTAG_TDO)>;
+	};
+
+	uarths_pinctrl: uarths-pinmux {
+		pinmux = <K210_FPIOA(4, K210_PCF_UARTHS_RX)>,
+			 <K210_FPIOA(5, K210_PCF_UARTHS_TX)>;
+	};
+
+	gpio_pinctrl: gpio-pinmux {
+		pinmux = <K210_FPIOA(8, K210_PCF_GPIO0)>,
+			 <K210_FPIOA(11, K210_PCF_GPIO3)>,
+			 <K210_FPIOA(12, K210_PCF_GPIO4)>,
+			 <K210_FPIOA(13, K210_PCF_GPIO5)>,
+			 <K210_FPIOA(14, K210_PCF_GPIO6)>,
+			 <K210_FPIOA(15, K210_PCF_GPIO7)>;
+	};
+
+	gpiohs_pinctrl: gpiohs-pinmux {
+		pinmux = <K210_FPIOA(16, K210_PCF_GPIOHS0)>,
+			 <K210_FPIOA(17, K210_PCF_GPIOHS1)>,
+			 <K210_FPIOA(21, K210_PCF_GPIOHS5)>,
+			 <K210_FPIOA(22, K210_PCF_GPIOHS6)>,
+			 <K210_FPIOA(23, K210_PCF_GPIOHS7)>,
+			 <K210_FPIOA(24, K210_PCF_GPIOHS8)>,
+			 <K210_FPIOA(25, K210_PCF_GPIOHS9)>,
+			 <K210_FPIOA(32, K210_PCF_GPIOHS16)>,
+			 <K210_FPIOA(33, K210_PCF_GPIOHS17)>,
+			 <K210_FPIOA(34, K210_PCF_GPIOHS18)>,
+			 <K210_FPIOA(35, K210_PCF_GPIOHS19)>;
+	};
+
+	i2s0_pinctrl: i2s0-pinmux {
+		pinmux = <K210_FPIOA(18, K210_PCF_I2S0_SCLK)>,
+			 <K210_FPIOA(19, K210_PCF_I2S0_WS)>,
+			 <K210_FPIOA(20, K210_PCF_I2S0_IN_D0)>;
+	};
+
+	dvp_pinctrl: dvp-pinmux {
+		pinmux = <K210_FPIOA(40, K210_PCF_SCCB_SDA)>,
+			 <K210_FPIOA(41, K210_PCF_SCCB_SCLK)>,
+			 <K210_FPIOA(42, K210_PCF_DVP_RST)>,
+			 <K210_FPIOA(43, K210_PCF_DVP_VSYNC)>,
+			 <K210_FPIOA(44, K210_PCF_DVP_PWDN)>,
+			 <K210_FPIOA(45, K210_PCF_DVP_HSYNC)>,
+			 <K210_FPIOA(46, K210_PCF_DVP_XCLK)>,
+			 <K210_FPIOA(47, K210_PCF_DVP_PCLK)>;
+	};
+
+	spi0_pinctrl: spi0-pinmux {
+		pinmux = <K210_FPIOA(36, K210_PCF_GPIOHS20)>,  /* cs */
+			 <K210_FPIOA(37, K210_PCF_GPIOHS21)>,  /* rst */
+			 <K210_FPIOA(38, K210_PCF_GPIOHS22)>,  /* dc */
+			 <K210_FPIOA(39, K210_PCF_SPI0_SCLK)>; /* wr */
+	};
+
+	spi1_pinctrl: spi1-pinmux {
+		pinmux = <K210_FPIOA(26, K210_PCF_SPI1_D1)>,
+			 <K210_FPIOA(27, K210_PCF_SPI1_SCLK)>,
+			 <K210_FPIOA(28, K210_PCF_SPI1_D0)>,
+			 <K210_FPIOA(29, K210_PCF_GPIOHS13)>; /* cs */
+	};
+
+	i2c1_pinctrl: i2c1-pinmux {
+		pinmux = <K210_FPIOA(9, K210_PCF_I2C1_SCLK)>,
+			 <K210_FPIOA(10, K210_PCF_I2C1_SDA)>;
+	};
+};
+
+&uarths0 {
+	pinctrl-0 = <&uarths_pinctrl>;
+	pinctrl-names = "default";
+	status = "okay";
+};
+
+&gpio0 {
+	pinctrl-0 = <&gpiohs_pinctrl>;
+	pinctrl-names = "default";
+	status = "okay";
+};
+
+&gpio1 {
+	pinctrl-0 = <&gpio_pinctrl>;
+	pinctrl-names = "default";
+	status = "okay";
+};
+
+&i2s0 {
+	#sound-dai-cells = <1>;
+	pinctrl-0 = <&i2s0_pinctrl>;
+	pinctrl-names = "default";
+};
+
+&i2c1 {
+	pinctrl-0 = <&i2c1_pinctrl>;
+	pinctrl-names = "default";
+	clock-frequency = <400000>;
+	status = "okay";
+};
+
+&dvp0 {
+	pinctrl-0 = <&dvp_pinctrl>;
+	pinctrl-names = "default";
+};
+
+&spi0 {
+	pinctrl-0 = <&spi0_pinctrl>;
+	pinctrl-names = "default";
+	num-cs = <1>;
+	cs-gpios = <&gpio0 20 GPIO_ACTIVE_HIGH>;
+
+	panel@0 {
+		compatible = "sitronix,st7789v";
+		reg = <0>;
+		reset-gpios = <&gpio0 21 GPIO_ACTIVE_LOW>;
+		dc-gpios = <&gpio0 22 0>;
+		spi-max-frequency = <15000000>;
+		status = "disabled";
+	};
+};
+
+&spi1 {
+	pinctrl-0 = <&spi1_pinctrl>;
+	pinctrl-names = "default";
+	num-cs = <1>;
+	cs-gpios = <&gpio0 13 GPIO_ACTIVE_LOW>;
+	status = "okay";
+
+	slot@0 {
+		compatible = "mmc-spi-slot";
+		reg = <0>;
+		voltage-ranges = <3300 3300>;
+		spi-max-frequency = <25000000>;
+		broken-cd;
+	};
+};
+
+&spi3 {
+	spi-flash@0 {
+		compatible = "jedec,spi-nor";
+		reg = <0>;
+		spi-max-frequency = <50000000>;
+		m25p,fast-read;
+		broken-flash-reset;
+	};
+};
-- 
2.29.2


^ permalink raw reply related	[flat|nested] 81+ messages in thread

* [PATCH v14 11/16] riscv: Add SiPeed MAIX DOCK board device tree
@ 2021-02-02 10:36   ` Damien Le Moal
  0 siblings, 0 replies; 81+ messages in thread
From: Damien Le Moal @ 2021-02-02 10:36 UTC (permalink / raw)
  To: Palmer Dabbelt, linux-riscv
  Cc: Atish Patra, devicetree, Anup Patel, Rob Herring, Sean Anderson

Add the device tree sipeed_maix_dock.dts for the SiPeed MAIX DOCK m1
and m1w boards. This device tree enables LEDs, gpio, i2c and spi/mmc
SD card devices.

Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
---
 .../boot/dts/canaan/sipeed_maix_dock.dts      | 236 ++++++++++++++++++
 1 file changed, 236 insertions(+)
 create mode 100644 arch/riscv/boot/dts/canaan/sipeed_maix_dock.dts

diff --git a/arch/riscv/boot/dts/canaan/sipeed_maix_dock.dts b/arch/riscv/boot/dts/canaan/sipeed_maix_dock.dts
new file mode 100644
index 000000000000..fae0149a8740
--- /dev/null
+++ b/arch/riscv/boot/dts/canaan/sipeed_maix_dock.dts
@@ -0,0 +1,236 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019-20 Sean Anderson <seanga2@gmail.com>
+ * Copyright (C) 2020 Western Digital Corporation or its affiliates.
+ */
+
+/dts-v1/;
+
+#include "k210.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+
+/ {
+	model = "SiPeed MAIX Dock";
+	compatible = "sipeed,maix-dock-m1", "sipeed,maix-dock-m1w",
+		     "canaan,kendryte-k210";
+
+	chosen {
+		bootargs = "earlycon console=ttySIF0";
+		stdout-path = "serial0:115200n8";
+	};
+
+	gpio-leds {
+		compatible = "gpio-leds";
+
+		/*
+		 * Note: the board wiring drawing documents green on
+		 * gpio #4, red on gpio #5 and blue on gpio #6. However,
+		 * the board is actually wired differently as defined here.
+		 */
+		led0 {
+			color = <LED_COLOR_ID_BLUE>;
+			label = "blue";
+			gpios = <&gpio1_0 4 GPIO_ACTIVE_LOW>;
+		};
+
+		led1 {
+			color = <LED_COLOR_ID_GREEN>;
+			label = "green";
+			gpios = <&gpio1_0 5 GPIO_ACTIVE_LOW>;
+		};
+
+		led2 {
+			color = <LED_COLOR_ID_RED>;
+			label = "red";
+			gpios = <&gpio1_0 6 GPIO_ACTIVE_LOW>;
+		};
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+
+		boot {
+			label = "BOOT";
+			linux,code = <BTN_0>;
+			gpios = <&gpio0 0 GPIO_ACTIVE_LOW>;
+		};
+	};
+
+	sound {
+		compatible = "simple-audio-card";
+		simple-audio-card,format = "i2s";
+		status = "disabled";
+
+		simple-audio-card,cpu {
+			sound-dai = <&i2s0 0>;
+		};
+
+		simple-audio-card,codec {
+			sound-dai = <&mic>;
+		};
+	};
+
+	mic: mic {
+		#sound-dai-cells = <0>;
+		compatible = "memsensing,msm261s4030h0";
+		status = "disabled";
+	};
+};
+
+&fpioa {
+	pinctrl-0 = <&jtag_pinctrl>;
+	pinctrl-names = "default";
+	status = "okay";
+
+	jtag_pinctrl: jtag-pinmux {
+		pinmux = <K210_FPIOA(0, K210_PCF_JTAG_TCLK)>,
+			 <K210_FPIOA(1, K210_PCF_JTAG_TDI)>,
+			 <K210_FPIOA(2, K210_PCF_JTAG_TMS)>,
+			 <K210_FPIOA(3, K210_PCF_JTAG_TDO)>;
+	};
+
+	uarths_pinctrl: uarths-pinmux {
+		pinmux = <K210_FPIOA(4, K210_PCF_UARTHS_RX)>,
+			 <K210_FPIOA(5, K210_PCF_UARTHS_TX)>;
+	};
+
+	gpio_pinctrl: gpio-pinmux {
+		pinmux = <K210_FPIOA(8, K210_PCF_GPIO0)>,
+			 <K210_FPIOA(11, K210_PCF_GPIO3)>,
+			 <K210_FPIOA(12, K210_PCF_GPIO4)>,
+			 <K210_FPIOA(13, K210_PCF_GPIO5)>,
+			 <K210_FPIOA(14, K210_PCF_GPIO6)>,
+			 <K210_FPIOA(15, K210_PCF_GPIO7)>;
+	};
+
+	gpiohs_pinctrl: gpiohs-pinmux {
+		pinmux = <K210_FPIOA(16, K210_PCF_GPIOHS0)>,
+			 <K210_FPIOA(17, K210_PCF_GPIOHS1)>,
+			 <K210_FPIOA(21, K210_PCF_GPIOHS5)>,
+			 <K210_FPIOA(22, K210_PCF_GPIOHS6)>,
+			 <K210_FPIOA(23, K210_PCF_GPIOHS7)>,
+			 <K210_FPIOA(24, K210_PCF_GPIOHS8)>,
+			 <K210_FPIOA(25, K210_PCF_GPIOHS9)>,
+			 <K210_FPIOA(32, K210_PCF_GPIOHS16)>,
+			 <K210_FPIOA(33, K210_PCF_GPIOHS17)>,
+			 <K210_FPIOA(34, K210_PCF_GPIOHS18)>,
+			 <K210_FPIOA(35, K210_PCF_GPIOHS19)>;
+	};
+
+	i2s0_pinctrl: i2s0-pinmux {
+		pinmux = <K210_FPIOA(18, K210_PCF_I2S0_SCLK)>,
+			 <K210_FPIOA(19, K210_PCF_I2S0_WS)>,
+			 <K210_FPIOA(20, K210_PCF_I2S0_IN_D0)>;
+	};
+
+	dvp_pinctrl: dvp-pinmux {
+		pinmux = <K210_FPIOA(40, K210_PCF_SCCB_SDA)>,
+			 <K210_FPIOA(41, K210_PCF_SCCB_SCLK)>,
+			 <K210_FPIOA(42, K210_PCF_DVP_RST)>,
+			 <K210_FPIOA(43, K210_PCF_DVP_VSYNC)>,
+			 <K210_FPIOA(44, K210_PCF_DVP_PWDN)>,
+			 <K210_FPIOA(45, K210_PCF_DVP_HSYNC)>,
+			 <K210_FPIOA(46, K210_PCF_DVP_XCLK)>,
+			 <K210_FPIOA(47, K210_PCF_DVP_PCLK)>;
+	};
+
+	spi0_pinctrl: spi0-pinmux {
+		pinmux = <K210_FPIOA(36, K210_PCF_GPIOHS20)>,  /* cs */
+			 <K210_FPIOA(37, K210_PCF_GPIOHS21)>,  /* rst */
+			 <K210_FPIOA(38, K210_PCF_GPIOHS22)>,  /* dc */
+			 <K210_FPIOA(39, K210_PCF_SPI0_SCLK)>; /* wr */
+	};
+
+	spi1_pinctrl: spi1-pinmux {
+		pinmux = <K210_FPIOA(26, K210_PCF_SPI1_D1)>,
+			 <K210_FPIOA(27, K210_PCF_SPI1_SCLK)>,
+			 <K210_FPIOA(28, K210_PCF_SPI1_D0)>,
+			 <K210_FPIOA(29, K210_PCF_GPIOHS13)>; /* cs */
+	};
+
+	i2c1_pinctrl: i2c1-pinmux {
+		pinmux = <K210_FPIOA(9, K210_PCF_I2C1_SCLK)>,
+			 <K210_FPIOA(10, K210_PCF_I2C1_SDA)>;
+	};
+};
+
+&uarths0 {
+	pinctrl-0 = <&uarths_pinctrl>;
+	pinctrl-names = "default";
+	status = "okay";
+};
+
+&gpio0 {
+	pinctrl-0 = <&gpiohs_pinctrl>;
+	pinctrl-names = "default";
+	status = "okay";
+};
+
+&gpio1 {
+	pinctrl-0 = <&gpio_pinctrl>;
+	pinctrl-names = "default";
+	status = "okay";
+};
+
+&i2s0 {
+	#sound-dai-cells = <1>;
+	pinctrl-0 = <&i2s0_pinctrl>;
+	pinctrl-names = "default";
+};
+
+&i2c1 {
+	pinctrl-0 = <&i2c1_pinctrl>;
+	pinctrl-names = "default";
+	clock-frequency = <400000>;
+	status = "okay";
+};
+
+&dvp0 {
+	pinctrl-0 = <&dvp_pinctrl>;
+	pinctrl-names = "default";
+};
+
+&spi0 {
+	pinctrl-0 = <&spi0_pinctrl>;
+	pinctrl-names = "default";
+	num-cs = <1>;
+	cs-gpios = <&gpio0 20 GPIO_ACTIVE_HIGH>;
+
+	panel@0 {
+		compatible = "sitronix,st7789v";
+		reg = <0>;
+		reset-gpios = <&gpio0 21 GPIO_ACTIVE_LOW>;
+		dc-gpios = <&gpio0 22 0>;
+		spi-max-frequency = <15000000>;
+		status = "disabled";
+	};
+};
+
+&spi1 {
+	pinctrl-0 = <&spi1_pinctrl>;
+	pinctrl-names = "default";
+	num-cs = <1>;
+	cs-gpios = <&gpio0 13 GPIO_ACTIVE_LOW>;
+	status = "okay";
+
+	slot@0 {
+		compatible = "mmc-spi-slot";
+		reg = <0>;
+		voltage-ranges = <3300 3300>;
+		spi-max-frequency = <25000000>;
+		broken-cd;
+	};
+};
+
+&spi3 {
+	spi-flash@0 {
+		compatible = "jedec,spi-nor";
+		reg = <0>;
+		spi-max-frequency = <50000000>;
+		m25p,fast-read;
+		broken-flash-reset;
+	};
+};
-- 
2.29.2


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply related	[flat|nested] 81+ messages in thread

* [PATCH v14 12/16] riscv: Add SiPeed MAIX GO board device tree
  2021-02-02 10:36 [PATCH v14 00/16] RISC-V Kendryte K210 support improvements Damien Le Moal
@ 2021-02-02 10:36   ` Damien Le Moal
  2021-02-02 10:36   ` Damien Le Moal
                     ` (14 subsequent siblings)
  15 siblings, 0 replies; 81+ messages in thread
From: Damien Le Moal @ 2021-02-02 10:36 UTC (permalink / raw)
  To: Palmer Dabbelt, linux-riscv
  Cc: Atish Patra, Anup Patel, Sean Anderson, Rob Herring, devicetree

Add the device tree sipeed_maix_go.dts for the SiPeed MAIX GO board.
This device tree enables buttons, LEDs, gpio, i2c and spi/mmc SD card
devices.

Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
---
 arch/riscv/boot/dts/canaan/sipeed_maix_go.dts | 244 ++++++++++++++++++
 1 file changed, 244 insertions(+)
 create mode 100644 arch/riscv/boot/dts/canaan/sipeed_maix_go.dts

diff --git a/arch/riscv/boot/dts/canaan/sipeed_maix_go.dts b/arch/riscv/boot/dts/canaan/sipeed_maix_go.dts
new file mode 100644
index 000000000000..373fbaa3ab94
--- /dev/null
+++ b/arch/riscv/boot/dts/canaan/sipeed_maix_go.dts
@@ -0,0 +1,244 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019-20 Sean Anderson <seanga2@gmail.com>
+ * Copyright (C) 2020 Western Digital Corporation or its affiliates.
+ */
+
+/dts-v1/;
+
+#include "k210.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+
+/ {
+	model = "SiPeed MAIX GO";
+	compatible = "sipeed,maix-go", "canaan,kendryte-k210";
+
+	chosen {
+		bootargs = "earlycon console=ttySIF0";
+		stdout-path = "serial0:115200n8";
+	};
+
+	gpio-leds {
+		compatible = "gpio-leds";
+
+		led0 {
+			color = <LED_COLOR_ID_GREEN>;
+			label = "green";
+			gpios = <&gpio1_0 4 GPIO_ACTIVE_LOW>;
+		};
+
+		led1 {
+			color = <LED_COLOR_ID_RED>;
+			label = "red";
+			gpios = <&gpio1_0 5 GPIO_ACTIVE_LOW>;
+		};
+
+		led2 {
+			color = <LED_COLOR_ID_BLUE>;
+			label = "blue";
+			gpios = <&gpio1_0 6 GPIO_ACTIVE_LOW>;
+		};
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+
+		up {
+			label = "UP";
+			linux,code = <BTN_1>;
+			gpios = <&gpio1_0 7 GPIO_ACTIVE_LOW>;
+		};
+
+		press {
+			label = "PRESS";
+			linux,code = <BTN_0>;
+			gpios = <&gpio0 0 GPIO_ACTIVE_LOW>;
+		};
+
+		down {
+			label = "DOWN";
+			linux,code = <BTN_2>;
+			gpios = <&gpio0 1 GPIO_ACTIVE_LOW>;
+		};
+	};
+
+	sound {
+		compatible = "simple-audio-card";
+		simple-audio-card,format = "i2s";
+		status = "disabled";
+
+		simple-audio-card,cpu {
+			sound-dai = <&i2s0 0>;
+		};
+
+		simple-audio-card,codec {
+			sound-dai = <&mic>;
+		};
+	};
+
+	mic: mic {
+		#sound-dai-cells = <0>;
+		compatible = "memsensing,msm261s4030h0";
+		status = "disabled";
+	};
+};
+
+&fpioa {
+	pinctrl-0 = <&jtag_pinctrl>;
+	pinctrl-names = "default";
+	status = "okay";
+
+	jtag_pinctrl: jtag-pinmux {
+		pinmux = <K210_FPIOA(0, K210_PCF_JTAG_TCLK)>,
+			 <K210_FPIOA(1, K210_PCF_JTAG_TDI)>,
+			 <K210_FPIOA(2, K210_PCF_JTAG_TMS)>,
+			 <K210_FPIOA(3, K210_PCF_JTAG_TDO)>;
+	};
+
+	uarths_pinctrl: uarths-pinmux {
+		pinmux = <K210_FPIOA(4, K210_PCF_UARTHS_RX)>,
+			 <K210_FPIOA(5, K210_PCF_UARTHS_TX)>;
+	};
+
+	gpio_pinctrl: gpio-pinmux {
+		pinmux = <K210_FPIOA(8, K210_PCF_GPIO0)>,
+			 <K210_FPIOA(9, K210_PCF_GPIO1)>,
+			 <K210_FPIOA(10, K210_PCF_GPIO2)>,
+			 <K210_FPIOA(11, K210_PCF_GPIO3)>,
+			 <K210_FPIOA(12, K210_PCF_GPIO4)>,
+			 <K210_FPIOA(13, K210_PCF_GPIO5)>,
+			 <K210_FPIOA(14, K210_PCF_GPIO6)>,
+			 <K210_FPIOA(15, K210_PCF_GPIO7)>;
+	};
+
+	gpiohs_pinctrl: gpiohs-pinmux {
+		pinmux = <K210_FPIOA(16, K210_PCF_GPIOHS0)>,
+			 <K210_FPIOA(17, K210_PCF_GPIOHS1)>,
+			 <K210_FPIOA(21, K210_PCF_GPIOHS5)>,
+			 <K210_FPIOA(22, K210_PCF_GPIOHS6)>,
+			 <K210_FPIOA(23, K210_PCF_GPIOHS7)>,
+			 <K210_FPIOA(24, K210_PCF_GPIOHS8)>,
+			 <K210_FPIOA(25, K210_PCF_GPIOHS9)>,
+			 <K210_FPIOA(32, K210_PCF_GPIOHS16)>,
+			 <K210_FPIOA(33, K210_PCF_GPIOHS17)>,
+			 <K210_FPIOA(34, K210_PCF_GPIOHS18)>,
+			 <K210_FPIOA(35, K210_PCF_GPIOHS19)>;
+	};
+
+	i2s0_pinctrl: i2s0-pinmux {
+		pinmux = <K210_FPIOA(18, K210_PCF_I2S0_SCLK)>,
+			 <K210_FPIOA(19, K210_PCF_I2S0_WS)>,
+			 <K210_FPIOA(20, K210_PCF_I2S0_IN_D0)>;
+	};
+
+	dvp_pinctrl: dvp-pinmux {
+		pinmux = <K210_FPIOA(40, K210_PCF_SCCB_SDA)>,
+			 <K210_FPIOA(41, K210_PCF_SCCB_SCLK)>,
+			 <K210_FPIOA(42, K210_PCF_DVP_RST)>,
+			 <K210_FPIOA(43, K210_PCF_DVP_VSYNC)>,
+			 <K210_FPIOA(44, K210_PCF_DVP_PWDN)>,
+			 <K210_FPIOA(45, K210_PCF_DVP_HSYNC)>,
+			 <K210_FPIOA(46, K210_PCF_DVP_XCLK)>,
+			 <K210_FPIOA(47, K210_PCF_DVP_PCLK)>;
+	};
+
+	spi0_pinctrl: spi0-pinmux {
+		pinmux = <K210_FPIOA(36, K210_PCF_GPIOHS20)>,  /* cs */
+			 <K210_FPIOA(37, K210_PCF_GPIOHS21)>,  /* rst */
+			 <K210_FPIOA(38, K210_PCF_GPIOHS22)>,  /* dc */
+			 <K210_FPIOA(39, K210_PCF_SPI0_SCLK)>; /* wr */
+	};
+
+	spi1_pinctrl: spi1-pinmux {
+		pinmux = <K210_FPIOA(26, K210_PCF_SPI1_D1)>,
+			 <K210_FPIOA(27, K210_PCF_SPI1_SCLK)>,
+			 <K210_FPIOA(28, K210_PCF_SPI1_D0)>,
+			 <K210_FPIOA(29, K210_PCF_GPIOHS13)>; /* cs */
+	};
+
+	i2c1_pinctrl: i2c1-pinmux {
+		pinmux = <K210_FPIOA(30, K210_PCF_I2C1_SCLK)>,
+			 <K210_FPIOA(31, K210_PCF_I2C1_SDA)>;
+	};
+};
+
+&uarths0 {
+	pinctrl-0 = <&uarths_pinctrl>;
+	pinctrl-names = "default";
+	status = "okay";
+};
+
+&gpio0 {
+	pinctrl-0 = <&gpiohs_pinctrl>;
+	pinctrl-names = "default";
+	status = "okay";
+};
+
+&gpio1 {
+	pinctrl-0 = <&gpio_pinctrl>;
+	pinctrl-names = "default";
+	status = "okay";
+};
+
+&i2s0 {
+	#sound-dai-cells = <1>;
+	pinctrl-0 = <&i2s0_pinctrl>;
+	pinctrl-names = "default";
+};
+
+&i2c1 {
+	pinctrl-0 = <&i2c1_pinctrl>;
+	pinctrl-names = "default";
+	clock-frequency = <400000>;
+	status = "okay";
+};
+
+&dvp0 {
+	pinctrl-0 = <&dvp_pinctrl>;
+	pinctrl-names = "default";
+};
+
+&spi0 {
+	pinctrl-0 = <&spi0_pinctrl>;
+	pinctrl-names = "default";
+	num-cs = <1>;
+	cs-gpios = <&gpio0 20 GPIO_ACTIVE_HIGH>;
+
+	panel@0 {
+		compatible = "sitronix,st7789v";
+		reg = <0>;
+		reset-gpios = <&gpio0 21 GPIO_ACTIVE_LOW>;
+		dc-gpios = <&gpio0 22 GPIO_ACTIVE_HIGH>;
+		spi-max-frequency = <15000000>;
+		status = "disabled";
+	};
+};
+
+&spi1 {
+	pinctrl-0 = <&spi1_pinctrl>;
+	pinctrl-names = "default";
+	num-cs = <1>;
+	cs-gpios = <&gpio0 13 GPIO_ACTIVE_LOW>;
+	status = "okay";
+
+	slot@0 {
+		compatible = "mmc-spi-slot";
+		reg = <0>;
+		voltage-ranges = <3300 3300>;
+		spi-max-frequency = <25000000>;
+		broken-cd;
+	};
+};
+
+&spi3 {
+	spi-flash@0 {
+		compatible = "jedec,spi-nor";
+		reg = <0>;
+		spi-max-frequency = <50000000>;
+		m25p,fast-read;
+		broken-flash-reset;
+	};
+};
-- 
2.29.2


^ permalink raw reply related	[flat|nested] 81+ messages in thread

* [PATCH v14 12/16] riscv: Add SiPeed MAIX GO board device tree
@ 2021-02-02 10:36   ` Damien Le Moal
  0 siblings, 0 replies; 81+ messages in thread
From: Damien Le Moal @ 2021-02-02 10:36 UTC (permalink / raw)
  To: Palmer Dabbelt, linux-riscv
  Cc: Atish Patra, devicetree, Anup Patel, Rob Herring, Sean Anderson

Add the device tree sipeed_maix_go.dts for the SiPeed MAIX GO board.
This device tree enables buttons, LEDs, gpio, i2c and spi/mmc SD card
devices.

Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
---
 arch/riscv/boot/dts/canaan/sipeed_maix_go.dts | 244 ++++++++++++++++++
 1 file changed, 244 insertions(+)
 create mode 100644 arch/riscv/boot/dts/canaan/sipeed_maix_go.dts

diff --git a/arch/riscv/boot/dts/canaan/sipeed_maix_go.dts b/arch/riscv/boot/dts/canaan/sipeed_maix_go.dts
new file mode 100644
index 000000000000..373fbaa3ab94
--- /dev/null
+++ b/arch/riscv/boot/dts/canaan/sipeed_maix_go.dts
@@ -0,0 +1,244 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019-20 Sean Anderson <seanga2@gmail.com>
+ * Copyright (C) 2020 Western Digital Corporation or its affiliates.
+ */
+
+/dts-v1/;
+
+#include "k210.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+
+/ {
+	model = "SiPeed MAIX GO";
+	compatible = "sipeed,maix-go", "canaan,kendryte-k210";
+
+	chosen {
+		bootargs = "earlycon console=ttySIF0";
+		stdout-path = "serial0:115200n8";
+	};
+
+	gpio-leds {
+		compatible = "gpio-leds";
+
+		led0 {
+			color = <LED_COLOR_ID_GREEN>;
+			label = "green";
+			gpios = <&gpio1_0 4 GPIO_ACTIVE_LOW>;
+		};
+
+		led1 {
+			color = <LED_COLOR_ID_RED>;
+			label = "red";
+			gpios = <&gpio1_0 5 GPIO_ACTIVE_LOW>;
+		};
+
+		led2 {
+			color = <LED_COLOR_ID_BLUE>;
+			label = "blue";
+			gpios = <&gpio1_0 6 GPIO_ACTIVE_LOW>;
+		};
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+
+		up {
+			label = "UP";
+			linux,code = <BTN_1>;
+			gpios = <&gpio1_0 7 GPIO_ACTIVE_LOW>;
+		};
+
+		press {
+			label = "PRESS";
+			linux,code = <BTN_0>;
+			gpios = <&gpio0 0 GPIO_ACTIVE_LOW>;
+		};
+
+		down {
+			label = "DOWN";
+			linux,code = <BTN_2>;
+			gpios = <&gpio0 1 GPIO_ACTIVE_LOW>;
+		};
+	};
+
+	sound {
+		compatible = "simple-audio-card";
+		simple-audio-card,format = "i2s";
+		status = "disabled";
+
+		simple-audio-card,cpu {
+			sound-dai = <&i2s0 0>;
+		};
+
+		simple-audio-card,codec {
+			sound-dai = <&mic>;
+		};
+	};
+
+	mic: mic {
+		#sound-dai-cells = <0>;
+		compatible = "memsensing,msm261s4030h0";
+		status = "disabled";
+	};
+};
+
+&fpioa {
+	pinctrl-0 = <&jtag_pinctrl>;
+	pinctrl-names = "default";
+	status = "okay";
+
+	jtag_pinctrl: jtag-pinmux {
+		pinmux = <K210_FPIOA(0, K210_PCF_JTAG_TCLK)>,
+			 <K210_FPIOA(1, K210_PCF_JTAG_TDI)>,
+			 <K210_FPIOA(2, K210_PCF_JTAG_TMS)>,
+			 <K210_FPIOA(3, K210_PCF_JTAG_TDO)>;
+	};
+
+	uarths_pinctrl: uarths-pinmux {
+		pinmux = <K210_FPIOA(4, K210_PCF_UARTHS_RX)>,
+			 <K210_FPIOA(5, K210_PCF_UARTHS_TX)>;
+	};
+
+	gpio_pinctrl: gpio-pinmux {
+		pinmux = <K210_FPIOA(8, K210_PCF_GPIO0)>,
+			 <K210_FPIOA(9, K210_PCF_GPIO1)>,
+			 <K210_FPIOA(10, K210_PCF_GPIO2)>,
+			 <K210_FPIOA(11, K210_PCF_GPIO3)>,
+			 <K210_FPIOA(12, K210_PCF_GPIO4)>,
+			 <K210_FPIOA(13, K210_PCF_GPIO5)>,
+			 <K210_FPIOA(14, K210_PCF_GPIO6)>,
+			 <K210_FPIOA(15, K210_PCF_GPIO7)>;
+	};
+
+	gpiohs_pinctrl: gpiohs-pinmux {
+		pinmux = <K210_FPIOA(16, K210_PCF_GPIOHS0)>,
+			 <K210_FPIOA(17, K210_PCF_GPIOHS1)>,
+			 <K210_FPIOA(21, K210_PCF_GPIOHS5)>,
+			 <K210_FPIOA(22, K210_PCF_GPIOHS6)>,
+			 <K210_FPIOA(23, K210_PCF_GPIOHS7)>,
+			 <K210_FPIOA(24, K210_PCF_GPIOHS8)>,
+			 <K210_FPIOA(25, K210_PCF_GPIOHS9)>,
+			 <K210_FPIOA(32, K210_PCF_GPIOHS16)>,
+			 <K210_FPIOA(33, K210_PCF_GPIOHS17)>,
+			 <K210_FPIOA(34, K210_PCF_GPIOHS18)>,
+			 <K210_FPIOA(35, K210_PCF_GPIOHS19)>;
+	};
+
+	i2s0_pinctrl: i2s0-pinmux {
+		pinmux = <K210_FPIOA(18, K210_PCF_I2S0_SCLK)>,
+			 <K210_FPIOA(19, K210_PCF_I2S0_WS)>,
+			 <K210_FPIOA(20, K210_PCF_I2S0_IN_D0)>;
+	};
+
+	dvp_pinctrl: dvp-pinmux {
+		pinmux = <K210_FPIOA(40, K210_PCF_SCCB_SDA)>,
+			 <K210_FPIOA(41, K210_PCF_SCCB_SCLK)>,
+			 <K210_FPIOA(42, K210_PCF_DVP_RST)>,
+			 <K210_FPIOA(43, K210_PCF_DVP_VSYNC)>,
+			 <K210_FPIOA(44, K210_PCF_DVP_PWDN)>,
+			 <K210_FPIOA(45, K210_PCF_DVP_HSYNC)>,
+			 <K210_FPIOA(46, K210_PCF_DVP_XCLK)>,
+			 <K210_FPIOA(47, K210_PCF_DVP_PCLK)>;
+	};
+
+	spi0_pinctrl: spi0-pinmux {
+		pinmux = <K210_FPIOA(36, K210_PCF_GPIOHS20)>,  /* cs */
+			 <K210_FPIOA(37, K210_PCF_GPIOHS21)>,  /* rst */
+			 <K210_FPIOA(38, K210_PCF_GPIOHS22)>,  /* dc */
+			 <K210_FPIOA(39, K210_PCF_SPI0_SCLK)>; /* wr */
+	};
+
+	spi1_pinctrl: spi1-pinmux {
+		pinmux = <K210_FPIOA(26, K210_PCF_SPI1_D1)>,
+			 <K210_FPIOA(27, K210_PCF_SPI1_SCLK)>,
+			 <K210_FPIOA(28, K210_PCF_SPI1_D0)>,
+			 <K210_FPIOA(29, K210_PCF_GPIOHS13)>; /* cs */
+	};
+
+	i2c1_pinctrl: i2c1-pinmux {
+		pinmux = <K210_FPIOA(30, K210_PCF_I2C1_SCLK)>,
+			 <K210_FPIOA(31, K210_PCF_I2C1_SDA)>;
+	};
+};
+
+&uarths0 {
+	pinctrl-0 = <&uarths_pinctrl>;
+	pinctrl-names = "default";
+	status = "okay";
+};
+
+&gpio0 {
+	pinctrl-0 = <&gpiohs_pinctrl>;
+	pinctrl-names = "default";
+	status = "okay";
+};
+
+&gpio1 {
+	pinctrl-0 = <&gpio_pinctrl>;
+	pinctrl-names = "default";
+	status = "okay";
+};
+
+&i2s0 {
+	#sound-dai-cells = <1>;
+	pinctrl-0 = <&i2s0_pinctrl>;
+	pinctrl-names = "default";
+};
+
+&i2c1 {
+	pinctrl-0 = <&i2c1_pinctrl>;
+	pinctrl-names = "default";
+	clock-frequency = <400000>;
+	status = "okay";
+};
+
+&dvp0 {
+	pinctrl-0 = <&dvp_pinctrl>;
+	pinctrl-names = "default";
+};
+
+&spi0 {
+	pinctrl-0 = <&spi0_pinctrl>;
+	pinctrl-names = "default";
+	num-cs = <1>;
+	cs-gpios = <&gpio0 20 GPIO_ACTIVE_HIGH>;
+
+	panel@0 {
+		compatible = "sitronix,st7789v";
+		reg = <0>;
+		reset-gpios = <&gpio0 21 GPIO_ACTIVE_LOW>;
+		dc-gpios = <&gpio0 22 GPIO_ACTIVE_HIGH>;
+		spi-max-frequency = <15000000>;
+		status = "disabled";
+	};
+};
+
+&spi1 {
+	pinctrl-0 = <&spi1_pinctrl>;
+	pinctrl-names = "default";
+	num-cs = <1>;
+	cs-gpios = <&gpio0 13 GPIO_ACTIVE_LOW>;
+	status = "okay";
+
+	slot@0 {
+		compatible = "mmc-spi-slot";
+		reg = <0>;
+		voltage-ranges = <3300 3300>;
+		spi-max-frequency = <25000000>;
+		broken-cd;
+	};
+};
+
+&spi3 {
+	spi-flash@0 {
+		compatible = "jedec,spi-nor";
+		reg = <0>;
+		spi-max-frequency = <50000000>;
+		m25p,fast-read;
+		broken-flash-reset;
+	};
+};
-- 
2.29.2


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply related	[flat|nested] 81+ messages in thread

* [PATCH v14 13/16] riscv: Add SiPeed MAIXDUINO board device tree
  2021-02-02 10:36 [PATCH v14 00/16] RISC-V Kendryte K210 support improvements Damien Le Moal
@ 2021-02-02 10:36   ` Damien Le Moal
  2021-02-02 10:36   ` Damien Le Moal
                     ` (14 subsequent siblings)
  15 siblings, 0 replies; 81+ messages in thread
From: Damien Le Moal @ 2021-02-02 10:36 UTC (permalink / raw)
  To: Palmer Dabbelt, linux-riscv
  Cc: Atish Patra, Anup Patel, Sean Anderson, Rob Herring, devicetree

Add the device tree sipeed_maixduino.dts for the SiPeed MAIXDUINO board.
This device tree enables LEDs and spi/mmc SD card device. Additionally,
gpios and i2c are also enabled and mapped to the board header pins as
indicated on the board itself.

Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
---
 .../boot/dts/canaan/sipeed_maixduino.dts      | 209 ++++++++++++++++++
 1 file changed, 209 insertions(+)
 create mode 100644 arch/riscv/boot/dts/canaan/sipeed_maixduino.dts

diff --git a/arch/riscv/boot/dts/canaan/sipeed_maixduino.dts b/arch/riscv/boot/dts/canaan/sipeed_maixduino.dts
new file mode 100644
index 000000000000..804edc45eeeb
--- /dev/null
+++ b/arch/riscv/boot/dts/canaan/sipeed_maixduino.dts
@@ -0,0 +1,209 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019-20 Sean Anderson <seanga2@gmail.com>
+ * Copyright (C) 2020 Western Digital Corporation or its affiliates.
+ */
+
+/dts-v1/;
+
+#include "k210.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+
+/ {
+	model = "SiPeed MAIXDUINO";
+	compatible = "sipeed,maixduino", "canaan,kendryte-k210";
+
+	chosen {
+		bootargs = "earlycon console=ttySIF0";
+		stdout-path = "serial0:115200n8";
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+
+		boot {
+			label = "BOOT";
+			linux,code = <BTN_0>;
+			gpios = <&gpio0 0 GPIO_ACTIVE_LOW>;
+		};
+	};
+
+	sound {
+		compatible = "simple-audio-card";
+		simple-audio-card,format = "i2s";
+		status = "disabled";
+
+		simple-audio-card,cpu {
+			sound-dai = <&i2s0 0>;
+		};
+
+		simple-audio-card,codec {
+			sound-dai = <&mic>;
+		};
+	};
+
+	mic: mic {
+		#sound-dai-cells = <0>;
+		compatible = "memsensing,msm261s4030h0";
+		status = "disabled";
+	};
+
+	vcc_3v3: regulator-3v3 {
+		compatible = "regulator-fixed";
+		regulator-name = "3v3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+	};
+};
+
+&fpioa {
+	status = "okay";
+
+	uarths_pinctrl: uarths-pinmux {
+		pinmux = <K210_FPIOA(4, K210_PCF_UARTHS_RX)>, /* Header "0" */
+			 <K210_FPIOA(5, K210_PCF_UARTHS_TX)>; /* Header "1" */
+	};
+
+	gpio_pinctrl: gpio-pinmux {
+		pinmux = <K210_FPIOA(8, K210_PCF_GPIO0)>,
+			 <K210_FPIOA(9, K210_PCF_GPIO1)>;
+	};
+
+	gpiohs_pinctrl: gpiohs-pinmux {
+		pinmux = <K210_FPIOA(16, K210_PCF_GPIOHS0)>,  /* BOOT */
+			 <K210_FPIOA(21, K210_PCF_GPIOHS2)>,  /* Header "2" */
+			 <K210_FPIOA(22, K210_PCF_GPIOHS3)>,  /* Header "3" */
+			 <K210_FPIOA(23, K210_PCF_GPIOHS4)>,  /* Header "4" */
+			 <K210_FPIOA(24, K210_PCF_GPIOHS5)>,  /* Header "5" */
+			 <K210_FPIOA(32, K210_PCF_GPIOHS6)>,  /* Header "6" */
+			 <K210_FPIOA(15, K210_PCF_GPIOHS7)>,  /* Header "7" */
+			 <K210_FPIOA(14, K210_PCF_GPIOHS8)>,  /* Header "8" */
+			 <K210_FPIOA(13, K210_PCF_GPIOHS9)>,  /* Header "9" */
+			 <K210_FPIOA(12, K210_PCF_GPIOHS10)>, /* Header "10" */
+			 <K210_FPIOA(11, K210_PCF_GPIOHS11)>, /* Header "11" */
+			 <K210_FPIOA(10, K210_PCF_GPIOHS12)>, /* Header "12" */
+			 <K210_FPIOA(3,  K210_PCF_GPIOHS13)>; /* Header "13" */
+	};
+
+	i2s0_pinctrl: i2s0-pinmux {
+		pinmux = <K210_FPIOA(18, K210_PCF_I2S0_SCLK)>,
+			 <K210_FPIOA(19, K210_PCF_I2S0_WS)>,
+			 <K210_FPIOA(20, K210_PCF_I2S0_IN_D0)>;
+	};
+
+	spi1_pinctrl: spi1-pinmux {
+		pinmux = <K210_FPIOA(26, K210_PCF_SPI1_D1)>,
+			 <K210_FPIOA(27, K210_PCF_SPI1_SCLK)>,
+			 <K210_FPIOA(28, K210_PCF_SPI1_D0)>,
+			 <K210_FPIOA(29, K210_PCF_GPIO2)>; /* cs */
+	};
+
+	i2c1_pinctrl: i2c1-pinmux {
+		pinmux = <K210_FPIOA(30, K210_PCF_I2C1_SCLK)>, /* Header "scl" */
+			 <K210_FPIOA(31, K210_PCF_I2C1_SDA)>;  /* Header "sda" */
+	};
+
+	i2s1_pinctrl: i2s1-pinmux {
+		pinmux = <K210_FPIOA(33, K210_PCF_I2S1_WS)>,
+			 <K210_FPIOA(34, K210_PCF_I2S1_IN_D0)>,
+			 <K210_FPIOA(35, K210_PCF_I2S1_SCLK)>;
+	};
+
+	spi0_pinctrl: spi0-pinmux {
+		pinmux = <K210_FPIOA(36, K210_PCF_GPIOHS20)>,  /* cs */
+			 <K210_FPIOA(37, K210_PCF_GPIOHS21)>,  /* rst */
+			 <K210_FPIOA(38, K210_PCF_GPIOHS22)>,  /* dc */
+			 <K210_FPIOA(39, K210_PCF_SPI0_SCLK)>; /* wr */
+	};
+
+	dvp_pinctrl: dvp-pinmux {
+		pinmux = <K210_FPIOA(40, K210_PCF_SCCB_SDA)>,
+			 <K210_FPIOA(41, K210_PCF_SCCB_SCLK)>,
+			 <K210_FPIOA(42, K210_PCF_DVP_RST)>,
+			 <K210_FPIOA(43, K210_PCF_DVP_VSYNC)>,
+			 <K210_FPIOA(44, K210_PCF_DVP_PWDN)>,
+			 <K210_FPIOA(45, K210_PCF_DVP_HSYNC)>,
+			 <K210_FPIOA(46, K210_PCF_DVP_XCLK)>,
+			 <K210_FPIOA(47, K210_PCF_DVP_PCLK)>;
+	};
+};
+
+&uarths0 {
+	pinctrl-0 = <&uarths_pinctrl>;
+	pinctrl-names = "default";
+	status = "okay";
+};
+
+&gpio0 {
+	pinctrl-0 = <&gpiohs_pinctrl>;
+	pinctrl-names = "default";
+	status = "okay";
+};
+
+&gpio1 {
+	pinctrl-0 = <&gpio_pinctrl>;
+	pinctrl-names = "default";
+	status = "okay";
+};
+
+&i2s0 {
+	#sound-dai-cells = <1>;
+	pinctrl-0 = <&i2s0_pinctrl>;
+	pinctrl-names = "default";
+};
+
+&i2c1 {
+	pinctrl-0 = <&i2c1_pinctrl>;
+	pinctrl-names = "default";
+	clock-frequency = <400000>;
+	status = "okay";
+};
+
+&dvp0 {
+	pinctrl-0 = <&dvp_pinctrl>;
+	pinctrl-names = "default";
+};
+
+&spi0 {
+	pinctrl-0 = <&spi0_pinctrl>;
+	pinctrl-names = "default";
+	num-cs = <1>;
+	cs-gpios = <&gpio0 20 GPIO_ACTIVE_HIGH>;
+
+	panel@0 {
+		compatible = "sitronix,st7789v";
+		reg = <0>;
+		reset-gpios = <&gpio0 21 GPIO_ACTIVE_LOW>;
+		dc-gpios = <&gpio0 22 0>;
+		spi-max-frequency = <15000000>;
+		power-supply = <&vcc_3v3>;
+	};
+};
+
+&spi1 {
+	pinctrl-0 = <&spi1_pinctrl>;
+	pinctrl-names = "default";
+	num-cs = <1>;
+	cs-gpios = <&gpio1_0 2 GPIO_ACTIVE_LOW>;
+	status = "okay";
+
+	slot@0 {
+		compatible = "mmc-spi-slot";
+		reg = <0>;
+		voltage-ranges = <3300 3300>;
+		spi-max-frequency = <25000000>;
+		broken-cd;
+	};
+};
+
+&spi3 {
+	spi-flash@0 {
+		compatible = "jedec,spi-nor";
+		reg = <0>;
+		spi-max-frequency = <50000000>;
+		m25p,fast-read;
+		broken-flash-reset;
+	};
+};
-- 
2.29.2


^ permalink raw reply related	[flat|nested] 81+ messages in thread

* [PATCH v14 13/16] riscv: Add SiPeed MAIXDUINO board device tree
@ 2021-02-02 10:36   ` Damien Le Moal
  0 siblings, 0 replies; 81+ messages in thread
From: Damien Le Moal @ 2021-02-02 10:36 UTC (permalink / raw)
  To: Palmer Dabbelt, linux-riscv
  Cc: Atish Patra, devicetree, Anup Patel, Rob Herring, Sean Anderson

Add the device tree sipeed_maixduino.dts for the SiPeed MAIXDUINO board.
This device tree enables LEDs and spi/mmc SD card device. Additionally,
gpios and i2c are also enabled and mapped to the board header pins as
indicated on the board itself.

Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
---
 .../boot/dts/canaan/sipeed_maixduino.dts      | 209 ++++++++++++++++++
 1 file changed, 209 insertions(+)
 create mode 100644 arch/riscv/boot/dts/canaan/sipeed_maixduino.dts

diff --git a/arch/riscv/boot/dts/canaan/sipeed_maixduino.dts b/arch/riscv/boot/dts/canaan/sipeed_maixduino.dts
new file mode 100644
index 000000000000..804edc45eeeb
--- /dev/null
+++ b/arch/riscv/boot/dts/canaan/sipeed_maixduino.dts
@@ -0,0 +1,209 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019-20 Sean Anderson <seanga2@gmail.com>
+ * Copyright (C) 2020 Western Digital Corporation or its affiliates.
+ */
+
+/dts-v1/;
+
+#include "k210.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+
+/ {
+	model = "SiPeed MAIXDUINO";
+	compatible = "sipeed,maixduino", "canaan,kendryte-k210";
+
+	chosen {
+		bootargs = "earlycon console=ttySIF0";
+		stdout-path = "serial0:115200n8";
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+
+		boot {
+			label = "BOOT";
+			linux,code = <BTN_0>;
+			gpios = <&gpio0 0 GPIO_ACTIVE_LOW>;
+		};
+	};
+
+	sound {
+		compatible = "simple-audio-card";
+		simple-audio-card,format = "i2s";
+		status = "disabled";
+
+		simple-audio-card,cpu {
+			sound-dai = <&i2s0 0>;
+		};
+
+		simple-audio-card,codec {
+			sound-dai = <&mic>;
+		};
+	};
+
+	mic: mic {
+		#sound-dai-cells = <0>;
+		compatible = "memsensing,msm261s4030h0";
+		status = "disabled";
+	};
+
+	vcc_3v3: regulator-3v3 {
+		compatible = "regulator-fixed";
+		regulator-name = "3v3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+	};
+};
+
+&fpioa {
+	status = "okay";
+
+	uarths_pinctrl: uarths-pinmux {
+		pinmux = <K210_FPIOA(4, K210_PCF_UARTHS_RX)>, /* Header "0" */
+			 <K210_FPIOA(5, K210_PCF_UARTHS_TX)>; /* Header "1" */
+	};
+
+	gpio_pinctrl: gpio-pinmux {
+		pinmux = <K210_FPIOA(8, K210_PCF_GPIO0)>,
+			 <K210_FPIOA(9, K210_PCF_GPIO1)>;
+	};
+
+	gpiohs_pinctrl: gpiohs-pinmux {
+		pinmux = <K210_FPIOA(16, K210_PCF_GPIOHS0)>,  /* BOOT */
+			 <K210_FPIOA(21, K210_PCF_GPIOHS2)>,  /* Header "2" */
+			 <K210_FPIOA(22, K210_PCF_GPIOHS3)>,  /* Header "3" */
+			 <K210_FPIOA(23, K210_PCF_GPIOHS4)>,  /* Header "4" */
+			 <K210_FPIOA(24, K210_PCF_GPIOHS5)>,  /* Header "5" */
+			 <K210_FPIOA(32, K210_PCF_GPIOHS6)>,  /* Header "6" */
+			 <K210_FPIOA(15, K210_PCF_GPIOHS7)>,  /* Header "7" */
+			 <K210_FPIOA(14, K210_PCF_GPIOHS8)>,  /* Header "8" */
+			 <K210_FPIOA(13, K210_PCF_GPIOHS9)>,  /* Header "9" */
+			 <K210_FPIOA(12, K210_PCF_GPIOHS10)>, /* Header "10" */
+			 <K210_FPIOA(11, K210_PCF_GPIOHS11)>, /* Header "11" */
+			 <K210_FPIOA(10, K210_PCF_GPIOHS12)>, /* Header "12" */
+			 <K210_FPIOA(3,  K210_PCF_GPIOHS13)>; /* Header "13" */
+	};
+
+	i2s0_pinctrl: i2s0-pinmux {
+		pinmux = <K210_FPIOA(18, K210_PCF_I2S0_SCLK)>,
+			 <K210_FPIOA(19, K210_PCF_I2S0_WS)>,
+			 <K210_FPIOA(20, K210_PCF_I2S0_IN_D0)>;
+	};
+
+	spi1_pinctrl: spi1-pinmux {
+		pinmux = <K210_FPIOA(26, K210_PCF_SPI1_D1)>,
+			 <K210_FPIOA(27, K210_PCF_SPI1_SCLK)>,
+			 <K210_FPIOA(28, K210_PCF_SPI1_D0)>,
+			 <K210_FPIOA(29, K210_PCF_GPIO2)>; /* cs */
+	};
+
+	i2c1_pinctrl: i2c1-pinmux {
+		pinmux = <K210_FPIOA(30, K210_PCF_I2C1_SCLK)>, /* Header "scl" */
+			 <K210_FPIOA(31, K210_PCF_I2C1_SDA)>;  /* Header "sda" */
+	};
+
+	i2s1_pinctrl: i2s1-pinmux {
+		pinmux = <K210_FPIOA(33, K210_PCF_I2S1_WS)>,
+			 <K210_FPIOA(34, K210_PCF_I2S1_IN_D0)>,
+			 <K210_FPIOA(35, K210_PCF_I2S1_SCLK)>;
+	};
+
+	spi0_pinctrl: spi0-pinmux {
+		pinmux = <K210_FPIOA(36, K210_PCF_GPIOHS20)>,  /* cs */
+			 <K210_FPIOA(37, K210_PCF_GPIOHS21)>,  /* rst */
+			 <K210_FPIOA(38, K210_PCF_GPIOHS22)>,  /* dc */
+			 <K210_FPIOA(39, K210_PCF_SPI0_SCLK)>; /* wr */
+	};
+
+	dvp_pinctrl: dvp-pinmux {
+		pinmux = <K210_FPIOA(40, K210_PCF_SCCB_SDA)>,
+			 <K210_FPIOA(41, K210_PCF_SCCB_SCLK)>,
+			 <K210_FPIOA(42, K210_PCF_DVP_RST)>,
+			 <K210_FPIOA(43, K210_PCF_DVP_VSYNC)>,
+			 <K210_FPIOA(44, K210_PCF_DVP_PWDN)>,
+			 <K210_FPIOA(45, K210_PCF_DVP_HSYNC)>,
+			 <K210_FPIOA(46, K210_PCF_DVP_XCLK)>,
+			 <K210_FPIOA(47, K210_PCF_DVP_PCLK)>;
+	};
+};
+
+&uarths0 {
+	pinctrl-0 = <&uarths_pinctrl>;
+	pinctrl-names = "default";
+	status = "okay";
+};
+
+&gpio0 {
+	pinctrl-0 = <&gpiohs_pinctrl>;
+	pinctrl-names = "default";
+	status = "okay";
+};
+
+&gpio1 {
+	pinctrl-0 = <&gpio_pinctrl>;
+	pinctrl-names = "default";
+	status = "okay";
+};
+
+&i2s0 {
+	#sound-dai-cells = <1>;
+	pinctrl-0 = <&i2s0_pinctrl>;
+	pinctrl-names = "default";
+};
+
+&i2c1 {
+	pinctrl-0 = <&i2c1_pinctrl>;
+	pinctrl-names = "default";
+	clock-frequency = <400000>;
+	status = "okay";
+};
+
+&dvp0 {
+	pinctrl-0 = <&dvp_pinctrl>;
+	pinctrl-names = "default";
+};
+
+&spi0 {
+	pinctrl-0 = <&spi0_pinctrl>;
+	pinctrl-names = "default";
+	num-cs = <1>;
+	cs-gpios = <&gpio0 20 GPIO_ACTIVE_HIGH>;
+
+	panel@0 {
+		compatible = "sitronix,st7789v";
+		reg = <0>;
+		reset-gpios = <&gpio0 21 GPIO_ACTIVE_LOW>;
+		dc-gpios = <&gpio0 22 0>;
+		spi-max-frequency = <15000000>;
+		power-supply = <&vcc_3v3>;
+	};
+};
+
+&spi1 {
+	pinctrl-0 = <&spi1_pinctrl>;
+	pinctrl-names = "default";
+	num-cs = <1>;
+	cs-gpios = <&gpio1_0 2 GPIO_ACTIVE_LOW>;
+	status = "okay";
+
+	slot@0 {
+		compatible = "mmc-spi-slot";
+		reg = <0>;
+		voltage-ranges = <3300 3300>;
+		spi-max-frequency = <25000000>;
+		broken-cd;
+	};
+};
+
+&spi3 {
+	spi-flash@0 {
+		compatible = "jedec,spi-nor";
+		reg = <0>;
+		spi-max-frequency = <50000000>;
+		m25p,fast-read;
+		broken-flash-reset;
+	};
+};
-- 
2.29.2


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply related	[flat|nested] 81+ messages in thread

* [PATCH v14 14/16] riscv: Add Kendryte KD233 board device tree
  2021-02-02 10:36 [PATCH v14 00/16] RISC-V Kendryte K210 support improvements Damien Le Moal
@ 2021-02-02 10:36   ` Damien Le Moal
  2021-02-02 10:36   ` Damien Le Moal
                     ` (14 subsequent siblings)
  15 siblings, 0 replies; 81+ messages in thread
From: Damien Le Moal @ 2021-02-02 10:36 UTC (permalink / raw)
  To: Palmer Dabbelt, linux-riscv
  Cc: Atish Patra, Anup Patel, Sean Anderson, Rob Herring, devicetree

Add the device tree canaan_kd233.dts for the Canaan Kendryte KD233
development board.  This device tree enables LEDs, some gpios and
spi/mmc SD card device. The WS2812B RGB LED and the 10 positions rotary
dip switch present on the board are left undefined.

Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Reviewed-by: Anup Patel <anup@brainfault.org>
---
 arch/riscv/boot/dts/canaan/canaan_kd233.dts | 177 ++++++++++++++++++++
 1 file changed, 177 insertions(+)
 create mode 100644 arch/riscv/boot/dts/canaan/canaan_kd233.dts

diff --git a/arch/riscv/boot/dts/canaan/canaan_kd233.dts b/arch/riscv/boot/dts/canaan/canaan_kd233.dts
new file mode 100644
index 000000000000..d9af66144938
--- /dev/null
+++ b/arch/riscv/boot/dts/canaan/canaan_kd233.dts
@@ -0,0 +1,177 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019-20 Sean Anderson <seanga2@gmail.com>
+ * Copyright (C) 2020 Western Digital Corporation or its affiliates.
+ */
+
+/dts-v1/;
+
+#include "k210.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+
+/ {
+	model = "Kendryte KD233";
+	compatible = "canaan,kendryte-kd233", "canaan,kendryte-k210";
+
+	chosen {
+		bootargs = "earlycon console=ttySIF0";
+		stdout-path = "serial0:115200n8";
+	};
+
+	gpio-leds {
+		compatible = "gpio-leds";
+
+		led0 {
+			gpios = <&gpio0 8 GPIO_ACTIVE_LOW>;
+		};
+
+		led1 {
+			gpios = <&gpio0 9 GPIO_ACTIVE_LOW>;
+		};
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+
+		key0 {
+			label = "KEY0";
+			linux,code = <BTN_0>;
+			gpios = <&gpio0 10 GPIO_ACTIVE_LOW>;
+		};
+	};
+
+	sound {
+		compatible = "simple-audio-card";
+		simple-audio-card,format = "i2s";
+		status = "disabled";
+
+		simple-audio-card,cpu {
+			sound-dai = <&i2s0 0>;
+		};
+
+		simple-audio-card,codec {
+			sound-dai = <&mic>;
+		};
+	};
+
+	mic: mic {
+		#sound-dai-cells = <0>;
+		compatible = "memsensing,msm261s4030h0";
+		status = "disabled";
+	};
+};
+
+&fpioa {
+	pinctrl-0 = <&jtag_pinctrl>;
+	pinctrl-names = "default";
+	status = "okay";
+
+	jtag_pinctrl: jtag-pinmux {
+		pinmux = <K210_FPIOA(0, K210_PCF_JTAG_TCLK)>,
+			 <K210_FPIOA(1, K210_PCF_JTAG_TDI)>,
+			 <K210_FPIOA(2, K210_PCF_JTAG_TMS)>,
+			 <K210_FPIOA(3, K210_PCF_JTAG_TDO)>;
+	};
+
+	uarths_pinctrl: uarths-pinmux {
+		pinmux = <K210_FPIOA(4, K210_PCF_UARTHS_RX)>,
+			 <K210_FPIOA(5, K210_PCF_UARTHS_TX)>;
+	};
+
+	spi0_pinctrl: spi0-pinmux {
+		pinmux = <K210_FPIOA(6, K210_PCF_GPIOHS20)>,  /* cs */
+			 <K210_FPIOA(7, K210_PCF_SPI0_SCLK)>, /* wr */
+			 <K210_FPIOA(8, K210_PCF_GPIOHS21)>;  /* dc */
+	};
+
+	dvp_pinctrl: dvp-pinmux {
+		pinmux = <K210_FPIOA(9, K210_PCF_SCCB_SCLK)>,
+			 <K210_FPIOA(10, K210_PCF_SCCB_SDA)>,
+			 <K210_FPIOA(11, K210_PCF_DVP_RST)>,
+			 <K210_FPIOA(12, K210_PCF_DVP_VSYNC)>,
+			 <K210_FPIOA(13, K210_PCF_DVP_PWDN)>,
+			 <K210_FPIOA(14, K210_PCF_DVP_XCLK)>,
+			 <K210_FPIOA(15, K210_PCF_DVP_PCLK)>,
+			 <K210_FPIOA(17, K210_PCF_DVP_HSYNC)>;
+	};
+
+	gpiohs_pinctrl: gpiohs-pinmux {
+		pinmux = <K210_FPIOA(16, K210_PCF_GPIOHS0)>,
+			 <K210_FPIOA(20, K210_PCF_GPIOHS4)>, /* Rot. dip sw line 8 */
+			 <K210_FPIOA(21, K210_PCF_GPIOHS5)>, /* Rot. dip sw line 4 */
+			 <K210_FPIOA(22, K210_PCF_GPIOHS6)>, /* Rot. dip sw line 2 */
+			 <K210_FPIOA(23, K210_PCF_GPIOHS7)>, /* Rot. dip sw line 1 */
+			 <K210_FPIOA(24, K210_PCF_GPIOHS8)>,
+			 <K210_FPIOA(25, K210_PCF_GPIOHS9)>,
+			 <K210_FPIOA(26, K210_PCF_GPIOHS10)>;
+	};
+
+	spi1_pinctrl: spi1-pinmux {
+		pinmux = <K210_FPIOA(29, K210_PCF_SPI1_SCLK)>,
+			 <K210_FPIOA(30, K210_PCF_SPI1_D0)>,
+			 <K210_FPIOA(31, K210_PCF_SPI1_D1)>,
+			 <K210_FPIOA(32, K210_PCF_GPIOHS16)>; /* cs */
+	};
+
+	i2s0_pinctrl: i2s0-pinmux {
+		pinmux = <K210_FPIOA(33, K210_PCF_I2S0_IN_D0)>,
+			 <K210_FPIOA(34, K210_PCF_I2S0_WS)>,
+			 <K210_FPIOA(35, K210_PCF_I2S0_SCLK)>;
+	};
+};
+
+&uarths0 {
+	pinctrl-0 = <&uarths_pinctrl>;
+	pinctrl-names = "default";
+	status = "okay";
+};
+
+&gpio0 {
+	pinctrl-0 = <&gpiohs_pinctrl>;
+	pinctrl-names = "default";
+	status = "okay";
+};
+
+&i2s0 {
+	#sound-dai-cells = <1>;
+	pinctrl-0 = <&i2s0_pinctrl>;
+	pinctrl-names = "default";
+};
+
+&dvp0 {
+	pinctrl-0 = <&dvp_pinctrl>;
+	pinctrl-names = "default";
+};
+
+&spi0 {
+	pinctrl-0 = <&spi0_pinctrl>;
+	pinctrl-names = "default";
+	num-cs = <1>;
+	cs-gpios = <&gpio0 20 GPIO_ACTIVE_HIGH>;
+
+	panel@0 {
+		compatible = "ilitek,ili9341";
+		reg = <0>;
+		dc-gpios = <&gpio0 21 GPIO_ACTIVE_HIGH>;
+		spi-max-frequency = <15000000>;
+		status = "disabled";
+	};
+};
+
+&spi1 {
+	pinctrl-0 = <&spi1_pinctrl>;
+	pinctrl-names = "default";
+	num-cs = <1>;
+	cs-gpios = <&gpio0 16 GPIO_ACTIVE_LOW>;
+	status = "okay";
+
+	slot@0 {
+		compatible = "mmc-spi-slot";
+		reg = <0>;
+		voltage-ranges = <3300 3300>;
+		spi-max-frequency = <25000000>;
+		broken-cd;
+	};
+};
-- 
2.29.2


^ permalink raw reply related	[flat|nested] 81+ messages in thread

* [PATCH v14 14/16] riscv: Add Kendryte KD233 board device tree
@ 2021-02-02 10:36   ` Damien Le Moal
  0 siblings, 0 replies; 81+ messages in thread
From: Damien Le Moal @ 2021-02-02 10:36 UTC (permalink / raw)
  To: Palmer Dabbelt, linux-riscv
  Cc: Atish Patra, devicetree, Anup Patel, Rob Herring, Sean Anderson

Add the device tree canaan_kd233.dts for the Canaan Kendryte KD233
development board.  This device tree enables LEDs, some gpios and
spi/mmc SD card device. The WS2812B RGB LED and the 10 positions rotary
dip switch present on the board are left undefined.

Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Reviewed-by: Anup Patel <anup@brainfault.org>
---
 arch/riscv/boot/dts/canaan/canaan_kd233.dts | 177 ++++++++++++++++++++
 1 file changed, 177 insertions(+)
 create mode 100644 arch/riscv/boot/dts/canaan/canaan_kd233.dts

diff --git a/arch/riscv/boot/dts/canaan/canaan_kd233.dts b/arch/riscv/boot/dts/canaan/canaan_kd233.dts
new file mode 100644
index 000000000000..d9af66144938
--- /dev/null
+++ b/arch/riscv/boot/dts/canaan/canaan_kd233.dts
@@ -0,0 +1,177 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019-20 Sean Anderson <seanga2@gmail.com>
+ * Copyright (C) 2020 Western Digital Corporation or its affiliates.
+ */
+
+/dts-v1/;
+
+#include "k210.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+
+/ {
+	model = "Kendryte KD233";
+	compatible = "canaan,kendryte-kd233", "canaan,kendryte-k210";
+
+	chosen {
+		bootargs = "earlycon console=ttySIF0";
+		stdout-path = "serial0:115200n8";
+	};
+
+	gpio-leds {
+		compatible = "gpio-leds";
+
+		led0 {
+			gpios = <&gpio0 8 GPIO_ACTIVE_LOW>;
+		};
+
+		led1 {
+			gpios = <&gpio0 9 GPIO_ACTIVE_LOW>;
+		};
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+
+		key0 {
+			label = "KEY0";
+			linux,code = <BTN_0>;
+			gpios = <&gpio0 10 GPIO_ACTIVE_LOW>;
+		};
+	};
+
+	sound {
+		compatible = "simple-audio-card";
+		simple-audio-card,format = "i2s";
+		status = "disabled";
+
+		simple-audio-card,cpu {
+			sound-dai = <&i2s0 0>;
+		};
+
+		simple-audio-card,codec {
+			sound-dai = <&mic>;
+		};
+	};
+
+	mic: mic {
+		#sound-dai-cells = <0>;
+		compatible = "memsensing,msm261s4030h0";
+		status = "disabled";
+	};
+};
+
+&fpioa {
+	pinctrl-0 = <&jtag_pinctrl>;
+	pinctrl-names = "default";
+	status = "okay";
+
+	jtag_pinctrl: jtag-pinmux {
+		pinmux = <K210_FPIOA(0, K210_PCF_JTAG_TCLK)>,
+			 <K210_FPIOA(1, K210_PCF_JTAG_TDI)>,
+			 <K210_FPIOA(2, K210_PCF_JTAG_TMS)>,
+			 <K210_FPIOA(3, K210_PCF_JTAG_TDO)>;
+	};
+
+	uarths_pinctrl: uarths-pinmux {
+		pinmux = <K210_FPIOA(4, K210_PCF_UARTHS_RX)>,
+			 <K210_FPIOA(5, K210_PCF_UARTHS_TX)>;
+	};
+
+	spi0_pinctrl: spi0-pinmux {
+		pinmux = <K210_FPIOA(6, K210_PCF_GPIOHS20)>,  /* cs */
+			 <K210_FPIOA(7, K210_PCF_SPI0_SCLK)>, /* wr */
+			 <K210_FPIOA(8, K210_PCF_GPIOHS21)>;  /* dc */
+	};
+
+	dvp_pinctrl: dvp-pinmux {
+		pinmux = <K210_FPIOA(9, K210_PCF_SCCB_SCLK)>,
+			 <K210_FPIOA(10, K210_PCF_SCCB_SDA)>,
+			 <K210_FPIOA(11, K210_PCF_DVP_RST)>,
+			 <K210_FPIOA(12, K210_PCF_DVP_VSYNC)>,
+			 <K210_FPIOA(13, K210_PCF_DVP_PWDN)>,
+			 <K210_FPIOA(14, K210_PCF_DVP_XCLK)>,
+			 <K210_FPIOA(15, K210_PCF_DVP_PCLK)>,
+			 <K210_FPIOA(17, K210_PCF_DVP_HSYNC)>;
+	};
+
+	gpiohs_pinctrl: gpiohs-pinmux {
+		pinmux = <K210_FPIOA(16, K210_PCF_GPIOHS0)>,
+			 <K210_FPIOA(20, K210_PCF_GPIOHS4)>, /* Rot. dip sw line 8 */
+			 <K210_FPIOA(21, K210_PCF_GPIOHS5)>, /* Rot. dip sw line 4 */
+			 <K210_FPIOA(22, K210_PCF_GPIOHS6)>, /* Rot. dip sw line 2 */
+			 <K210_FPIOA(23, K210_PCF_GPIOHS7)>, /* Rot. dip sw line 1 */
+			 <K210_FPIOA(24, K210_PCF_GPIOHS8)>,
+			 <K210_FPIOA(25, K210_PCF_GPIOHS9)>,
+			 <K210_FPIOA(26, K210_PCF_GPIOHS10)>;
+	};
+
+	spi1_pinctrl: spi1-pinmux {
+		pinmux = <K210_FPIOA(29, K210_PCF_SPI1_SCLK)>,
+			 <K210_FPIOA(30, K210_PCF_SPI1_D0)>,
+			 <K210_FPIOA(31, K210_PCF_SPI1_D1)>,
+			 <K210_FPIOA(32, K210_PCF_GPIOHS16)>; /* cs */
+	};
+
+	i2s0_pinctrl: i2s0-pinmux {
+		pinmux = <K210_FPIOA(33, K210_PCF_I2S0_IN_D0)>,
+			 <K210_FPIOA(34, K210_PCF_I2S0_WS)>,
+			 <K210_FPIOA(35, K210_PCF_I2S0_SCLK)>;
+	};
+};
+
+&uarths0 {
+	pinctrl-0 = <&uarths_pinctrl>;
+	pinctrl-names = "default";
+	status = "okay";
+};
+
+&gpio0 {
+	pinctrl-0 = <&gpiohs_pinctrl>;
+	pinctrl-names = "default";
+	status = "okay";
+};
+
+&i2s0 {
+	#sound-dai-cells = <1>;
+	pinctrl-0 = <&i2s0_pinctrl>;
+	pinctrl-names = "default";
+};
+
+&dvp0 {
+	pinctrl-0 = <&dvp_pinctrl>;
+	pinctrl-names = "default";
+};
+
+&spi0 {
+	pinctrl-0 = <&spi0_pinctrl>;
+	pinctrl-names = "default";
+	num-cs = <1>;
+	cs-gpios = <&gpio0 20 GPIO_ACTIVE_HIGH>;
+
+	panel@0 {
+		compatible = "ilitek,ili9341";
+		reg = <0>;
+		dc-gpios = <&gpio0 21 GPIO_ACTIVE_HIGH>;
+		spi-max-frequency = <15000000>;
+		status = "disabled";
+	};
+};
+
+&spi1 {
+	pinctrl-0 = <&spi1_pinctrl>;
+	pinctrl-names = "default";
+	num-cs = <1>;
+	cs-gpios = <&gpio0 16 GPIO_ACTIVE_LOW>;
+	status = "okay";
+
+	slot@0 {
+		compatible = "mmc-spi-slot";
+		reg = <0>;
+		voltage-ranges = <3300 3300>;
+		spi-max-frequency = <25000000>;
+		broken-cd;
+	};
+};
-- 
2.29.2


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply related	[flat|nested] 81+ messages in thread

* [PATCH v14 15/16] riscv: Update Canaan Kendryte K210 defconfig
  2021-02-02 10:36 [PATCH v14 00/16] RISC-V Kendryte K210 support improvements Damien Le Moal
                   ` (13 preceding siblings ...)
  2021-02-02 10:36   ` Damien Le Moal
@ 2021-02-02 10:36 ` Damien Le Moal
  2021-02-02 18:49   ` Atish Patra
  2021-02-02 10:36 ` [PATCH v14 16/16] riscv: Add Canaan Kendryte K210 SD card defconfig Damien Le Moal
  15 siblings, 1 reply; 81+ messages in thread
From: Damien Le Moal @ 2021-02-02 10:36 UTC (permalink / raw)
  To: Palmer Dabbelt, linux-riscv; +Cc: Atish Patra, Anup Patel, Sean Anderson

Update the Kendryte k210 nommu default configuration file
(nommu_k210_defconfig) to include device drivers for reset, reboot,
I2C, SPI, gpio and LEDs support. Virtual Terminal support is also
disabled as no terminal devices are supported and enabled. Disabling
CONFIG_VT (removing the no longer needed override for
CONFIG_VGA_CONSOLE) reduces the kernel image size by about 65 KB.

This default configuration remains suitable for a system using an
initramfs cpio file linked into the kernel image.

Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Reviewed-by: Anup Patel <anup@brainfault.org>
---
 arch/riscv/configs/nommu_k210_defconfig | 44 ++++++++++++++++++++-----
 1 file changed, 36 insertions(+), 8 deletions(-)

diff --git a/arch/riscv/configs/nommu_k210_defconfig b/arch/riscv/configs/nommu_k210_defconfig
index 368a28cf1467..b16a2a12c82a 100644
--- a/arch/riscv/configs/nommu_k210_defconfig
+++ b/arch/riscv/configs/nommu_k210_defconfig
@@ -1,17 +1,19 @@
 # CONFIG_CPU_ISOLATION is not set
-CONFIG_LOG_BUF_SHIFT=15
+CONFIG_LOG_BUF_SHIFT=13
 CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=12
 CONFIG_BLK_DEV_INITRD=y
-CONFIG_INITRAMFS_FORCE=y
+# CONFIG_RD_GZIP is not set
 # CONFIG_RD_BZIP2 is not set
 # CONFIG_RD_LZMA is not set
 # CONFIG_RD_XZ is not set
 # CONFIG_RD_LZO is not set
 # CONFIG_RD_LZ4 is not set
+# CONFIG_RD_ZSTD is not set
 CONFIG_CC_OPTIMIZE_FOR_SIZE=y
 # CONFIG_SYSFS_SYSCALL is not set
 # CONFIG_FHANDLE is not set
 # CONFIG_BASE_FULL is not set
+# CONFIG_FUTEX is not set
 # CONFIG_EPOLL is not set
 # CONFIG_SIGNALFD is not set
 # CONFIG_TIMERFD is not set
@@ -25,15 +27,17 @@ CONFIG_EMBEDDED=y
 # CONFIG_VM_EVENT_COUNTERS is not set
 # CONFIG_COMPAT_BRK is not set
 CONFIG_SLOB=y
-# CONFIG_SLAB_MERGE_DEFAULT is not set
 # CONFIG_MMU is not set
 CONFIG_SOC_CANAAN=y
+CONFIG_SOC_CANAAN_K210_DTB_SOURCE="k210_generic"
 CONFIG_MAXPHYSMEM_2GB=y
 CONFIG_SMP=y
 CONFIG_NR_CPUS=2
 CONFIG_CMDLINE="earlycon console=ttySIF0"
 CONFIG_CMDLINE_FORCE=y
-CONFIG_JUMP_LABEL=y
+# CONFIG_SECCOMP is not set
+# CONFIG_STACKPROTECTOR is not set
+# CONFIG_GCC_PLUGINS is not set
 # CONFIG_BLOCK is not set
 CONFIG_BINFMT_FLAT=y
 # CONFIG_COREDUMP is not set
@@ -41,23 +45,47 @@ CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
 # CONFIG_FW_LOADER is not set
 # CONFIG_ALLOW_DEV_COREDUMP is not set
-# CONFIG_INPUT_KEYBOARD is not set
-# CONFIG_INPUT_MOUSE is not set
+# CONFIG_INPUT is not set
 # CONFIG_SERIO is not set
+# CONFIG_VT is not set
+# CONFIG_UNIX98_PTYS is not set
 # CONFIG_LEGACY_PTYS is not set
 # CONFIG_LDISC_AUTOLOAD is not set
 # CONFIG_HW_RANDOM is not set
 # CONFIG_DEVMEM is not set
+CONFIG_I2C=y
+# CONFIG_I2C_COMPAT is not set
+CONFIG_I2C_CHARDEV=y
+# CONFIG_I2C_HELPER_AUTO is not set
+CONFIG_I2C_DESIGNWARE_PLATFORM=y
+CONFIG_SPI=y
+# CONFIG_SPI_MEM is not set
+CONFIG_SPI_DESIGNWARE=y
+CONFIG_SPI_DW_MMIO=y
+# CONFIG_GPIO_CDEV_V1 is not set
+CONFIG_GPIO_DWAPB=y
+CONFIG_GPIO_SIFIVE=y
+CONFIG_POWER_RESET=y
+CONFIG_POWER_RESET_SYSCON=y
 # CONFIG_HWMON is not set
-# CONFIG_VGA_CONSOLE is not set
-# CONFIG_HID is not set
 # CONFIG_USB_SUPPORT is not set
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_GPIO=y
+CONFIG_LEDS_USER=y
 # CONFIG_VIRTIO_MENU is not set
+# CONFIG_VHOST_MENU is not set
+# CONFIG_SURFACE_PLATFORMS is not set
+# CONFIG_FILE_LOCKING is not set
 # CONFIG_DNOTIFY is not set
 # CONFIG_INOTIFY_USER is not set
 # CONFIG_MISC_FILESYSTEMS is not set
 CONFIG_LSM="[]"
 CONFIG_PRINTK_TIME=y
+# CONFIG_SYMBOLIC_ERRNAME is not set
+# CONFIG_DEBUG_BUGVERBOSE is not set
+# CONFIG_SECTION_MISMATCH_WARN_ONLY is not set
+# CONFIG_FRAME_POINTER is not set
 # CONFIG_DEBUG_MISC is not set
 CONFIG_PANIC_ON_OOPS=y
 # CONFIG_SCHED_DEBUG is not set
-- 
2.29.2


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply related	[flat|nested] 81+ messages in thread

* [PATCH v14 16/16] riscv: Add Canaan Kendryte K210 SD card defconfig
  2021-02-02 10:36 [PATCH v14 00/16] RISC-V Kendryte K210 support improvements Damien Le Moal
                   ` (14 preceding siblings ...)
  2021-02-02 10:36 ` [PATCH v14 15/16] riscv: Update Canaan Kendryte K210 defconfig Damien Le Moal
@ 2021-02-02 10:36 ` Damien Le Moal
  2021-02-02 18:48   ` Atish Patra
  15 siblings, 1 reply; 81+ messages in thread
From: Damien Le Moal @ 2021-02-02 10:36 UTC (permalink / raw)
  To: Palmer Dabbelt, linux-riscv; +Cc: Atish Patra, Anup Patel, Sean Anderson

The nommu_k210_defconfig default configuration allows booting a Canaan
Kendryte K210 SoC based boards using an embedded intramfs cpio file.
Modifying this configuration to enable support for the board SD card is
not trivial for all users. To help beginners getting started with these
boards, add the nommu_k210_sdcard_defconfig default configuration file
to set all configuration options necessary to use the board mmc-spi sd
card for the root file system.

This new configuration adds support for the block layer, the mmc-spi
driver and modifies the boot options to specify the rootfs device as
mmcblk0p1 (first partition of the sd card block device). The ext2 file
system is selected by default to encourage its use as that results in
only about 4KB added to the kernel image size. As ext2 does not have
journaling, the boot options specify a read-only mount of the file
system. Similarly to the smaller nommu_k210_defconfig, this new default
configuration disables virtual terminal support to reduce the kernel
image size.

The default device tree selected is unchanged, specifying the simple
"k210_generic" device tree file. The user must change this setting to
specify the device tree suitable for the board being used
(sipeed_maix_bit, sipeed_maix_dock, sipeed_maix_go, sipeed_maixduino or
canaan_kd233).

Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Reviewed-by: Anup Patel <anup@brainfault.org>
---
 .../riscv/configs/nommu_k210_sdcard_defconfig | 92 +++++++++++++++++++
 1 file changed, 92 insertions(+)
 create mode 100644 arch/riscv/configs/nommu_k210_sdcard_defconfig

diff --git a/arch/riscv/configs/nommu_k210_sdcard_defconfig b/arch/riscv/configs/nommu_k210_sdcard_defconfig
new file mode 100644
index 000000000000..61f887f65419
--- /dev/null
+++ b/arch/riscv/configs/nommu_k210_sdcard_defconfig
@@ -0,0 +1,92 @@
+# CONFIG_CPU_ISOLATION is not set
+CONFIG_LOG_BUF_SHIFT=13
+CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=12
+CONFIG_CC_OPTIMIZE_FOR_SIZE=y
+# CONFIG_SYSFS_SYSCALL is not set
+# CONFIG_FHANDLE is not set
+# CONFIG_BASE_FULL is not set
+# CONFIG_FUTEX is not set
+# CONFIG_EPOLL is not set
+# CONFIG_SIGNALFD is not set
+# CONFIG_TIMERFD is not set
+# CONFIG_EVENTFD is not set
+# CONFIG_AIO is not set
+# CONFIG_IO_URING is not set
+# CONFIG_ADVISE_SYSCALLS is not set
+# CONFIG_MEMBARRIER is not set
+# CONFIG_KALLSYMS is not set
+CONFIG_EMBEDDED=y
+# CONFIG_VM_EVENT_COUNTERS is not set
+# CONFIG_COMPAT_BRK is not set
+CONFIG_SLOB=y
+# CONFIG_MMU is not set
+CONFIG_SOC_CANAAN=y
+CONFIG_SOC_CANAAN_K210_DTB_SOURCE="k210_generic"
+CONFIG_MAXPHYSMEM_2GB=y
+CONFIG_SMP=y
+CONFIG_NR_CPUS=2
+CONFIG_CMDLINE="earlycon console=ttySIF0 rootdelay=2 root=/dev/mmcblk0p1 ro"
+CONFIG_CMDLINE_FORCE=y
+# CONFIG_SECCOMP is not set
+# CONFIG_STACKPROTECTOR is not set
+# CONFIG_GCC_PLUGINS is not set
+# CONFIG_BLK_DEV_BSG is not set
+# CONFIG_MQ_IOSCHED_DEADLINE is not set
+# CONFIG_MQ_IOSCHED_KYBER is not set
+CONFIG_BINFMT_FLAT=y
+# CONFIG_COREDUMP is not set
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+# CONFIG_FW_LOADER is not set
+# CONFIG_ALLOW_DEV_COREDUMP is not set
+# CONFIG_BLK_DEV is not set
+# CONFIG_INPUT is not set
+# CONFIG_SERIO is not set
+# CONFIG_VT is not set
+# CONFIG_LEGACY_PTYS is not set
+# CONFIG_LDISC_AUTOLOAD is not set
+# CONFIG_HW_RANDOM is not set
+# CONFIG_DEVMEM is not set
+CONFIG_I2C=y
+CONFIG_I2C_CHARDEV=y
+# CONFIG_I2C_HELPER_AUTO is not set
+CONFIG_I2C_DESIGNWARE_PLATFORM=y
+CONFIG_SPI=y
+# CONFIG_SPI_MEM is not set
+CONFIG_SPI_DESIGNWARE=y
+CONFIG_SPI_DW_MMIO=y
+# CONFIG_GPIO_CDEV_V1 is not set
+CONFIG_GPIO_DWAPB=y
+CONFIG_GPIO_SIFIVE=y
+CONFIG_POWER_RESET=y
+CONFIG_POWER_RESET_SYSCON=y
+# CONFIG_HWMON is not set
+# CONFIG_USB_SUPPORT is not set
+CONFIG_MMC=y
+# CONFIG_PWRSEQ_EMMC is not set
+# CONFIG_PWRSEQ_SIMPLE is not set
+CONFIG_MMC_SPI=y
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_GPIO=y
+CONFIG_LEDS_USER=y
+# CONFIG_VIRTIO_MENU is not set
+# CONFIG_VHOST_MENU is not set
+# CONFIG_SURFACE_PLATFORMS is not set
+CONFIG_EXT2_FS=y
+# CONFIG_FILE_LOCKING is not set
+# CONFIG_DNOTIFY is not set
+# CONFIG_INOTIFY_USER is not set
+# CONFIG_MISC_FILESYSTEMS is not set
+CONFIG_LSM="[]"
+CONFIG_PRINTK_TIME=y
+# CONFIG_SYMBOLIC_ERRNAME is not set
+# CONFIG_DEBUG_BUGVERBOSE is not set
+# CONFIG_SECTION_MISMATCH_WARN_ONLY is not set
+# CONFIG_FRAME_POINTER is not set
+# CONFIG_DEBUG_MISC is not set
+CONFIG_PANIC_ON_OOPS=y
+# CONFIG_SCHED_DEBUG is not set
+# CONFIG_RCU_TRACE is not set
+# CONFIG_FTRACE is not set
+# CONFIG_RUNTIME_TESTING_MENU is not set
-- 
2.29.2


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply related	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 05/16] dt-bindings: update sifive clint compatible string
  2021-02-02 10:36   ` Damien Le Moal
@ 2021-02-02 17:52     ` Atish Patra
  -1 siblings, 0 replies; 81+ messages in thread
From: Atish Patra @ 2021-02-02 17:52 UTC (permalink / raw)
  To: Damien Le Moal
  Cc: Palmer Dabbelt, linux-riscv, Atish Patra, devicetree, Anup Patel,
	Rob Herring, Sean Anderson

On Tue, Feb 2, 2021 at 2:37 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
>
> Add the "canaan,k210-clint" compatible string to the Sifive clint
> bindings to indicate the use of the "sifive,clint0" IP block in the
> Canaan Kendryte K210 SoC. The description of the compatible string
> property is also updated to reflect this addition.
>
> Cc: Anup Patel <anup.patel@wdc.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> ---
>  .../bindings/timer/sifive,clint.yaml          | 19 +++++++++++++------
>  1 file changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/timer/sifive,clint.yaml b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
> index 2a0e9cd9fbcf..1a7d582a208f 100644
> --- a/Documentation/devicetree/bindings/timer/sifive,clint.yaml
> +++ b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
> @@ -22,16 +22,23 @@ description:
>
>  properties:
>    compatible:
> -    items:
> -      - const: sifive,fu540-c000-clint
> -      - const: sifive,clint0
> +    oneOf:
> +      - items:
> +          - const: sifive,fu540-c000-clint
> +          - const: sifive,clint0
> +
> +      - items:
> +          - const: canaan,k210-clint
> +          - const: sifive,clint0
>
>      description:
> -      Should be "sifive,<chip>-clint" and "sifive,clint<version>".
> +      Should be "<vendor>,<chip>-clint" and "sifive,clint<version>".
>        Supported compatible strings are -
>        "sifive,fu540-c000-clint" for the SiFive CLINT v0 as integrated
> -      onto the SiFive FU540 chip, and "sifive,clint0" for the SiFive
> -      CLINT v0 IP block with no chip integration tweaks.
> +      onto the SiFive FU540 chip, "canaan,k210-clint" for the SiFive
> +      CLINT v0 as integrated onto the Canaan Kendryte K210 chip, and
> +      "sifive,clint0" for the SiFive CLINT v0 IP block with no chip
> +      integration tweaks.
>        Please refer to sifive-blocks-ip-versioning.txt for details
>
>    reg:
> --
> 2.29.2
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv


Reviewed-by: Atish Patra <atish.patra@wdc.com>

-- 
Regards,
Atish

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 05/16] dt-bindings: update sifive clint compatible string
@ 2021-02-02 17:52     ` Atish Patra
  0 siblings, 0 replies; 81+ messages in thread
From: Atish Patra @ 2021-02-02 17:52 UTC (permalink / raw)
  To: Damien Le Moal
  Cc: Rob Herring, devicetree, Anup Patel, Sean Anderson, Atish Patra,
	Palmer Dabbelt, linux-riscv

On Tue, Feb 2, 2021 at 2:37 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
>
> Add the "canaan,k210-clint" compatible string to the Sifive clint
> bindings to indicate the use of the "sifive,clint0" IP block in the
> Canaan Kendryte K210 SoC. The description of the compatible string
> property is also updated to reflect this addition.
>
> Cc: Anup Patel <anup.patel@wdc.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> ---
>  .../bindings/timer/sifive,clint.yaml          | 19 +++++++++++++------
>  1 file changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/timer/sifive,clint.yaml b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
> index 2a0e9cd9fbcf..1a7d582a208f 100644
> --- a/Documentation/devicetree/bindings/timer/sifive,clint.yaml
> +++ b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
> @@ -22,16 +22,23 @@ description:
>
>  properties:
>    compatible:
> -    items:
> -      - const: sifive,fu540-c000-clint
> -      - const: sifive,clint0
> +    oneOf:
> +      - items:
> +          - const: sifive,fu540-c000-clint
> +          - const: sifive,clint0
> +
> +      - items:
> +          - const: canaan,k210-clint
> +          - const: sifive,clint0
>
>      description:
> -      Should be "sifive,<chip>-clint" and "sifive,clint<version>".
> +      Should be "<vendor>,<chip>-clint" and "sifive,clint<version>".
>        Supported compatible strings are -
>        "sifive,fu540-c000-clint" for the SiFive CLINT v0 as integrated
> -      onto the SiFive FU540 chip, and "sifive,clint0" for the SiFive
> -      CLINT v0 IP block with no chip integration tweaks.
> +      onto the SiFive FU540 chip, "canaan,k210-clint" for the SiFive
> +      CLINT v0 as integrated onto the Canaan Kendryte K210 chip, and
> +      "sifive,clint0" for the SiFive CLINT v0 IP block with no chip
> +      integration tweaks.
>        Please refer to sifive-blocks-ip-versioning.txt for details
>
>    reg:
> --
> 2.29.2
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv


Reviewed-by: Atish Patra <atish.patra@wdc.com>

-- 
Regards,
Atish

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 03/16] dt-bindings: update risc-v cpu properties
  2021-02-02 10:36   ` Damien Le Moal
@ 2021-02-02 17:54     ` Atish Patra
  -1 siblings, 0 replies; 81+ messages in thread
From: Atish Patra @ 2021-02-02 17:54 UTC (permalink / raw)
  To: Damien Le Moal
  Cc: Palmer Dabbelt, linux-riscv, devicetree, Rob Herring, Anup Patel,
	Sean Anderson, Atish Patra, Paul Walmsley

On Tue, Feb 2, 2021 at 2:37 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
>
> The Canaan Kendryte K210 SoC CPU cores are based on a rocket chip
> version using a draft verion of the RISC-V ISA specifications. To avoid
> any confusion with CPU cores using stable specifications, add the
> compatible string "canaan,k210" for this SoC CPU cores.
>
> Also add the "riscv,none" value to the mmu-type property to allow a DT
> to indicate that the CPU being described does not have an MMU or that
> it has an MMU that is not usable (which is the case for the K210 SoC).
>
> Cc: Paul Walmsley <paul.walmsley@sifive.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> ---
>  Documentation/devicetree/bindings/riscv/cpus.yaml | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
> index eb6843f69f7c..e534f6a7cfa1 100644
> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml
> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
> @@ -39,6 +39,7 @@ properties:
>                - sifive,u74
>                - sifive,u5
>                - sifive,u7
> +              - canaan,k210
>            - const: riscv
>        - const: riscv    # Simulator only
>      description:
> @@ -56,6 +57,7 @@ properties:
>        - riscv,sv32
>        - riscv,sv39
>        - riscv,sv48
> +      - riscv,none
>
>    riscv,isa:
>      description:
> --
> 2.29.2
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv


Reviewed-by: Atish Patra <atish.patra@wdc.com>

-- 
Regards,
Atish

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 03/16] dt-bindings: update risc-v cpu properties
@ 2021-02-02 17:54     ` Atish Patra
  0 siblings, 0 replies; 81+ messages in thread
From: Atish Patra @ 2021-02-02 17:54 UTC (permalink / raw)
  To: Damien Le Moal
  Cc: devicetree, Rob Herring, Anup Patel, Sean Anderson, Atish Patra,
	Palmer Dabbelt, Paul Walmsley, linux-riscv

On Tue, Feb 2, 2021 at 2:37 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
>
> The Canaan Kendryte K210 SoC CPU cores are based on a rocket chip
> version using a draft verion of the RISC-V ISA specifications. To avoid
> any confusion with CPU cores using stable specifications, add the
> compatible string "canaan,k210" for this SoC CPU cores.
>
> Also add the "riscv,none" value to the mmu-type property to allow a DT
> to indicate that the CPU being described does not have an MMU or that
> it has an MMU that is not usable (which is the case for the K210 SoC).
>
> Cc: Paul Walmsley <paul.walmsley@sifive.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> ---
>  Documentation/devicetree/bindings/riscv/cpus.yaml | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
> index eb6843f69f7c..e534f6a7cfa1 100644
> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml
> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
> @@ -39,6 +39,7 @@ properties:
>                - sifive,u74
>                - sifive,u5
>                - sifive,u7
> +              - canaan,k210
>            - const: riscv
>        - const: riscv    # Simulator only
>      description:
> @@ -56,6 +57,7 @@ properties:
>        - riscv,sv32
>        - riscv,sv39
>        - riscv,sv48
> +      - riscv,none
>
>    riscv,isa:
>      description:
> --
> 2.29.2
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv


Reviewed-by: Atish Patra <atish.patra@wdc.com>

-- 
Regards,
Atish

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 02/16] dt-bindings: add Canaan boards compatible strings
  2021-02-02 10:36   ` Damien Le Moal
@ 2021-02-02 17:55     ` Atish Patra
  -1 siblings, 0 replies; 81+ messages in thread
From: Atish Patra @ 2021-02-02 17:55 UTC (permalink / raw)
  To: Damien Le Moal
  Cc: Palmer Dabbelt, linux-riscv, Atish Patra, devicetree, Anup Patel,
	Rob Herring, Sean Anderson

On Tue, Feb 2, 2021 at 2:37 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
>
> Introduce the file riscv/canaan.yaml to document compatible strings
> related to the Canaan Kendryte K210 SoC. The compatible string
> "canaan,kendryte-k210" used to indicate the use of this SoC to the
> early SoC init code is added. This new file also defines the compatible
> strings of all supported boards based on this SoC.
>
> Cc: Rob Herring <robh@kernel.org>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> ---
>  .../devicetree/bindings/riscv/canaan.yaml     | 47 +++++++++++++++++++
>  1 file changed, 47 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/riscv/canaan.yaml
>
> diff --git a/Documentation/devicetree/bindings/riscv/canaan.yaml b/Documentation/devicetree/bindings/riscv/canaan.yaml
> new file mode 100644
> index 000000000000..f8f3f286bd55
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/riscv/canaan.yaml
> @@ -0,0 +1,47 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/riscv/canaan.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Canaan SoC-based boards
> +
> +maintainers:
> +  - Damien Le Moal <damien.lemoal@wdc.com>
> +
> +description:
> +  Canaan Kendryte K210 SoC-based boards
> +
> +properties:
> +  $nodename:
> +    const: '/'
> +  compatible:
> +    oneOf:
> +      - items:
> +          - const: sipeed,maix-bit
> +          - const: sipeed,maix-bitm
> +          - const: canaan,kendryte-k210
> +
> +      - items:
> +          - const: sipeed,maix-go
> +          - const: canaan,kendryte-k210
> +
> +      - items:
> +          - const: sipeed,maix-dock-m1
> +          - const: sipeed,maix-dock-m1w
> +          - const: canaan,kendryte-k210
> +
> +      - items:
> +          - const: sipeed,maixduino
> +          - const: canaan,kendryte-k210
> +
> +      - items:
> +          - const: canaan,kendryte-kd233
> +          - const: canaan,kendryte-k210
> +
> +      - items:
> +          - const: canaan,kendryte-k210
> +
> +additionalProperties: true
> +
> +...
> --
> 2.29.2
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv


Reviewed-by: Atish Patra <atish.patra@wdc.com>

-- 
Regards,
Atish

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 02/16] dt-bindings: add Canaan boards compatible strings
@ 2021-02-02 17:55     ` Atish Patra
  0 siblings, 0 replies; 81+ messages in thread
From: Atish Patra @ 2021-02-02 17:55 UTC (permalink / raw)
  To: Damien Le Moal
  Cc: Rob Herring, devicetree, Anup Patel, Sean Anderson, Atish Patra,
	Palmer Dabbelt, linux-riscv

On Tue, Feb 2, 2021 at 2:37 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
>
> Introduce the file riscv/canaan.yaml to document compatible strings
> related to the Canaan Kendryte K210 SoC. The compatible string
> "canaan,kendryte-k210" used to indicate the use of this SoC to the
> early SoC init code is added. This new file also defines the compatible
> strings of all supported boards based on this SoC.
>
> Cc: Rob Herring <robh@kernel.org>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> ---
>  .../devicetree/bindings/riscv/canaan.yaml     | 47 +++++++++++++++++++
>  1 file changed, 47 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/riscv/canaan.yaml
>
> diff --git a/Documentation/devicetree/bindings/riscv/canaan.yaml b/Documentation/devicetree/bindings/riscv/canaan.yaml
> new file mode 100644
> index 000000000000..f8f3f286bd55
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/riscv/canaan.yaml
> @@ -0,0 +1,47 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/riscv/canaan.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Canaan SoC-based boards
> +
> +maintainers:
> +  - Damien Le Moal <damien.lemoal@wdc.com>
> +
> +description:
> +  Canaan Kendryte K210 SoC-based boards
> +
> +properties:
> +  $nodename:
> +    const: '/'
> +  compatible:
> +    oneOf:
> +      - items:
> +          - const: sipeed,maix-bit
> +          - const: sipeed,maix-bitm
> +          - const: canaan,kendryte-k210
> +
> +      - items:
> +          - const: sipeed,maix-go
> +          - const: canaan,kendryte-k210
> +
> +      - items:
> +          - const: sipeed,maix-dock-m1
> +          - const: sipeed,maix-dock-m1w
> +          - const: canaan,kendryte-k210
> +
> +      - items:
> +          - const: sipeed,maixduino
> +          - const: canaan,kendryte-k210
> +
> +      - items:
> +          - const: canaan,kendryte-kd233
> +          - const: canaan,kendryte-k210
> +
> +      - items:
> +          - const: canaan,kendryte-k210
> +
> +additionalProperties: true
> +
> +...
> --
> 2.29.2
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv


Reviewed-by: Atish Patra <atish.patra@wdc.com>

-- 
Regards,
Atish

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 04/16] dt-bindings: update sifive plic compatible string
  2021-02-02 10:36   ` Damien Le Moal
@ 2021-02-02 18:26     ` Atish Patra
  -1 siblings, 0 replies; 81+ messages in thread
From: Atish Patra @ 2021-02-02 18:26 UTC (permalink / raw)
  To: Damien Le Moal
  Cc: Palmer Dabbelt, linux-riscv, devicetree, Rob Herring, Anup Patel,
	Sean Anderson, Atish Patra, Paul Walmsley

On Tue, Feb 2, 2021 at 2:37 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
>
> Add the compatible string "canaan,k210-plic" to the Sifive plic bindings
> to indicate the use of the "sifive,plic-1.0.0" IP block in the Canaan
> Kendryte K210 SoC. The description is also updated to reflect this
> change, that is, that SoCs from other vendors may also use this plic
> implementation.
>
> Cc: Paul Walmsley <paul.walmsley@sifive.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> ---
>  .../sifive,plic-1.0.0.yaml                    | 20 ++++++++++++-------
>  1 file changed, 13 insertions(+), 7 deletions(-)
>
> 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 b9a61c9f7530..3db86d329e1e 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
> @@ -8,10 +8,11 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
>  title: SiFive Platform-Level Interrupt Controller (PLIC)
>
>  description:
> -  SiFive SOCs include an implementation of the Platform-Level Interrupt Controller
> -  (PLIC) high-level specification in the RISC-V Privileged Architecture
> -  specification. The PLIC connects all external interrupts in the system to all
> -  hart contexts in the system, via the external interrupt source in each hart.
> +  SiFive other RISC-V and other SoCs include an implementation of the
> +  Platform-Level Interrupt Controller (PLIC) high-level specification in
> +  the RISC-V Privileged Architecture specification. The PLIC connects all

The latest privilege spec doesn't specify PLIC anymore.

> +  external interrupts in the system to all hart contexts in the system, via
> +  the external interrupt source in each hart.
>
>    A hart context is a privilege mode in a hardware execution thread. For example,
>    in an 4 core system with 2-way SMT, you have 8 harts and probably at least two
> @@ -41,9 +42,14 @@ maintainers:
>
>  properties:
>    compatible:
> -    items:
> -      - const: sifive,fu540-c000-plic
> -      - const: sifive,plic-1.0.0
> +    oneOf:
> +      - items:
> +          - const: sifive,fu540-c000-plic
> +          - const: sifive,plic-1.0.0
> +
> +      - items:
> +          - const: canaan,k210-plic
> +          - const: sifive,plic-1.0.0
>
>    reg:
>      maxItems: 1
> --
> 2.29.2
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

other than that,

Reviewed-by: Atish Patra <atish.patra@wdc.com>

-- 
Regards,
Atish

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 04/16] dt-bindings: update sifive plic compatible string
@ 2021-02-02 18:26     ` Atish Patra
  0 siblings, 0 replies; 81+ messages in thread
From: Atish Patra @ 2021-02-02 18:26 UTC (permalink / raw)
  To: Damien Le Moal
  Cc: devicetree, Rob Herring, Anup Patel, Sean Anderson, Atish Patra,
	Palmer Dabbelt, Paul Walmsley, linux-riscv

On Tue, Feb 2, 2021 at 2:37 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
>
> Add the compatible string "canaan,k210-plic" to the Sifive plic bindings
> to indicate the use of the "sifive,plic-1.0.0" IP block in the Canaan
> Kendryte K210 SoC. The description is also updated to reflect this
> change, that is, that SoCs from other vendors may also use this plic
> implementation.
>
> Cc: Paul Walmsley <paul.walmsley@sifive.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> ---
>  .../sifive,plic-1.0.0.yaml                    | 20 ++++++++++++-------
>  1 file changed, 13 insertions(+), 7 deletions(-)
>
> 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 b9a61c9f7530..3db86d329e1e 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
> @@ -8,10 +8,11 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
>  title: SiFive Platform-Level Interrupt Controller (PLIC)
>
>  description:
> -  SiFive SOCs include an implementation of the Platform-Level Interrupt Controller
> -  (PLIC) high-level specification in the RISC-V Privileged Architecture
> -  specification. The PLIC connects all external interrupts in the system to all
> -  hart contexts in the system, via the external interrupt source in each hart.
> +  SiFive other RISC-V and other SoCs include an implementation of the
> +  Platform-Level Interrupt Controller (PLIC) high-level specification in
> +  the RISC-V Privileged Architecture specification. The PLIC connects all

The latest privilege spec doesn't specify PLIC anymore.

> +  external interrupts in the system to all hart contexts in the system, via
> +  the external interrupt source in each hart.
>
>    A hart context is a privilege mode in a hardware execution thread. For example,
>    in an 4 core system with 2-way SMT, you have 8 harts and probably at least two
> @@ -41,9 +42,14 @@ maintainers:
>
>  properties:
>    compatible:
> -    items:
> -      - const: sifive,fu540-c000-plic
> -      - const: sifive,plic-1.0.0
> +    oneOf:
> +      - items:
> +          - const: sifive,fu540-c000-plic
> +          - const: sifive,plic-1.0.0
> +
> +      - items:
> +          - const: canaan,k210-plic
> +          - const: sifive,plic-1.0.0
>
>    reg:
>      maxItems: 1
> --
> 2.29.2
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

other than that,

Reviewed-by: Atish Patra <atish.patra@wdc.com>

-- 
Regards,
Atish

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 06/16] dt-bindings: update sifive uart compatible string
  2021-02-02 10:36   ` Damien Le Moal
@ 2021-02-02 18:27     ` Atish Patra
  -1 siblings, 0 replies; 81+ messages in thread
From: Atish Patra @ 2021-02-02 18:27 UTC (permalink / raw)
  To: Damien Le Moal
  Cc: Palmer Dabbelt, linux-riscv, devicetree, Rob Herring, Anup Patel,
	Sean Anderson, Atish Patra, Paul Walmsley

On Tue, Feb 2, 2021 at 2:37 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
>
> Add the compatible string "canaan,k210-uarths" to the sifive uart
> bindings to indicate the use of this IP block in the Canaan Kendryte
> K210 SoC.
>
> Cc: Paul Walmsley <paul.walmsley@sifive.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> ---
>  Documentation/devicetree/bindings/serial/sifive-serial.yaml | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/serial/sifive-serial.yaml b/Documentation/devicetree/bindings/serial/sifive-serial.yaml
> index 3ac5c7ff2758..5fa94dacbba9 100644
> --- a/Documentation/devicetree/bindings/serial/sifive-serial.yaml
> +++ b/Documentation/devicetree/bindings/serial/sifive-serial.yaml
> @@ -20,6 +20,7 @@ properties:
>        - enum:
>            - sifive,fu540-c000-uart
>            - sifive,fu740-c000-uart
> +          - canaan,k210-uarths
>        - const: sifive,uart0
>
>      description:
> --
> 2.29.2
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv


Reviewed-by: Atish Patra <atish.patra@wdc.com>

-- 
Regards,
Atish

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 06/16] dt-bindings: update sifive uart compatible string
@ 2021-02-02 18:27     ` Atish Patra
  0 siblings, 0 replies; 81+ messages in thread
From: Atish Patra @ 2021-02-02 18:27 UTC (permalink / raw)
  To: Damien Le Moal
  Cc: devicetree, Rob Herring, Anup Patel, Sean Anderson, Atish Patra,
	Palmer Dabbelt, Paul Walmsley, linux-riscv

On Tue, Feb 2, 2021 at 2:37 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
>
> Add the compatible string "canaan,k210-uarths" to the sifive uart
> bindings to indicate the use of this IP block in the Canaan Kendryte
> K210 SoC.
>
> Cc: Paul Walmsley <paul.walmsley@sifive.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> ---
>  Documentation/devicetree/bindings/serial/sifive-serial.yaml | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/serial/sifive-serial.yaml b/Documentation/devicetree/bindings/serial/sifive-serial.yaml
> index 3ac5c7ff2758..5fa94dacbba9 100644
> --- a/Documentation/devicetree/bindings/serial/sifive-serial.yaml
> +++ b/Documentation/devicetree/bindings/serial/sifive-serial.yaml
> @@ -20,6 +20,7 @@ properties:
>        - enum:
>            - sifive,fu540-c000-uart
>            - sifive,fu740-c000-uart
> +          - canaan,k210-uarths
>        - const: sifive,uart0
>
>      description:
> --
> 2.29.2
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv


Reviewed-by: Atish Patra <atish.patra@wdc.com>

-- 
Regards,
Atish

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 07/16] dt-bindings: fix sifive gpio properties
  2021-02-02 10:36   ` Damien Le Moal
@ 2021-02-02 18:45     ` Atish Patra
  -1 siblings, 0 replies; 81+ messages in thread
From: Atish Patra @ 2021-02-02 18:45 UTC (permalink / raw)
  To: Damien Le Moal
  Cc: Palmer Dabbelt, linux-riscv, devicetree, Rob Herring, Anup Patel,
	Sean Anderson, Atish Patra, Paul Walmsley

On Tue, Feb 2, 2021 at 2:37 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
>
> The sifive gpio IP block supports up to 32 GPIOs. Reflect that in the

The spec here says 16 GPIOs
https://static.dev.sifive.com/FU540-C000-v1.0.pdf

Is there a updated spec available ?

> interrupts property description and maxItems. Also add the standard
> ngpios property to describe the number of GPIOs available on the
> implementation.
>
> Also add the "canaan,k210-gpiohs" compatible string to indicate the use
> of this gpio controller in the Canaan Kendryte K210 SoC. If this
> compatible string is used, do not define the clocks property as
> required as the K210 SoC does not have a software controllable clock
> for the Sifive gpio IP block.
>
> Cc: Paul Walmsley <paul.walmsley@sifive.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> ---
>  .../devicetree/bindings/gpio/sifive,gpio.yaml | 21 ++++++++++++++++---
>  1 file changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> index ab22056f8b44..2cef18ca737c 100644
> --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> @@ -16,6 +16,7 @@ properties:
>        - enum:
>            - sifive,fu540-c000-gpio
>            - sifive,fu740-c000-gpio
> +          - canaan,k210-gpiohs
>        - const: sifive,gpio0
>
>    reg:
> @@ -23,9 +24,9 @@ properties:
>
>    interrupts:
>      description:
> -      interrupt mapping one per GPIO. Maximum 16 GPIOs.
> +      interrupt mapping one per GPIO. Maximum 32 GPIOs.
>      minItems: 1
> -    maxItems: 16
> +    maxItems: 32
>
>    interrupt-controller: true
>
> @@ -38,6 +39,10 @@ properties:
>    "#gpio-cells":
>      const: 2
>
> +  ngpios:
> +    minimum: 1
> +    maximum: 32
> +
>    gpio-controller: true
>
>  required:
> @@ -46,10 +51,20 @@ required:
>    - interrupts
>    - interrupt-controller
>    - "#interrupt-cells"
> -  - clocks
>    - "#gpio-cells"
>    - gpio-controller
>
> +if:
> +  properties:
> +    compatible:
> +      contains:
> +        enum:
> +          - sifive,fu540-c000-gpio
> +          - sifive,fu740-c000-gpio
> +then:
> +  required:
> +    - clocks
> +
>  additionalProperties: false
>
>  examples:
> --
> 2.29.2
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv



-- 
Regards,
Atish

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 07/16] dt-bindings: fix sifive gpio properties
@ 2021-02-02 18:45     ` Atish Patra
  0 siblings, 0 replies; 81+ messages in thread
From: Atish Patra @ 2021-02-02 18:45 UTC (permalink / raw)
  To: Damien Le Moal
  Cc: devicetree, Rob Herring, Anup Patel, Sean Anderson, Atish Patra,
	Palmer Dabbelt, Paul Walmsley, linux-riscv

On Tue, Feb 2, 2021 at 2:37 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
>
> The sifive gpio IP block supports up to 32 GPIOs. Reflect that in the

The spec here says 16 GPIOs
https://static.dev.sifive.com/FU540-C000-v1.0.pdf

Is there a updated spec available ?

> interrupts property description and maxItems. Also add the standard
> ngpios property to describe the number of GPIOs available on the
> implementation.
>
> Also add the "canaan,k210-gpiohs" compatible string to indicate the use
> of this gpio controller in the Canaan Kendryte K210 SoC. If this
> compatible string is used, do not define the clocks property as
> required as the K210 SoC does not have a software controllable clock
> for the Sifive gpio IP block.
>
> Cc: Paul Walmsley <paul.walmsley@sifive.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> ---
>  .../devicetree/bindings/gpio/sifive,gpio.yaml | 21 ++++++++++++++++---
>  1 file changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> index ab22056f8b44..2cef18ca737c 100644
> --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> @@ -16,6 +16,7 @@ properties:
>        - enum:
>            - sifive,fu540-c000-gpio
>            - sifive,fu740-c000-gpio
> +          - canaan,k210-gpiohs
>        - const: sifive,gpio0
>
>    reg:
> @@ -23,9 +24,9 @@ properties:
>
>    interrupts:
>      description:
> -      interrupt mapping one per GPIO. Maximum 16 GPIOs.
> +      interrupt mapping one per GPIO. Maximum 32 GPIOs.
>      minItems: 1
> -    maxItems: 16
> +    maxItems: 32
>
>    interrupt-controller: true
>
> @@ -38,6 +39,10 @@ properties:
>    "#gpio-cells":
>      const: 2
>
> +  ngpios:
> +    minimum: 1
> +    maximum: 32
> +
>    gpio-controller: true
>
>  required:
> @@ -46,10 +51,20 @@ required:
>    - interrupts
>    - interrupt-controller
>    - "#interrupt-cells"
> -  - clocks
>    - "#gpio-cells"
>    - gpio-controller
>
> +if:
> +  properties:
> +    compatible:
> +      contains:
> +        enum:
> +          - sifive,fu540-c000-gpio
> +          - sifive,fu740-c000-gpio
> +then:
> +  required:
> +    - clocks
> +
>  additionalProperties: false
>
>  examples:
> --
> 2.29.2
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv



-- 
Regards,
Atish

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 08/16] dt-bindings: add resets property to dw-apb-timer
  2021-02-02 10:36   ` Damien Le Moal
@ 2021-02-02 18:45     ` Atish Patra
  -1 siblings, 0 replies; 81+ messages in thread
From: Atish Patra @ 2021-02-02 18:45 UTC (permalink / raw)
  To: Damien Le Moal
  Cc: Palmer Dabbelt, linux-riscv, Rob Herring, Daniel Lezcano,
	devicetree, Anup Patel, Sean Anderson, Atish Patra

On Tue, Feb 2, 2021 at 2:37 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
>
> The Synopsis DesignWare APB timer driver
> (drivers/clocksource/dw_apb_timer_of.c) indirectly uses the resets
> property of its node as it executes the function of_reset_control_get().
> Make sure that this property is documented in
> timer/snps,dw-apb-timer.yaml to avoid make dtbs_check warnings.
>
> Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
> Cc: Rob Herring <robh@kernel.org>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> ---
>  Documentation/devicetree/bindings/timer/snps,dw-apb-timer.yaml | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/timer/snps,dw-apb-timer.yaml b/Documentation/devicetree/bindings/timer/snps,dw-apb-timer.yaml
> index d65faf289a83..d33c9205a909 100644
> --- a/Documentation/devicetree/bindings/timer/snps,dw-apb-timer.yaml
> +++ b/Documentation/devicetree/bindings/timer/snps,dw-apb-timer.yaml
> @@ -24,6 +24,9 @@ properties:
>    interrupts:
>      maxItems: 1
>
> +  resets:
> +    maxItems: 1
> +
>    clocks:
>      minItems: 1
>      items:
> --
> 2.29.2
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv



Reviewed-by: Atish Patra <atish.patra@wdc.com>
-- 
Regards,
Atish

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 08/16] dt-bindings: add resets property to dw-apb-timer
@ 2021-02-02 18:45     ` Atish Patra
  0 siblings, 0 replies; 81+ messages in thread
From: Atish Patra @ 2021-02-02 18:45 UTC (permalink / raw)
  To: Damien Le Moal
  Cc: Rob Herring, Daniel Lezcano, devicetree, Anup Patel,
	Sean Anderson, Atish Patra, Palmer Dabbelt, linux-riscv

On Tue, Feb 2, 2021 at 2:37 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
>
> The Synopsis DesignWare APB timer driver
> (drivers/clocksource/dw_apb_timer_of.c) indirectly uses the resets
> property of its node as it executes the function of_reset_control_get().
> Make sure that this property is documented in
> timer/snps,dw-apb-timer.yaml to avoid make dtbs_check warnings.
>
> Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
> Cc: Rob Herring <robh@kernel.org>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> ---
>  Documentation/devicetree/bindings/timer/snps,dw-apb-timer.yaml | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/timer/snps,dw-apb-timer.yaml b/Documentation/devicetree/bindings/timer/snps,dw-apb-timer.yaml
> index d65faf289a83..d33c9205a909 100644
> --- a/Documentation/devicetree/bindings/timer/snps,dw-apb-timer.yaml
> +++ b/Documentation/devicetree/bindings/timer/snps,dw-apb-timer.yaml
> @@ -24,6 +24,9 @@ properties:
>    interrupts:
>      maxItems: 1
>
> +  resets:
> +    maxItems: 1
> +
>    clocks:
>      minItems: 1
>      items:
> --
> 2.29.2
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv



Reviewed-by: Atish Patra <atish.patra@wdc.com>
-- 
Regards,
Atish

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 16/16] riscv: Add Canaan Kendryte K210 SD card defconfig
  2021-02-02 10:36 ` [PATCH v14 16/16] riscv: Add Canaan Kendryte K210 SD card defconfig Damien Le Moal
@ 2021-02-02 18:48   ` Atish Patra
  0 siblings, 0 replies; 81+ messages in thread
From: Atish Patra @ 2021-02-02 18:48 UTC (permalink / raw)
  To: Damien Le Moal
  Cc: Atish Patra, linux-riscv, Anup Patel, Palmer Dabbelt, Sean Anderson

On Tue, Feb 2, 2021 at 2:37 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
>
> The nommu_k210_defconfig default configuration allows booting a Canaan
> Kendryte K210 SoC based boards using an embedded intramfs cpio file.
> Modifying this configuration to enable support for the board SD card is
> not trivial for all users. To help beginners getting started with these
> boards, add the nommu_k210_sdcard_defconfig default configuration file
> to set all configuration options necessary to use the board mmc-spi sd
> card for the root file system.
>
> This new configuration adds support for the block layer, the mmc-spi
> driver and modifies the boot options to specify the rootfs device as
> mmcblk0p1 (first partition of the sd card block device). The ext2 file
> system is selected by default to encourage its use as that results in
> only about 4KB added to the kernel image size. As ext2 does not have
> journaling, the boot options specify a read-only mount of the file
> system. Similarly to the smaller nommu_k210_defconfig, this new default
> configuration disables virtual terminal support to reduce the kernel
> image size.
>
> The default device tree selected is unchanged, specifying the simple
> "k210_generic" device tree file. The user must change this setting to
> specify the device tree suitable for the board being used
> (sipeed_maix_bit, sipeed_maix_dock, sipeed_maix_go, sipeed_maixduino or
> canaan_kd233).
>
> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> Reviewed-by: Anup Patel <anup@brainfault.org>
> ---
>  .../riscv/configs/nommu_k210_sdcard_defconfig | 92 +++++++++++++++++++
>  1 file changed, 92 insertions(+)
>  create mode 100644 arch/riscv/configs/nommu_k210_sdcard_defconfig
>
> diff --git a/arch/riscv/configs/nommu_k210_sdcard_defconfig b/arch/riscv/configs/nommu_k210_sdcard_defconfig
> new file mode 100644
> index 000000000000..61f887f65419
> --- /dev/null
> +++ b/arch/riscv/configs/nommu_k210_sdcard_defconfig
> @@ -0,0 +1,92 @@
> +# CONFIG_CPU_ISOLATION is not set
> +CONFIG_LOG_BUF_SHIFT=13
> +CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=12
> +CONFIG_CC_OPTIMIZE_FOR_SIZE=y
> +# CONFIG_SYSFS_SYSCALL is not set
> +# CONFIG_FHANDLE is not set
> +# CONFIG_BASE_FULL is not set
> +# CONFIG_FUTEX is not set
> +# CONFIG_EPOLL is not set
> +# CONFIG_SIGNALFD is not set
> +# CONFIG_TIMERFD is not set
> +# CONFIG_EVENTFD is not set
> +# CONFIG_AIO is not set
> +# CONFIG_IO_URING is not set
> +# CONFIG_ADVISE_SYSCALLS is not set
> +# CONFIG_MEMBARRIER is not set
> +# CONFIG_KALLSYMS is not set
> +CONFIG_EMBEDDED=y
> +# CONFIG_VM_EVENT_COUNTERS is not set
> +# CONFIG_COMPAT_BRK is not set
> +CONFIG_SLOB=y
> +# CONFIG_MMU is not set
> +CONFIG_SOC_CANAAN=y
> +CONFIG_SOC_CANAAN_K210_DTB_SOURCE="k210_generic"
> +CONFIG_MAXPHYSMEM_2GB=y
> +CONFIG_SMP=y
> +CONFIG_NR_CPUS=2
> +CONFIG_CMDLINE="earlycon console=ttySIF0 rootdelay=2 root=/dev/mmcblk0p1 ro"
> +CONFIG_CMDLINE_FORCE=y
> +# CONFIG_SECCOMP is not set
> +# CONFIG_STACKPROTECTOR is not set
> +# CONFIG_GCC_PLUGINS is not set
> +# CONFIG_BLK_DEV_BSG is not set
> +# CONFIG_MQ_IOSCHED_DEADLINE is not set
> +# CONFIG_MQ_IOSCHED_KYBER is not set
> +CONFIG_BINFMT_FLAT=y
> +# CONFIG_COREDUMP is not set
> +CONFIG_DEVTMPFS=y
> +CONFIG_DEVTMPFS_MOUNT=y
> +# CONFIG_FW_LOADER is not set
> +# CONFIG_ALLOW_DEV_COREDUMP is not set
> +# CONFIG_BLK_DEV is not set
> +# CONFIG_INPUT is not set
> +# CONFIG_SERIO is not set
> +# CONFIG_VT is not set
> +# CONFIG_LEGACY_PTYS is not set
> +# CONFIG_LDISC_AUTOLOAD is not set
> +# CONFIG_HW_RANDOM is not set
> +# CONFIG_DEVMEM is not set
> +CONFIG_I2C=y
> +CONFIG_I2C_CHARDEV=y
> +# CONFIG_I2C_HELPER_AUTO is not set
> +CONFIG_I2C_DESIGNWARE_PLATFORM=y
> +CONFIG_SPI=y
> +# CONFIG_SPI_MEM is not set
> +CONFIG_SPI_DESIGNWARE=y
> +CONFIG_SPI_DW_MMIO=y
> +# CONFIG_GPIO_CDEV_V1 is not set
> +CONFIG_GPIO_DWAPB=y
> +CONFIG_GPIO_SIFIVE=y
> +CONFIG_POWER_RESET=y
> +CONFIG_POWER_RESET_SYSCON=y
> +# CONFIG_HWMON is not set
> +# CONFIG_USB_SUPPORT is not set
> +CONFIG_MMC=y
> +# CONFIG_PWRSEQ_EMMC is not set
> +# CONFIG_PWRSEQ_SIMPLE is not set
> +CONFIG_MMC_SPI=y
> +CONFIG_NEW_LEDS=y
> +CONFIG_LEDS_CLASS=y
> +CONFIG_LEDS_GPIO=y
> +CONFIG_LEDS_USER=y
> +# CONFIG_VIRTIO_MENU is not set
> +# CONFIG_VHOST_MENU is not set
> +# CONFIG_SURFACE_PLATFORMS is not set
> +CONFIG_EXT2_FS=y
> +# CONFIG_FILE_LOCKING is not set
> +# CONFIG_DNOTIFY is not set
> +# CONFIG_INOTIFY_USER is not set
> +# CONFIG_MISC_FILESYSTEMS is not set
> +CONFIG_LSM="[]"
> +CONFIG_PRINTK_TIME=y
> +# CONFIG_SYMBOLIC_ERRNAME is not set
> +# CONFIG_DEBUG_BUGVERBOSE is not set
> +# CONFIG_SECTION_MISMATCH_WARN_ONLY is not set
> +# CONFIG_FRAME_POINTER is not set
> +# CONFIG_DEBUG_MISC is not set
> +CONFIG_PANIC_ON_OOPS=y
> +# CONFIG_SCHED_DEBUG is not set
> +# CONFIG_RCU_TRACE is not set
> +# CONFIG_FTRACE is not set
> +# CONFIG_RUNTIME_TESTING_MENU is not set
> --
> 2.29.2
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv


Reviewed-by: Atish Patra <atish.patra@wdc.com>

--
Regards,
Atish

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 15/16] riscv: Update Canaan Kendryte K210 defconfig
  2021-02-02 10:36 ` [PATCH v14 15/16] riscv: Update Canaan Kendryte K210 defconfig Damien Le Moal
@ 2021-02-02 18:49   ` Atish Patra
  0 siblings, 0 replies; 81+ messages in thread
From: Atish Patra @ 2021-02-02 18:49 UTC (permalink / raw)
  To: Damien Le Moal
  Cc: Atish Patra, linux-riscv, Anup Patel, Palmer Dabbelt, Sean Anderson

On Tue, Feb 2, 2021 at 2:37 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
>
> Update the Kendryte k210 nommu default configuration file
> (nommu_k210_defconfig) to include device drivers for reset, reboot,
> I2C, SPI, gpio and LEDs support. Virtual Terminal support is also
> disabled as no terminal devices are supported and enabled. Disabling
> CONFIG_VT (removing the no longer needed override for
> CONFIG_VGA_CONSOLE) reduces the kernel image size by about 65 KB.
>
> This default configuration remains suitable for a system using an
> initramfs cpio file linked into the kernel image.
>
> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> Reviewed-by: Anup Patel <anup@brainfault.org>
> ---
>  arch/riscv/configs/nommu_k210_defconfig | 44 ++++++++++++++++++++-----
>  1 file changed, 36 insertions(+), 8 deletions(-)
>
> diff --git a/arch/riscv/configs/nommu_k210_defconfig b/arch/riscv/configs/nommu_k210_defconfig
> index 368a28cf1467..b16a2a12c82a 100644
> --- a/arch/riscv/configs/nommu_k210_defconfig
> +++ b/arch/riscv/configs/nommu_k210_defconfig
> @@ -1,17 +1,19 @@
>  # CONFIG_CPU_ISOLATION is not set
> -CONFIG_LOG_BUF_SHIFT=15
> +CONFIG_LOG_BUF_SHIFT=13
>  CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=12
>  CONFIG_BLK_DEV_INITRD=y
> -CONFIG_INITRAMFS_FORCE=y
> +# CONFIG_RD_GZIP is not set
>  # CONFIG_RD_BZIP2 is not set
>  # CONFIG_RD_LZMA is not set
>  # CONFIG_RD_XZ is not set
>  # CONFIG_RD_LZO is not set
>  # CONFIG_RD_LZ4 is not set
> +# CONFIG_RD_ZSTD is not set
>  CONFIG_CC_OPTIMIZE_FOR_SIZE=y
>  # CONFIG_SYSFS_SYSCALL is not set
>  # CONFIG_FHANDLE is not set
>  # CONFIG_BASE_FULL is not set
> +# CONFIG_FUTEX is not set
>  # CONFIG_EPOLL is not set
>  # CONFIG_SIGNALFD is not set
>  # CONFIG_TIMERFD is not set
> @@ -25,15 +27,17 @@ CONFIG_EMBEDDED=y
>  # CONFIG_VM_EVENT_COUNTERS is not set
>  # CONFIG_COMPAT_BRK is not set
>  CONFIG_SLOB=y
> -# CONFIG_SLAB_MERGE_DEFAULT is not set
>  # CONFIG_MMU is not set
>  CONFIG_SOC_CANAAN=y
> +CONFIG_SOC_CANAAN_K210_DTB_SOURCE="k210_generic"
>  CONFIG_MAXPHYSMEM_2GB=y
>  CONFIG_SMP=y
>  CONFIG_NR_CPUS=2
>  CONFIG_CMDLINE="earlycon console=ttySIF0"
>  CONFIG_CMDLINE_FORCE=y
> -CONFIG_JUMP_LABEL=y
> +# CONFIG_SECCOMP is not set
> +# CONFIG_STACKPROTECTOR is not set
> +# CONFIG_GCC_PLUGINS is not set
>  # CONFIG_BLOCK is not set
>  CONFIG_BINFMT_FLAT=y
>  # CONFIG_COREDUMP is not set
> @@ -41,23 +45,47 @@ CONFIG_DEVTMPFS=y
>  CONFIG_DEVTMPFS_MOUNT=y
>  # CONFIG_FW_LOADER is not set
>  # CONFIG_ALLOW_DEV_COREDUMP is not set
> -# CONFIG_INPUT_KEYBOARD is not set
> -# CONFIG_INPUT_MOUSE is not set
> +# CONFIG_INPUT is not set
>  # CONFIG_SERIO is not set
> +# CONFIG_VT is not set
> +# CONFIG_UNIX98_PTYS is not set
>  # CONFIG_LEGACY_PTYS is not set
>  # CONFIG_LDISC_AUTOLOAD is not set
>  # CONFIG_HW_RANDOM is not set
>  # CONFIG_DEVMEM is not set
> +CONFIG_I2C=y
> +# CONFIG_I2C_COMPAT is not set
> +CONFIG_I2C_CHARDEV=y
> +# CONFIG_I2C_HELPER_AUTO is not set
> +CONFIG_I2C_DESIGNWARE_PLATFORM=y
> +CONFIG_SPI=y
> +# CONFIG_SPI_MEM is not set
> +CONFIG_SPI_DESIGNWARE=y
> +CONFIG_SPI_DW_MMIO=y
> +# CONFIG_GPIO_CDEV_V1 is not set
> +CONFIG_GPIO_DWAPB=y
> +CONFIG_GPIO_SIFIVE=y
> +CONFIG_POWER_RESET=y
> +CONFIG_POWER_RESET_SYSCON=y
>  # CONFIG_HWMON is not set
> -# CONFIG_VGA_CONSOLE is not set
> -# CONFIG_HID is not set
>  # CONFIG_USB_SUPPORT is not set
> +CONFIG_NEW_LEDS=y
> +CONFIG_LEDS_CLASS=y
> +CONFIG_LEDS_GPIO=y
> +CONFIG_LEDS_USER=y
>  # CONFIG_VIRTIO_MENU is not set
> +# CONFIG_VHOST_MENU is not set
> +# CONFIG_SURFACE_PLATFORMS is not set
> +# CONFIG_FILE_LOCKING is not set
>  # CONFIG_DNOTIFY is not set
>  # CONFIG_INOTIFY_USER is not set
>  # CONFIG_MISC_FILESYSTEMS is not set
>  CONFIG_LSM="[]"
>  CONFIG_PRINTK_TIME=y
> +# CONFIG_SYMBOLIC_ERRNAME is not set
> +# CONFIG_DEBUG_BUGVERBOSE is not set
> +# CONFIG_SECTION_MISMATCH_WARN_ONLY is not set
> +# CONFIG_FRAME_POINTER is not set
>  # CONFIG_DEBUG_MISC is not set
>  CONFIG_PANIC_ON_OOPS=y
>  # CONFIG_SCHED_DEBUG is not set
> --
> 2.29.2
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv


Reviewed-by: Atish Patra <atish.patra@wdc.com>

-- 
Regards,
Atish

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 07/16] dt-bindings: fix sifive gpio properties
  2021-02-02 10:36   ` Damien Le Moal
@ 2021-02-02 19:02     ` Rob Herring
  -1 siblings, 0 replies; 81+ messages in thread
From: Rob Herring @ 2021-02-02 19:02 UTC (permalink / raw)
  To: Damien Le Moal
  Cc: Palmer Dabbelt, linux-riscv, Atish Patra, Anup Patel,
	Sean Anderson, Paul Walmsley, devicetree

On Tue, Feb 2, 2021 at 4:36 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
>
> The sifive gpio IP block supports up to 32 GPIOs. Reflect that in the
> interrupts property description and maxItems. Also add the standard
> ngpios property to describe the number of GPIOs available on the
> implementation.
>
> Also add the "canaan,k210-gpiohs" compatible string to indicate the use
> of this gpio controller in the Canaan Kendryte K210 SoC. If this
> compatible string is used, do not define the clocks property as
> required as the K210 SoC does not have a software controllable clock
> for the Sifive gpio IP block.
>
> Cc: Paul Walmsley <paul.walmsley@sifive.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> ---
>  .../devicetree/bindings/gpio/sifive,gpio.yaml | 21 ++++++++++++++++---
>  1 file changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> index ab22056f8b44..2cef18ca737c 100644
> --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> @@ -16,6 +16,7 @@ properties:
>        - enum:
>            - sifive,fu540-c000-gpio
>            - sifive,fu740-c000-gpio
> +          - canaan,k210-gpiohs
>        - const: sifive,gpio0
>
>    reg:
> @@ -23,9 +24,9 @@ properties:
>
>    interrupts:
>      description:
> -      interrupt mapping one per GPIO. Maximum 16 GPIOs.
> +      interrupt mapping one per GPIO. Maximum 32 GPIOs.
>      minItems: 1
> -    maxItems: 16
> +    maxItems: 32
>
>    interrupt-controller: true
>
> @@ -38,6 +39,10 @@ properties:
>    "#gpio-cells":
>      const: 2
>
> +  ngpios:
> +    minimum: 1
> +    maximum: 32

What's the default as obviously drivers already assume something.

Does a driver actually need to know this? For example, does the
register stride change or something?

Please don't add it if the only purpose is error check your DT (IOW,
if it just checks the max cell value in gpios phandles).

Rob

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 07/16] dt-bindings: fix sifive gpio properties
@ 2021-02-02 19:02     ` Rob Herring
  0 siblings, 0 replies; 81+ messages in thread
From: Rob Herring @ 2021-02-02 19:02 UTC (permalink / raw)
  To: Damien Le Moal
  Cc: devicetree, Anup Patel, Sean Anderson, Atish Patra,
	Palmer Dabbelt, Paul Walmsley, linux-riscv

On Tue, Feb 2, 2021 at 4:36 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
>
> The sifive gpio IP block supports up to 32 GPIOs. Reflect that in the
> interrupts property description and maxItems. Also add the standard
> ngpios property to describe the number of GPIOs available on the
> implementation.
>
> Also add the "canaan,k210-gpiohs" compatible string to indicate the use
> of this gpio controller in the Canaan Kendryte K210 SoC. If this
> compatible string is used, do not define the clocks property as
> required as the K210 SoC does not have a software controllable clock
> for the Sifive gpio IP block.
>
> Cc: Paul Walmsley <paul.walmsley@sifive.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> ---
>  .../devicetree/bindings/gpio/sifive,gpio.yaml | 21 ++++++++++++++++---
>  1 file changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> index ab22056f8b44..2cef18ca737c 100644
> --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> @@ -16,6 +16,7 @@ properties:
>        - enum:
>            - sifive,fu540-c000-gpio
>            - sifive,fu740-c000-gpio
> +          - canaan,k210-gpiohs
>        - const: sifive,gpio0
>
>    reg:
> @@ -23,9 +24,9 @@ properties:
>
>    interrupts:
>      description:
> -      interrupt mapping one per GPIO. Maximum 16 GPIOs.
> +      interrupt mapping one per GPIO. Maximum 32 GPIOs.
>      minItems: 1
> -    maxItems: 16
> +    maxItems: 32
>
>    interrupt-controller: true
>
> @@ -38,6 +39,10 @@ properties:
>    "#gpio-cells":
>      const: 2
>
> +  ngpios:
> +    minimum: 1
> +    maximum: 32

What's the default as obviously drivers already assume something.

Does a driver actually need to know this? For example, does the
register stride change or something?

Please don't add it if the only purpose is error check your DT (IOW,
if it just checks the max cell value in gpios phandles).

Rob

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 07/16] dt-bindings: fix sifive gpio properties
  2021-02-02 18:45     ` Atish Patra
@ 2021-02-02 23:54       ` Sean Anderson
  -1 siblings, 0 replies; 81+ messages in thread
From: Sean Anderson @ 2021-02-02 23:54 UTC (permalink / raw)
  To: Atish Patra, Damien Le Moal
  Cc: Palmer Dabbelt, linux-riscv, devicetree, Rob Herring, Anup Patel,
	Atish Patra, Paul Walmsley

On 2/2/21 1:45 PM, Atish Patra wrote:
> On Tue, Feb 2, 2021 at 2:37 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
>>
>> The sifive gpio IP block supports up to 32 GPIOs. Reflect that in the
> 
> The spec here says 16 GPIOs
> https://static.dev.sifive.com/FU540-C000-v1.0.pdf
> 
> Is there a updated spec available ?

This GPIO device is (AFAICT) from [1]. While the version instantiated on
SiFive's cores has 16 GPIOs, the actual number of GPIOs is configurable. In
Canaan's version, there are 32 GPIOs. Unfortunately, I am not aware of any
non-implementation-specific documentation for this device.

--Sean

[1] https://github.com/sifive/sifive-blocks/tree/master/src/main/scala/devices/gpio

> 
>> interrupts property description and maxItems. Also add the standard
>> ngpios property to describe the number of GPIOs available on the
>> implementation.
>>
>> Also add the "canaan,k210-gpiohs" compatible string to indicate the use
>> of this gpio controller in the Canaan Kendryte K210 SoC. If this
>> compatible string is used, do not define the clocks property as
>> required as the K210 SoC does not have a software controllable clock
>> for the Sifive gpio IP block.
>>
>> Cc: Paul Walmsley <paul.walmsley@sifive.com>
>> Cc: Rob Herring <robh@kernel.org>
>> Cc: devicetree@vger.kernel.org
>> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
>> ---
>>   .../devicetree/bindings/gpio/sifive,gpio.yaml | 21 ++++++++++++++++---
>>   1 file changed, 18 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>> index ab22056f8b44..2cef18ca737c 100644
>> --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>> +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>> @@ -16,6 +16,7 @@ properties:
>>         - enum:
>>             - sifive,fu540-c000-gpio
>>             - sifive,fu740-c000-gpio
>> +          - canaan,k210-gpiohs
>>         - const: sifive,gpio0
>>
>>     reg:
>> @@ -23,9 +24,9 @@ properties:
>>
>>     interrupts:
>>       description:
>> -      interrupt mapping one per GPIO. Maximum 16 GPIOs.
>> +      interrupt mapping one per GPIO. Maximum 32 GPIOs.
>>       minItems: 1
>> -    maxItems: 16
>> +    maxItems: 32
>>
>>     interrupt-controller: true
>>
>> @@ -38,6 +39,10 @@ properties:
>>     "#gpio-cells":
>>       const: 2
>>
>> +  ngpios:
>> +    minimum: 1
>> +    maximum: 32
>> +
>>     gpio-controller: true
>>
>>   required:
>> @@ -46,10 +51,20 @@ required:
>>     - interrupts
>>     - interrupt-controller
>>     - "#interrupt-cells"
>> -  - clocks
>>     - "#gpio-cells"
>>     - gpio-controller
>>
>> +if:
>> +  properties:
>> +    compatible:
>> +      contains:
>> +        enum:
>> +          - sifive,fu540-c000-gpio
>> +          - sifive,fu740-c000-gpio
>> +then:
>> +  required:
>> +    - clocks
>> +
>>   additionalProperties: false
>>
>>   examples:
>> --
>> 2.29.2
>>
>>
>> _______________________________________________
>> linux-riscv mailing list
>> linux-riscv@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-riscv
> 
> 
> 


^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 07/16] dt-bindings: fix sifive gpio properties
@ 2021-02-02 23:54       ` Sean Anderson
  0 siblings, 0 replies; 81+ messages in thread
From: Sean Anderson @ 2021-02-02 23:54 UTC (permalink / raw)
  To: Atish Patra, Damien Le Moal
  Cc: devicetree, Rob Herring, Anup Patel, Atish Patra, Palmer Dabbelt,
	Paul Walmsley, linux-riscv

On 2/2/21 1:45 PM, Atish Patra wrote:
> On Tue, Feb 2, 2021 at 2:37 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
>>
>> The sifive gpio IP block supports up to 32 GPIOs. Reflect that in the
> 
> The spec here says 16 GPIOs
> https://static.dev.sifive.com/FU540-C000-v1.0.pdf
> 
> Is there a updated spec available ?

This GPIO device is (AFAICT) from [1]. While the version instantiated on
SiFive's cores has 16 GPIOs, the actual number of GPIOs is configurable. In
Canaan's version, there are 32 GPIOs. Unfortunately, I am not aware of any
non-implementation-specific documentation for this device.

--Sean

[1] https://github.com/sifive/sifive-blocks/tree/master/src/main/scala/devices/gpio

> 
>> interrupts property description and maxItems. Also add the standard
>> ngpios property to describe the number of GPIOs available on the
>> implementation.
>>
>> Also add the "canaan,k210-gpiohs" compatible string to indicate the use
>> of this gpio controller in the Canaan Kendryte K210 SoC. If this
>> compatible string is used, do not define the clocks property as
>> required as the K210 SoC does not have a software controllable clock
>> for the Sifive gpio IP block.
>>
>> Cc: Paul Walmsley <paul.walmsley@sifive.com>
>> Cc: Rob Herring <robh@kernel.org>
>> Cc: devicetree@vger.kernel.org
>> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
>> ---
>>   .../devicetree/bindings/gpio/sifive,gpio.yaml | 21 ++++++++++++++++---
>>   1 file changed, 18 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>> index ab22056f8b44..2cef18ca737c 100644
>> --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>> +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>> @@ -16,6 +16,7 @@ properties:
>>         - enum:
>>             - sifive,fu540-c000-gpio
>>             - sifive,fu740-c000-gpio
>> +          - canaan,k210-gpiohs
>>         - const: sifive,gpio0
>>
>>     reg:
>> @@ -23,9 +24,9 @@ properties:
>>
>>     interrupts:
>>       description:
>> -      interrupt mapping one per GPIO. Maximum 16 GPIOs.
>> +      interrupt mapping one per GPIO. Maximum 32 GPIOs.
>>       minItems: 1
>> -    maxItems: 16
>> +    maxItems: 32
>>
>>     interrupt-controller: true
>>
>> @@ -38,6 +39,10 @@ properties:
>>     "#gpio-cells":
>>       const: 2
>>
>> +  ngpios:
>> +    minimum: 1
>> +    maximum: 32
>> +
>>     gpio-controller: true
>>
>>   required:
>> @@ -46,10 +51,20 @@ required:
>>     - interrupts
>>     - interrupt-controller
>>     - "#interrupt-cells"
>> -  - clocks
>>     - "#gpio-cells"
>>     - gpio-controller
>>
>> +if:
>> +  properties:
>> +    compatible:
>> +      contains:
>> +        enum:
>> +          - sifive,fu540-c000-gpio
>> +          - sifive,fu740-c000-gpio
>> +then:
>> +  required:
>> +    - clocks
>> +
>>   additionalProperties: false
>>
>>   examples:
>> --
>> 2.29.2
>>
>>
>> _______________________________________________
>> linux-riscv mailing list
>> linux-riscv@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-riscv
> 
> 
> 


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 07/16] dt-bindings: fix sifive gpio properties
  2021-02-02 19:02     ` Rob Herring
@ 2021-02-03  0:01       ` Sean Anderson
  -1 siblings, 0 replies; 81+ messages in thread
From: Sean Anderson @ 2021-02-03  0:01 UTC (permalink / raw)
  To: Rob Herring, Damien Le Moal
  Cc: Palmer Dabbelt, linux-riscv, Atish Patra, Anup Patel,
	Paul Walmsley, devicetree

On 2/2/21 2:02 PM, Rob Herring wrote:
> On Tue, Feb 2, 2021 at 4:36 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
>>
>> The sifive gpio IP block supports up to 32 GPIOs. Reflect that in the
>> interrupts property description and maxItems. Also add the standard
>> ngpios property to describe the number of GPIOs available on the
>> implementation.
>>
>> Also add the "canaan,k210-gpiohs" compatible string to indicate the use
>> of this gpio controller in the Canaan Kendryte K210 SoC. If this
>> compatible string is used, do not define the clocks property as
>> required as the K210 SoC does not have a software controllable clock
>> for the Sifive gpio IP block.
>>
>> Cc: Paul Walmsley <paul.walmsley@sifive.com>
>> Cc: Rob Herring <robh@kernel.org>
>> Cc: devicetree@vger.kernel.org
>> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
>> ---
>>   .../devicetree/bindings/gpio/sifive,gpio.yaml | 21 ++++++++++++++++---
>>   1 file changed, 18 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>> index ab22056f8b44..2cef18ca737c 100644
>> --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>> +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>> @@ -16,6 +16,7 @@ properties:
>>         - enum:
>>             - sifive,fu540-c000-gpio
>>             - sifive,fu740-c000-gpio
>> +          - canaan,k210-gpiohs
>>         - const: sifive,gpio0
>>
>>     reg:
>> @@ -23,9 +24,9 @@ properties:
>>
>>     interrupts:
>>       description:
>> -      interrupt mapping one per GPIO. Maximum 16 GPIOs.
>> +      interrupt mapping one per GPIO. Maximum 32 GPIOs.
>>       minItems: 1
>> -    maxItems: 16
>> +    maxItems: 32
>>
>>     interrupt-controller: true
>>
>> @@ -38,6 +39,10 @@ properties:
>>     "#gpio-cells":
>>       const: 2
>>
>> +  ngpios:
>> +    minimum: 1
>> +    maximum: 32
> 
> What's the default as obviously drivers already assume something.

The driver currently assumes 16. However, as noted in reply to Atish,
the number of GPIOs is configurable.

> Does a driver actually need to know this? For example, does the
> register stride change or something?

No. I believe that the number of GPIOs sets which bits in the control
registers are valid. So the maximum number of GPIOs is the word width of
the bus.

> Please don't add it if the only purpose is error check your DT (IOW,
> if it just checks the max cell value in gpios phandles).

Why not? This seems like exactly the situation this property was
designed for.

> Optionally, a GPIO controller may have a "ngpios" property. This property
> indicates the number of in-use slots of available slots for GPIOs. The
> typical example is something like this: the hardware register is 32 bits
> wide, but only 18 of the bits have a physical counterpart. The driver is
> generally written so that all 32 bits can be used, but the IP block is reused
> in a lot of designs, some using all 32 bits, some using 18 and some using
> 12. In this case, setting "ngpios = <18>;" informs the driver that only the
> first 18 GPIOs, at local offset 0 .. 17, are in use.

--Sean

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 07/16] dt-bindings: fix sifive gpio properties
@ 2021-02-03  0:01       ` Sean Anderson
  0 siblings, 0 replies; 81+ messages in thread
From: Sean Anderson @ 2021-02-03  0:01 UTC (permalink / raw)
  To: Rob Herring, Damien Le Moal
  Cc: devicetree, Anup Patel, Atish Patra, Palmer Dabbelt,
	Paul Walmsley, linux-riscv

On 2/2/21 2:02 PM, Rob Herring wrote:
> On Tue, Feb 2, 2021 at 4:36 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
>>
>> The sifive gpio IP block supports up to 32 GPIOs. Reflect that in the
>> interrupts property description and maxItems. Also add the standard
>> ngpios property to describe the number of GPIOs available on the
>> implementation.
>>
>> Also add the "canaan,k210-gpiohs" compatible string to indicate the use
>> of this gpio controller in the Canaan Kendryte K210 SoC. If this
>> compatible string is used, do not define the clocks property as
>> required as the K210 SoC does not have a software controllable clock
>> for the Sifive gpio IP block.
>>
>> Cc: Paul Walmsley <paul.walmsley@sifive.com>
>> Cc: Rob Herring <robh@kernel.org>
>> Cc: devicetree@vger.kernel.org
>> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
>> ---
>>   .../devicetree/bindings/gpio/sifive,gpio.yaml | 21 ++++++++++++++++---
>>   1 file changed, 18 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>> index ab22056f8b44..2cef18ca737c 100644
>> --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>> +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>> @@ -16,6 +16,7 @@ properties:
>>         - enum:
>>             - sifive,fu540-c000-gpio
>>             - sifive,fu740-c000-gpio
>> +          - canaan,k210-gpiohs
>>         - const: sifive,gpio0
>>
>>     reg:
>> @@ -23,9 +24,9 @@ properties:
>>
>>     interrupts:
>>       description:
>> -      interrupt mapping one per GPIO. Maximum 16 GPIOs.
>> +      interrupt mapping one per GPIO. Maximum 32 GPIOs.
>>       minItems: 1
>> -    maxItems: 16
>> +    maxItems: 32
>>
>>     interrupt-controller: true
>>
>> @@ -38,6 +39,10 @@ properties:
>>     "#gpio-cells":
>>       const: 2
>>
>> +  ngpios:
>> +    minimum: 1
>> +    maximum: 32
> 
> What's the default as obviously drivers already assume something.

The driver currently assumes 16. However, as noted in reply to Atish,
the number of GPIOs is configurable.

> Does a driver actually need to know this? For example, does the
> register stride change or something?

No. I believe that the number of GPIOs sets which bits in the control
registers are valid. So the maximum number of GPIOs is the word width of
the bus.

> Please don't add it if the only purpose is error check your DT (IOW,
> if it just checks the max cell value in gpios phandles).

Why not? This seems like exactly the situation this property was
designed for.

> Optionally, a GPIO controller may have a "ngpios" property. This property
> indicates the number of in-use slots of available slots for GPIOs. The
> typical example is something like this: the hardware register is 32 bits
> wide, but only 18 of the bits have a physical counterpart. The driver is
> generally written so that all 32 bits can be used, but the IP block is reused
> in a lot of designs, some using all 32 bits, some using 18 and some using
> 12. In this case, setting "ngpios = <18>;" informs the driver that only the
> first 18 GPIOs, at local offset 0 .. 17, are in use.

--Sean

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 04/16] dt-bindings: update sifive plic compatible string
  2021-02-02 18:26     ` Atish Patra
@ 2021-02-03 12:38       ` Damien Le Moal
  -1 siblings, 0 replies; 81+ messages in thread
From: Damien Le Moal @ 2021-02-03 12:38 UTC (permalink / raw)
  To: atishp
  Cc: linux-riscv, Atish Patra, Anup Patel, devicetree, robh, palmer,
	paul.walmsley, seanga2

On Tue, 2021-02-02 at 10:26 -0800, Atish Patra wrote:
> On Tue, Feb 2, 2021 at 2:37 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
> > 
> > Add the compatible string "canaan,k210-plic" to the Sifive plic bindings
> > to indicate the use of the "sifive,plic-1.0.0" IP block in the Canaan
> > Kendryte K210 SoC. The description is also updated to reflect this
> > change, that is, that SoCs from other vendors may also use this plic
> > implementation.
> > 
> > Cc: Paul Walmsley <paul.walmsley@sifive.com>
> > Cc: Rob Herring <robh@kernel.org>
> > Cc: devicetree@vger.kernel.org
> > Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> > ---
> >  .../sifive,plic-1.0.0.yaml                    | 20 ++++++++++++-------
> >  1 file changed, 13 insertions(+), 7 deletions(-)
> > 
> > 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 b9a61c9f7530..3db86d329e1e 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
> > @@ -8,10 +8,11 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
> >  title: SiFive Platform-Level Interrupt Controller (PLIC)
> > 
> >  description:
> > -  SiFive SOCs include an implementation of the Platform-Level Interrupt Controller
> > -  (PLIC) high-level specification in the RISC-V Privileged Architecture
> > -  specification. The PLIC connects all external interrupts in the system to all
> > -  hart contexts in the system, via the external interrupt source in each hart.
> > +  SiFive other RISC-V and other SoCs include an implementation of the
> > +  Platform-Level Interrupt Controller (PLIC) high-level specification in
> > +  the RISC-V Privileged Architecture specification. The PLIC connects all
> 
> The latest privilege spec doesn't specify PLIC anymore.

I kept the text as it was, only adding the reference to the K210. A separate
patch should fix this. I will fix the typo at the beginning of the sentence
though (just noticed it now).

> 
> > +  external interrupts in the system to all hart contexts in the system, via
> > +  the external interrupt source in each hart.
> > 
> >    A hart context is a privilege mode in a hardware execution thread. For example,
> >    in an 4 core system with 2-way SMT, you have 8 harts and probably at least two
> > @@ -41,9 +42,14 @@ maintainers:
> > 
> >  properties:
> >    compatible:
> > -    items:
> > -      - const: sifive,fu540-c000-plic
> > -      - const: sifive,plic-1.0.0
> > +    oneOf:
> > +      - items:
> > +          - const: sifive,fu540-c000-plic
> > +          - const: sifive,plic-1.0.0
> > +
> > +      - items:
> > +          - const: canaan,k210-plic
> > +          - const: sifive,plic-1.0.0
> > 
> >    reg:
> >      maxItems: 1
> > --
> > 2.29.2
> > 
> > 
> > _______________________________________________
> > linux-riscv mailing list
> > linux-riscv@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-riscv
> 
> other than that,
> 
> Reviewed-by: Atish Patra <atish.patra@wdc.com>
> 

-- 
Damien Le Moal
Western Digital Research


^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 04/16] dt-bindings: update sifive plic compatible string
@ 2021-02-03 12:38       ` Damien Le Moal
  0 siblings, 0 replies; 81+ messages in thread
From: Damien Le Moal @ 2021-02-03 12:38 UTC (permalink / raw)
  To: atishp
  Cc: robh, devicetree, Anup Patel, seanga2, Atish Patra, palmer,
	paul.walmsley, linux-riscv

On Tue, 2021-02-02 at 10:26 -0800, Atish Patra wrote:
> On Tue, Feb 2, 2021 at 2:37 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
> > 
> > Add the compatible string "canaan,k210-plic" to the Sifive plic bindings
> > to indicate the use of the "sifive,plic-1.0.0" IP block in the Canaan
> > Kendryte K210 SoC. The description is also updated to reflect this
> > change, that is, that SoCs from other vendors may also use this plic
> > implementation.
> > 
> > Cc: Paul Walmsley <paul.walmsley@sifive.com>
> > Cc: Rob Herring <robh@kernel.org>
> > Cc: devicetree@vger.kernel.org
> > Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> > ---
> >  .../sifive,plic-1.0.0.yaml                    | 20 ++++++++++++-------
> >  1 file changed, 13 insertions(+), 7 deletions(-)
> > 
> > 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 b9a61c9f7530..3db86d329e1e 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
> > @@ -8,10 +8,11 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
> >  title: SiFive Platform-Level Interrupt Controller (PLIC)
> > 
> >  description:
> > -  SiFive SOCs include an implementation of the Platform-Level Interrupt Controller
> > -  (PLIC) high-level specification in the RISC-V Privileged Architecture
> > -  specification. The PLIC connects all external interrupts in the system to all
> > -  hart contexts in the system, via the external interrupt source in each hart.
> > +  SiFive other RISC-V and other SoCs include an implementation of the
> > +  Platform-Level Interrupt Controller (PLIC) high-level specification in
> > +  the RISC-V Privileged Architecture specification. The PLIC connects all
> 
> The latest privilege spec doesn't specify PLIC anymore.

I kept the text as it was, only adding the reference to the K210. A separate
patch should fix this. I will fix the typo at the beginning of the sentence
though (just noticed it now).

> 
> > +  external interrupts in the system to all hart contexts in the system, via
> > +  the external interrupt source in each hart.
> > 
> >    A hart context is a privilege mode in a hardware execution thread. For example,
> >    in an 4 core system with 2-way SMT, you have 8 harts and probably at least two
> > @@ -41,9 +42,14 @@ maintainers:
> > 
> >  properties:
> >    compatible:
> > -    items:
> > -      - const: sifive,fu540-c000-plic
> > -      - const: sifive,plic-1.0.0
> > +    oneOf:
> > +      - items:
> > +          - const: sifive,fu540-c000-plic
> > +          - const: sifive,plic-1.0.0
> > +
> > +      - items:
> > +          - const: canaan,k210-plic
> > +          - const: sifive,plic-1.0.0
> > 
> >    reg:
> >      maxItems: 1
> > --
> > 2.29.2
> > 
> > 
> > _______________________________________________
> > linux-riscv mailing list
> > linux-riscv@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-riscv
> 
> other than that,
> 
> Reviewed-by: Atish Patra <atish.patra@wdc.com>
> 

-- 
Damien Le Moal
Western Digital Research

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 07/16] dt-bindings: fix sifive gpio properties
  2021-02-02 19:02     ` Rob Herring
@ 2021-02-03 12:52       ` Damien Le Moal
  -1 siblings, 0 replies; 81+ messages in thread
From: Damien Le Moal @ 2021-02-03 12:52 UTC (permalink / raw)
  To: robh
  Cc: paul.walmsley, palmer, linux-riscv, Atish Patra, seanga2,
	Anup Patel, devicetree

On Tue, 2021-02-02 at 13:02 -0600, Rob Herring wrote:
> On Tue, Feb 2, 2021 at 4:36 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
> > 
> > The sifive gpio IP block supports up to 32 GPIOs. Reflect that in the
> > interrupts property description and maxItems. Also add the standard
> > ngpios property to describe the number of GPIOs available on the
> > implementation.
> > 
> > Also add the "canaan,k210-gpiohs" compatible string to indicate the use
> > of this gpio controller in the Canaan Kendryte K210 SoC. If this
> > compatible string is used, do not define the clocks property as
> > required as the K210 SoC does not have a software controllable clock
> > for the Sifive gpio IP block.
> > 
> > Cc: Paul Walmsley <paul.walmsley@sifive.com>
> > Cc: Rob Herring <robh@kernel.org>
> > Cc: devicetree@vger.kernel.org
> > Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> > ---
> >  .../devicetree/bindings/gpio/sifive,gpio.yaml | 21 ++++++++++++++++---
> >  1 file changed, 18 insertions(+), 3 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > index ab22056f8b44..2cef18ca737c 100644
> > --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > @@ -16,6 +16,7 @@ properties:
> >        - enum:
> >            - sifive,fu540-c000-gpio
> >            - sifive,fu740-c000-gpio
> > +          - canaan,k210-gpiohs
> >        - const: sifive,gpio0
> > 
> >    reg:
> > @@ -23,9 +24,9 @@ properties:
> > 
> >    interrupts:
> >      description:
> > -      interrupt mapping one per GPIO. Maximum 16 GPIOs.
> > +      interrupt mapping one per GPIO. Maximum 32 GPIOs.
> >      minItems: 1
> > -    maxItems: 16
> > +    maxItems: 32
> > 
> >    interrupt-controller: true
> > 
> > @@ -38,6 +39,10 @@ properties:
> >    "#gpio-cells":
> >      const: 2
> > 
> > +  ngpios:
> > +    minimum: 1
> > +    maximum: 32
> 
> What's the default as obviously drivers already assume something.
> 
> Does a driver actually need to know this? For example, does the
> register stride change or something?
> 
> Please don't add it if the only purpose is error check your DT (IOW,
> if it just checks the max cell value in gpios phandles).

If I remove that, make dtbs_check complains. Looking at othe gpio controller
bindings, they all have it. So isn't it better to be consistent, and avoid make
dtbs_check errors ?


> 
> Rob

-- 
Damien Le Moal
Western Digital Research


^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 07/16] dt-bindings: fix sifive gpio properties
@ 2021-02-03 12:52       ` Damien Le Moal
  0 siblings, 0 replies; 81+ messages in thread
From: Damien Le Moal @ 2021-02-03 12:52 UTC (permalink / raw)
  To: robh
  Cc: devicetree, Anup Patel, seanga2, Atish Patra, palmer,
	paul.walmsley, linux-riscv

On Tue, 2021-02-02 at 13:02 -0600, Rob Herring wrote:
> On Tue, Feb 2, 2021 at 4:36 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
> > 
> > The sifive gpio IP block supports up to 32 GPIOs. Reflect that in the
> > interrupts property description and maxItems. Also add the standard
> > ngpios property to describe the number of GPIOs available on the
> > implementation.
> > 
> > Also add the "canaan,k210-gpiohs" compatible string to indicate the use
> > of this gpio controller in the Canaan Kendryte K210 SoC. If this
> > compatible string is used, do not define the clocks property as
> > required as the K210 SoC does not have a software controllable clock
> > for the Sifive gpio IP block.
> > 
> > Cc: Paul Walmsley <paul.walmsley@sifive.com>
> > Cc: Rob Herring <robh@kernel.org>
> > Cc: devicetree@vger.kernel.org
> > Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> > ---
> >  .../devicetree/bindings/gpio/sifive,gpio.yaml | 21 ++++++++++++++++---
> >  1 file changed, 18 insertions(+), 3 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > index ab22056f8b44..2cef18ca737c 100644
> > --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > @@ -16,6 +16,7 @@ properties:
> >        - enum:
> >            - sifive,fu540-c000-gpio
> >            - sifive,fu740-c000-gpio
> > +          - canaan,k210-gpiohs
> >        - const: sifive,gpio0
> > 
> >    reg:
> > @@ -23,9 +24,9 @@ properties:
> > 
> >    interrupts:
> >      description:
> > -      interrupt mapping one per GPIO. Maximum 16 GPIOs.
> > +      interrupt mapping one per GPIO. Maximum 32 GPIOs.
> >      minItems: 1
> > -    maxItems: 16
> > +    maxItems: 32
> > 
> >    interrupt-controller: true
> > 
> > @@ -38,6 +39,10 @@ properties:
> >    "#gpio-cells":
> >      const: 2
> > 
> > +  ngpios:
> > +    minimum: 1
> > +    maximum: 32
> 
> What's the default as obviously drivers already assume something.
> 
> Does a driver actually need to know this? For example, does the
> register stride change or something?
> 
> Please don't add it if the only purpose is error check your DT (IOW,
> if it just checks the max cell value in gpios phandles).

If I remove that, make dtbs_check complains. Looking at othe gpio controller
bindings, they all have it. So isn't it better to be consistent, and avoid make
dtbs_check errors ?


> 
> Rob

-- 
Damien Le Moal
Western Digital Research

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 07/16] dt-bindings: fix sifive gpio properties
  2021-02-03  0:01       ` Sean Anderson
@ 2021-02-03 20:23         ` Rob Herring
  -1 siblings, 0 replies; 81+ messages in thread
From: Rob Herring @ 2021-02-03 20:23 UTC (permalink / raw)
  To: Sean Anderson
  Cc: Damien Le Moal, Palmer Dabbelt, linux-riscv, Atish Patra,
	Anup Patel, Paul Walmsley, devicetree

On Tue, Feb 2, 2021 at 6:01 PM Sean Anderson <seanga2@gmail.com> wrote:
>
> On 2/2/21 2:02 PM, Rob Herring wrote:
> > On Tue, Feb 2, 2021 at 4:36 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
> >>
> >> The sifive gpio IP block supports up to 32 GPIOs. Reflect that in the
> >> interrupts property description and maxItems. Also add the standard
> >> ngpios property to describe the number of GPIOs available on the
> >> implementation.
> >>
> >> Also add the "canaan,k210-gpiohs" compatible string to indicate the use
> >> of this gpio controller in the Canaan Kendryte K210 SoC. If this
> >> compatible string is used, do not define the clocks property as
> >> required as the K210 SoC does not have a software controllable clock
> >> for the Sifive gpio IP block.
> >>
> >> Cc: Paul Walmsley <paul.walmsley@sifive.com>
> >> Cc: Rob Herring <robh@kernel.org>
> >> Cc: devicetree@vger.kernel.org
> >> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> >> ---
> >>   .../devicetree/bindings/gpio/sifive,gpio.yaml | 21 ++++++++++++++++---
> >>   1 file changed, 18 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> >> index ab22056f8b44..2cef18ca737c 100644
> >> --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> >> +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> >> @@ -16,6 +16,7 @@ properties:
> >>         - enum:
> >>             - sifive,fu540-c000-gpio
> >>             - sifive,fu740-c000-gpio
> >> +          - canaan,k210-gpiohs
> >>         - const: sifive,gpio0
> >>
> >>     reg:
> >> @@ -23,9 +24,9 @@ properties:
> >>
> >>     interrupts:
> >>       description:
> >> -      interrupt mapping one per GPIO. Maximum 16 GPIOs.
> >> +      interrupt mapping one per GPIO. Maximum 32 GPIOs.
> >>       minItems: 1
> >> -    maxItems: 16
> >> +    maxItems: 32
> >>
> >>     interrupt-controller: true
> >>
> >> @@ -38,6 +39,10 @@ properties:
> >>     "#gpio-cells":
> >>       const: 2
> >>
> >> +  ngpios:
> >> +    minimum: 1
> >> +    maximum: 32
> >
> > What's the default as obviously drivers already assume something.
>
> The driver currently assumes 16. However, as noted in reply to Atish,
> the number of GPIOs is configurable.

So you need a 'default: 16' here.

> > Does a driver actually need to know this? For example, does the
> > register stride change or something?
>
> No. I believe that the number of GPIOs sets which bits in the control
> registers are valid. So the maximum number of GPIOs is the word width of
> the bus.

So like register access size (e.g. readw vs readl)? If so, we have
'reg-io-width' for that purpose.

> > Please don't add it if the only purpose is error check your DT (IOW,
> > if it just checks the max cell value in gpios phandles).
>
> Why not? This seems like exactly the situation this property was
> designed for.

Because it is redundant. All the GPIO lines you want to use should be
connected to something with a *-gpios property. If not, then that's a
failure to describe part of the h/w.

For comparison, we generally don't define how many interrupts an
interrupt controller has. Or how many power-domains a power domain
provider has. I can go on with every provider/consumer binding...

Rob

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 07/16] dt-bindings: fix sifive gpio properties
@ 2021-02-03 20:23         ` Rob Herring
  0 siblings, 0 replies; 81+ messages in thread
From: Rob Herring @ 2021-02-03 20:23 UTC (permalink / raw)
  To: Sean Anderson
  Cc: devicetree, Damien Le Moal, Anup Patel, Atish Patra,
	Palmer Dabbelt, Paul Walmsley, linux-riscv

On Tue, Feb 2, 2021 at 6:01 PM Sean Anderson <seanga2@gmail.com> wrote:
>
> On 2/2/21 2:02 PM, Rob Herring wrote:
> > On Tue, Feb 2, 2021 at 4:36 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
> >>
> >> The sifive gpio IP block supports up to 32 GPIOs. Reflect that in the
> >> interrupts property description and maxItems. Also add the standard
> >> ngpios property to describe the number of GPIOs available on the
> >> implementation.
> >>
> >> Also add the "canaan,k210-gpiohs" compatible string to indicate the use
> >> of this gpio controller in the Canaan Kendryte K210 SoC. If this
> >> compatible string is used, do not define the clocks property as
> >> required as the K210 SoC does not have a software controllable clock
> >> for the Sifive gpio IP block.
> >>
> >> Cc: Paul Walmsley <paul.walmsley@sifive.com>
> >> Cc: Rob Herring <robh@kernel.org>
> >> Cc: devicetree@vger.kernel.org
> >> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> >> ---
> >>   .../devicetree/bindings/gpio/sifive,gpio.yaml | 21 ++++++++++++++++---
> >>   1 file changed, 18 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> >> index ab22056f8b44..2cef18ca737c 100644
> >> --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> >> +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> >> @@ -16,6 +16,7 @@ properties:
> >>         - enum:
> >>             - sifive,fu540-c000-gpio
> >>             - sifive,fu740-c000-gpio
> >> +          - canaan,k210-gpiohs
> >>         - const: sifive,gpio0
> >>
> >>     reg:
> >> @@ -23,9 +24,9 @@ properties:
> >>
> >>     interrupts:
> >>       description:
> >> -      interrupt mapping one per GPIO. Maximum 16 GPIOs.
> >> +      interrupt mapping one per GPIO. Maximum 32 GPIOs.
> >>       minItems: 1
> >> -    maxItems: 16
> >> +    maxItems: 32
> >>
> >>     interrupt-controller: true
> >>
> >> @@ -38,6 +39,10 @@ properties:
> >>     "#gpio-cells":
> >>       const: 2
> >>
> >> +  ngpios:
> >> +    minimum: 1
> >> +    maximum: 32
> >
> > What's the default as obviously drivers already assume something.
>
> The driver currently assumes 16. However, as noted in reply to Atish,
> the number of GPIOs is configurable.

So you need a 'default: 16' here.

> > Does a driver actually need to know this? For example, does the
> > register stride change or something?
>
> No. I believe that the number of GPIOs sets which bits in the control
> registers are valid. So the maximum number of GPIOs is the word width of
> the bus.

So like register access size (e.g. readw vs readl)? If so, we have
'reg-io-width' for that purpose.

> > Please don't add it if the only purpose is error check your DT (IOW,
> > if it just checks the max cell value in gpios phandles).
>
> Why not? This seems like exactly the situation this property was
> designed for.

Because it is redundant. All the GPIO lines you want to use should be
connected to something with a *-gpios property. If not, then that's a
failure to describe part of the h/w.

For comparison, we generally don't define how many interrupts an
interrupt controller has. Or how many power-domains a power domain
provider has. I can go on with every provider/consumer binding...

Rob

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 07/16] dt-bindings: fix sifive gpio properties
  2021-02-03 12:52       ` Damien Le Moal
@ 2021-02-03 20:41         ` Rob Herring
  -1 siblings, 0 replies; 81+ messages in thread
From: Rob Herring @ 2021-02-03 20:41 UTC (permalink / raw)
  To: Damien Le Moal
  Cc: paul.walmsley, palmer, linux-riscv, Atish Patra, seanga2,
	Anup Patel, devicetree

On Wed, Feb 3, 2021 at 6:52 AM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
>
> On Tue, 2021-02-02 at 13:02 -0600, Rob Herring wrote:
> > On Tue, Feb 2, 2021 at 4:36 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
> > >
> > > The sifive gpio IP block supports up to 32 GPIOs. Reflect that in the
> > > interrupts property description and maxItems. Also add the standard
> > > ngpios property to describe the number of GPIOs available on the
> > > implementation.
> > >
> > > Also add the "canaan,k210-gpiohs" compatible string to indicate the use
> > > of this gpio controller in the Canaan Kendryte K210 SoC. If this
> > > compatible string is used, do not define the clocks property as
> > > required as the K210 SoC does not have a software controllable clock
> > > for the Sifive gpio IP block.
> > >
> > > Cc: Paul Walmsley <paul.walmsley@sifive.com>
> > > Cc: Rob Herring <robh@kernel.org>
> > > Cc: devicetree@vger.kernel.org
> > > Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> > > ---
> > >  .../devicetree/bindings/gpio/sifive,gpio.yaml | 21 ++++++++++++++++---
> > >  1 file changed, 18 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > > index ab22056f8b44..2cef18ca737c 100644
> > > --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > > +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > > @@ -16,6 +16,7 @@ properties:
> > >        - enum:
> > >            - sifive,fu540-c000-gpio
> > >            - sifive,fu740-c000-gpio
> > > +          - canaan,k210-gpiohs
> > >        - const: sifive,gpio0
> > >
> > >    reg:
> > > @@ -23,9 +24,9 @@ properties:
> > >
> > >    interrupts:
> > >      description:
> > > -      interrupt mapping one per GPIO. Maximum 16 GPIOs.
> > > +      interrupt mapping one per GPIO. Maximum 32 GPIOs.
> > >      minItems: 1
> > > -    maxItems: 16
> > > +    maxItems: 32
> > >
> > >    interrupt-controller: true
> > >
> > > @@ -38,6 +39,10 @@ properties:
> > >    "#gpio-cells":
> > >      const: 2
> > >
> > > +  ngpios:
> > > +    minimum: 1
> > > +    maximum: 32
> >
> > What's the default as obviously drivers already assume something.
> >
> > Does a driver actually need to know this? For example, does the
> > register stride change or something?
> >
> > Please don't add it if the only purpose is error check your DT (IOW,
> > if it just checks the max cell value in gpios phandles).
>
> If I remove that, make dtbs_check complains. Looking at othe gpio controller
> bindings, they all have it. So isn't it better to be consistent, and avoid make
> dtbs_check errors ?

That would mean you are already using 'ngpios' and it is undocumented
(for this binding). If already in use and possibly having users then
that changes things, but that's not what the commit msg says.

Not *all* gpio controllers have ngpios. It's a good number, but
probably more than need it though. If we wanted it everywhere, there
would be a schema enforcing that.

Rob

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 07/16] dt-bindings: fix sifive gpio properties
@ 2021-02-03 20:41         ` Rob Herring
  0 siblings, 0 replies; 81+ messages in thread
From: Rob Herring @ 2021-02-03 20:41 UTC (permalink / raw)
  To: Damien Le Moal
  Cc: devicetree, Anup Patel, seanga2, Atish Patra, palmer,
	paul.walmsley, linux-riscv

On Wed, Feb 3, 2021 at 6:52 AM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
>
> On Tue, 2021-02-02 at 13:02 -0600, Rob Herring wrote:
> > On Tue, Feb 2, 2021 at 4:36 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
> > >
> > > The sifive gpio IP block supports up to 32 GPIOs. Reflect that in the
> > > interrupts property description and maxItems. Also add the standard
> > > ngpios property to describe the number of GPIOs available on the
> > > implementation.
> > >
> > > Also add the "canaan,k210-gpiohs" compatible string to indicate the use
> > > of this gpio controller in the Canaan Kendryte K210 SoC. If this
> > > compatible string is used, do not define the clocks property as
> > > required as the K210 SoC does not have a software controllable clock
> > > for the Sifive gpio IP block.
> > >
> > > Cc: Paul Walmsley <paul.walmsley@sifive.com>
> > > Cc: Rob Herring <robh@kernel.org>
> > > Cc: devicetree@vger.kernel.org
> > > Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> > > ---
> > >  .../devicetree/bindings/gpio/sifive,gpio.yaml | 21 ++++++++++++++++---
> > >  1 file changed, 18 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > > index ab22056f8b44..2cef18ca737c 100644
> > > --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > > +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > > @@ -16,6 +16,7 @@ properties:
> > >        - enum:
> > >            - sifive,fu540-c000-gpio
> > >            - sifive,fu740-c000-gpio
> > > +          - canaan,k210-gpiohs
> > >        - const: sifive,gpio0
> > >
> > >    reg:
> > > @@ -23,9 +24,9 @@ properties:
> > >
> > >    interrupts:
> > >      description:
> > > -      interrupt mapping one per GPIO. Maximum 16 GPIOs.
> > > +      interrupt mapping one per GPIO. Maximum 32 GPIOs.
> > >      minItems: 1
> > > -    maxItems: 16
> > > +    maxItems: 32
> > >
> > >    interrupt-controller: true
> > >
> > > @@ -38,6 +39,10 @@ properties:
> > >    "#gpio-cells":
> > >      const: 2
> > >
> > > +  ngpios:
> > > +    minimum: 1
> > > +    maximum: 32
> >
> > What's the default as obviously drivers already assume something.
> >
> > Does a driver actually need to know this? For example, does the
> > register stride change or something?
> >
> > Please don't add it if the only purpose is error check your DT (IOW,
> > if it just checks the max cell value in gpios phandles).
>
> If I remove that, make dtbs_check complains. Looking at othe gpio controller
> bindings, they all have it. So isn't it better to be consistent, and avoid make
> dtbs_check errors ?

That would mean you are already using 'ngpios' and it is undocumented
(for this binding). If already in use and possibly having users then
that changes things, but that's not what the commit msg says.

Not *all* gpio controllers have ngpios. It's a good number, but
probably more than need it though. If we wanted it everywhere, there
would be a schema enforcing that.

Rob

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 07/16] dt-bindings: fix sifive gpio properties
  2021-02-03 20:23         ` Rob Herring
@ 2021-02-03 23:13           ` Sean Anderson
  -1 siblings, 0 replies; 81+ messages in thread
From: Sean Anderson @ 2021-02-03 23:13 UTC (permalink / raw)
  To: Rob Herring
  Cc: Damien Le Moal, Palmer Dabbelt, linux-riscv, Atish Patra,
	Anup Patel, Paul Walmsley, devicetree

On 2/3/21 3:23 PM, Rob Herring wrote:
> On Tue, Feb 2, 2021 at 6:01 PM Sean Anderson <seanga2@gmail.com> wrote:
>>
>> On 2/2/21 2:02 PM, Rob Herring wrote:
>>> On Tue, Feb 2, 2021 at 4:36 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
>>>>
>>>> The sifive gpio IP block supports up to 32 GPIOs. Reflect that in the
>>>> interrupts property description and maxItems. Also add the standard
>>>> ngpios property to describe the number of GPIOs available on the
>>>> implementation.
>>>>
>>>> Also add the "canaan,k210-gpiohs" compatible string to indicate the use
>>>> of this gpio controller in the Canaan Kendryte K210 SoC. If this
>>>> compatible string is used, do not define the clocks property as
>>>> required as the K210 SoC does not have a software controllable clock
>>>> for the Sifive gpio IP block.
>>>>
>>>> Cc: Paul Walmsley <paul.walmsley@sifive.com>
>>>> Cc: Rob Herring <robh@kernel.org>
>>>> Cc: devicetree@vger.kernel.org
>>>> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
>>>> ---
>>>>    .../devicetree/bindings/gpio/sifive,gpio.yaml | 21 ++++++++++++++++---
>>>>    1 file changed, 18 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>> index ab22056f8b44..2cef18ca737c 100644
>>>> --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>> +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>> @@ -16,6 +16,7 @@ properties:
>>>>          - enum:
>>>>              - sifive,fu540-c000-gpio
>>>>              - sifive,fu740-c000-gpio
>>>> +          - canaan,k210-gpiohs
>>>>          - const: sifive,gpio0
>>>>
>>>>      reg:
>>>> @@ -23,9 +24,9 @@ properties:
>>>>
>>>>      interrupts:
>>>>        description:
>>>> -      interrupt mapping one per GPIO. Maximum 16 GPIOs.
>>>> +      interrupt mapping one per GPIO. Maximum 32 GPIOs.
>>>>        minItems: 1
>>>> -    maxItems: 16
>>>> +    maxItems: 32
>>>>
>>>>      interrupt-controller: true
>>>>
>>>> @@ -38,6 +39,10 @@ properties:
>>>>      "#gpio-cells":
>>>>        const: 2
>>>>
>>>> +  ngpios:
>>>> +    minimum: 1
>>>> +    maximum: 32
>>>
>>> What's the default as obviously drivers already assume something.
>>
>> The driver currently assumes 16. However, as noted in reply to Atish,
>> the number of GPIOs is configurable.
> 
> So you need a 'default: 16' here.

There is no reasonable default. This device can be configured to have
any number of GPIOs between 1 and 32.

>>> Does a driver actually need to know this? For example, does the
>>> register stride change or something?
>>
>> No. I believe that the number of GPIOs sets which bits in the control
>> registers are valid. So the maximum number of GPIOs is the word width of
>> the bus.
> 
> So like register access size (e.g. readw vs readl)? If so, we have
> 'reg-io-width' for that purpose.

This is just the "maximum configurable" due to how the device's
registers are laid out. If you wanted to have more GPIOs than the
register access size, you would need to make more extensive (and likely
incompatible) modifications to the device. However, I don't believe
there are any devices with 64-bit register width (yet) and the driver
does not support 64-bit accesses.

> 
>>> Please don't add it if the only purpose is error check your DT (IOW,
>>> if it just checks the max cell value in gpios phandles).
>>
>> Why not? This seems like exactly the situation this property was
>> designed for.
> 
> Because it is redundant. All the GPIO lines you want to use should be
> connected to something with a *-gpios property. If not, then that's a
> failure to describe part of the h/w.

This is wrong. On SoCs with pinmuxing (such as this one), not all GPIO
lines may be connected for any particular board.

> For comparison, we generally don't define how many interrupts an
> interrupt controller has. Or how many power-domains a power domain
> provider has. I can go on with every provider/consumer binding...

And yet the in-kernel documentation *specifically* recommends using this
property in this situation. I suggest you submit a patch to remove that
paragraph if you think that it is not necessary.

--Sean

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 07/16] dt-bindings: fix sifive gpio properties
@ 2021-02-03 23:13           ` Sean Anderson
  0 siblings, 0 replies; 81+ messages in thread
From: Sean Anderson @ 2021-02-03 23:13 UTC (permalink / raw)
  To: Rob Herring
  Cc: devicetree, Damien Le Moal, Anup Patel, Atish Patra,
	Palmer Dabbelt, Paul Walmsley, linux-riscv

On 2/3/21 3:23 PM, Rob Herring wrote:
> On Tue, Feb 2, 2021 at 6:01 PM Sean Anderson <seanga2@gmail.com> wrote:
>>
>> On 2/2/21 2:02 PM, Rob Herring wrote:
>>> On Tue, Feb 2, 2021 at 4:36 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
>>>>
>>>> The sifive gpio IP block supports up to 32 GPIOs. Reflect that in the
>>>> interrupts property description and maxItems. Also add the standard
>>>> ngpios property to describe the number of GPIOs available on the
>>>> implementation.
>>>>
>>>> Also add the "canaan,k210-gpiohs" compatible string to indicate the use
>>>> of this gpio controller in the Canaan Kendryte K210 SoC. If this
>>>> compatible string is used, do not define the clocks property as
>>>> required as the K210 SoC does not have a software controllable clock
>>>> for the Sifive gpio IP block.
>>>>
>>>> Cc: Paul Walmsley <paul.walmsley@sifive.com>
>>>> Cc: Rob Herring <robh@kernel.org>
>>>> Cc: devicetree@vger.kernel.org
>>>> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
>>>> ---
>>>>    .../devicetree/bindings/gpio/sifive,gpio.yaml | 21 ++++++++++++++++---
>>>>    1 file changed, 18 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>> index ab22056f8b44..2cef18ca737c 100644
>>>> --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>> +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>> @@ -16,6 +16,7 @@ properties:
>>>>          - enum:
>>>>              - sifive,fu540-c000-gpio
>>>>              - sifive,fu740-c000-gpio
>>>> +          - canaan,k210-gpiohs
>>>>          - const: sifive,gpio0
>>>>
>>>>      reg:
>>>> @@ -23,9 +24,9 @@ properties:
>>>>
>>>>      interrupts:
>>>>        description:
>>>> -      interrupt mapping one per GPIO. Maximum 16 GPIOs.
>>>> +      interrupt mapping one per GPIO. Maximum 32 GPIOs.
>>>>        minItems: 1
>>>> -    maxItems: 16
>>>> +    maxItems: 32
>>>>
>>>>      interrupt-controller: true
>>>>
>>>> @@ -38,6 +39,10 @@ properties:
>>>>      "#gpio-cells":
>>>>        const: 2
>>>>
>>>> +  ngpios:
>>>> +    minimum: 1
>>>> +    maximum: 32
>>>
>>> What's the default as obviously drivers already assume something.
>>
>> The driver currently assumes 16. However, as noted in reply to Atish,
>> the number of GPIOs is configurable.
> 
> So you need a 'default: 16' here.

There is no reasonable default. This device can be configured to have
any number of GPIOs between 1 and 32.

>>> Does a driver actually need to know this? For example, does the
>>> register stride change or something?
>>
>> No. I believe that the number of GPIOs sets which bits in the control
>> registers are valid. So the maximum number of GPIOs is the word width of
>> the bus.
> 
> So like register access size (e.g. readw vs readl)? If so, we have
> 'reg-io-width' for that purpose.

This is just the "maximum configurable" due to how the device's
registers are laid out. If you wanted to have more GPIOs than the
register access size, you would need to make more extensive (and likely
incompatible) modifications to the device. However, I don't believe
there are any devices with 64-bit register width (yet) and the driver
does not support 64-bit accesses.

> 
>>> Please don't add it if the only purpose is error check your DT (IOW,
>>> if it just checks the max cell value in gpios phandles).
>>
>> Why not? This seems like exactly the situation this property was
>> designed for.
> 
> Because it is redundant. All the GPIO lines you want to use should be
> connected to something with a *-gpios property. If not, then that's a
> failure to describe part of the h/w.

This is wrong. On SoCs with pinmuxing (such as this one), not all GPIO
lines may be connected for any particular board.

> For comparison, we generally don't define how many interrupts an
> interrupt controller has. Or how many power-domains a power domain
> provider has. I can go on with every provider/consumer binding...

And yet the in-kernel documentation *specifically* recommends using this
property in this situation. I suggest you submit a patch to remove that
paragraph if you think that it is not necessary.

--Sean

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 07/16] dt-bindings: fix sifive gpio properties
  2021-02-03 20:41         ` Rob Herring
@ 2021-02-04  0:47           ` Damien Le Moal
  -1 siblings, 0 replies; 81+ messages in thread
From: Damien Le Moal @ 2021-02-04  0:47 UTC (permalink / raw)
  To: robh
  Cc: paul.walmsley, palmer, linux-riscv, Atish Patra, seanga2,
	Anup Patel, devicetree

On Wed, 2021-02-03 at 14:41 -0600, Rob Herring wrote:
> On Wed, Feb 3, 2021 at 6:52 AM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
> > 
> > On Tue, 2021-02-02 at 13:02 -0600, Rob Herring wrote:
> > > On Tue, Feb 2, 2021 at 4:36 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
> > > > 
> > > > The sifive gpio IP block supports up to 32 GPIOs. Reflect that in the
> > > > interrupts property description and maxItems. Also add the standard
> > > > ngpios property to describe the number of GPIOs available on the
> > > > implementation.
> > > > 
> > > > Also add the "canaan,k210-gpiohs" compatible string to indicate the use
> > > > of this gpio controller in the Canaan Kendryte K210 SoC. If this
> > > > compatible string is used, do not define the clocks property as
> > > > required as the K210 SoC does not have a software controllable clock
> > > > for the Sifive gpio IP block.
> > > > 
> > > > Cc: Paul Walmsley <paul.walmsley@sifive.com>
> > > > Cc: Rob Herring <robh@kernel.org>
> > > > Cc: devicetree@vger.kernel.org
> > > > Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> > > > ---
> > > >  .../devicetree/bindings/gpio/sifive,gpio.yaml | 21 ++++++++++++++++---
> > > >  1 file changed, 18 insertions(+), 3 deletions(-)
> > > > 
> > > > diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > > > index ab22056f8b44..2cef18ca737c 100644
> > > > --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > > > +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > > > @@ -16,6 +16,7 @@ properties:
> > > >        - enum:
> > > >            - sifive,fu540-c000-gpio
> > > >            - sifive,fu740-c000-gpio
> > > > +          - canaan,k210-gpiohs
> > > >        - const: sifive,gpio0
> > > > 
> > > >    reg:
> > > > @@ -23,9 +24,9 @@ properties:
> > > > 
> > > >    interrupts:
> > > >      description:
> > > > -      interrupt mapping one per GPIO. Maximum 16 GPIOs.
> > > > +      interrupt mapping one per GPIO. Maximum 32 GPIOs.
> > > >      minItems: 1
> > > > -    maxItems: 16
> > > > +    maxItems: 32
> > > > 
> > > >    interrupt-controller: true
> > > > 
> > > > @@ -38,6 +39,10 @@ properties:
> > > >    "#gpio-cells":
> > > >      const: 2
> > > > 
> > > > +  ngpios:
> > > > +    minimum: 1
> > > > +    maximum: 32
> > > 
> > > What's the default as obviously drivers already assume something.
> > > 
> > > Does a driver actually need to know this? For example, does the
> > > register stride change or something?
> > > 
> > > Please don't add it if the only purpose is error check your DT (IOW,
> > > if it just checks the max cell value in gpios phandles).
> > 
> > If I remove that, make dtbs_check complains. Looking at othe gpio controller
> > bindings, they all have it. So isn't it better to be consistent, and avoid make
> > dtbs_check errors ?
> 
> That would mean you are already using 'ngpios' and it is undocumented
> (for this binding). If already in use and possibly having users then
> that changes things, but that's not what the commit msg says.
> 
> Not *all* gpio controllers have ngpios. It's a good number, but
> probably more than need it though. If we wanted it everywhere, there
> would be a schema enforcing that.

If I remove the minimum and maximum lines, I get this error:

./Documentation/devicetree/bindings/gpio/sifive,gpio.yaml:42:10: [error] empty
value in block mapping (empty-values)
  CHKDT   Documentation/devicetree/bindings/processed-schema-examples.json
/home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
,gpio.yaml: properties:ngpios: None is not of type 'object', 'boolean'
  SCHEMA  Documentation/devicetree/bindings/processed-schema-examples.json
/home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
,gpio.yaml: ignoring, error in schema: properties: ngpios
warning: no schema found in file:
./Documentation/devicetree/bindings/gpio/sifive,gpio.yaml

If I remove the ngpios property entirely, then I get a hit on the device tree:

  CHECK   arch/riscv/boot/dts/canaan/sipeed_maix_bit.dt.yaml
/linux/arch/riscv/boot/dts/canaan/sipeed_maix_bit.dt.yaml:
gpio-controller@38001000: 'ngpios' does not match any of the regexes: 'pinctrl-
[0-9]+'
	From schema:
/home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
,gpio.yaml

Now, If I change the property definition to this:

diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
index 2cef18ca737c..5c7865180383 100644
--- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
@@ -40,8 +40,11 @@ properties:
     const: 2
 
   ngpios:
-    minimum: 1
-    maximum: 32
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description:
+      The number of GPIO pins implemented by the controller.
+      It is 16 for the SiFive SoCs and 32 for the Canaan K210 SoC.
+
 
   gpio-controller: true

Then all is OK.

Which option should I go for here ? If we want to avoid a dtbs_check error, as
far as I can see, we can:
1) Remove the ngpios property and remove its use from the DTS, which is not
nice in my opinion
2) Use the modification proposed above

Please advise. Thanks !

-- 
Damien Le Moal
Western Digital Research


^ permalink raw reply related	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 07/16] dt-bindings: fix sifive gpio properties
@ 2021-02-04  0:47           ` Damien Le Moal
  0 siblings, 0 replies; 81+ messages in thread
From: Damien Le Moal @ 2021-02-04  0:47 UTC (permalink / raw)
  To: robh
  Cc: devicetree, Anup Patel, seanga2, Atish Patra, palmer,
	paul.walmsley, linux-riscv

On Wed, 2021-02-03 at 14:41 -0600, Rob Herring wrote:
> On Wed, Feb 3, 2021 at 6:52 AM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
> > 
> > On Tue, 2021-02-02 at 13:02 -0600, Rob Herring wrote:
> > > On Tue, Feb 2, 2021 at 4:36 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
> > > > 
> > > > The sifive gpio IP block supports up to 32 GPIOs. Reflect that in the
> > > > interrupts property description and maxItems. Also add the standard
> > > > ngpios property to describe the number of GPIOs available on the
> > > > implementation.
> > > > 
> > > > Also add the "canaan,k210-gpiohs" compatible string to indicate the use
> > > > of this gpio controller in the Canaan Kendryte K210 SoC. If this
> > > > compatible string is used, do not define the clocks property as
> > > > required as the K210 SoC does not have a software controllable clock
> > > > for the Sifive gpio IP block.
> > > > 
> > > > Cc: Paul Walmsley <paul.walmsley@sifive.com>
> > > > Cc: Rob Herring <robh@kernel.org>
> > > > Cc: devicetree@vger.kernel.org
> > > > Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> > > > ---
> > > >  .../devicetree/bindings/gpio/sifive,gpio.yaml | 21 ++++++++++++++++---
> > > >  1 file changed, 18 insertions(+), 3 deletions(-)
> > > > 
> > > > diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > > > index ab22056f8b44..2cef18ca737c 100644
> > > > --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > > > +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > > > @@ -16,6 +16,7 @@ properties:
> > > >        - enum:
> > > >            - sifive,fu540-c000-gpio
> > > >            - sifive,fu740-c000-gpio
> > > > +          - canaan,k210-gpiohs
> > > >        - const: sifive,gpio0
> > > > 
> > > >    reg:
> > > > @@ -23,9 +24,9 @@ properties:
> > > > 
> > > >    interrupts:
> > > >      description:
> > > > -      interrupt mapping one per GPIO. Maximum 16 GPIOs.
> > > > +      interrupt mapping one per GPIO. Maximum 32 GPIOs.
> > > >      minItems: 1
> > > > -    maxItems: 16
> > > > +    maxItems: 32
> > > > 
> > > >    interrupt-controller: true
> > > > 
> > > > @@ -38,6 +39,10 @@ properties:
> > > >    "#gpio-cells":
> > > >      const: 2
> > > > 
> > > > +  ngpios:
> > > > +    minimum: 1
> > > > +    maximum: 32
> > > 
> > > What's the default as obviously drivers already assume something.
> > > 
> > > Does a driver actually need to know this? For example, does the
> > > register stride change or something?
> > > 
> > > Please don't add it if the only purpose is error check your DT (IOW,
> > > if it just checks the max cell value in gpios phandles).
> > 
> > If I remove that, make dtbs_check complains. Looking at othe gpio controller
> > bindings, they all have it. So isn't it better to be consistent, and avoid make
> > dtbs_check errors ?
> 
> That would mean you are already using 'ngpios' and it is undocumented
> (for this binding). If already in use and possibly having users then
> that changes things, but that's not what the commit msg says.
> 
> Not *all* gpio controllers have ngpios. It's a good number, but
> probably more than need it though. If we wanted it everywhere, there
> would be a schema enforcing that.

If I remove the minimum and maximum lines, I get this error:

./Documentation/devicetree/bindings/gpio/sifive,gpio.yaml:42:10: [error] empty
value in block mapping (empty-values)
  CHKDT   Documentation/devicetree/bindings/processed-schema-examples.json
/home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
,gpio.yaml: properties:ngpios: None is not of type 'object', 'boolean'
  SCHEMA  Documentation/devicetree/bindings/processed-schema-examples.json
/home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
,gpio.yaml: ignoring, error in schema: properties: ngpios
warning: no schema found in file:
./Documentation/devicetree/bindings/gpio/sifive,gpio.yaml

If I remove the ngpios property entirely, then I get a hit on the device tree:

  CHECK   arch/riscv/boot/dts/canaan/sipeed_maix_bit.dt.yaml
/linux/arch/riscv/boot/dts/canaan/sipeed_maix_bit.dt.yaml:
gpio-controller@38001000: 'ngpios' does not match any of the regexes: 'pinctrl-
[0-9]+'
	From schema:
/home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
,gpio.yaml

Now, If I change the property definition to this:

diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
index 2cef18ca737c..5c7865180383 100644
--- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
@@ -40,8 +40,11 @@ properties:
     const: 2
 
   ngpios:
-    minimum: 1
-    maximum: 32
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description:
+      The number of GPIO pins implemented by the controller.
+      It is 16 for the SiFive SoCs and 32 for the Canaan K210 SoC.
+
 
   gpio-controller: true

Then all is OK.

Which option should I go for here ? If we want to avoid a dtbs_check error, as
far as I can see, we can:
1) Remove the ngpios property and remove its use from the DTS, which is not
nice in my opinion
2) Use the modification proposed above

Please advise. Thanks !

-- 
Damien Le Moal
Western Digital Research

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply related	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 07/16] dt-bindings: fix sifive gpio properties
  2021-02-04  0:47           ` Damien Le Moal
@ 2021-02-05  0:29             ` Damien Le Moal
  -1 siblings, 0 replies; 81+ messages in thread
From: Damien Le Moal @ 2021-02-05  0:29 UTC (permalink / raw)
  To: robh
  Cc: paul.walmsley, palmer, linux-riscv, Atish Patra, seanga2,
	Anup Patel, devicetree

On 2021/02/04 9:47, Damien Le Moal wrote:
> On Wed, 2021-02-03 at 14:41 -0600, Rob Herring wrote:
>> On Wed, Feb 3, 2021 at 6:52 AM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
>>>
>>> On Tue, 2021-02-02 at 13:02 -0600, Rob Herring wrote:
>>>> On Tue, Feb 2, 2021 at 4:36 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
>>>>>
>>>>> The sifive gpio IP block supports up to 32 GPIOs. Reflect that in the
>>>>> interrupts property description and maxItems. Also add the standard
>>>>> ngpios property to describe the number of GPIOs available on the
>>>>> implementation.
>>>>>
>>>>> Also add the "canaan,k210-gpiohs" compatible string to indicate the use
>>>>> of this gpio controller in the Canaan Kendryte K210 SoC. If this
>>>>> compatible string is used, do not define the clocks property as
>>>>> required as the K210 SoC does not have a software controllable clock
>>>>> for the Sifive gpio IP block.
>>>>>
>>>>> Cc: Paul Walmsley <paul.walmsley@sifive.com>
>>>>> Cc: Rob Herring <robh@kernel.org>
>>>>> Cc: devicetree@vger.kernel.org
>>>>> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
>>>>> ---
>>>>>  .../devicetree/bindings/gpio/sifive,gpio.yaml | 21 ++++++++++++++++---
>>>>>  1 file changed, 18 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>> index ab22056f8b44..2cef18ca737c 100644
>>>>> --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>> +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>> @@ -16,6 +16,7 @@ properties:
>>>>>        - enum:
>>>>>            - sifive,fu540-c000-gpio
>>>>>            - sifive,fu740-c000-gpio
>>>>> +          - canaan,k210-gpiohs
>>>>>        - const: sifive,gpio0
>>>>>
>>>>>    reg:
>>>>> @@ -23,9 +24,9 @@ properties:
>>>>>
>>>>>    interrupts:
>>>>>      description:
>>>>> -      interrupt mapping one per GPIO. Maximum 16 GPIOs.
>>>>> +      interrupt mapping one per GPIO. Maximum 32 GPIOs.
>>>>>      minItems: 1
>>>>> -    maxItems: 16
>>>>> +    maxItems: 32
>>>>>
>>>>>    interrupt-controller: true
>>>>>
>>>>> @@ -38,6 +39,10 @@ properties:
>>>>>    "#gpio-cells":
>>>>>      const: 2
>>>>>
>>>>> +  ngpios:
>>>>> +    minimum: 1
>>>>> +    maximum: 32
>>>>
>>>> What's the default as obviously drivers already assume something.
>>>>
>>>> Does a driver actually need to know this? For example, does the
>>>> register stride change or something?
>>>>
>>>> Please don't add it if the only purpose is error check your DT (IOW,
>>>> if it just checks the max cell value in gpios phandles).
>>>
>>> If I remove that, make dtbs_check complains. Looking at othe gpio controller
>>> bindings, they all have it. So isn't it better to be consistent, and avoid make
>>> dtbs_check errors ?
>>
>> That would mean you are already using 'ngpios' and it is undocumented
>> (for this binding). If already in use and possibly having users then
>> that changes things, but that's not what the commit msg says.
>>
>> Not *all* gpio controllers have ngpios. It's a good number, but
>> probably more than need it though. If we wanted it everywhere, there
>> would be a schema enforcing that.
> 
> If I remove the minimum and maximum lines, I get this error:
> 
> ./Documentation/devicetree/bindings/gpio/sifive,gpio.yaml:42:10: [error] empty
> value in block mapping (empty-values)
>   CHKDT   Documentation/devicetree/bindings/processed-schema-examples.json
> /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
> ,gpio.yaml: properties:ngpios: None is not of type 'object', 'boolean'
>   SCHEMA  Documentation/devicetree/bindings/processed-schema-examples.json
> /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
> ,gpio.yaml: ignoring, error in schema: properties: ngpios
> warning: no schema found in file:
> ./Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> 
> If I remove the ngpios property entirely, then I get a hit on the device tree:
> 
>   CHECK   arch/riscv/boot/dts/canaan/sipeed_maix_bit.dt.yaml
> /linux/arch/riscv/boot/dts/canaan/sipeed_maix_bit.dt.yaml:
> gpio-controller@38001000: 'ngpios' does not match any of the regexes: 'pinctrl-
> [0-9]+'
> 	From schema:
> /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
> ,gpio.yaml
> 
> Now, If I change the property definition to this:
> 
> diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> index 2cef18ca737c..5c7865180383 100644
> --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> @@ -40,8 +40,11 @@ properties:
>      const: 2
>  
>    ngpios:
> -    minimum: 1
> -    maximum: 32
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    description:
> +      The number of GPIO pins implemented by the controller.
> +      It is 16 for the SiFive SoCs and 32 for the Canaan K210 SoC.
> +
>  
>    gpio-controller: true
> 
> Then all is OK.
> 
> Which option should I go for here ? If we want to avoid a dtbs_check error, as
> far as I can see, we can:
> 1) Remove the ngpios property and remove its use from the DTS, which is not
> nice in my opinion
> 2) Use the modification proposed above
> 
> Please advise. Thanks !
> 

Rob,

Thanks for the reviews and acks on the other patches. I would like to send v16
with your suggested fixes. But what should I do about ngpios ? Option (1) or (2)
above ? Any other option ?

Thanks !

-- 
Damien Le Moal
Western Digital Research

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 07/16] dt-bindings: fix sifive gpio properties
@ 2021-02-05  0:29             ` Damien Le Moal
  0 siblings, 0 replies; 81+ messages in thread
From: Damien Le Moal @ 2021-02-05  0:29 UTC (permalink / raw)
  To: robh
  Cc: devicetree, Anup Patel, seanga2, Atish Patra, palmer,
	paul.walmsley, linux-riscv

On 2021/02/04 9:47, Damien Le Moal wrote:
> On Wed, 2021-02-03 at 14:41 -0600, Rob Herring wrote:
>> On Wed, Feb 3, 2021 at 6:52 AM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
>>>
>>> On Tue, 2021-02-02 at 13:02 -0600, Rob Herring wrote:
>>>> On Tue, Feb 2, 2021 at 4:36 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
>>>>>
>>>>> The sifive gpio IP block supports up to 32 GPIOs. Reflect that in the
>>>>> interrupts property description and maxItems. Also add the standard
>>>>> ngpios property to describe the number of GPIOs available on the
>>>>> implementation.
>>>>>
>>>>> Also add the "canaan,k210-gpiohs" compatible string to indicate the use
>>>>> of this gpio controller in the Canaan Kendryte K210 SoC. If this
>>>>> compatible string is used, do not define the clocks property as
>>>>> required as the K210 SoC does not have a software controllable clock
>>>>> for the Sifive gpio IP block.
>>>>>
>>>>> Cc: Paul Walmsley <paul.walmsley@sifive.com>
>>>>> Cc: Rob Herring <robh@kernel.org>
>>>>> Cc: devicetree@vger.kernel.org
>>>>> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
>>>>> ---
>>>>>  .../devicetree/bindings/gpio/sifive,gpio.yaml | 21 ++++++++++++++++---
>>>>>  1 file changed, 18 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>> index ab22056f8b44..2cef18ca737c 100644
>>>>> --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>> +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>> @@ -16,6 +16,7 @@ properties:
>>>>>        - enum:
>>>>>            - sifive,fu540-c000-gpio
>>>>>            - sifive,fu740-c000-gpio
>>>>> +          - canaan,k210-gpiohs
>>>>>        - const: sifive,gpio0
>>>>>
>>>>>    reg:
>>>>> @@ -23,9 +24,9 @@ properties:
>>>>>
>>>>>    interrupts:
>>>>>      description:
>>>>> -      interrupt mapping one per GPIO. Maximum 16 GPIOs.
>>>>> +      interrupt mapping one per GPIO. Maximum 32 GPIOs.
>>>>>      minItems: 1
>>>>> -    maxItems: 16
>>>>> +    maxItems: 32
>>>>>
>>>>>    interrupt-controller: true
>>>>>
>>>>> @@ -38,6 +39,10 @@ properties:
>>>>>    "#gpio-cells":
>>>>>      const: 2
>>>>>
>>>>> +  ngpios:
>>>>> +    minimum: 1
>>>>> +    maximum: 32
>>>>
>>>> What's the default as obviously drivers already assume something.
>>>>
>>>> Does a driver actually need to know this? For example, does the
>>>> register stride change or something?
>>>>
>>>> Please don't add it if the only purpose is error check your DT (IOW,
>>>> if it just checks the max cell value in gpios phandles).
>>>
>>> If I remove that, make dtbs_check complains. Looking at othe gpio controller
>>> bindings, they all have it. So isn't it better to be consistent, and avoid make
>>> dtbs_check errors ?
>>
>> That would mean you are already using 'ngpios' and it is undocumented
>> (for this binding). If already in use and possibly having users then
>> that changes things, but that's not what the commit msg says.
>>
>> Not *all* gpio controllers have ngpios. It's a good number, but
>> probably more than need it though. If we wanted it everywhere, there
>> would be a schema enforcing that.
> 
> If I remove the minimum and maximum lines, I get this error:
> 
> ./Documentation/devicetree/bindings/gpio/sifive,gpio.yaml:42:10: [error] empty
> value in block mapping (empty-values)
>   CHKDT   Documentation/devicetree/bindings/processed-schema-examples.json
> /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
> ,gpio.yaml: properties:ngpios: None is not of type 'object', 'boolean'
>   SCHEMA  Documentation/devicetree/bindings/processed-schema-examples.json
> /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
> ,gpio.yaml: ignoring, error in schema: properties: ngpios
> warning: no schema found in file:
> ./Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> 
> If I remove the ngpios property entirely, then I get a hit on the device tree:
> 
>   CHECK   arch/riscv/boot/dts/canaan/sipeed_maix_bit.dt.yaml
> /linux/arch/riscv/boot/dts/canaan/sipeed_maix_bit.dt.yaml:
> gpio-controller@38001000: 'ngpios' does not match any of the regexes: 'pinctrl-
> [0-9]+'
> 	From schema:
> /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
> ,gpio.yaml
> 
> Now, If I change the property definition to this:
> 
> diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> index 2cef18ca737c..5c7865180383 100644
> --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> @@ -40,8 +40,11 @@ properties:
>      const: 2
>  
>    ngpios:
> -    minimum: 1
> -    maximum: 32
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    description:
> +      The number of GPIO pins implemented by the controller.
> +      It is 16 for the SiFive SoCs and 32 for the Canaan K210 SoC.
> +
>  
>    gpio-controller: true
> 
> Then all is OK.
> 
> Which option should I go for here ? If we want to avoid a dtbs_check error, as
> far as I can see, we can:
> 1) Remove the ngpios property and remove its use from the DTS, which is not
> nice in my opinion
> 2) Use the modification proposed above
> 
> Please advise. Thanks !
> 

Rob,

Thanks for the reviews and acks on the other patches. I would like to send v16
with your suggested fixes. But what should I do about ngpios ? Option (1) or (2)
above ? Any other option ?

Thanks !

-- 
Damien Le Moal
Western Digital Research

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 07/16] dt-bindings: fix sifive gpio properties
  2021-02-04  0:47           ` Damien Le Moal
@ 2021-02-05 20:02             ` Rob Herring
  -1 siblings, 0 replies; 81+ messages in thread
From: Rob Herring @ 2021-02-05 20:02 UTC (permalink / raw)
  To: Damien Le Moal
  Cc: paul.walmsley, palmer, linux-riscv, Atish Patra, seanga2,
	Anup Patel, devicetree

On Wed, Feb 3, 2021 at 6:47 PM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
>
> On Wed, 2021-02-03 at 14:41 -0600, Rob Herring wrote:
> > On Wed, Feb 3, 2021 at 6:52 AM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
> > >
> > > On Tue, 2021-02-02 at 13:02 -0600, Rob Herring wrote:
> > > > On Tue, Feb 2, 2021 at 4:36 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
> > > > >
> > > > > The sifive gpio IP block supports up to 32 GPIOs. Reflect that in the
> > > > > interrupts property description and maxItems. Also add the standard
> > > > > ngpios property to describe the number of GPIOs available on the
> > > > > implementation.
> > > > >
> > > > > Also add the "canaan,k210-gpiohs" compatible string to indicate the use
> > > > > of this gpio controller in the Canaan Kendryte K210 SoC. If this
> > > > > compatible string is used, do not define the clocks property as
> > > > > required as the K210 SoC does not have a software controllable clock
> > > > > for the Sifive gpio IP block.
> > > > >
> > > > > Cc: Paul Walmsley <paul.walmsley@sifive.com>
> > > > > Cc: Rob Herring <robh@kernel.org>
> > > > > Cc: devicetree@vger.kernel.org
> > > > > Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> > > > > ---
> > > > >  .../devicetree/bindings/gpio/sifive,gpio.yaml | 21 ++++++++++++++++---
> > > > >  1 file changed, 18 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > > > > index ab22056f8b44..2cef18ca737c 100644
> > > > > --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > > > > +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > > > > @@ -16,6 +16,7 @@ properties:
> > > > >        - enum:
> > > > >            - sifive,fu540-c000-gpio
> > > > >            - sifive,fu740-c000-gpio
> > > > > +          - canaan,k210-gpiohs
> > > > >        - const: sifive,gpio0
> > > > >
> > > > >    reg:
> > > > > @@ -23,9 +24,9 @@ properties:
> > > > >
> > > > >    interrupts:
> > > > >      description:
> > > > > -      interrupt mapping one per GPIO. Maximum 16 GPIOs.
> > > > > +      interrupt mapping one per GPIO. Maximum 32 GPIOs.
> > > > >      minItems: 1
> > > > > -    maxItems: 16
> > > > > +    maxItems: 32
> > > > >
> > > > >    interrupt-controller: true
> > > > >
> > > > > @@ -38,6 +39,10 @@ properties:
> > > > >    "#gpio-cells":
> > > > >      const: 2
> > > > >
> > > > > +  ngpios:
> > > > > +    minimum: 1
> > > > > +    maximum: 32
> > > >
> > > > What's the default as obviously drivers already assume something.
> > > >
> > > > Does a driver actually need to know this? For example, does the
> > > > register stride change or something?
> > > >
> > > > Please don't add it if the only purpose is error check your DT (IOW,
> > > > if it just checks the max cell value in gpios phandles).
> > >
> > > If I remove that, make dtbs_check complains. Looking at othe gpio controller
> > > bindings, they all have it. So isn't it better to be consistent, and avoid make
> > > dtbs_check errors ?
> >
> > That would mean you are already using 'ngpios' and it is undocumented
> > (for this binding). If already in use and possibly having users then
> > that changes things, but that's not what the commit msg says.
> >
> > Not *all* gpio controllers have ngpios. It's a good number, but
> > probably more than need it though. If we wanted it everywhere, there
> > would be a schema enforcing that.
>
> If I remove the minimum and maximum lines, I get this error:

I never said remove minimum/maximum. The suggestion is either add
'default: 16' or remove 'ngpios' entirely.

> ./Documentation/devicetree/bindings/gpio/sifive,gpio.yaml:42:10: [error] empty
> value in block mapping (empty-values)
>   CHKDT   Documentation/devicetree/bindings/processed-schema-examples.json
> /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
> ,gpio.yaml: properties:ngpios: None is not of type 'object', 'boolean'
>   SCHEMA  Documentation/devicetree/bindings/processed-schema-examples.json
> /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
> ,gpio.yaml: ignoring, error in schema: properties: ngpios
> warning: no schema found in file:
> ./Documentation/devicetree/bindings/gpio/sifive,gpio.yaml

ngpios: true

or

ngpios: {}

Are the minimum valid values for a key. (Though not what should be done here.)

>
> If I remove the ngpios property entirely, then I get a hit on the device tree:
>
>   CHECK   arch/riscv/boot/dts/canaan/sipeed_maix_bit.dt.yaml
> /linux/arch/riscv/boot/dts/canaan/sipeed_maix_bit.dt.yaml:
> gpio-controller@38001000: 'ngpios' does not match any of the regexes: 'pinctrl-
> [0-9]+'
>         From schema:
> /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
> ,gpio.yaml

That's not upstream, right? Then fix it.

> Now, If I change the property definition to this:
>
> diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> index 2cef18ca737c..5c7865180383 100644
> --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> @@ -40,8 +40,11 @@ properties:
>      const: 2
>
>    ngpios:
> -    minimum: 1
> -    maximum: 32
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    description:
> +      The number of GPIO pins implemented by the controller.
> +      It is 16 for the SiFive SoCs and 32 for the Canaan K210 SoC.
> +
>
>    gpio-controller: true
>
> Then all is OK.
>
> Which option should I go for here ? If we want to avoid a dtbs_check error, as
> far as I can see, we can:
> 1) Remove the ngpios property and remove its use from the DTS, which is not
> nice in my opinion

Again, it depends if there are users depending on it. A user being a
GPIO driver somewhere, not a DTS file. The GPIO driver in the kernel
doesn't need it. So u-boot? BSD?

> 2) Use the modification proposed above

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 07/16] dt-bindings: fix sifive gpio properties
@ 2021-02-05 20:02             ` Rob Herring
  0 siblings, 0 replies; 81+ messages in thread
From: Rob Herring @ 2021-02-05 20:02 UTC (permalink / raw)
  To: Damien Le Moal
  Cc: devicetree, Anup Patel, seanga2, Atish Patra, palmer,
	paul.walmsley, linux-riscv

On Wed, Feb 3, 2021 at 6:47 PM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
>
> On Wed, 2021-02-03 at 14:41 -0600, Rob Herring wrote:
> > On Wed, Feb 3, 2021 at 6:52 AM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
> > >
> > > On Tue, 2021-02-02 at 13:02 -0600, Rob Herring wrote:
> > > > On Tue, Feb 2, 2021 at 4:36 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
> > > > >
> > > > > The sifive gpio IP block supports up to 32 GPIOs. Reflect that in the
> > > > > interrupts property description and maxItems. Also add the standard
> > > > > ngpios property to describe the number of GPIOs available on the
> > > > > implementation.
> > > > >
> > > > > Also add the "canaan,k210-gpiohs" compatible string to indicate the use
> > > > > of this gpio controller in the Canaan Kendryte K210 SoC. If this
> > > > > compatible string is used, do not define the clocks property as
> > > > > required as the K210 SoC does not have a software controllable clock
> > > > > for the Sifive gpio IP block.
> > > > >
> > > > > Cc: Paul Walmsley <paul.walmsley@sifive.com>
> > > > > Cc: Rob Herring <robh@kernel.org>
> > > > > Cc: devicetree@vger.kernel.org
> > > > > Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> > > > > ---
> > > > >  .../devicetree/bindings/gpio/sifive,gpio.yaml | 21 ++++++++++++++++---
> > > > >  1 file changed, 18 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > > > > index ab22056f8b44..2cef18ca737c 100644
> > > > > --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > > > > +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > > > > @@ -16,6 +16,7 @@ properties:
> > > > >        - enum:
> > > > >            - sifive,fu540-c000-gpio
> > > > >            - sifive,fu740-c000-gpio
> > > > > +          - canaan,k210-gpiohs
> > > > >        - const: sifive,gpio0
> > > > >
> > > > >    reg:
> > > > > @@ -23,9 +24,9 @@ properties:
> > > > >
> > > > >    interrupts:
> > > > >      description:
> > > > > -      interrupt mapping one per GPIO. Maximum 16 GPIOs.
> > > > > +      interrupt mapping one per GPIO. Maximum 32 GPIOs.
> > > > >      minItems: 1
> > > > > -    maxItems: 16
> > > > > +    maxItems: 32
> > > > >
> > > > >    interrupt-controller: true
> > > > >
> > > > > @@ -38,6 +39,10 @@ properties:
> > > > >    "#gpio-cells":
> > > > >      const: 2
> > > > >
> > > > > +  ngpios:
> > > > > +    minimum: 1
> > > > > +    maximum: 32
> > > >
> > > > What's the default as obviously drivers already assume something.
> > > >
> > > > Does a driver actually need to know this? For example, does the
> > > > register stride change or something?
> > > >
> > > > Please don't add it if the only purpose is error check your DT (IOW,
> > > > if it just checks the max cell value in gpios phandles).
> > >
> > > If I remove that, make dtbs_check complains. Looking at othe gpio controller
> > > bindings, they all have it. So isn't it better to be consistent, and avoid make
> > > dtbs_check errors ?
> >
> > That would mean you are already using 'ngpios' and it is undocumented
> > (for this binding). If already in use and possibly having users then
> > that changes things, but that's not what the commit msg says.
> >
> > Not *all* gpio controllers have ngpios. It's a good number, but
> > probably more than need it though. If we wanted it everywhere, there
> > would be a schema enforcing that.
>
> If I remove the minimum and maximum lines, I get this error:

I never said remove minimum/maximum. The suggestion is either add
'default: 16' or remove 'ngpios' entirely.

> ./Documentation/devicetree/bindings/gpio/sifive,gpio.yaml:42:10: [error] empty
> value in block mapping (empty-values)
>   CHKDT   Documentation/devicetree/bindings/processed-schema-examples.json
> /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
> ,gpio.yaml: properties:ngpios: None is not of type 'object', 'boolean'
>   SCHEMA  Documentation/devicetree/bindings/processed-schema-examples.json
> /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
> ,gpio.yaml: ignoring, error in schema: properties: ngpios
> warning: no schema found in file:
> ./Documentation/devicetree/bindings/gpio/sifive,gpio.yaml

ngpios: true

or

ngpios: {}

Are the minimum valid values for a key. (Though not what should be done here.)

>
> If I remove the ngpios property entirely, then I get a hit on the device tree:
>
>   CHECK   arch/riscv/boot/dts/canaan/sipeed_maix_bit.dt.yaml
> /linux/arch/riscv/boot/dts/canaan/sipeed_maix_bit.dt.yaml:
> gpio-controller@38001000: 'ngpios' does not match any of the regexes: 'pinctrl-
> [0-9]+'
>         From schema:
> /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
> ,gpio.yaml

That's not upstream, right? Then fix it.

> Now, If I change the property definition to this:
>
> diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> index 2cef18ca737c..5c7865180383 100644
> --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> @@ -40,8 +40,11 @@ properties:
>      const: 2
>
>    ngpios:
> -    minimum: 1
> -    maximum: 32
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    description:
> +      The number of GPIO pins implemented by the controller.
> +      It is 16 for the SiFive SoCs and 32 for the Canaan K210 SoC.
> +
>
>    gpio-controller: true
>
> Then all is OK.
>
> Which option should I go for here ? If we want to avoid a dtbs_check error, as
> far as I can see, we can:
> 1) Remove the ngpios property and remove its use from the DTS, which is not
> nice in my opinion

Again, it depends if there are users depending on it. A user being a
GPIO driver somewhere, not a DTS file. The GPIO driver in the kernel
doesn't need it. So u-boot? BSD?

> 2) Use the modification proposed above

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 07/16] dt-bindings: fix sifive gpio properties
  2021-02-05 20:02             ` Rob Herring
@ 2021-02-05 22:53               ` Damien Le Moal
  -1 siblings, 0 replies; 81+ messages in thread
From: Damien Le Moal @ 2021-02-05 22:53 UTC (permalink / raw)
  To: robh
  Cc: paul.walmsley, palmer, linux-riscv, Atish Patra, seanga2,
	Anup Patel, devicetree

On Fri, 2021-02-05 at 14:02 -0600, Rob Herring wrote:
> On Wed, Feb 3, 2021 at 6:47 PM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
> > 
> > On Wed, 2021-02-03 at 14:41 -0600, Rob Herring wrote:
> > > On Wed, Feb 3, 2021 at 6:52 AM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
> > > > 
> > > > On Tue, 2021-02-02 at 13:02 -0600, Rob Herring wrote:
> > > > > On Tue, Feb 2, 2021 at 4:36 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
> > > > > > 
> > > > > > The sifive gpio IP block supports up to 32 GPIOs. Reflect that in the
> > > > > > interrupts property description and maxItems. Also add the standard
> > > > > > ngpios property to describe the number of GPIOs available on the
> > > > > > implementation.
> > > > > > 
> > > > > > Also add the "canaan,k210-gpiohs" compatible string to indicate the use
> > > > > > of this gpio controller in the Canaan Kendryte K210 SoC. If this
> > > > > > compatible string is used, do not define the clocks property as
> > > > > > required as the K210 SoC does not have a software controllable clock
> > > > > > for the Sifive gpio IP block.
> > > > > > 
> > > > > > Cc: Paul Walmsley <paul.walmsley@sifive.com>
> > > > > > Cc: Rob Herring <robh@kernel.org>
> > > > > > Cc: devicetree@vger.kernel.org
> > > > > > Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> > > > > > ---
> > > > > >  .../devicetree/bindings/gpio/sifive,gpio.yaml | 21 ++++++++++++++++---
> > > > > >  1 file changed, 18 insertions(+), 3 deletions(-)
> > > > > > 
> > > > > > diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > > > > > index ab22056f8b44..2cef18ca737c 100644
> > > > > > --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > > > > > +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > > > > > @@ -16,6 +16,7 @@ properties:
> > > > > >        - enum:
> > > > > >            - sifive,fu540-c000-gpio
> > > > > >            - sifive,fu740-c000-gpio
> > > > > > +          - canaan,k210-gpiohs
> > > > > >        - const: sifive,gpio0
> > > > > > 
> > > > > >    reg:
> > > > > > @@ -23,9 +24,9 @@ properties:
> > > > > > 
> > > > > >    interrupts:
> > > > > >      description:
> > > > > > -      interrupt mapping one per GPIO. Maximum 16 GPIOs.
> > > > > > +      interrupt mapping one per GPIO. Maximum 32 GPIOs.
> > > > > >      minItems: 1
> > > > > > -    maxItems: 16
> > > > > > +    maxItems: 32
> > > > > > 
> > > > > >    interrupt-controller: true
> > > > > > 
> > > > > > @@ -38,6 +39,10 @@ properties:
> > > > > >    "#gpio-cells":
> > > > > >      const: 2
> > > > > > 
> > > > > > +  ngpios:
> > > > > > +    minimum: 1
> > > > > > +    maximum: 32
> > > > > 
> > > > > What's the default as obviously drivers already assume something.
> > > > > 
> > > > > Does a driver actually need to know this? For example, does the
> > > > > register stride change or something?
> > > > > 
> > > > > Please don't add it if the only purpose is error check your DT (IOW,
> > > > > if it just checks the max cell value in gpios phandles).
> > > > 
> > > > If I remove that, make dtbs_check complains. Looking at othe gpio controller
> > > > bindings, they all have it. So isn't it better to be consistent, and avoid make
> > > > dtbs_check errors ?
> > > 
> > > That would mean you are already using 'ngpios' and it is undocumented
> > > (for this binding). If already in use and possibly having users then
> > > that changes things, but that's not what the commit msg says.
> > > 
> > > Not *all* gpio controllers have ngpios. It's a good number, but
> > > probably more than need it though. If we wanted it everywhere, there
> > > would be a schema enforcing that.
> > 
> > If I remove the minimum and maximum lines, I get this error:
> 
> I never said remove minimum/maximum. The suggestion is either add
> 'default: 16' or remove 'ngpios' entirely.
> 
> > ./Documentation/devicetree/bindings/gpio/sifive,gpio.yaml:42:10: [error] empty
> > value in block mapping (empty-values)
> >   CHKDT   Documentation/devicetree/bindings/processed-schema-examples.json
> > /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
> > ,gpio.yaml: properties:ngpios: None is not of type 'object', 'boolean'
> >   SCHEMA  Documentation/devicetree/bindings/processed-schema-examples.json
> > /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
> > ,gpio.yaml: ignoring, error in schema: properties: ngpios
> > warning: no schema found in file:
> > ./Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> 
> ngpios: true
> 
> or
> 
> ngpios: {}
> 
> Are the minimum valid values for a key. (Though not what should be done here.)
> 
> > 
> > If I remove the ngpios property entirely, then I get a hit on the device tree:
> > 
> >   CHECK   arch/riscv/boot/dts/canaan/sipeed_maix_bit.dt.yaml
> > /linux/arch/riscv/boot/dts/canaan/sipeed_maix_bit.dt.yaml:
> > gpio-controller@38001000: 'ngpios' does not match any of the regexes: 'pinctrl-
> > [0-9]+'
> >         From schema:
> > /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
> > ,gpio.yaml
> 
> That's not upstream, right? Then fix it.
> 
> > Now, If I change the property definition to this:
> > 
> > diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > index 2cef18ca737c..5c7865180383 100644
> > --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > @@ -40,8 +40,11 @@ properties:
> >      const: 2
> > 
> >    ngpios:
> > -    minimum: 1
> > -    maximum: 32
> > +    $ref: /schemas/types.yaml#/definitions/uint32
> > +    description:
> > +      The number of GPIO pins implemented by the controller.
> > +      It is 16 for the SiFive SoCs and 32 for the Canaan K210 SoC.
> > +
> > 
> >    gpio-controller: true
> > 
> > Then all is OK.
> > 
> > Which option should I go for here ? If we want to avoid a dtbs_check error, as
> > far as I can see, we can:
> > 1) Remove the ngpios property and remove its use from the DTS, which is not
> > nice in my opinion
> 
> Again, it depends if there are users depending on it. A user being a
> GPIO driver somewhere, not a DTS file. The GPIO driver in the kernel
> doesn't need it. So u-boot? BSD?

The Linux driver uses the number of interrupts for the number of gpios but
upstream U-Boot uses the ngpios property. So I will change this to use
"default: 16" as you suggested.

Thanks !

> 
> > 2) Use the modification proposed above

-- 
Damien Le Moal
Western Digital Research


^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 07/16] dt-bindings: fix sifive gpio properties
@ 2021-02-05 22:53               ` Damien Le Moal
  0 siblings, 0 replies; 81+ messages in thread
From: Damien Le Moal @ 2021-02-05 22:53 UTC (permalink / raw)
  To: robh
  Cc: devicetree, Anup Patel, seanga2, Atish Patra, palmer,
	paul.walmsley, linux-riscv

On Fri, 2021-02-05 at 14:02 -0600, Rob Herring wrote:
> On Wed, Feb 3, 2021 at 6:47 PM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
> > 
> > On Wed, 2021-02-03 at 14:41 -0600, Rob Herring wrote:
> > > On Wed, Feb 3, 2021 at 6:52 AM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
> > > > 
> > > > On Tue, 2021-02-02 at 13:02 -0600, Rob Herring wrote:
> > > > > On Tue, Feb 2, 2021 at 4:36 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
> > > > > > 
> > > > > > The sifive gpio IP block supports up to 32 GPIOs. Reflect that in the
> > > > > > interrupts property description and maxItems. Also add the standard
> > > > > > ngpios property to describe the number of GPIOs available on the
> > > > > > implementation.
> > > > > > 
> > > > > > Also add the "canaan,k210-gpiohs" compatible string to indicate the use
> > > > > > of this gpio controller in the Canaan Kendryte K210 SoC. If this
> > > > > > compatible string is used, do not define the clocks property as
> > > > > > required as the K210 SoC does not have a software controllable clock
> > > > > > for the Sifive gpio IP block.
> > > > > > 
> > > > > > Cc: Paul Walmsley <paul.walmsley@sifive.com>
> > > > > > Cc: Rob Herring <robh@kernel.org>
> > > > > > Cc: devicetree@vger.kernel.org
> > > > > > Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> > > > > > ---
> > > > > >  .../devicetree/bindings/gpio/sifive,gpio.yaml | 21 ++++++++++++++++---
> > > > > >  1 file changed, 18 insertions(+), 3 deletions(-)
> > > > > > 
> > > > > > diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > > > > > index ab22056f8b44..2cef18ca737c 100644
> > > > > > --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > > > > > +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > > > > > @@ -16,6 +16,7 @@ properties:
> > > > > >        - enum:
> > > > > >            - sifive,fu540-c000-gpio
> > > > > >            - sifive,fu740-c000-gpio
> > > > > > +          - canaan,k210-gpiohs
> > > > > >        - const: sifive,gpio0
> > > > > > 
> > > > > >    reg:
> > > > > > @@ -23,9 +24,9 @@ properties:
> > > > > > 
> > > > > >    interrupts:
> > > > > >      description:
> > > > > > -      interrupt mapping one per GPIO. Maximum 16 GPIOs.
> > > > > > +      interrupt mapping one per GPIO. Maximum 32 GPIOs.
> > > > > >      minItems: 1
> > > > > > -    maxItems: 16
> > > > > > +    maxItems: 32
> > > > > > 
> > > > > >    interrupt-controller: true
> > > > > > 
> > > > > > @@ -38,6 +39,10 @@ properties:
> > > > > >    "#gpio-cells":
> > > > > >      const: 2
> > > > > > 
> > > > > > +  ngpios:
> > > > > > +    minimum: 1
> > > > > > +    maximum: 32
> > > > > 
> > > > > What's the default as obviously drivers already assume something.
> > > > > 
> > > > > Does a driver actually need to know this? For example, does the
> > > > > register stride change or something?
> > > > > 
> > > > > Please don't add it if the only purpose is error check your DT (IOW,
> > > > > if it just checks the max cell value in gpios phandles).
> > > > 
> > > > If I remove that, make dtbs_check complains. Looking at othe gpio controller
> > > > bindings, they all have it. So isn't it better to be consistent, and avoid make
> > > > dtbs_check errors ?
> > > 
> > > That would mean you are already using 'ngpios' and it is undocumented
> > > (for this binding). If already in use and possibly having users then
> > > that changes things, but that's not what the commit msg says.
> > > 
> > > Not *all* gpio controllers have ngpios. It's a good number, but
> > > probably more than need it though. If we wanted it everywhere, there
> > > would be a schema enforcing that.
> > 
> > If I remove the minimum and maximum lines, I get this error:
> 
> I never said remove minimum/maximum. The suggestion is either add
> 'default: 16' or remove 'ngpios' entirely.
> 
> > ./Documentation/devicetree/bindings/gpio/sifive,gpio.yaml:42:10: [error] empty
> > value in block mapping (empty-values)
> >   CHKDT   Documentation/devicetree/bindings/processed-schema-examples.json
> > /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
> > ,gpio.yaml: properties:ngpios: None is not of type 'object', 'boolean'
> >   SCHEMA  Documentation/devicetree/bindings/processed-schema-examples.json
> > /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
> > ,gpio.yaml: ignoring, error in schema: properties: ngpios
> > warning: no schema found in file:
> > ./Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> 
> ngpios: true
> 
> or
> 
> ngpios: {}
> 
> Are the minimum valid values for a key. (Though not what should be done here.)
> 
> > 
> > If I remove the ngpios property entirely, then I get a hit on the device tree:
> > 
> >   CHECK   arch/riscv/boot/dts/canaan/sipeed_maix_bit.dt.yaml
> > /linux/arch/riscv/boot/dts/canaan/sipeed_maix_bit.dt.yaml:
> > gpio-controller@38001000: 'ngpios' does not match any of the regexes: 'pinctrl-
> > [0-9]+'
> >         From schema:
> > /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
> > ,gpio.yaml
> 
> That's not upstream, right? Then fix it.
> 
> > Now, If I change the property definition to this:
> > 
> > diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > index 2cef18ca737c..5c7865180383 100644
> > --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > @@ -40,8 +40,11 @@ properties:
> >      const: 2
> > 
> >    ngpios:
> > -    minimum: 1
> > -    maximum: 32
> > +    $ref: /schemas/types.yaml#/definitions/uint32
> > +    description:
> > +      The number of GPIO pins implemented by the controller.
> > +      It is 16 for the SiFive SoCs and 32 for the Canaan K210 SoC.
> > +
> > 
> >    gpio-controller: true
> > 
> > Then all is OK.
> > 
> > Which option should I go for here ? If we want to avoid a dtbs_check error, as
> > far as I can see, we can:
> > 1) Remove the ngpios property and remove its use from the DTS, which is not
> > nice in my opinion
> 
> Again, it depends if there are users depending on it. A user being a
> GPIO driver somewhere, not a DTS file. The GPIO driver in the kernel
> doesn't need it. So u-boot? BSD?

The Linux driver uses the number of interrupts for the number of gpios but
upstream U-Boot uses the ngpios property. So I will change this to use
"default: 16" as you suggested.

Thanks !

> 
> > 2) Use the modification proposed above

-- 
Damien Le Moal
Western Digital Research

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 07/16] dt-bindings: fix sifive gpio properties
  2021-02-05 22:53               ` Damien Le Moal
@ 2021-02-05 22:55                 ` Sean Anderson
  -1 siblings, 0 replies; 81+ messages in thread
From: Sean Anderson @ 2021-02-05 22:55 UTC (permalink / raw)
  To: Damien Le Moal, robh
  Cc: paul.walmsley, palmer, linux-riscv, Atish Patra, Anup Patel, devicetree

On 2/5/21 5:53 PM, Damien Le Moal wrote:
> On Fri, 2021-02-05 at 14:02 -0600, Rob Herring wrote:
>> On Wed, Feb 3, 2021 at 6:47 PM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
>>>
>>> On Wed, 2021-02-03 at 14:41 -0600, Rob Herring wrote:
>>>> On Wed, Feb 3, 2021 at 6:52 AM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
>>>>>
>>>>> On Tue, 2021-02-02 at 13:02 -0600, Rob Herring wrote:
>>>>>> On Tue, Feb 2, 2021 at 4:36 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
>>>>>>>
>>>>>>> The sifive gpio IP block supports up to 32 GPIOs. Reflect that in the
>>>>>>> interrupts property description and maxItems. Also add the standard
>>>>>>> ngpios property to describe the number of GPIOs available on the
>>>>>>> implementation.
>>>>>>>
>>>>>>> Also add the "canaan,k210-gpiohs" compatible string to indicate the use
>>>>>>> of this gpio controller in the Canaan Kendryte K210 SoC. If this
>>>>>>> compatible string is used, do not define the clocks property as
>>>>>>> required as the K210 SoC does not have a software controllable clock
>>>>>>> for the Sifive gpio IP block.
>>>>>>>
>>>>>>> Cc: Paul Walmsley <paul.walmsley@sifive.com>
>>>>>>> Cc: Rob Herring <robh@kernel.org>
>>>>>>> Cc: devicetree@vger.kernel.org
>>>>>>> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
>>>>>>> ---
>>>>>>>   .../devicetree/bindings/gpio/sifive,gpio.yaml | 21 ++++++++++++++++---
>>>>>>>   1 file changed, 18 insertions(+), 3 deletions(-)
>>>>>>>
>>>>>>> diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>>>> index ab22056f8b44..2cef18ca737c 100644
>>>>>>> --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>>>> +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>>>> @@ -16,6 +16,7 @@ properties:
>>>>>>>         - enum:
>>>>>>>             - sifive,fu540-c000-gpio
>>>>>>>             - sifive,fu740-c000-gpio
>>>>>>> +          - canaan,k210-gpiohs
>>>>>>>         - const: sifive,gpio0
>>>>>>>
>>>>>>>     reg:
>>>>>>> @@ -23,9 +24,9 @@ properties:
>>>>>>>
>>>>>>>     interrupts:
>>>>>>>       description:
>>>>>>> -      interrupt mapping one per GPIO. Maximum 16 GPIOs.
>>>>>>> +      interrupt mapping one per GPIO. Maximum 32 GPIOs.
>>>>>>>       minItems: 1
>>>>>>> -    maxItems: 16
>>>>>>> +    maxItems: 32
>>>>>>>
>>>>>>>     interrupt-controller: true
>>>>>>>
>>>>>>> @@ -38,6 +39,10 @@ properties:
>>>>>>>     "#gpio-cells":
>>>>>>>       const: 2
>>>>>>>
>>>>>>> +  ngpios:
>>>>>>> +    minimum: 1
>>>>>>> +    maximum: 32
>>>>>>
>>>>>> What's the default as obviously drivers already assume something.
>>>>>>
>>>>>> Does a driver actually need to know this? For example, does the
>>>>>> register stride change or something?
>>>>>>
>>>>>> Please don't add it if the only purpose is error check your DT (IOW,
>>>>>> if it just checks the max cell value in gpios phandles).
>>>>>
>>>>> If I remove that, make dtbs_check complains. Looking at othe gpio controller
>>>>> bindings, they all have it. So isn't it better to be consistent, and avoid make
>>>>> dtbs_check errors ?
>>>>
>>>> That would mean you are already using 'ngpios' and it is undocumented
>>>> (for this binding). If already in use and possibly having users then
>>>> that changes things, but that's not what the commit msg says.
>>>>
>>>> Not *all* gpio controllers have ngpios. It's a good number, but
>>>> probably more than need it though. If we wanted it everywhere, there
>>>> would be a schema enforcing that.
>>>
>>> If I remove the minimum and maximum lines, I get this error:
>>
>> I never said remove minimum/maximum. The suggestion is either add
>> 'default: 16' or remove 'ngpios' entirely.
>>
>>> ./Documentation/devicetree/bindings/gpio/sifive,gpio.yaml:42:10: [error] empty
>>> value in block mapping (empty-values)
>>>    CHKDT   Documentation/devicetree/bindings/processed-schema-examples.json
>>> /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
>>> ,gpio.yaml: properties:ngpios: None is not of type 'object', 'boolean'
>>>    SCHEMA  Documentation/devicetree/bindings/processed-schema-examples.json
>>> /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
>>> ,gpio.yaml: ignoring, error in schema: properties: ngpios
>>> warning: no schema found in file:
>>> ./Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>
>> ngpios: true
>>
>> or
>>
>> ngpios: {}
>>
>> Are the minimum valid values for a key. (Though not what should be done here.)
>>
>>>
>>> If I remove the ngpios property entirely, then I get a hit on the device tree:
>>>
>>>    CHECK   arch/riscv/boot/dts/canaan/sipeed_maix_bit.dt.yaml
>>> /linux/arch/riscv/boot/dts/canaan/sipeed_maix_bit.dt.yaml:
>>> gpio-controller@38001000: 'ngpios' does not match any of the regexes: 'pinctrl-
>>> [0-9]+'
>>>          From schema:
>>> /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
>>> ,gpio.yaml
>>
>> That's not upstream, right? Then fix it.
>>
>>> Now, If I change the property definition to this:
>>>
>>> diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>> b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>> index 2cef18ca737c..5c7865180383 100644
>>> --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>> +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>> @@ -40,8 +40,11 @@ properties:
>>>       const: 2
>>>
>>>     ngpios:
>>> -    minimum: 1
>>> -    maximum: 32
>>> +    $ref: /schemas/types.yaml#/definitions/uint32
>>> +    description:
>>> +      The number of GPIO pins implemented by the controller.
>>> +      It is 16 for the SiFive SoCs and 32 for the Canaan K210 SoC.
>>> +
>>>
>>>     gpio-controller: true
>>>
>>> Then all is OK.
>>>
>>> Which option should I go for here ? If we want to avoid a dtbs_check error, as
>>> far as I can see, we can:
>>> 1) Remove the ngpios property and remove its use from the DTS, which is not
>>> nice in my opinion
>>
>> Again, it depends if there are users depending on it. A user being a
>> GPIO driver somewhere, not a DTS file. The GPIO driver in the kernel
>> doesn't need it. So u-boot? BSD?
> 
> The Linux driver uses the number of interrupts for the number of gpios but
> upstream U-Boot uses the ngpios property. So I will change this to use
> "default: 16" as you suggested.

There is no reasonable default for this hardware. I would much rather
you keep the schema as-is, or at least go with the second option.

--Sean

> 
> Thanks !
> 
>>
>>> 2) Use the modification proposed above
> 


^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 07/16] dt-bindings: fix sifive gpio properties
@ 2021-02-05 22:55                 ` Sean Anderson
  0 siblings, 0 replies; 81+ messages in thread
From: Sean Anderson @ 2021-02-05 22:55 UTC (permalink / raw)
  To: Damien Le Moal, robh
  Cc: devicetree, Anup Patel, Atish Patra, palmer, paul.walmsley, linux-riscv

On 2/5/21 5:53 PM, Damien Le Moal wrote:
> On Fri, 2021-02-05 at 14:02 -0600, Rob Herring wrote:
>> On Wed, Feb 3, 2021 at 6:47 PM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
>>>
>>> On Wed, 2021-02-03 at 14:41 -0600, Rob Herring wrote:
>>>> On Wed, Feb 3, 2021 at 6:52 AM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
>>>>>
>>>>> On Tue, 2021-02-02 at 13:02 -0600, Rob Herring wrote:
>>>>>> On Tue, Feb 2, 2021 at 4:36 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
>>>>>>>
>>>>>>> The sifive gpio IP block supports up to 32 GPIOs. Reflect that in the
>>>>>>> interrupts property description and maxItems. Also add the standard
>>>>>>> ngpios property to describe the number of GPIOs available on the
>>>>>>> implementation.
>>>>>>>
>>>>>>> Also add the "canaan,k210-gpiohs" compatible string to indicate the use
>>>>>>> of this gpio controller in the Canaan Kendryte K210 SoC. If this
>>>>>>> compatible string is used, do not define the clocks property as
>>>>>>> required as the K210 SoC does not have a software controllable clock
>>>>>>> for the Sifive gpio IP block.
>>>>>>>
>>>>>>> Cc: Paul Walmsley <paul.walmsley@sifive.com>
>>>>>>> Cc: Rob Herring <robh@kernel.org>
>>>>>>> Cc: devicetree@vger.kernel.org
>>>>>>> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
>>>>>>> ---
>>>>>>>   .../devicetree/bindings/gpio/sifive,gpio.yaml | 21 ++++++++++++++++---
>>>>>>>   1 file changed, 18 insertions(+), 3 deletions(-)
>>>>>>>
>>>>>>> diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>>>> index ab22056f8b44..2cef18ca737c 100644
>>>>>>> --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>>>> +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>>>> @@ -16,6 +16,7 @@ properties:
>>>>>>>         - enum:
>>>>>>>             - sifive,fu540-c000-gpio
>>>>>>>             - sifive,fu740-c000-gpio
>>>>>>> +          - canaan,k210-gpiohs
>>>>>>>         - const: sifive,gpio0
>>>>>>>
>>>>>>>     reg:
>>>>>>> @@ -23,9 +24,9 @@ properties:
>>>>>>>
>>>>>>>     interrupts:
>>>>>>>       description:
>>>>>>> -      interrupt mapping one per GPIO. Maximum 16 GPIOs.
>>>>>>> +      interrupt mapping one per GPIO. Maximum 32 GPIOs.
>>>>>>>       minItems: 1
>>>>>>> -    maxItems: 16
>>>>>>> +    maxItems: 32
>>>>>>>
>>>>>>>     interrupt-controller: true
>>>>>>>
>>>>>>> @@ -38,6 +39,10 @@ properties:
>>>>>>>     "#gpio-cells":
>>>>>>>       const: 2
>>>>>>>
>>>>>>> +  ngpios:
>>>>>>> +    minimum: 1
>>>>>>> +    maximum: 32
>>>>>>
>>>>>> What's the default as obviously drivers already assume something.
>>>>>>
>>>>>> Does a driver actually need to know this? For example, does the
>>>>>> register stride change or something?
>>>>>>
>>>>>> Please don't add it if the only purpose is error check your DT (IOW,
>>>>>> if it just checks the max cell value in gpios phandles).
>>>>>
>>>>> If I remove that, make dtbs_check complains. Looking at othe gpio controller
>>>>> bindings, they all have it. So isn't it better to be consistent, and avoid make
>>>>> dtbs_check errors ?
>>>>
>>>> That would mean you are already using 'ngpios' and it is undocumented
>>>> (for this binding). If already in use and possibly having users then
>>>> that changes things, but that's not what the commit msg says.
>>>>
>>>> Not *all* gpio controllers have ngpios. It's a good number, but
>>>> probably more than need it though. If we wanted it everywhere, there
>>>> would be a schema enforcing that.
>>>
>>> If I remove the minimum and maximum lines, I get this error:
>>
>> I never said remove minimum/maximum. The suggestion is either add
>> 'default: 16' or remove 'ngpios' entirely.
>>
>>> ./Documentation/devicetree/bindings/gpio/sifive,gpio.yaml:42:10: [error] empty
>>> value in block mapping (empty-values)
>>>    CHKDT   Documentation/devicetree/bindings/processed-schema-examples.json
>>> /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
>>> ,gpio.yaml: properties:ngpios: None is not of type 'object', 'boolean'
>>>    SCHEMA  Documentation/devicetree/bindings/processed-schema-examples.json
>>> /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
>>> ,gpio.yaml: ignoring, error in schema: properties: ngpios
>>> warning: no schema found in file:
>>> ./Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>
>> ngpios: true
>>
>> or
>>
>> ngpios: {}
>>
>> Are the minimum valid values for a key. (Though not what should be done here.)
>>
>>>
>>> If I remove the ngpios property entirely, then I get a hit on the device tree:
>>>
>>>    CHECK   arch/riscv/boot/dts/canaan/sipeed_maix_bit.dt.yaml
>>> /linux/arch/riscv/boot/dts/canaan/sipeed_maix_bit.dt.yaml:
>>> gpio-controller@38001000: 'ngpios' does not match any of the regexes: 'pinctrl-
>>> [0-9]+'
>>>          From schema:
>>> /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
>>> ,gpio.yaml
>>
>> That's not upstream, right? Then fix it.
>>
>>> Now, If I change the property definition to this:
>>>
>>> diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>> b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>> index 2cef18ca737c..5c7865180383 100644
>>> --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>> +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>> @@ -40,8 +40,11 @@ properties:
>>>       const: 2
>>>
>>>     ngpios:
>>> -    minimum: 1
>>> -    maximum: 32
>>> +    $ref: /schemas/types.yaml#/definitions/uint32
>>> +    description:
>>> +      The number of GPIO pins implemented by the controller.
>>> +      It is 16 for the SiFive SoCs and 32 for the Canaan K210 SoC.
>>> +
>>>
>>>     gpio-controller: true
>>>
>>> Then all is OK.
>>>
>>> Which option should I go for here ? If we want to avoid a dtbs_check error, as
>>> far as I can see, we can:
>>> 1) Remove the ngpios property and remove its use from the DTS, which is not
>>> nice in my opinion
>>
>> Again, it depends if there are users depending on it. A user being a
>> GPIO driver somewhere, not a DTS file. The GPIO driver in the kernel
>> doesn't need it. So u-boot? BSD?
> 
> The Linux driver uses the number of interrupts for the number of gpios but
> upstream U-Boot uses the ngpios property. So I will change this to use
> "default: 16" as you suggested.

There is no reasonable default for this hardware. I would much rather
you keep the schema as-is, or at least go with the second option.

--Sean

> 
> Thanks !
> 
>>
>>> 2) Use the modification proposed above
> 


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 07/16] dt-bindings: fix sifive gpio properties
  2021-02-05 22:55                 ` Sean Anderson
@ 2021-02-05 23:32                   ` Damien Le Moal
  -1 siblings, 0 replies; 81+ messages in thread
From: Damien Le Moal @ 2021-02-05 23:32 UTC (permalink / raw)
  To: robh, seanga2
  Cc: paul.walmsley, palmer, linux-riscv, Atish Patra, devicetree, Anup Patel

On Fri, 2021-02-05 at 17:55 -0500, Sean Anderson wrote:
> On 2/5/21 5:53 PM, Damien Le Moal wrote:
> > On Fri, 2021-02-05 at 14:02 -0600, Rob Herring wrote:
> > > On Wed, Feb 3, 2021 at 6:47 PM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
> > > > 
> > > > On Wed, 2021-02-03 at 14:41 -0600, Rob Herring wrote:
> > > > > On Wed, Feb 3, 2021 at 6:52 AM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
> > > > > > 
> > > > > > On Tue, 2021-02-02 at 13:02 -0600, Rob Herring wrote:
> > > > > > > On Tue, Feb 2, 2021 at 4:36 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
> > > > > > > > 
> > > > > > > > The sifive gpio IP block supports up to 32 GPIOs. Reflect that in the
> > > > > > > > interrupts property description and maxItems. Also add the standard
> > > > > > > > ngpios property to describe the number of GPIOs available on the
> > > > > > > > implementation.
> > > > > > > > 
> > > > > > > > Also add the "canaan,k210-gpiohs" compatible string to indicate the use
> > > > > > > > of this gpio controller in the Canaan Kendryte K210 SoC. If this
> > > > > > > > compatible string is used, do not define the clocks property as
> > > > > > > > required as the K210 SoC does not have a software controllable clock
> > > > > > > > for the Sifive gpio IP block.
> > > > > > > > 
> > > > > > > > Cc: Paul Walmsley <paul.walmsley@sifive.com>
> > > > > > > > Cc: Rob Herring <robh@kernel.org>
> > > > > > > > Cc: devicetree@vger.kernel.org
> > > > > > > > Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> > > > > > > > ---
> > > > > > > >   .../devicetree/bindings/gpio/sifive,gpio.yaml | 21 ++++++++++++++++---
> > > > > > > >   1 file changed, 18 insertions(+), 3 deletions(-)
> > > > > > > > 
> > > > > > > > diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > > > > > > > index ab22056f8b44..2cef18ca737c 100644
> > > > > > > > --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > > > > > > > +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > > > > > > > @@ -16,6 +16,7 @@ properties:
> > > > > > > >         - enum:
> > > > > > > >             - sifive,fu540-c000-gpio
> > > > > > > >             - sifive,fu740-c000-gpio
> > > > > > > > +          - canaan,k210-gpiohs
> > > > > > > >         - const: sifive,gpio0
> > > > > > > > 
> > > > > > > >     reg:
> > > > > > > > @@ -23,9 +24,9 @@ properties:
> > > > > > > > 
> > > > > > > >     interrupts:
> > > > > > > >       description:
> > > > > > > > -      interrupt mapping one per GPIO. Maximum 16 GPIOs.
> > > > > > > > +      interrupt mapping one per GPIO. Maximum 32 GPIOs.
> > > > > > > >       minItems: 1
> > > > > > > > -    maxItems: 16
> > > > > > > > +    maxItems: 32
> > > > > > > > 
> > > > > > > >     interrupt-controller: true
> > > > > > > > 
> > > > > > > > @@ -38,6 +39,10 @@ properties:
> > > > > > > >     "#gpio-cells":
> > > > > > > >       const: 2
> > > > > > > > 
> > > > > > > > +  ngpios:
> > > > > > > > +    minimum: 1
> > > > > > > > +    maximum: 32
> > > > > > > 
> > > > > > > What's the default as obviously drivers already assume something.
> > > > > > > 
> > > > > > > Does a driver actually need to know this? For example, does the
> > > > > > > register stride change or something?
> > > > > > > 
> > > > > > > Please don't add it if the only purpose is error check your DT (IOW,
> > > > > > > if it just checks the max cell value in gpios phandles).
> > > > > > 
> > > > > > If I remove that, make dtbs_check complains. Looking at othe gpio controller
> > > > > > bindings, they all have it. So isn't it better to be consistent, and avoid make
> > > > > > dtbs_check errors ?
> > > > > 
> > > > > That would mean you are already using 'ngpios' and it is undocumented
> > > > > (for this binding). If already in use and possibly having users then
> > > > > that changes things, but that's not what the commit msg says.
> > > > > 
> > > > > Not *all* gpio controllers have ngpios. It's a good number, but
> > > > > probably more than need it though. If we wanted it everywhere, there
> > > > > would be a schema enforcing that.
> > > > 
> > > > If I remove the minimum and maximum lines, I get this error:
> > > 
> > > I never said remove minimum/maximum. The suggestion is either add
> > > 'default: 16' or remove 'ngpios' entirely.
> > > 
> > > > ./Documentation/devicetree/bindings/gpio/sifive,gpio.yaml:42:10: [error] empty
> > > > value in block mapping (empty-values)
> > > >    CHKDT   Documentation/devicetree/bindings/processed-schema-examples.json
> > > > /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
> > > > ,gpio.yaml: properties:ngpios: None is not of type 'object', 'boolean'
> > > >    SCHEMA  Documentation/devicetree/bindings/processed-schema-examples.json
> > > > /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
> > > > ,gpio.yaml: ignoring, error in schema: properties: ngpios
> > > > warning: no schema found in file:
> > > > ./Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > > 
> > > ngpios: true
> > > 
> > > or
> > > 
> > > ngpios: {}
> > > 
> > > Are the minimum valid values for a key. (Though not what should be done here.)
> > > 
> > > > 
> > > > If I remove the ngpios property entirely, then I get a hit on the device tree:
> > > > 
> > > >    CHECK   arch/riscv/boot/dts/canaan/sipeed_maix_bit.dt.yaml
> > > > /linux/arch/riscv/boot/dts/canaan/sipeed_maix_bit.dt.yaml:
> > > > gpio-controller@38001000: 'ngpios' does not match any of the regexes: 'pinctrl-
> > > > [0-9]+'
> > > >          From schema:
> > > > /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
> > > > ,gpio.yaml
> > > 
> > > That's not upstream, right? Then fix it.
> > > 
> > > > Now, If I change the property definition to this:
> > > > 
> > > > diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > > > b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > > > index 2cef18ca737c..5c7865180383 100644
> > > > --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > > > +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > > > @@ -40,8 +40,11 @@ properties:
> > > >       const: 2
> > > > 
> > > >     ngpios:
> > > > -    minimum: 1
> > > > -    maximum: 32
> > > > +    $ref: /schemas/types.yaml#/definitions/uint32
> > > > +    description:
> > > > +      The number of GPIO pins implemented by the controller.
> > > > +      It is 16 for the SiFive SoCs and 32 for the Canaan K210 SoC.
> > > > +
> > > > 
> > > >     gpio-controller: true
> > > > 
> > > > Then all is OK.
> > > > 
> > > > Which option should I go for here ? If we want to avoid a dtbs_check error, as
> > > > far as I can see, we can:
> > > > 1) Remove the ngpios property and remove its use from the DTS, which is not
> > > > nice in my opinion
> > > 
> > > Again, it depends if there are users depending on it. A user being a
> > > GPIO driver somewhere, not a DTS file. The GPIO driver in the kernel
> > > doesn't need it. So u-boot? BSD?
> > 
> > The Linux driver uses the number of interrupts for the number of gpios but
> > upstream U-Boot uses the ngpios property. So I will change this to use
> > "default: 16" as you suggested.
> 
> There is no reasonable default for this hardware. I would much rather
> you keep the schema as-is, or at least go with the second option.

Since the SiFive official doc seems to say "16" as the number of gpio for this
controller, we could assume that to be the default. No ? But I agree that
clearly, the implementation can be hacked to have any number of GPIOs...


> 
> --Sean
> 
> > 
> > Thanks !
> > 
> > > 
> > > > 2) Use the modification proposed above
> > 
> 

-- 
Damien Le Moal
Western Digital Research


^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 07/16] dt-bindings: fix sifive gpio properties
@ 2021-02-05 23:32                   ` Damien Le Moal
  0 siblings, 0 replies; 81+ messages in thread
From: Damien Le Moal @ 2021-02-05 23:32 UTC (permalink / raw)
  To: robh, seanga2
  Cc: devicetree, Anup Patel, Atish Patra, palmer, paul.walmsley, linux-riscv

On Fri, 2021-02-05 at 17:55 -0500, Sean Anderson wrote:
> On 2/5/21 5:53 PM, Damien Le Moal wrote:
> > On Fri, 2021-02-05 at 14:02 -0600, Rob Herring wrote:
> > > On Wed, Feb 3, 2021 at 6:47 PM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
> > > > 
> > > > On Wed, 2021-02-03 at 14:41 -0600, Rob Herring wrote:
> > > > > On Wed, Feb 3, 2021 at 6:52 AM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
> > > > > > 
> > > > > > On Tue, 2021-02-02 at 13:02 -0600, Rob Herring wrote:
> > > > > > > On Tue, Feb 2, 2021 at 4:36 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
> > > > > > > > 
> > > > > > > > The sifive gpio IP block supports up to 32 GPIOs. Reflect that in the
> > > > > > > > interrupts property description and maxItems. Also add the standard
> > > > > > > > ngpios property to describe the number of GPIOs available on the
> > > > > > > > implementation.
> > > > > > > > 
> > > > > > > > Also add the "canaan,k210-gpiohs" compatible string to indicate the use
> > > > > > > > of this gpio controller in the Canaan Kendryte K210 SoC. If this
> > > > > > > > compatible string is used, do not define the clocks property as
> > > > > > > > required as the K210 SoC does not have a software controllable clock
> > > > > > > > for the Sifive gpio IP block.
> > > > > > > > 
> > > > > > > > Cc: Paul Walmsley <paul.walmsley@sifive.com>
> > > > > > > > Cc: Rob Herring <robh@kernel.org>
> > > > > > > > Cc: devicetree@vger.kernel.org
> > > > > > > > Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> > > > > > > > ---
> > > > > > > >   .../devicetree/bindings/gpio/sifive,gpio.yaml | 21 ++++++++++++++++---
> > > > > > > >   1 file changed, 18 insertions(+), 3 deletions(-)
> > > > > > > > 
> > > > > > > > diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > > > > > > > index ab22056f8b44..2cef18ca737c 100644
> > > > > > > > --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > > > > > > > +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > > > > > > > @@ -16,6 +16,7 @@ properties:
> > > > > > > >         - enum:
> > > > > > > >             - sifive,fu540-c000-gpio
> > > > > > > >             - sifive,fu740-c000-gpio
> > > > > > > > +          - canaan,k210-gpiohs
> > > > > > > >         - const: sifive,gpio0
> > > > > > > > 
> > > > > > > >     reg:
> > > > > > > > @@ -23,9 +24,9 @@ properties:
> > > > > > > > 
> > > > > > > >     interrupts:
> > > > > > > >       description:
> > > > > > > > -      interrupt mapping one per GPIO. Maximum 16 GPIOs.
> > > > > > > > +      interrupt mapping one per GPIO. Maximum 32 GPIOs.
> > > > > > > >       minItems: 1
> > > > > > > > -    maxItems: 16
> > > > > > > > +    maxItems: 32
> > > > > > > > 
> > > > > > > >     interrupt-controller: true
> > > > > > > > 
> > > > > > > > @@ -38,6 +39,10 @@ properties:
> > > > > > > >     "#gpio-cells":
> > > > > > > >       const: 2
> > > > > > > > 
> > > > > > > > +  ngpios:
> > > > > > > > +    minimum: 1
> > > > > > > > +    maximum: 32
> > > > > > > 
> > > > > > > What's the default as obviously drivers already assume something.
> > > > > > > 
> > > > > > > Does a driver actually need to know this? For example, does the
> > > > > > > register stride change or something?
> > > > > > > 
> > > > > > > Please don't add it if the only purpose is error check your DT (IOW,
> > > > > > > if it just checks the max cell value in gpios phandles).
> > > > > > 
> > > > > > If I remove that, make dtbs_check complains. Looking at othe gpio controller
> > > > > > bindings, they all have it. So isn't it better to be consistent, and avoid make
> > > > > > dtbs_check errors ?
> > > > > 
> > > > > That would mean you are already using 'ngpios' and it is undocumented
> > > > > (for this binding). If already in use and possibly having users then
> > > > > that changes things, but that's not what the commit msg says.
> > > > > 
> > > > > Not *all* gpio controllers have ngpios. It's a good number, but
> > > > > probably more than need it though. If we wanted it everywhere, there
> > > > > would be a schema enforcing that.
> > > > 
> > > > If I remove the minimum and maximum lines, I get this error:
> > > 
> > > I never said remove minimum/maximum. The suggestion is either add
> > > 'default: 16' or remove 'ngpios' entirely.
> > > 
> > > > ./Documentation/devicetree/bindings/gpio/sifive,gpio.yaml:42:10: [error] empty
> > > > value in block mapping (empty-values)
> > > >    CHKDT   Documentation/devicetree/bindings/processed-schema-examples.json
> > > > /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
> > > > ,gpio.yaml: properties:ngpios: None is not of type 'object', 'boolean'
> > > >    SCHEMA  Documentation/devicetree/bindings/processed-schema-examples.json
> > > > /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
> > > > ,gpio.yaml: ignoring, error in schema: properties: ngpios
> > > > warning: no schema found in file:
> > > > ./Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > > 
> > > ngpios: true
> > > 
> > > or
> > > 
> > > ngpios: {}
> > > 
> > > Are the minimum valid values for a key. (Though not what should be done here.)
> > > 
> > > > 
> > > > If I remove the ngpios property entirely, then I get a hit on the device tree:
> > > > 
> > > >    CHECK   arch/riscv/boot/dts/canaan/sipeed_maix_bit.dt.yaml
> > > > /linux/arch/riscv/boot/dts/canaan/sipeed_maix_bit.dt.yaml:
> > > > gpio-controller@38001000: 'ngpios' does not match any of the regexes: 'pinctrl-
> > > > [0-9]+'
> > > >          From schema:
> > > > /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
> > > > ,gpio.yaml
> > > 
> > > That's not upstream, right? Then fix it.
> > > 
> > > > Now, If I change the property definition to this:
> > > > 
> > > > diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > > > b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > > > index 2cef18ca737c..5c7865180383 100644
> > > > --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > > > +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> > > > @@ -40,8 +40,11 @@ properties:
> > > >       const: 2
> > > > 
> > > >     ngpios:
> > > > -    minimum: 1
> > > > -    maximum: 32
> > > > +    $ref: /schemas/types.yaml#/definitions/uint32
> > > > +    description:
> > > > +      The number of GPIO pins implemented by the controller.
> > > > +      It is 16 for the SiFive SoCs and 32 for the Canaan K210 SoC.
> > > > +
> > > > 
> > > >     gpio-controller: true
> > > > 
> > > > Then all is OK.
> > > > 
> > > > Which option should I go for here ? If we want to avoid a dtbs_check error, as
> > > > far as I can see, we can:
> > > > 1) Remove the ngpios property and remove its use from the DTS, which is not
> > > > nice in my opinion
> > > 
> > > Again, it depends if there are users depending on it. A user being a
> > > GPIO driver somewhere, not a DTS file. The GPIO driver in the kernel
> > > doesn't need it. So u-boot? BSD?
> > 
> > The Linux driver uses the number of interrupts for the number of gpios but
> > upstream U-Boot uses the ngpios property. So I will change this to use
> > "default: 16" as you suggested.
> 
> There is no reasonable default for this hardware. I would much rather
> you keep the schema as-is, or at least go with the second option.

Since the SiFive official doc seems to say "16" as the number of gpio for this
controller, we could assume that to be the default. No ? But I agree that
clearly, the implementation can be hacked to have any number of GPIOs...


> 
> --Sean
> 
> > 
> > Thanks !
> > 
> > > 
> > > > 2) Use the modification proposed above
> > 
> 

-- 
Damien Le Moal
Western Digital Research

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 07/16] dt-bindings: fix sifive gpio properties
  2021-02-05 23:32                   ` Damien Le Moal
@ 2021-02-06  0:31                     ` Sean Anderson
  -1 siblings, 0 replies; 81+ messages in thread
From: Sean Anderson @ 2021-02-06  0:31 UTC (permalink / raw)
  To: Damien Le Moal, robh
  Cc: paul.walmsley, palmer, linux-riscv, Atish Patra, devicetree, Anup Patel

On 2/5/21 6:32 PM, Damien Le Moal wrote:
> On Fri, 2021-02-05 at 17:55 -0500, Sean Anderson wrote:
>> On 2/5/21 5:53 PM, Damien Le Moal wrote:
>>> On Fri, 2021-02-05 at 14:02 -0600, Rob Herring wrote:
>>>> On Wed, Feb 3, 2021 at 6:47 PM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
>>>>>
>>>>> On Wed, 2021-02-03 at 14:41 -0600, Rob Herring wrote:
>>>>>> On Wed, Feb 3, 2021 at 6:52 AM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
>>>>>>>
>>>>>>> On Tue, 2021-02-02 at 13:02 -0600, Rob Herring wrote:
>>>>>>>> On Tue, Feb 2, 2021 at 4:36 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
>>>>>>>>>
>>>>>>>>> The sifive gpio IP block supports up to 32 GPIOs. Reflect that in the
>>>>>>>>> interrupts property description and maxItems. Also add the standard
>>>>>>>>> ngpios property to describe the number of GPIOs available on the
>>>>>>>>> implementation.
>>>>>>>>>
>>>>>>>>> Also add the "canaan,k210-gpiohs" compatible string to indicate the use
>>>>>>>>> of this gpio controller in the Canaan Kendryte K210 SoC. If this
>>>>>>>>> compatible string is used, do not define the clocks property as
>>>>>>>>> required as the K210 SoC does not have a software controllable clock
>>>>>>>>> for the Sifive gpio IP block.
>>>>>>>>>
>>>>>>>>> Cc: Paul Walmsley <paul.walmsley@sifive.com>
>>>>>>>>> Cc: Rob Herring <robh@kernel.org>
>>>>>>>>> Cc: devicetree@vger.kernel.org
>>>>>>>>> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
>>>>>>>>> ---
>>>>>>>>>    .../devicetree/bindings/gpio/sifive,gpio.yaml | 21 ++++++++++++++++---
>>>>>>>>>    1 file changed, 18 insertions(+), 3 deletions(-)
>>>>>>>>>
>>>>>>>>> diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>>>>>> index ab22056f8b44..2cef18ca737c 100644
>>>>>>>>> --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>>>>>> +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>>>>>> @@ -16,6 +16,7 @@ properties:
>>>>>>>>>          - enum:
>>>>>>>>>              - sifive,fu540-c000-gpio
>>>>>>>>>              - sifive,fu740-c000-gpio
>>>>>>>>> +          - canaan,k210-gpiohs
>>>>>>>>>          - const: sifive,gpio0
>>>>>>>>>
>>>>>>>>>      reg:
>>>>>>>>> @@ -23,9 +24,9 @@ properties:
>>>>>>>>>
>>>>>>>>>      interrupts:
>>>>>>>>>        description:
>>>>>>>>> -      interrupt mapping one per GPIO. Maximum 16 GPIOs.
>>>>>>>>> +      interrupt mapping one per GPIO. Maximum 32 GPIOs.
>>>>>>>>>        minItems: 1
>>>>>>>>> -    maxItems: 16
>>>>>>>>> +    maxItems: 32
>>>>>>>>>
>>>>>>>>>      interrupt-controller: true
>>>>>>>>>
>>>>>>>>> @@ -38,6 +39,10 @@ properties:
>>>>>>>>>      "#gpio-cells":
>>>>>>>>>        const: 2
>>>>>>>>>
>>>>>>>>> +  ngpios:
>>>>>>>>> +    minimum: 1
>>>>>>>>> +    maximum: 32
>>>>>>>>
>>>>>>>> What's the default as obviously drivers already assume something.
>>>>>>>>
>>>>>>>> Does a driver actually need to know this? For example, does the
>>>>>>>> register stride change or something?
>>>>>>>>
>>>>>>>> Please don't add it if the only purpose is error check your DT (IOW,
>>>>>>>> if it just checks the max cell value in gpios phandles).
>>>>>>>
>>>>>>> If I remove that, make dtbs_check complains. Looking at othe gpio controller
>>>>>>> bindings, they all have it. So isn't it better to be consistent, and avoid make
>>>>>>> dtbs_check errors ?
>>>>>>
>>>>>> That would mean you are already using 'ngpios' and it is undocumented
>>>>>> (for this binding). If already in use and possibly having users then
>>>>>> that changes things, but that's not what the commit msg says.
>>>>>>
>>>>>> Not *all* gpio controllers have ngpios. It's a good number, but
>>>>>> probably more than need it though. If we wanted it everywhere, there
>>>>>> would be a schema enforcing that.
>>>>>
>>>>> If I remove the minimum and maximum lines, I get this error:
>>>>
>>>> I never said remove minimum/maximum. The suggestion is either add
>>>> 'default: 16' or remove 'ngpios' entirely.
>>>>
>>>>> ./Documentation/devicetree/bindings/gpio/sifive,gpio.yaml:42:10: [error] empty
>>>>> value in block mapping (empty-values)
>>>>>     CHKDT   Documentation/devicetree/bindings/processed-schema-examples.json
>>>>> /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
>>>>> ,gpio.yaml: properties:ngpios: None is not of type 'object', 'boolean'
>>>>>     SCHEMA  Documentation/devicetree/bindings/processed-schema-examples.json
>>>>> /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
>>>>> ,gpio.yaml: ignoring, error in schema: properties: ngpios
>>>>> warning: no schema found in file:
>>>>> ./Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>
>>>> ngpios: true
>>>>
>>>> or
>>>>
>>>> ngpios: {}
>>>>
>>>> Are the minimum valid values for a key. (Though not what should be done here.)
>>>>
>>>>>
>>>>> If I remove the ngpios property entirely, then I get a hit on the device tree:
>>>>>
>>>>>     CHECK   arch/riscv/boot/dts/canaan/sipeed_maix_bit.dt.yaml
>>>>> /linux/arch/riscv/boot/dts/canaan/sipeed_maix_bit.dt.yaml:
>>>>> gpio-controller@38001000: 'ngpios' does not match any of the regexes: 'pinctrl-
>>>>> [0-9]+'
>>>>>           From schema:
>>>>> /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
>>>>> ,gpio.yaml
>>>>
>>>> That's not upstream, right? Then fix it.
>>>>
>>>>> Now, If I change the property definition to this:
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>> b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>> index 2cef18ca737c..5c7865180383 100644
>>>>> --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>> +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>> @@ -40,8 +40,11 @@ properties:
>>>>>        const: 2
>>>>>
>>>>>      ngpios:
>>>>> -    minimum: 1
>>>>> -    maximum: 32
>>>>> +    $ref: /schemas/types.yaml#/definitions/uint32
>>>>> +    description:
>>>>> +      The number of GPIO pins implemented by the controller.
>>>>> +      It is 16 for the SiFive SoCs and 32 for the Canaan K210 SoC.
>>>>> +
>>>>>
>>>>>      gpio-controller: true
>>>>>
>>>>> Then all is OK.
>>>>>
>>>>> Which option should I go for here ? If we want to avoid a dtbs_check error, as
>>>>> far as I can see, we can:
>>>>> 1) Remove the ngpios property and remove its use from the DTS, which is not
>>>>> nice in my opinion
>>>>
>>>> Again, it depends if there are users depending on it. A user being a
>>>> GPIO driver somewhere, not a DTS file. The GPIO driver in the kernel
>>>> doesn't need it. So u-boot? BSD?
>>>
>>> The Linux driver uses the number of interrupts for the number of gpios but
>>> upstream U-Boot uses the ngpios property. So I will change this to use
>>> "default: 16" as you suggested.
>>
>> There is no reasonable default for this hardware. I would much rather
>> you keep the schema as-is, or at least go with the second option.
> 
> Since the SiFive official doc seems to say "16" as the number of gpio for this
> controller, we could assume that to be the default. No ? But I agree that
> clearly, the implementation can be hacked to have any number of GPIOs...

Keep in mind that those docs are for SiFive's particular instantiation
of that IP, not for the IP in general. Although some parameters (e.g.
dsWidth) have defaults, width does not.

--Sean

> 
> 
>>
>> --Sean
>>
>>>
>>> Thanks !
>>>
>>>>
>>>>> 2) Use the modification proposed above
>>>
>>
> 


^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 07/16] dt-bindings: fix sifive gpio properties
@ 2021-02-06  0:31                     ` Sean Anderson
  0 siblings, 0 replies; 81+ messages in thread
From: Sean Anderson @ 2021-02-06  0:31 UTC (permalink / raw)
  To: Damien Le Moal, robh
  Cc: devicetree, Anup Patel, Atish Patra, palmer, paul.walmsley, linux-riscv

On 2/5/21 6:32 PM, Damien Le Moal wrote:
> On Fri, 2021-02-05 at 17:55 -0500, Sean Anderson wrote:
>> On 2/5/21 5:53 PM, Damien Le Moal wrote:
>>> On Fri, 2021-02-05 at 14:02 -0600, Rob Herring wrote:
>>>> On Wed, Feb 3, 2021 at 6:47 PM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
>>>>>
>>>>> On Wed, 2021-02-03 at 14:41 -0600, Rob Herring wrote:
>>>>>> On Wed, Feb 3, 2021 at 6:52 AM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
>>>>>>>
>>>>>>> On Tue, 2021-02-02 at 13:02 -0600, Rob Herring wrote:
>>>>>>>> On Tue, Feb 2, 2021 at 4:36 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
>>>>>>>>>
>>>>>>>>> The sifive gpio IP block supports up to 32 GPIOs. Reflect that in the
>>>>>>>>> interrupts property description and maxItems. Also add the standard
>>>>>>>>> ngpios property to describe the number of GPIOs available on the
>>>>>>>>> implementation.
>>>>>>>>>
>>>>>>>>> Also add the "canaan,k210-gpiohs" compatible string to indicate the use
>>>>>>>>> of this gpio controller in the Canaan Kendryte K210 SoC. If this
>>>>>>>>> compatible string is used, do not define the clocks property as
>>>>>>>>> required as the K210 SoC does not have a software controllable clock
>>>>>>>>> for the Sifive gpio IP block.
>>>>>>>>>
>>>>>>>>> Cc: Paul Walmsley <paul.walmsley@sifive.com>
>>>>>>>>> Cc: Rob Herring <robh@kernel.org>
>>>>>>>>> Cc: devicetree@vger.kernel.org
>>>>>>>>> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
>>>>>>>>> ---
>>>>>>>>>    .../devicetree/bindings/gpio/sifive,gpio.yaml | 21 ++++++++++++++++---
>>>>>>>>>    1 file changed, 18 insertions(+), 3 deletions(-)
>>>>>>>>>
>>>>>>>>> diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>>>>>> index ab22056f8b44..2cef18ca737c 100644
>>>>>>>>> --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>>>>>> +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>>>>>> @@ -16,6 +16,7 @@ properties:
>>>>>>>>>          - enum:
>>>>>>>>>              - sifive,fu540-c000-gpio
>>>>>>>>>              - sifive,fu740-c000-gpio
>>>>>>>>> +          - canaan,k210-gpiohs
>>>>>>>>>          - const: sifive,gpio0
>>>>>>>>>
>>>>>>>>>      reg:
>>>>>>>>> @@ -23,9 +24,9 @@ properties:
>>>>>>>>>
>>>>>>>>>      interrupts:
>>>>>>>>>        description:
>>>>>>>>> -      interrupt mapping one per GPIO. Maximum 16 GPIOs.
>>>>>>>>> +      interrupt mapping one per GPIO. Maximum 32 GPIOs.
>>>>>>>>>        minItems: 1
>>>>>>>>> -    maxItems: 16
>>>>>>>>> +    maxItems: 32
>>>>>>>>>
>>>>>>>>>      interrupt-controller: true
>>>>>>>>>
>>>>>>>>> @@ -38,6 +39,10 @@ properties:
>>>>>>>>>      "#gpio-cells":
>>>>>>>>>        const: 2
>>>>>>>>>
>>>>>>>>> +  ngpios:
>>>>>>>>> +    minimum: 1
>>>>>>>>> +    maximum: 32
>>>>>>>>
>>>>>>>> What's the default as obviously drivers already assume something.
>>>>>>>>
>>>>>>>> Does a driver actually need to know this? For example, does the
>>>>>>>> register stride change or something?
>>>>>>>>
>>>>>>>> Please don't add it if the only purpose is error check your DT (IOW,
>>>>>>>> if it just checks the max cell value in gpios phandles).
>>>>>>>
>>>>>>> If I remove that, make dtbs_check complains. Looking at othe gpio controller
>>>>>>> bindings, they all have it. So isn't it better to be consistent, and avoid make
>>>>>>> dtbs_check errors ?
>>>>>>
>>>>>> That would mean you are already using 'ngpios' and it is undocumented
>>>>>> (for this binding). If already in use and possibly having users then
>>>>>> that changes things, but that's not what the commit msg says.
>>>>>>
>>>>>> Not *all* gpio controllers have ngpios. It's a good number, but
>>>>>> probably more than need it though. If we wanted it everywhere, there
>>>>>> would be a schema enforcing that.
>>>>>
>>>>> If I remove the minimum and maximum lines, I get this error:
>>>>
>>>> I never said remove minimum/maximum. The suggestion is either add
>>>> 'default: 16' or remove 'ngpios' entirely.
>>>>
>>>>> ./Documentation/devicetree/bindings/gpio/sifive,gpio.yaml:42:10: [error] empty
>>>>> value in block mapping (empty-values)
>>>>>     CHKDT   Documentation/devicetree/bindings/processed-schema-examples.json
>>>>> /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
>>>>> ,gpio.yaml: properties:ngpios: None is not of type 'object', 'boolean'
>>>>>     SCHEMA  Documentation/devicetree/bindings/processed-schema-examples.json
>>>>> /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
>>>>> ,gpio.yaml: ignoring, error in schema: properties: ngpios
>>>>> warning: no schema found in file:
>>>>> ./Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>
>>>> ngpios: true
>>>>
>>>> or
>>>>
>>>> ngpios: {}
>>>>
>>>> Are the minimum valid values for a key. (Though not what should be done here.)
>>>>
>>>>>
>>>>> If I remove the ngpios property entirely, then I get a hit on the device tree:
>>>>>
>>>>>     CHECK   arch/riscv/boot/dts/canaan/sipeed_maix_bit.dt.yaml
>>>>> /linux/arch/riscv/boot/dts/canaan/sipeed_maix_bit.dt.yaml:
>>>>> gpio-controller@38001000: 'ngpios' does not match any of the regexes: 'pinctrl-
>>>>> [0-9]+'
>>>>>           From schema:
>>>>> /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
>>>>> ,gpio.yaml
>>>>
>>>> That's not upstream, right? Then fix it.
>>>>
>>>>> Now, If I change the property definition to this:
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>> b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>> index 2cef18ca737c..5c7865180383 100644
>>>>> --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>> +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>> @@ -40,8 +40,11 @@ properties:
>>>>>        const: 2
>>>>>
>>>>>      ngpios:
>>>>> -    minimum: 1
>>>>> -    maximum: 32
>>>>> +    $ref: /schemas/types.yaml#/definitions/uint32
>>>>> +    description:
>>>>> +      The number of GPIO pins implemented by the controller.
>>>>> +      It is 16 for the SiFive SoCs and 32 for the Canaan K210 SoC.
>>>>> +
>>>>>
>>>>>      gpio-controller: true
>>>>>
>>>>> Then all is OK.
>>>>>
>>>>> Which option should I go for here ? If we want to avoid a dtbs_check error, as
>>>>> far as I can see, we can:
>>>>> 1) Remove the ngpios property and remove its use from the DTS, which is not
>>>>> nice in my opinion
>>>>
>>>> Again, it depends if there are users depending on it. A user being a
>>>> GPIO driver somewhere, not a DTS file. The GPIO driver in the kernel
>>>> doesn't need it. So u-boot? BSD?
>>>
>>> The Linux driver uses the number of interrupts for the number of gpios but
>>> upstream U-Boot uses the ngpios property. So I will change this to use
>>> "default: 16" as you suggested.
>>
>> There is no reasonable default for this hardware. I would much rather
>> you keep the schema as-is, or at least go with the second option.
> 
> Since the SiFive official doc seems to say "16" as the number of gpio for this
> controller, we could assume that to be the default. No ? But I agree that
> clearly, the implementation can be hacked to have any number of GPIOs...

Keep in mind that those docs are for SiFive's particular instantiation
of that IP, not for the IP in general. Although some parameters (e.g.
dsWidth) have defaults, width does not.

--Sean

> 
> 
>>
>> --Sean
>>
>>>
>>> Thanks !
>>>
>>>>
>>>>> 2) Use the modification proposed above
>>>
>>
> 


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 07/16] dt-bindings: fix sifive gpio properties
  2021-02-06  0:31                     ` Sean Anderson
@ 2021-02-06  0:52                       ` Damien Le Moal
  -1 siblings, 0 replies; 81+ messages in thread
From: Damien Le Moal @ 2021-02-06  0:52 UTC (permalink / raw)
  To: Sean Anderson, robh
  Cc: paul.walmsley, palmer, linux-riscv, Atish Patra, devicetree, Anup Patel

On 2021/02/06 9:31, Sean Anderson wrote:
> On 2/5/21 6:32 PM, Damien Le Moal wrote:
>> On Fri, 2021-02-05 at 17:55 -0500, Sean Anderson wrote:
>>> On 2/5/21 5:53 PM, Damien Le Moal wrote:
>>>> On Fri, 2021-02-05 at 14:02 -0600, Rob Herring wrote:
>>>>> On Wed, Feb 3, 2021 at 6:47 PM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
>>>>>>
>>>>>> On Wed, 2021-02-03 at 14:41 -0600, Rob Herring wrote:
>>>>>>> On Wed, Feb 3, 2021 at 6:52 AM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
>>>>>>>>
>>>>>>>> On Tue, 2021-02-02 at 13:02 -0600, Rob Herring wrote:
>>>>>>>>> On Tue, Feb 2, 2021 at 4:36 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
>>>>>>>>>>
>>>>>>>>>> The sifive gpio IP block supports up to 32 GPIOs. Reflect that in the
>>>>>>>>>> interrupts property description and maxItems. Also add the standard
>>>>>>>>>> ngpios property to describe the number of GPIOs available on the
>>>>>>>>>> implementation.
>>>>>>>>>>
>>>>>>>>>> Also add the "canaan,k210-gpiohs" compatible string to indicate the use
>>>>>>>>>> of this gpio controller in the Canaan Kendryte K210 SoC. If this
>>>>>>>>>> compatible string is used, do not define the clocks property as
>>>>>>>>>> required as the K210 SoC does not have a software controllable clock
>>>>>>>>>> for the Sifive gpio IP block.
>>>>>>>>>>
>>>>>>>>>> Cc: Paul Walmsley <paul.walmsley@sifive.com>
>>>>>>>>>> Cc: Rob Herring <robh@kernel.org>
>>>>>>>>>> Cc: devicetree@vger.kernel.org
>>>>>>>>>> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
>>>>>>>>>> ---
>>>>>>>>>>    .../devicetree/bindings/gpio/sifive,gpio.yaml | 21 ++++++++++++++++---
>>>>>>>>>>    1 file changed, 18 insertions(+), 3 deletions(-)
>>>>>>>>>>
>>>>>>>>>> diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>>>>>>> index ab22056f8b44..2cef18ca737c 100644
>>>>>>>>>> --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>>>>>>> +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>>>>>>> @@ -16,6 +16,7 @@ properties:
>>>>>>>>>>          - enum:
>>>>>>>>>>              - sifive,fu540-c000-gpio
>>>>>>>>>>              - sifive,fu740-c000-gpio
>>>>>>>>>> +          - canaan,k210-gpiohs
>>>>>>>>>>          - const: sifive,gpio0
>>>>>>>>>>
>>>>>>>>>>      reg:
>>>>>>>>>> @@ -23,9 +24,9 @@ properties:
>>>>>>>>>>
>>>>>>>>>>      interrupts:
>>>>>>>>>>        description:
>>>>>>>>>> -      interrupt mapping one per GPIO. Maximum 16 GPIOs.
>>>>>>>>>> +      interrupt mapping one per GPIO. Maximum 32 GPIOs.
>>>>>>>>>>        minItems: 1
>>>>>>>>>> -    maxItems: 16
>>>>>>>>>> +    maxItems: 32
>>>>>>>>>>
>>>>>>>>>>      interrupt-controller: true
>>>>>>>>>>
>>>>>>>>>> @@ -38,6 +39,10 @@ properties:
>>>>>>>>>>      "#gpio-cells":
>>>>>>>>>>        const: 2
>>>>>>>>>>
>>>>>>>>>> +  ngpios:
>>>>>>>>>> +    minimum: 1
>>>>>>>>>> +    maximum: 32
>>>>>>>>>
>>>>>>>>> What's the default as obviously drivers already assume something.
>>>>>>>>>
>>>>>>>>> Does a driver actually need to know this? For example, does the
>>>>>>>>> register stride change or something?
>>>>>>>>>
>>>>>>>>> Please don't add it if the only purpose is error check your DT (IOW,
>>>>>>>>> if it just checks the max cell value in gpios phandles).
>>>>>>>>
>>>>>>>> If I remove that, make dtbs_check complains. Looking at othe gpio controller
>>>>>>>> bindings, they all have it. So isn't it better to be consistent, and avoid make
>>>>>>>> dtbs_check errors ?
>>>>>>>
>>>>>>> That would mean you are already using 'ngpios' and it is undocumented
>>>>>>> (for this binding). If already in use and possibly having users then
>>>>>>> that changes things, but that's not what the commit msg says.
>>>>>>>
>>>>>>> Not *all* gpio controllers have ngpios. It's a good number, but
>>>>>>> probably more than need it though. If we wanted it everywhere, there
>>>>>>> would be a schema enforcing that.
>>>>>>
>>>>>> If I remove the minimum and maximum lines, I get this error:
>>>>>
>>>>> I never said remove minimum/maximum. The suggestion is either add
>>>>> 'default: 16' or remove 'ngpios' entirely.
>>>>>
>>>>>> ./Documentation/devicetree/bindings/gpio/sifive,gpio.yaml:42:10: [error] empty
>>>>>> value in block mapping (empty-values)
>>>>>>     CHKDT   Documentation/devicetree/bindings/processed-schema-examples.json
>>>>>> /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
>>>>>> ,gpio.yaml: properties:ngpios: None is not of type 'object', 'boolean'
>>>>>>     SCHEMA  Documentation/devicetree/bindings/processed-schema-examples.json
>>>>>> /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
>>>>>> ,gpio.yaml: ignoring, error in schema: properties: ngpios
>>>>>> warning: no schema found in file:
>>>>>> ./Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>>
>>>>> ngpios: true
>>>>>
>>>>> or
>>>>>
>>>>> ngpios: {}
>>>>>
>>>>> Are the minimum valid values for a key. (Though not what should be done here.)
>>>>>
>>>>>>
>>>>>> If I remove the ngpios property entirely, then I get a hit on the device tree:
>>>>>>
>>>>>>     CHECK   arch/riscv/boot/dts/canaan/sipeed_maix_bit.dt.yaml
>>>>>> /linux/arch/riscv/boot/dts/canaan/sipeed_maix_bit.dt.yaml:
>>>>>> gpio-controller@38001000: 'ngpios' does not match any of the regexes: 'pinctrl-
>>>>>> [0-9]+'
>>>>>>           From schema:
>>>>>> /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
>>>>>> ,gpio.yaml
>>>>>
>>>>> That's not upstream, right? Then fix it.
>>>>>
>>>>>> Now, If I change the property definition to this:
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>>> b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>>> index 2cef18ca737c..5c7865180383 100644
>>>>>> --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>>> +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>>> @@ -40,8 +40,11 @@ properties:
>>>>>>        const: 2
>>>>>>
>>>>>>      ngpios:
>>>>>> -    minimum: 1
>>>>>> -    maximum: 32
>>>>>> +    $ref: /schemas/types.yaml#/definitions/uint32
>>>>>> +    description:
>>>>>> +      The number of GPIO pins implemented by the controller.
>>>>>> +      It is 16 for the SiFive SoCs and 32 for the Canaan K210 SoC.
>>>>>> +
>>>>>>
>>>>>>      gpio-controller: true
>>>>>>
>>>>>> Then all is OK.
>>>>>>
>>>>>> Which option should I go for here ? If we want to avoid a dtbs_check error, as
>>>>>> far as I can see, we can:
>>>>>> 1) Remove the ngpios property and remove its use from the DTS, which is not
>>>>>> nice in my opinion
>>>>>
>>>>> Again, it depends if there are users depending on it. A user being a
>>>>> GPIO driver somewhere, not a DTS file. The GPIO driver in the kernel
>>>>> doesn't need it. So u-boot? BSD?
>>>>
>>>> The Linux driver uses the number of interrupts for the number of gpios but
>>>> upstream U-Boot uses the ngpios property. So I will change this to use
>>>> "default: 16" as you suggested.
>>>
>>> There is no reasonable default for this hardware. I would much rather
>>> you keep the schema as-is, or at least go with the second option.
>>
>> Since the SiFive official doc seems to say "16" as the number of gpio for this
>> controller, we could assume that to be the default. No ? But I agree that
>> clearly, the implementation can be hacked to have any number of GPIOs...
> 
> Keep in mind that those docs are for SiFive's particular instantiation
> of that IP, not for the IP in general. Although some parameters (e.g.
> dsWidth) have defaults, width does not.

OK. Then I think the simplest is to keep the minimum/maximum. Many binding docs
use that anyway.

Rob, any objections ?


> 
> --Sean
> 
>>
>>
>>>
>>> --Sean
>>>
>>>>
>>>> Thanks !
>>>>
>>>>>
>>>>>> 2) Use the modification proposed above
>>>>
>>>
>>
> 
> 


-- 
Damien Le Moal
Western Digital Research

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 07/16] dt-bindings: fix sifive gpio properties
@ 2021-02-06  0:52                       ` Damien Le Moal
  0 siblings, 0 replies; 81+ messages in thread
From: Damien Le Moal @ 2021-02-06  0:52 UTC (permalink / raw)
  To: Sean Anderson, robh
  Cc: devicetree, Anup Patel, Atish Patra, palmer, paul.walmsley, linux-riscv

On 2021/02/06 9:31, Sean Anderson wrote:
> On 2/5/21 6:32 PM, Damien Le Moal wrote:
>> On Fri, 2021-02-05 at 17:55 -0500, Sean Anderson wrote:
>>> On 2/5/21 5:53 PM, Damien Le Moal wrote:
>>>> On Fri, 2021-02-05 at 14:02 -0600, Rob Herring wrote:
>>>>> On Wed, Feb 3, 2021 at 6:47 PM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
>>>>>>
>>>>>> On Wed, 2021-02-03 at 14:41 -0600, Rob Herring wrote:
>>>>>>> On Wed, Feb 3, 2021 at 6:52 AM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
>>>>>>>>
>>>>>>>> On Tue, 2021-02-02 at 13:02 -0600, Rob Herring wrote:
>>>>>>>>> On Tue, Feb 2, 2021 at 4:36 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
>>>>>>>>>>
>>>>>>>>>> The sifive gpio IP block supports up to 32 GPIOs. Reflect that in the
>>>>>>>>>> interrupts property description and maxItems. Also add the standard
>>>>>>>>>> ngpios property to describe the number of GPIOs available on the
>>>>>>>>>> implementation.
>>>>>>>>>>
>>>>>>>>>> Also add the "canaan,k210-gpiohs" compatible string to indicate the use
>>>>>>>>>> of this gpio controller in the Canaan Kendryte K210 SoC. If this
>>>>>>>>>> compatible string is used, do not define the clocks property as
>>>>>>>>>> required as the K210 SoC does not have a software controllable clock
>>>>>>>>>> for the Sifive gpio IP block.
>>>>>>>>>>
>>>>>>>>>> Cc: Paul Walmsley <paul.walmsley@sifive.com>
>>>>>>>>>> Cc: Rob Herring <robh@kernel.org>
>>>>>>>>>> Cc: devicetree@vger.kernel.org
>>>>>>>>>> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
>>>>>>>>>> ---
>>>>>>>>>>    .../devicetree/bindings/gpio/sifive,gpio.yaml | 21 ++++++++++++++++---
>>>>>>>>>>    1 file changed, 18 insertions(+), 3 deletions(-)
>>>>>>>>>>
>>>>>>>>>> diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>>>>>>> index ab22056f8b44..2cef18ca737c 100644
>>>>>>>>>> --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>>>>>>> +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>>>>>>> @@ -16,6 +16,7 @@ properties:
>>>>>>>>>>          - enum:
>>>>>>>>>>              - sifive,fu540-c000-gpio
>>>>>>>>>>              - sifive,fu740-c000-gpio
>>>>>>>>>> +          - canaan,k210-gpiohs
>>>>>>>>>>          - const: sifive,gpio0
>>>>>>>>>>
>>>>>>>>>>      reg:
>>>>>>>>>> @@ -23,9 +24,9 @@ properties:
>>>>>>>>>>
>>>>>>>>>>      interrupts:
>>>>>>>>>>        description:
>>>>>>>>>> -      interrupt mapping one per GPIO. Maximum 16 GPIOs.
>>>>>>>>>> +      interrupt mapping one per GPIO. Maximum 32 GPIOs.
>>>>>>>>>>        minItems: 1
>>>>>>>>>> -    maxItems: 16
>>>>>>>>>> +    maxItems: 32
>>>>>>>>>>
>>>>>>>>>>      interrupt-controller: true
>>>>>>>>>>
>>>>>>>>>> @@ -38,6 +39,10 @@ properties:
>>>>>>>>>>      "#gpio-cells":
>>>>>>>>>>        const: 2
>>>>>>>>>>
>>>>>>>>>> +  ngpios:
>>>>>>>>>> +    minimum: 1
>>>>>>>>>> +    maximum: 32
>>>>>>>>>
>>>>>>>>> What's the default as obviously drivers already assume something.
>>>>>>>>>
>>>>>>>>> Does a driver actually need to know this? For example, does the
>>>>>>>>> register stride change or something?
>>>>>>>>>
>>>>>>>>> Please don't add it if the only purpose is error check your DT (IOW,
>>>>>>>>> if it just checks the max cell value in gpios phandles).
>>>>>>>>
>>>>>>>> If I remove that, make dtbs_check complains. Looking at othe gpio controller
>>>>>>>> bindings, they all have it. So isn't it better to be consistent, and avoid make
>>>>>>>> dtbs_check errors ?
>>>>>>>
>>>>>>> That would mean you are already using 'ngpios' and it is undocumented
>>>>>>> (for this binding). If already in use and possibly having users then
>>>>>>> that changes things, but that's not what the commit msg says.
>>>>>>>
>>>>>>> Not *all* gpio controllers have ngpios. It's a good number, but
>>>>>>> probably more than need it though. If we wanted it everywhere, there
>>>>>>> would be a schema enforcing that.
>>>>>>
>>>>>> If I remove the minimum and maximum lines, I get this error:
>>>>>
>>>>> I never said remove minimum/maximum. The suggestion is either add
>>>>> 'default: 16' or remove 'ngpios' entirely.
>>>>>
>>>>>> ./Documentation/devicetree/bindings/gpio/sifive,gpio.yaml:42:10: [error] empty
>>>>>> value in block mapping (empty-values)
>>>>>>     CHKDT   Documentation/devicetree/bindings/processed-schema-examples.json
>>>>>> /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
>>>>>> ,gpio.yaml: properties:ngpios: None is not of type 'object', 'boolean'
>>>>>>     SCHEMA  Documentation/devicetree/bindings/processed-schema-examples.json
>>>>>> /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
>>>>>> ,gpio.yaml: ignoring, error in schema: properties: ngpios
>>>>>> warning: no schema found in file:
>>>>>> ./Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>>
>>>>> ngpios: true
>>>>>
>>>>> or
>>>>>
>>>>> ngpios: {}
>>>>>
>>>>> Are the minimum valid values for a key. (Though not what should be done here.)
>>>>>
>>>>>>
>>>>>> If I remove the ngpios property entirely, then I get a hit on the device tree:
>>>>>>
>>>>>>     CHECK   arch/riscv/boot/dts/canaan/sipeed_maix_bit.dt.yaml
>>>>>> /linux/arch/riscv/boot/dts/canaan/sipeed_maix_bit.dt.yaml:
>>>>>> gpio-controller@38001000: 'ngpios' does not match any of the regexes: 'pinctrl-
>>>>>> [0-9]+'
>>>>>>           From schema:
>>>>>> /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
>>>>>> ,gpio.yaml
>>>>>
>>>>> That's not upstream, right? Then fix it.
>>>>>
>>>>>> Now, If I change the property definition to this:
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>>> b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>>> index 2cef18ca737c..5c7865180383 100644
>>>>>> --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>>> +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
>>>>>> @@ -40,8 +40,11 @@ properties:
>>>>>>        const: 2
>>>>>>
>>>>>>      ngpios:
>>>>>> -    minimum: 1
>>>>>> -    maximum: 32
>>>>>> +    $ref: /schemas/types.yaml#/definitions/uint32
>>>>>> +    description:
>>>>>> +      The number of GPIO pins implemented by the controller.
>>>>>> +      It is 16 for the SiFive SoCs and 32 for the Canaan K210 SoC.
>>>>>> +
>>>>>>
>>>>>>      gpio-controller: true
>>>>>>
>>>>>> Then all is OK.
>>>>>>
>>>>>> Which option should I go for here ? If we want to avoid a dtbs_check error, as
>>>>>> far as I can see, we can:
>>>>>> 1) Remove the ngpios property and remove its use from the DTS, which is not
>>>>>> nice in my opinion
>>>>>
>>>>> Again, it depends if there are users depending on it. A user being a
>>>>> GPIO driver somewhere, not a DTS file. The GPIO driver in the kernel
>>>>> doesn't need it. So u-boot? BSD?
>>>>
>>>> The Linux driver uses the number of interrupts for the number of gpios but
>>>> upstream U-Boot uses the ngpios property. So I will change this to use
>>>> "default: 16" as you suggested.
>>>
>>> There is no reasonable default for this hardware. I would much rather
>>> you keep the schema as-is, or at least go with the second option.
>>
>> Since the SiFive official doc seems to say "16" as the number of gpio for this
>> controller, we could assume that to be the default. No ? But I agree that
>> clearly, the implementation can be hacked to have any number of GPIOs...
> 
> Keep in mind that those docs are for SiFive's particular instantiation
> of that IP, not for the IP in general. Although some parameters (e.g.
> dsWidth) have defaults, width does not.

OK. Then I think the simplest is to keep the minimum/maximum. Many binding docs
use that anyway.

Rob, any objections ?


> 
> --Sean
> 
>>
>>
>>>
>>> --Sean
>>>
>>>>
>>>> Thanks !
>>>>
>>>>>
>>>>>> 2) Use the modification proposed above
>>>>
>>>
>>
> 
> 


-- 
Damien Le Moal
Western Digital Research

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 07/16] dt-bindings: fix sifive gpio properties
  2021-02-06  0:52                       ` Damien Le Moal
@ 2021-02-07 17:37                         ` Rob Herring
  -1 siblings, 0 replies; 81+ messages in thread
From: Rob Herring @ 2021-02-07 17:37 UTC (permalink / raw)
  To: Damien Le Moal
  Cc: Sean Anderson, paul.walmsley, palmer, linux-riscv, Atish Patra,
	devicetree, Anup Patel

On Fri, Feb 5, 2021 at 6:52 PM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
>
> On 2021/02/06 9:31, Sean Anderson wrote:
> > On 2/5/21 6:32 PM, Damien Le Moal wrote:
> >> On Fri, 2021-02-05 at 17:55 -0500, Sean Anderson wrote:
> >>> On 2/5/21 5:53 PM, Damien Le Moal wrote:
> >>>> On Fri, 2021-02-05 at 14:02 -0600, Rob Herring wrote:
> >>>>> On Wed, Feb 3, 2021 at 6:47 PM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
> >>>>>>
> >>>>>> On Wed, 2021-02-03 at 14:41 -0600, Rob Herring wrote:
> >>>>>>> On Wed, Feb 3, 2021 at 6:52 AM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
> >>>>>>>>
> >>>>>>>> On Tue, 2021-02-02 at 13:02 -0600, Rob Herring wrote:
> >>>>>>>>> On Tue, Feb 2, 2021 at 4:36 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
> >>>>>>>>>>
> >>>>>>>>>> The sifive gpio IP block supports up to 32 GPIOs. Reflect that in the
> >>>>>>>>>> interrupts property description and maxItems. Also add the standard
> >>>>>>>>>> ngpios property to describe the number of GPIOs available on the
> >>>>>>>>>> implementation.
> >>>>>>>>>>
> >>>>>>>>>> Also add the "canaan,k210-gpiohs" compatible string to indicate the use
> >>>>>>>>>> of this gpio controller in the Canaan Kendryte K210 SoC. If this
> >>>>>>>>>> compatible string is used, do not define the clocks property as
> >>>>>>>>>> required as the K210 SoC does not have a software controllable clock
> >>>>>>>>>> for the Sifive gpio IP block.
> >>>>>>>>>>
> >>>>>>>>>> Cc: Paul Walmsley <paul.walmsley@sifive.com>
> >>>>>>>>>> Cc: Rob Herring <robh@kernel.org>
> >>>>>>>>>> Cc: devicetree@vger.kernel.org
> >>>>>>>>>> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> >>>>>>>>>> ---
> >>>>>>>>>>    .../devicetree/bindings/gpio/sifive,gpio.yaml | 21 ++++++++++++++++---
> >>>>>>>>>>    1 file changed, 18 insertions(+), 3 deletions(-)
> >>>>>>>>>>
> >>>>>>>>>> diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> >>>>>>>>>> index ab22056f8b44..2cef18ca737c 100644
> >>>>>>>>>> --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> >>>>>>>>>> +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> >>>>>>>>>> @@ -16,6 +16,7 @@ properties:
> >>>>>>>>>>          - enum:
> >>>>>>>>>>              - sifive,fu540-c000-gpio
> >>>>>>>>>>              - sifive,fu740-c000-gpio
> >>>>>>>>>> +          - canaan,k210-gpiohs
> >>>>>>>>>>          - const: sifive,gpio0
> >>>>>>>>>>
> >>>>>>>>>>      reg:
> >>>>>>>>>> @@ -23,9 +24,9 @@ properties:
> >>>>>>>>>>
> >>>>>>>>>>      interrupts:
> >>>>>>>>>>        description:
> >>>>>>>>>> -      interrupt mapping one per GPIO. Maximum 16 GPIOs.
> >>>>>>>>>> +      interrupt mapping one per GPIO. Maximum 32 GPIOs.
> >>>>>>>>>>        minItems: 1
> >>>>>>>>>> -    maxItems: 16
> >>>>>>>>>> +    maxItems: 32
> >>>>>>>>>>
> >>>>>>>>>>      interrupt-controller: true
> >>>>>>>>>>
> >>>>>>>>>> @@ -38,6 +39,10 @@ properties:
> >>>>>>>>>>      "#gpio-cells":
> >>>>>>>>>>        const: 2
> >>>>>>>>>>
> >>>>>>>>>> +  ngpios:
> >>>>>>>>>> +    minimum: 1
> >>>>>>>>>> +    maximum: 32
> >>>>>>>>>
> >>>>>>>>> What's the default as obviously drivers already assume something.
> >>>>>>>>>
> >>>>>>>>> Does a driver actually need to know this? For example, does the
> >>>>>>>>> register stride change or something?
> >>>>>>>>>
> >>>>>>>>> Please don't add it if the only purpose is error check your DT (IOW,
> >>>>>>>>> if it just checks the max cell value in gpios phandles).
> >>>>>>>>
> >>>>>>>> If I remove that, make dtbs_check complains. Looking at othe gpio controller
> >>>>>>>> bindings, they all have it. So isn't it better to be consistent, and avoid make
> >>>>>>>> dtbs_check errors ?
> >>>>>>>
> >>>>>>> That would mean you are already using 'ngpios' and it is undocumented
> >>>>>>> (for this binding). If already in use and possibly having users then
> >>>>>>> that changes things, but that's not what the commit msg says.
> >>>>>>>
> >>>>>>> Not *all* gpio controllers have ngpios. It's a good number, but
> >>>>>>> probably more than need it though. If we wanted it everywhere, there
> >>>>>>> would be a schema enforcing that.
> >>>>>>
> >>>>>> If I remove the minimum and maximum lines, I get this error:
> >>>>>
> >>>>> I never said remove minimum/maximum. The suggestion is either add
> >>>>> 'default: 16' or remove 'ngpios' entirely.
> >>>>>
> >>>>>> ./Documentation/devicetree/bindings/gpio/sifive,gpio.yaml:42:10: [error] empty
> >>>>>> value in block mapping (empty-values)
> >>>>>>     CHKDT   Documentation/devicetree/bindings/processed-schema-examples.json
> >>>>>> /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
> >>>>>> ,gpio.yaml: properties:ngpios: None is not of type 'object', 'boolean'
> >>>>>>     SCHEMA  Documentation/devicetree/bindings/processed-schema-examples.json
> >>>>>> /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
> >>>>>> ,gpio.yaml: ignoring, error in schema: properties: ngpios
> >>>>>> warning: no schema found in file:
> >>>>>> ./Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> >>>>>
> >>>>> ngpios: true
> >>>>>
> >>>>> or
> >>>>>
> >>>>> ngpios: {}
> >>>>>
> >>>>> Are the minimum valid values for a key. (Though not what should be done here.)
> >>>>>
> >>>>>>
> >>>>>> If I remove the ngpios property entirely, then I get a hit on the device tree:
> >>>>>>
> >>>>>>     CHECK   arch/riscv/boot/dts/canaan/sipeed_maix_bit.dt.yaml
> >>>>>> /linux/arch/riscv/boot/dts/canaan/sipeed_maix_bit.dt.yaml:
> >>>>>> gpio-controller@38001000: 'ngpios' does not match any of the regexes: 'pinctrl-
> >>>>>> [0-9]+'
> >>>>>>           From schema:
> >>>>>> /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
> >>>>>> ,gpio.yaml
> >>>>>
> >>>>> That's not upstream, right? Then fix it.
> >>>>>
> >>>>>> Now, If I change the property definition to this:
> >>>>>>
> >>>>>> diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> >>>>>> b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> >>>>>> index 2cef18ca737c..5c7865180383 100644
> >>>>>> --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> >>>>>> +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> >>>>>> @@ -40,8 +40,11 @@ properties:
> >>>>>>        const: 2
> >>>>>>
> >>>>>>      ngpios:
> >>>>>> -    minimum: 1
> >>>>>> -    maximum: 32
> >>>>>> +    $ref: /schemas/types.yaml#/definitions/uint32
> >>>>>> +    description:
> >>>>>> +      The number of GPIO pins implemented by the controller.
> >>>>>> +      It is 16 for the SiFive SoCs and 32 for the Canaan K210 SoC.
> >>>>>> +
> >>>>>>
> >>>>>>      gpio-controller: true
> >>>>>>
> >>>>>> Then all is OK.
> >>>>>>
> >>>>>> Which option should I go for here ? If we want to avoid a dtbs_check error, as
> >>>>>> far as I can see, we can:
> >>>>>> 1) Remove the ngpios property and remove its use from the DTS, which is not
> >>>>>> nice in my opinion
> >>>>>
> >>>>> Again, it depends if there are users depending on it. A user being a
> >>>>> GPIO driver somewhere, not a DTS file. The GPIO driver in the kernel
> >>>>> doesn't need it. So u-boot? BSD?
> >>>>
> >>>> The Linux driver uses the number of interrupts for the number of gpios but
> >>>> upstream U-Boot uses the ngpios property. So I will change this to use
> >>>> "default: 16" as you suggested.
> >>>
> >>> There is no reasonable default for this hardware. I would much rather
> >>> you keep the schema as-is, or at least go with the second option.
> >>
> >> Since the SiFive official doc seems to say "16" as the number of gpio for this
> >> controller, we could assume that to be the default. No ? But I agree that
> >> clearly, the implementation can be hacked to have any number of GPIOs...

Yes, 'default' is simply what a driver should assume if the property
is not present. Drivers had to assume something already, right? Or
simply the value doesn't matter as I've suggested.

> > Keep in mind that those docs are for SiFive's particular instantiation
> > of that IP, not for the IP in general. Although some parameters (e.g.
> > dsWidth) have defaults, width does not.
>
> OK. Then I think the simplest is to keep the minimum/maximum. Many binding docs
> use that anyway.

Either that or an enum is required IMO.

32 is clearly the max here or the register layout would have to change.

Rob

^ permalink raw reply	[flat|nested] 81+ messages in thread

* Re: [PATCH v14 07/16] dt-bindings: fix sifive gpio properties
@ 2021-02-07 17:37                         ` Rob Herring
  0 siblings, 0 replies; 81+ messages in thread
From: Rob Herring @ 2021-02-07 17:37 UTC (permalink / raw)
  To: Damien Le Moal
  Cc: devicetree, Anup Patel, Sean Anderson, Atish Patra, palmer,
	paul.walmsley, linux-riscv

On Fri, Feb 5, 2021 at 6:52 PM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
>
> On 2021/02/06 9:31, Sean Anderson wrote:
> > On 2/5/21 6:32 PM, Damien Le Moal wrote:
> >> On Fri, 2021-02-05 at 17:55 -0500, Sean Anderson wrote:
> >>> On 2/5/21 5:53 PM, Damien Le Moal wrote:
> >>>> On Fri, 2021-02-05 at 14:02 -0600, Rob Herring wrote:
> >>>>> On Wed, Feb 3, 2021 at 6:47 PM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
> >>>>>>
> >>>>>> On Wed, 2021-02-03 at 14:41 -0600, Rob Herring wrote:
> >>>>>>> On Wed, Feb 3, 2021 at 6:52 AM Damien Le Moal <Damien.LeMoal@wdc.com> wrote:
> >>>>>>>>
> >>>>>>>> On Tue, 2021-02-02 at 13:02 -0600, Rob Herring wrote:
> >>>>>>>>> On Tue, Feb 2, 2021 at 4:36 AM Damien Le Moal <damien.lemoal@wdc.com> wrote:
> >>>>>>>>>>
> >>>>>>>>>> The sifive gpio IP block supports up to 32 GPIOs. Reflect that in the
> >>>>>>>>>> interrupts property description and maxItems. Also add the standard
> >>>>>>>>>> ngpios property to describe the number of GPIOs available on the
> >>>>>>>>>> implementation.
> >>>>>>>>>>
> >>>>>>>>>> Also add the "canaan,k210-gpiohs" compatible string to indicate the use
> >>>>>>>>>> of this gpio controller in the Canaan Kendryte K210 SoC. If this
> >>>>>>>>>> compatible string is used, do not define the clocks property as
> >>>>>>>>>> required as the K210 SoC does not have a software controllable clock
> >>>>>>>>>> for the Sifive gpio IP block.
> >>>>>>>>>>
> >>>>>>>>>> Cc: Paul Walmsley <paul.walmsley@sifive.com>
> >>>>>>>>>> Cc: Rob Herring <robh@kernel.org>
> >>>>>>>>>> Cc: devicetree@vger.kernel.org
> >>>>>>>>>> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> >>>>>>>>>> ---
> >>>>>>>>>>    .../devicetree/bindings/gpio/sifive,gpio.yaml | 21 ++++++++++++++++---
> >>>>>>>>>>    1 file changed, 18 insertions(+), 3 deletions(-)
> >>>>>>>>>>
> >>>>>>>>>> diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> >>>>>>>>>> index ab22056f8b44..2cef18ca737c 100644
> >>>>>>>>>> --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> >>>>>>>>>> +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> >>>>>>>>>> @@ -16,6 +16,7 @@ properties:
> >>>>>>>>>>          - enum:
> >>>>>>>>>>              - sifive,fu540-c000-gpio
> >>>>>>>>>>              - sifive,fu740-c000-gpio
> >>>>>>>>>> +          - canaan,k210-gpiohs
> >>>>>>>>>>          - const: sifive,gpio0
> >>>>>>>>>>
> >>>>>>>>>>      reg:
> >>>>>>>>>> @@ -23,9 +24,9 @@ properties:
> >>>>>>>>>>
> >>>>>>>>>>      interrupts:
> >>>>>>>>>>        description:
> >>>>>>>>>> -      interrupt mapping one per GPIO. Maximum 16 GPIOs.
> >>>>>>>>>> +      interrupt mapping one per GPIO. Maximum 32 GPIOs.
> >>>>>>>>>>        minItems: 1
> >>>>>>>>>> -    maxItems: 16
> >>>>>>>>>> +    maxItems: 32
> >>>>>>>>>>
> >>>>>>>>>>      interrupt-controller: true
> >>>>>>>>>>
> >>>>>>>>>> @@ -38,6 +39,10 @@ properties:
> >>>>>>>>>>      "#gpio-cells":
> >>>>>>>>>>        const: 2
> >>>>>>>>>>
> >>>>>>>>>> +  ngpios:
> >>>>>>>>>> +    minimum: 1
> >>>>>>>>>> +    maximum: 32
> >>>>>>>>>
> >>>>>>>>> What's the default as obviously drivers already assume something.
> >>>>>>>>>
> >>>>>>>>> Does a driver actually need to know this? For example, does the
> >>>>>>>>> register stride change or something?
> >>>>>>>>>
> >>>>>>>>> Please don't add it if the only purpose is error check your DT (IOW,
> >>>>>>>>> if it just checks the max cell value in gpios phandles).
> >>>>>>>>
> >>>>>>>> If I remove that, make dtbs_check complains. Looking at othe gpio controller
> >>>>>>>> bindings, they all have it. So isn't it better to be consistent, and avoid make
> >>>>>>>> dtbs_check errors ?
> >>>>>>>
> >>>>>>> That would mean you are already using 'ngpios' and it is undocumented
> >>>>>>> (for this binding). If already in use and possibly having users then
> >>>>>>> that changes things, but that's not what the commit msg says.
> >>>>>>>
> >>>>>>> Not *all* gpio controllers have ngpios. It's a good number, but
> >>>>>>> probably more than need it though. If we wanted it everywhere, there
> >>>>>>> would be a schema enforcing that.
> >>>>>>
> >>>>>> If I remove the minimum and maximum lines, I get this error:
> >>>>>
> >>>>> I never said remove minimum/maximum. The suggestion is either add
> >>>>> 'default: 16' or remove 'ngpios' entirely.
> >>>>>
> >>>>>> ./Documentation/devicetree/bindings/gpio/sifive,gpio.yaml:42:10: [error] empty
> >>>>>> value in block mapping (empty-values)
> >>>>>>     CHKDT   Documentation/devicetree/bindings/processed-schema-examples.json
> >>>>>> /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
> >>>>>> ,gpio.yaml: properties:ngpios: None is not of type 'object', 'boolean'
> >>>>>>     SCHEMA  Documentation/devicetree/bindings/processed-schema-examples.json
> >>>>>> /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
> >>>>>> ,gpio.yaml: ignoring, error in schema: properties: ngpios
> >>>>>> warning: no schema found in file:
> >>>>>> ./Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> >>>>>
> >>>>> ngpios: true
> >>>>>
> >>>>> or
> >>>>>
> >>>>> ngpios: {}
> >>>>>
> >>>>> Are the minimum valid values for a key. (Though not what should be done here.)
> >>>>>
> >>>>>>
> >>>>>> If I remove the ngpios property entirely, then I get a hit on the device tree:
> >>>>>>
> >>>>>>     CHECK   arch/riscv/boot/dts/canaan/sipeed_maix_bit.dt.yaml
> >>>>>> /linux/arch/riscv/boot/dts/canaan/sipeed_maix_bit.dt.yaml:
> >>>>>> gpio-controller@38001000: 'ngpios' does not match any of the regexes: 'pinctrl-
> >>>>>> [0-9]+'
> >>>>>>           From schema:
> >>>>>> /home/damien/Projects/RISCV/linux/Documentation/devicetree/bindings/gpio/sifive
> >>>>>> ,gpio.yaml
> >>>>>
> >>>>> That's not upstream, right? Then fix it.
> >>>>>
> >>>>>> Now, If I change the property definition to this:
> >>>>>>
> >>>>>> diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> >>>>>> b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> >>>>>> index 2cef18ca737c..5c7865180383 100644
> >>>>>> --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> >>>>>> +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
> >>>>>> @@ -40,8 +40,11 @@ properties:
> >>>>>>        const: 2
> >>>>>>
> >>>>>>      ngpios:
> >>>>>> -    minimum: 1
> >>>>>> -    maximum: 32
> >>>>>> +    $ref: /schemas/types.yaml#/definitions/uint32
> >>>>>> +    description:
> >>>>>> +      The number of GPIO pins implemented by the controller.
> >>>>>> +      It is 16 for the SiFive SoCs and 32 for the Canaan K210 SoC.
> >>>>>> +
> >>>>>>
> >>>>>>      gpio-controller: true
> >>>>>>
> >>>>>> Then all is OK.
> >>>>>>
> >>>>>> Which option should I go for here ? If we want to avoid a dtbs_check error, as
> >>>>>> far as I can see, we can:
> >>>>>> 1) Remove the ngpios property and remove its use from the DTS, which is not
> >>>>>> nice in my opinion
> >>>>>
> >>>>> Again, it depends if there are users depending on it. A user being a
> >>>>> GPIO driver somewhere, not a DTS file. The GPIO driver in the kernel
> >>>>> doesn't need it. So u-boot? BSD?
> >>>>
> >>>> The Linux driver uses the number of interrupts for the number of gpios but
> >>>> upstream U-Boot uses the ngpios property. So I will change this to use
> >>>> "default: 16" as you suggested.
> >>>
> >>> There is no reasonable default for this hardware. I would much rather
> >>> you keep the schema as-is, or at least go with the second option.
> >>
> >> Since the SiFive official doc seems to say "16" as the number of gpio for this
> >> controller, we could assume that to be the default. No ? But I agree that
> >> clearly, the implementation can be hacked to have any number of GPIOs...

Yes, 'default' is simply what a driver should assume if the property
is not present. Drivers had to assume something already, right? Or
simply the value doesn't matter as I've suggested.

> > Keep in mind that those docs are for SiFive's particular instantiation
> > of that IP, not for the IP in general. Although some parameters (e.g.
> > dsWidth) have defaults, width does not.
>
> OK. Then I think the simplest is to keep the minimum/maximum. Many binding docs
> use that anyway.

Either that or an enum is required IMO.

32 is clearly the max here or the register layout would have to change.

Rob

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 81+ messages in thread

end of thread, other threads:[~2021-02-07 17:38 UTC | newest]

Thread overview: 81+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-02 10:36 [PATCH v14 00/16] RISC-V Kendryte K210 support improvements Damien Le Moal
2021-02-02 10:36 ` [PATCH v14 01/16] clk: Add RISC-V Canaan Kendryte K210 clock driver Damien Le Moal
2021-02-02 10:36   ` Damien Le Moal
2021-02-02 10:36 ` [PATCH v14 02/16] dt-bindings: add Canaan boards compatible strings Damien Le Moal
2021-02-02 10:36   ` Damien Le Moal
2021-02-02 17:55   ` Atish Patra
2021-02-02 17:55     ` Atish Patra
2021-02-02 10:36 ` [PATCH v14 03/16] dt-bindings: update risc-v cpu properties Damien Le Moal
2021-02-02 10:36   ` Damien Le Moal
2021-02-02 17:54   ` Atish Patra
2021-02-02 17:54     ` Atish Patra
2021-02-02 10:36 ` [PATCH v14 04/16] dt-bindings: update sifive plic compatible string Damien Le Moal
2021-02-02 10:36   ` Damien Le Moal
2021-02-02 18:26   ` Atish Patra
2021-02-02 18:26     ` Atish Patra
2021-02-03 12:38     ` Damien Le Moal
2021-02-03 12:38       ` Damien Le Moal
2021-02-02 10:36 ` [PATCH v14 05/16] dt-bindings: update sifive clint " Damien Le Moal
2021-02-02 10:36   ` Damien Le Moal
2021-02-02 17:52   ` Atish Patra
2021-02-02 17:52     ` Atish Patra
2021-02-02 10:36 ` [PATCH v14 06/16] dt-bindings: update sifive uart " Damien Le Moal
2021-02-02 10:36   ` Damien Le Moal
2021-02-02 18:27   ` Atish Patra
2021-02-02 18:27     ` Atish Patra
2021-02-02 10:36 ` [PATCH v14 07/16] dt-bindings: fix sifive gpio properties Damien Le Moal
2021-02-02 10:36   ` Damien Le Moal
2021-02-02 18:45   ` Atish Patra
2021-02-02 18:45     ` Atish Patra
2021-02-02 23:54     ` Sean Anderson
2021-02-02 23:54       ` Sean Anderson
2021-02-02 19:02   ` Rob Herring
2021-02-02 19:02     ` Rob Herring
2021-02-03  0:01     ` Sean Anderson
2021-02-03  0:01       ` Sean Anderson
2021-02-03 20:23       ` Rob Herring
2021-02-03 20:23         ` Rob Herring
2021-02-03 23:13         ` Sean Anderson
2021-02-03 23:13           ` Sean Anderson
2021-02-03 12:52     ` Damien Le Moal
2021-02-03 12:52       ` Damien Le Moal
2021-02-03 20:41       ` Rob Herring
2021-02-03 20:41         ` Rob Herring
2021-02-04  0:47         ` Damien Le Moal
2021-02-04  0:47           ` Damien Le Moal
2021-02-05  0:29           ` Damien Le Moal
2021-02-05  0:29             ` Damien Le Moal
2021-02-05 20:02           ` Rob Herring
2021-02-05 20:02             ` Rob Herring
2021-02-05 22:53             ` Damien Le Moal
2021-02-05 22:53               ` Damien Le Moal
2021-02-05 22:55               ` Sean Anderson
2021-02-05 22:55                 ` Sean Anderson
2021-02-05 23:32                 ` Damien Le Moal
2021-02-05 23:32                   ` Damien Le Moal
2021-02-06  0:31                   ` Sean Anderson
2021-02-06  0:31                     ` Sean Anderson
2021-02-06  0:52                     ` Damien Le Moal
2021-02-06  0:52                       ` Damien Le Moal
2021-02-07 17:37                       ` Rob Herring
2021-02-07 17:37                         ` Rob Herring
2021-02-02 10:36 ` [PATCH v14 08/16] dt-bindings: add resets property to dw-apb-timer Damien Le Moal
2021-02-02 10:36   ` Damien Le Moal
2021-02-02 18:45   ` Atish Patra
2021-02-02 18:45     ` Atish Patra
2021-02-02 10:36 ` [PATCH v14 09/16] riscv: Update Canaan Kendryte K210 device tree Damien Le Moal
2021-02-02 10:36   ` Damien Le Moal
2021-02-02 10:36 ` [PATCH v14 10/16] riscv: Add SiPeed MAIX BiT board " Damien Le Moal
2021-02-02 10:36   ` Damien Le Moal
2021-02-02 10:36 ` [PATCH v14 11/16] riscv: Add SiPeed MAIX DOCK " Damien Le Moal
2021-02-02 10:36   ` Damien Le Moal
2021-02-02 10:36 ` [PATCH v14 12/16] riscv: Add SiPeed MAIX GO " Damien Le Moal
2021-02-02 10:36   ` Damien Le Moal
2021-02-02 10:36 ` [PATCH v14 13/16] riscv: Add SiPeed MAIXDUINO " Damien Le Moal
2021-02-02 10:36   ` Damien Le Moal
2021-02-02 10:36 ` [PATCH v14 14/16] riscv: Add Kendryte KD233 " Damien Le Moal
2021-02-02 10:36   ` Damien Le Moal
2021-02-02 10:36 ` [PATCH v14 15/16] riscv: Update Canaan Kendryte K210 defconfig Damien Le Moal
2021-02-02 18:49   ` Atish Patra
2021-02-02 10:36 ` [PATCH v14 16/16] riscv: Add Canaan Kendryte K210 SD card defconfig Damien Le Moal
2021-02-02 18:48   ` Atish Patra

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.