* [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
* 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
* [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
* 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
* [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
* 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 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
* [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
* 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
* [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
* 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
* [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
* 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 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 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 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 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 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-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 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: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
* [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
* 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
* [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
* 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
* [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 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